I talked about the concept of OAuth in my previous post. Today I’m going to dive a bit too deep and talk about the implementation details provided by the OAuth 2.0 specification. The first specific of OAuth was OAuth 1.0 and after a few years of the use, people identified some problems with it and created OAuth 2.0, the improved version.

Introduction

OAuth 2.0 specification primarily talks about 4 grant types. A grant type can be seen as a method or a protocol of using the concept of OAuth in a particular instance. Therefore, OAuth 2 provides 4 different methods to use the token concept in a business use case.

1. Authorization code grant
2. Implicit grant
3. Resource owner password credential grant
4. Client credential grant

Authorization code grant

Authorization code grant is identified as the most secure grant type described in the OAuth 2.0 specification. It offers few important security benefits such as,

• The ability to authenticate the client.
• Transmission of the access token directly to the client without passing it through the resource owner’s user-agent and potentially exposing it to others.
• Even the resource owner won’t be able to see the access token issued.

Let me explain the code grant type using a sequence diagram.

1. The user wants to access some service offered by the client, which needs to get some resources of the user from the resource server.
2. Client redirects the user to the authorization server, with the following parameters in the request.
   1. client_id=<>  The unique identification of the client, provided by the authorization server in a previous client registration phase.
   2. response_type=code  Indicates that this is the authorization code grant type, and the client is expecting a code.
3. Authorization server prompts the user to login to his/her account and then asks for permission to grant access to the client.
4. Once the user provides consent, the authorization server redirects the user back to the client, with a one time code. This is not the actual access token, but a temporary string for the client to get the actual token from the auth server.
5. Once the code is received to the client, it makes a back channel call to the auth server with the following parameters.
   1. grant_type=authorization_code  Indicates the grant type.
   2. client_id=<>  The unique identification of the client.
   3. client_secret=<>  Password of the client, provided by the auth server in the previous client registration phase.
   4. code=<> – Authorization code obtained in the previous step.
6. Auth server validates the client information and if everything looks good, responds with an access token. The response contains the following parameters.
   1. access_token=<>  Access token
   2. token_type=bearer  Type of the token issued. In most cases it’s bearer, but there are other token types as well.
   3. expires_in=<>  Lifetime of the token. This is a recommended parameter to be sent.
7. Since now the client has an access token, it can request the resources from the resource server.

Authorization code grant is possible only if the client can ensure the secrecy of its client secret. Applications that have their own backends are examples for these types of clients, and on OAuth world, we called them confidential clients.

Implicit grant

Mobile applications or web applications run on a browser cannot protect their client secrets and we call them public clients. There’s no point of using auth code grant for public clients and for that purpose, the implicit grant is designed.

1. Similar to the code grant, the user is redirected to the authorization server, with the following parameters.
   1. client_id=<>
   2. response_type=token
2. Auth server first authenticate the user by asking to login and then ask for permission to issue a token.
3. Once the user provides consent, auth server responds back with a redirection call to the client, along with the following parameters added as URI fragments.
   1. access_token=<>
   2. token_type=bearer 
   3. expires_in=<>
4. The client should extract the token from the URI, using a script runs on the user agent (browser.)
5. After the token is extracted, the client can make calls to the resource server to get the users resources.

Unlike the auth code grant, the access token is visible to the user agent and therefore it’s vulnerable to get hijacked from a third party.

Resource owner password credential grant

Password grant is suitable if you trust the application to handle your credentials. For example, when you download the Facebook app to your phone, you directly enter your facebook credential to the app itself. But in reality, it’s a separate application that runs on your phone. Since it’s made by Facebook, we trust the app and provide our credentials.

1. The user enters his/her username and password of the authorization server to the client itself.
2. Then the client makes a call to the auth server with following parameters.
   1. client_id=<>
   2. client_secret=<> 
   3. grant_type=password
   4. username=<>  Username of the user.
   5. password=<>  Password of the user.
3. After validation, the information auth server responds with a valid token to the client.
4. Now the client can continue its work by calling the resource server with the obtained access token.

Client credential grant

Client credential grant is used by the clients to access resources about themselves rather than to access a user’s resources.

1. The client sends a request to the auth server with the following parameters.
   1. grant_type=client_credentials
   2. client_id=<>
   3. client_secret=<> 
2. After validating the information the auth server sends a token as a response.
3. The client can use this token to access the data in the resource server.

That’s all about the basic grant types introduced with the OAuth 2.0 specification. I’ll write another post on seeing these grant types in action with the WSO2 Identity Server and its sample playground application. Let me know your thoughts in the comments section.

Cheers!