Say Hello to OAuth 2.0

Published in

Identity Beyond Borders

5 min readOct 9, 2018

OAuth2.0 is the de facto standard in access delegation. I know there are many articles that discuss about OAuth out there, But I thought of writing this document, to simply explain OAuth 2.0 concepts to whom still struggling to understand it. This is the first article in the OAuth 2.0 series that I thought of writing.

MemoryLane is a photo sharing service that let you to upload your photos/selfies and share it with your friends. At the moment MemoryLane manages users within the application. So you can login with providing credentials to MemoryLane.

In this scenario MemoryLane service manages all the resources (Images, Likes, Comments, Posts) and users and their authentication and authorization.

Ava is a MemoryLane user. She has created an account in MemoryLane (ava_user) and shares her photos (ava_image).

Ava is identified as the Resource owner.

Stage 02

MemoryLane.Inc has a plan to introduce new set of services future. Hence they thought of decoupling Identity and access management from MemoryLane photo sharing service. Identity and access management will handle in a central place and all new services can use this central IAM solution (IDP).

Now MemoryLane service is limited to resources (Images, Likes, Comments, Posts) management hence we call this as the Resource Server.

User management and authorization validation happen in central IAM solution. So MemoryLane Inc IDP is identified as Authorization Server.

Stage 03

Later MemoryLane wants more community engagements so it allows external developers to write MemoryLane client application. Now MemoryLane users can use these applications and access to their images.

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

Now ML_WithDave Client application access protected resource (photos of Ava) on behalf of resource owners(Ava).

Hmmm…

But how ML_WithDave authenticate to MemoryLane service, One simple way is to get the credential from Ava and use that to authenticate with MemoryLane IDP.

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

Eve is an untrustworthy developer who has developed ML_WithEve, so what happened if Ava going to use the ML_WithEve with the same approach. It’s obvious that Eve can misuse Ava’s credentials.

Is there a better solution for this use-case. Yes, its OAuth 2.0

1. Ava will try to access her images via ML_WithDave client application

2. ML_WithDave application will request access to MemoryLane service from authorization server (MemoryLane Inc IDP).

3. Ava will authenticate to authorization server (MemoryLane Inc IDP) and provide the authorization grant to ML_WithDave application to access MemoryLane service on-behalf of Ava.

4. Authorization server will provide a token (Access token) as an authorization grant to ML_WithDave applications.

5. ML_WithDave present that token (which is given by authorization server) when it access the resources in MemoryLane resource server.

6. MemoryLane resource server will validate the token calling to MemoryLane IDP. If it’s a valid token it allows to access protected resources.

In this scenario Ava delegate access to client application to act on behalf of her. But she does not share her credential with applications.

Do we need to provide full privileged access?

ML_WithEve is designed only to view the images and its a free application. Now Eve build ML_WithEve using OAuth 2.0, So Ava decided to use it.

Now Ava does not give her credentials to application but with the access grant ML_WithEve is possible to do all the actions on Ava’s images. This is more than ML_WithEve application needs because this is designed only to view images, no more than that. Can OAuth 2.0 handle this?

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

Roles and concepts in OAuth 2.0.

If we look back, now you should be familiar with the following 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 Its Ava

Resource server

The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

In this article Its MemoryLane Service

Authorization server

The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

In this article Its 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 other devices).

In this article Its 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 duration 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