​​What is OAuth 2.0? How does it work?

Assume you have a social media account where you have saved both private and public information. You have an app called "Who are my closest friends?" that you can't wait to try out. This app requires access to your social media's protected information, such as your friend list and possibly your email. To grant access to your friend list, you must provide the application with your social media login credentials. You have now granted full access to your social media account to an application that you are unfamiliar with. The application can now act like you, posting and reading messages. This poses a significant security risk.

This is where secure access delegation comes into play. In simple terms, secure access delegation means providing limited access to an otherwise protected resource on behalf of a user. The valet key of a car is a classic example of access delegation. A car's valet key only allows access to the necessary parts of the vehicle, such as the driver's side door and engine ignition. It will restrict access to the glove box and trunk. In this manner, the items stored in the glove box or trunk are protected.

• How does OAuth fit into all this?

OAuth is an open standard that applications can use to provide secure delegated access to client applications. Instead of using credentials, OAuth works over HTTPS with temporary tokens that can be revoked. OAuth comes in two versions: OAuth 1.0a and OAuth 2.0. The most commonly used form is OAuth 2.0, which we will discuss here.

The typical OAuth use case involves a user, a resource server that has the user's protected resources, an authorization server or an identity provider, and a client application requesting access to protected resources. The client application can access the resource server on behalf of the user using the OAuth 2.0 standard. To accomplish this access delegation, the authorization server issues a token to the client application.

Let's go back to our "Who are my closest friends?" application scenario, but this time with OAuth 2.0. Previously, in order to grant access to your contact list, you had to provide the credentials to your social media account, which posed a significant security risk. However, with OAuth 2.0, you can now request that your social media account provide an access token to the client application (i.e. "Who are my closest friends" application) on your behalf. This token will contain your permission and the scope of the access delegation, which are required by the authorization server to determine the permitted resources and operations, in this case, your friend list and email address.

There are several ways in which a client application can request access tokens from an authentication server. These are called grant types.

• Authorization Code

The client application sends an authorization request to an authorization server in the authorization code grant type. The server authenticates the user and requests that the user approve the access delegation to the specified client application. If approved, the client application receives an authorization code, which can then be exchanged for an access token in an authenticated back channel call. Aside from the access token, which is short lived, the client application will typically receive a refresh token, which can be used to request a new access token. The user only provides their credentials to the authorization server in this grant type, not to the client application.

• Client Credentials

There is no user involved in the client credentials flow. This flow is only used for server-to-server communication. The client application sends its credentials to an authorization server and receives an access token in this flow. A refresh token is unnecessary because the client can always request another access token using its credentials.

• Device Code

In this method, the device prompts the user to open a URL in a secondary device's browser, where the user can easily provide the inputs. The primary device will poll the authorization server for an access token while the user completes the authorization flow on their secondary device. If the user approves the authorization, the authorization server will return an access token; if the user denies the authorization, the server will respond with an error.

• Refresh Token

When the previous access token expires, the refresh token grant type is used to retrieve a new access token for a previously issued refresh token (in a different grant type). This enables the client application to obtain an access token without requiring any user interaction.

• Legacy Grant Types

The implicit flow and resource owner password grants have been deprecated and are now considered legacy grant types.

Let's take a look at why the implicit flow is now considered a legacy. Browser-based JavaScript apps made use of the implicit flow. The implicit flow begins similarly to the authorization code grant type. However, instead of an authorization code, the server responds with an access token. The issue here is that the token is sent to the client application via a user agent (i.e. browser) and is thus vulnerable to access token leakage. The Authorization Code Grant Type with PCKE extension is now recommended by the OAuth 2.0 specification for client applications.

The resource owner password grant was designed to address the needs of first-party applications in which the front-end application and backend APIs are owned by the same entity. As a result, there is no additional risk in providing your credentials to your client-side application. However, because it violates the fundamental rules of access delegation, OAuth 2.1 has also deprecated this grant type.

While this article may serve as an introduction, I recommend reading the OAuth 2.0 Specification for a more in-depth understanding of OAuth 2.0. Also, you can experiment with different grant types on OAuth 2.0 Playground.