How OAuth 2.0 works?

Jude Niroshan
Oct 9, 2018 · 4 min read

OAuth is a specification and it is being used to Authorization of resources for different outside people. We are using OAuth 2.0 as the standard specification by the time of writing this post. OAuth is a very simple workflow which has defined to allow the facility for the resource owner to share resources in a more controlled manner.

Today, almost all the giants in software industry adhere to this specification so that other software systems can easily share resources in between the system.

OAuth 2.0 is a HTTPS-based protocol which enables a resource owner (the end-user), using a user-agent (typically a browser), lets a client (typically an API consumer) access a protected resource on a resource server (typically an API provider) using credentials stored on an authorization server. Access to the protected resource is authorized by an access token.

Clients are assigned secrets that are shared with the authorization server.

1. Authorization Flows

There are 4 flows available.

1.1. Authorization Code flow

The Authorization Code flow is used when the client is a third-party server or web application, which performs the access to the protected resource.

The client does not have access to the resource owner credentials.

The user-agent connects to a URL hosted by the client. The client redirects the user-agent to the authorization server, including information identifying itself (a client id), the request (scope — the permissions being requested), and a URL pointing back to the client (redirect URL — it is referred to as an URI in the spec though it is always a HTTP URL).

The authorization server authorizes the resource owner, and may perform authentication such as username/password verification, and confirmation of the action requested. On success, it directs the user-agent back to the client through the provided redirect URL, adding an authorization code to the URL.

The redirect URL typically points to a server-side script that requests the access token through a POST to the authorization server. The POST is authenticated by the client secret, and provides the authorization code received as proof that the resource owner has indeed authorized the request. The server responds with the access token and an expiration time in the POST response.

1.2. Implicit Grant flow

The Implicit Grant flow is used when the user-agent will access the protected resource directly, such as in a rich web application or a mobile app. The client secret is not used.

The user-agent connects to a URL on the authorization server. This could either be a direct connection, or through a redirect made from the client. The request contains the client id, the request scope, and the redirect URL. If the authorization server passes the request, it performs a redirect to the redirect URL with the access token and expiration time in the fragment (after the hash #).

While the redirect URL points to the client, code inside the client (that is, the server-side app) does not see it. Instead, the URL may be used to load JavaScript that takes the access token from the URL and uses it. Or, a mobile app can capture the redirect, extract the access token and use it in its code, in which case the URL may just point to static content.

1.3. Resource Owner Password Credentials flow

The resource owner password credentials flow is used when the resource owner trusts the client to get its username and password. The client obtains the credentials through other means that are out of scope, then passes them directly to the authorization server to request an access token. This flow can be used to migrate traditional username/password authentication schemes.

1.4. Client Credentials flow

The client credentials flow obtains the access token purely based on the client shared secret.

2. Access to the Protected Resource

Once the client or user-agent (in the implicit grant flow) has the access token, it may use it to access the protected resource. There are 2 standard ways of sending the credentials, though more can be defined.

2.1. Bearer Token

The access token is should be placed in the Authorization HTTP header, and may only be placed in a POST request body, or the GET URL parameters as a fallback option.

2.2. MAC

A cryptographic MAC (Message Authentication Code) is computed using elements of the request and sent in the Authorization header. The Resource Owner computes and compares the MAC upon receiving the request.

The access token may only be placed in the Authorization HTTP header

3. Refresh Tokens

In the Authorization Code and Resource Owner Credentials flows, the authorization server implementation may choose to issue a refresh token. This refresh token may be used to obtain a new access token without requesting authorization again.

Jude Niroshan

Written by

Undergraduate at SLIIT | Google Summer of Code student