Say Hello to OAuth 2.0

OAuth2.0 is the de facto standard in access delegation. There are many articles available that discuss OAuth, but I am writing this to simply explain OAuth 2.0 concepts to those still struggling to understand it. This is my first article in the OAuth 2.0 series.

Stage 01

MemoryLane is a photo-sharing service that allows users to upload photos/selfies and share it among their friends. MemoryLane manages users within the application by allowing them to log in by providing their credentials.

In this scenario, MemoryLane manages all its resources (images, likes, comments, posts) and users, as well as their authentication and authorization.

Ava is a MemoryLane user. She has created an account in MemoryLane (ava_user) and shares her photos (ava_image) through the application. Ava is identified as the Resource owner.

Stage 02

MemoryLane.Inc plans to introduce a new set of services in the future. Hence, they thought of decoupling identity and access management from the MemoryLane photo-sharing service, and handling it in a central location, which will allow all new services to use this central IAM solution (IDP).

The MemoryLane service is limited to resources (images, likes, comments, posts) management, and hence, we call this the Resource Server.

Meanwhile, user management and authorization validation occurs in the central IAM solution, thereby identifying the MemoryLane.Inc IDP as the Authorization Server.

Stage 03

Later on, when MemoryLane wants more community engagements, it can allow external developers to write MemoryLane client applications. This allows MemoryLane users to use these applications and access their images.

Dave is an external developer and has to develop the ML_WithDave application so Ava can use this application to access MemoryLane services and manage her photos.

The ML_WithDave client application access protects resources (Ava’s photos) on behalf of resource owners (Ava).

But how will ML_WithDave authenticate the MemoryLane service? One simple way is to get Ava’s credentials and use that to authenticate the MemoryLane IDP.

Dave is a trusted developer, so Ava is confident that he won’t misuse her credentials.

In contrast, Eve is an untrustworthy developer who has developed ML_WithEve. So if Ava was to use ML_WithEve with the same approach, it’s obvious that Eve will misuse Ava’s credentials.

Is there a better solution for this user case? Yes, OAuth 2.0.

1. Ava will try to access her images via the ML_WithDave client application.
2. The ML_WithDave application will request access to MemoryLane from the authorization server (MemoryLane Inc IDP).
3. Ava will authenticate the authorization server (MemoryLane Inc IDP) and provide the authorization grant to the ML_WithDave application to access MemoryLane on behalf of Ava.
4. The authorization server will provide a token (Access token) as an authorization grant to ML_WithDave applications.
5. ML_WithDave will present that token (given by the authorization server) when it accesses resources in MemoryLane’s server.
6. The MemoryLane resource server will validate the token by calling MemoryLane IDP. If it’s a valid token, it will allow access to the protected resources.

In this scenario, Ava delegates access to the client application to act on her behalf. However, she does not share her credentials with applications.

Do we need to provide full privileged access?

ML_WithEve is designed only to view images and is a free application. Eve has built ML_WithEve using OAuth 2.0, So Ava decides to use it.

However, Ava does not provide her credentials to the application, but with the access grant, ML_WithEve can access Ava’s images. This is more than the ML_WithEve application needs because it is designed only to view images, and no more. Can OAuth 2.0 handle this?

Yes, OAuth facilitates this. In the authorization access request, ML_WithEve needs to specify the access level (capabilities) it requires. OAuth defines this as the Scope. Therefore, Ava (users) can see the access level application request and ask the authorization server to grant only the relevant access with the access grant.

Roles and concepts in OAuth 2.0

Resource owner

An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user. In this article, it’s Ava.

Resource server

The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. In this article, it’s MemoryLane Service.

Authorization server

The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. In this article, it’s MemoryLane.Inc IDP.

Client

An application making protected resource requests on behalf of the resource owner and with its authorization. The term “client” does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop or any other device). In this article, it’s ML_WithEve or ML_WithDave.

Access tokens

Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client. The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server.

Scope

The level of access that the application is requesting.

Abstract OAuth 2.0 protocol flow

The abstract OAuth 2.0 protocol flow we discussed so far is as follows:

I hope this article provided a good idea on how OAuth 2.0 works. Let’s deep dive into OAuth 2.0 in the near future.

Resources

RFC 6749 — The OAuth 2.0 Authorization Framework: https://tools.ietf.org/html/rfc6749