OAuth 2.0
The OAuth 2.0 authorization framework enables a 3rd party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the 3rd party application to obtain access on its own behalf.
This feature is supported in mobile applications only.
Figure: Protocol flow
The OAuth 2.0 specification is defined in [RFC 6749] and it builds on the OAuth 1.0 [RFC 5849] deployment experience, as well as additional use cases and extensibility requirements gathered from the wider IETF community. The OAuth 2.0 protocol is not backward-compatible with OAuth 1.0.
Authorization Grant
An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token.
The specification defines the following 4 grant types as well as an extensibility mechanism for defining additional types:
- Authorization code
The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server, which in turn directs the resource owner back to the client with the authorization code.
The authorization code provides some important security benefits, such as the ability to authenticate the client, as well as the 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, including the resource owner.
Figure: Authorization code flow
- Implicit
In the implicit flow, the client is issued an access token directly (as a result of the resource owner authorization). The grant type is implicit, as no intermediate credentials (such as an authorization code) are issued.
Implicit grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application), since it reduces the number of round trips required to obtain an access token.
Figure: Implicit grant flow
- Resource owner password credentials
The resource owner password credentials (such as username and password) can be used directly as an authorization grant to obtain an access token.
Even though this grant type requires direct client access to the resource owner credentials, the resource owner credentials are used for a single request and are exchanged for an access token. This grant type can eliminate the need for the client to store the resource owner credentials for future use, by exchanging the credentials with a long-lived access token or refresh token.
Figure: Resource owner password credentials flow
- Client credentials
The client credentials can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server. Client credentials are typically used as an authorization grant when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server.
Figure: Client credentials flow
To request an access token for the implicit, resource owner password credentials, or client credentials grant type, follow the direct access token request instructions.
