OAuth 2.0 grant types

OAuth 2.0 specifies four grant types. We only discuss the Authorization Code Grant and the Implicit Grant, as they are the most common and both are supported by Airlock IAM. We give a brief overview of these grants in order to illustrate their most common use case. The Terms and definitions below explains some OAuth 2.0 terms in more detail.

The Authorization Code Grant is usually used to delegate authorization from one web application to another.

The OAuth 2.0 RFC depicts the Authorization Code Grant as follows:

We give an example to illustrate this grant type.

Goal:

Delegate authorization to access Facebook (Authorization Server) pictures to Pinterest (Client).

• The user (Resource Owner) navigates in her browser (User Agent) to Pinterest (Client). Pinterest would like to display pictures contained in the user's Facebook account.
• (A) Pinterest redirects the user to Facebook (Authorization Server), with a request saying that Pinterest (client_id) would like to access the user's pictures (scope).
• (B) The user authenticates with Facebook and is asked if she would like to grant Pinterest access to her pictures. We assume the user grants access.
• (C) Facebook sends a redirect containing an Authorization Code to Pinterest.
• (D) Pinterest directly authenticates with Facebook and then uses the Authorization Code to obtain an Access Token (E).

Finally, Pinterest uses the Access Token to access the user's Facebook pictures.

The client credentials grant is used by clients to directly obtain an access token with the clients credentials and without involvement of a user.

The client credentials grant is only supported by the AS-centric implementation of OAuth 2.0.

To use the client credentials grant, follow these steps:

• The client sends a request to the authorization server.
• The server verfies the credentials supplied in the request.
• Upon success the authorizstion server issues an access token and sends it to the client in the response.

The Implicit Grant is used when there is no remote webapplication to grant authorization to but the target instead is a local application on the User-Agent, typically a java script application.

The implicit grant is deprecated by the new OAuth 2.1 standards draft. It is only supported by the client-centric implementation of OAuth 2.0.

The OAuth 2.0 RFC illustrates the Implicit Grant as follows:

Again, we provide an example to illustrate this grant type.

Goal:

Delegate authorization to access Facebook (Authorization Server) pictures to the Pinterest JavaScript application (Client) running in the user's browser (User-Agent).

• The user accesses Pinterest and obtains a JavaScript application (Client) that runs in her browser (User-Agent).
• (A) The JavaScript application issues a request to Facebook (Authorization Server), saying that Pinterest (client_id) would like to access the user's pictures (scope).
• (B) The user authenticates with Facebook and is asked if she would like to grant Pinterest access to her pictures. We assume the user grants access.
• (C) Facebook sends a redirect with an Access Token in the fragment.
• (D), (E) The JavaScript application extracts the Access Token from the fragment, typically using JavaScript code it obtained from Pinterest (Web-Hosted Client Resource).

Finally, the JavaScript application uses the access token to access the user's Facebook pictures.