OAuth 2.0 is an authorization framework or protocol that grants a API clients (third-party applications) a limited access to protected web resources of users on a HTTP service provider, such as Twitter, Instagram and LinkedIn etc. - without sharing their credentials. A commonly used protocol for web, desktop and mobile applications - the OAuth 2.0 framework is dependent on an "authentication & authorization" flow, in which the user is authenticated by the service provider, and the client application is authorized to access protected web resources. The OAuth 2.0 protocol issues Access Tokens to client applications seeking to access protected web resources.

This article serves as an overview of the various OAuth 2.0 concepts, such as roles, grants (also called flows), and possible use cases. OAuth 2.0 is an improvement over OAuth 1.0.

OAuth 2.0 Roles

The following roles are considered in OAuth 2.0:

• Resource Owner
• Resource Server
• Client
• Authorization Server

Resource Owner:

Also referred to as the end-user that grants a client access to a protected resource. The client's access is limited to the "scope" of the authorization grant (e.g. create or delete access).

Resource Server:

This is the server hosting the protected resource. The API (of the service provider) that is accessed.

Client:

This is the third-party application requesting protected resources on behalf of the user (resource owner).

Authorization Server:

This is the server that verifies the identity of the resource owner, and issues an Access Token to access protected web resource, after being authorized by the service provider.The service provider's API usually acts as the resource & authorization server in application development.

Abstract OAuth 2.0 Flow

The abstract OAuth 2.0 flow describes how the four roles listed above interact with each other. Below is a diagram that illustrates this.

We can further understand the details of the diagram:

1. The IOT device (client) requests authorization from the user (resource owner) to access protected resource.
2. The user authorizes the request, and sends an authorization grant to the client.
3. The client requests access token from authorization server (service provider's API) using authentication identity and authorization grant received from user.
4. The authorization server (service provider's API) sends an access token to the client, if the client authentication identity and authorization grant provided is valid. At this point, the IOT device (client) has been authorized.
5. The client requests the protected resource from resource server (service provider's API) using the access token.
6. The resource server sends protected resource to the client, if the access token is authenticated (valid).

Authorization Grant Types

Authorization grant is defined in the OAuth 2.0 Framework specification. According to the definition:

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.

In OAuth 2.0 Framework specification, there are four authorization grant types (also called flows), to wit, authorization code, implicit, resource owner password credentials, and client credentials. These flows are use-cases or scenarios an API client performs in order to receive an access token from an authorization server.

Authorization Code

This is the most commonly used authorization grant type, compatible with server-side applications (i.e. web and mobile web apps). The authorization code acts as a "middle-man" between the user (resource owner) and the client requesting access. This is also known as a redirection-based flow, in which the client directs the resource owner to an authorization server via the user-agent (resource owner's browser) for authentication, and the resource owner is redirected to the client with the authorization code - without sharing resource owner's credentials to client or resource owner (i.e. via user-agent). Hence ensuring a safe and secure transmission of authorization code, and subsequent access token.

The authorization code flow is explained below:

(A) An authorization link is provided for the resource owner to send authorization code request as below:

https://example.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=create+delete

The link components are explained below:

• https://example.com/v1/oauth/authorize: the service provider's API authorization endpoint
• response_type=code: specifies the client is requesting an authorization code grant
• client_id=CLIENT_ID: specifies how the API identifies the client application
• redirect_uri=CALLBACK_URL: where the user-agent (browser) is redirected after authorization code is granted
• scope=create+delete: specifies access level of the client

(B) The resource owner clicks authorization link, and is directed to authentication page to enter credentials (except authenticated already), and then prompted by authorization server to either allow or cancel client access to account.

(C) After resource owner authorizes access (i.e. clicking "Allow"), the authorization server redirects user-agent to client using the redirect URI, which contains authorization code.

(D) The client sends an access token request to authorization server using authorization code, and authenticates on the authorization server using client credentials. The redirect URI is also sent along with the authorization code for verification.

(E) When the client is authenticated by the authorization server, and the authorization code and redirect URI validated, the access token and an (optional) refresh token is sent back to the client.

Implicit

The implicit flow is used for Single-Page Applications (SPA) executing on the user-agent using a Scripting language, such as JavaScript. This flow does not require any middle-man (authorization code), and receives access token directly from the authorization server. The implicit grant type however is prone to some security breaches, as access tokens can be exposed to the resource owner or a third-party client application that has access to the resource owner's user-agent. The implicit grant flow is detailed in four steps below:

1. In this flow, an authorization link is also provided for the resource owner to send authorization request to service provider's API. It's similar to the authorization code link, but with a little tweak (i.e. it's requesting a token instead of a code). The response_type is set to token.

https://example.com/v1/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read+write

2. The user is prompted by the authorization server to log in (authenticate) and deny or allow access.

3. If the resource owner allows access, the authorization server redirects the resource owner to the client with access token.

4. The client uses access token to send requests to service provider's API to access protected resources.

Resource Owner Password Credentials

The resource owner password credentials (i.e. username and password) can be used directly by the client to obtain access token. This authorization grant type is however not adviced, as it requires a high level of trust between resource owner and client (e.g. client is a highly privileged application released by service provider).

The resource owner password credentials flow is detailed below:

1. The resource owner authenticates using credentials (i.e. username and password).

2. The client sends request to authorization server to obtain access token.

3. The authorization server validates the resource owner credentials, and responds with access token.

Client Credentials

This type of authorization grant is used for server-to-server communication (i.e. the client acting on its own behalf rather than on behalf of any resource owner). In this case, the client acts as the resource owner requesting access to protected resource.

Conclusion

We have been able to explain the various OAuth 2.0 concepts and how they interact with each other in the development of a web and mobile web application. However, this article serves as an introduction, not as a standard - you are adviced to also consult other resources online for deeper insights on the OAuth 2.0 Framework Protocol.

With this article at OpenGenus, you must have a good idea of the basics of OAuth 2.0. Enjoy.