What is OAuth 2.0 and how it works?

OAuth 2.0 is an open standard for access delegation that allows users to grant third-party access to their web resources without sharing their credentials. It has become one of the most popular ways to implement authentication and authorization in web and mobile applications.

What is OAuth?

OAuth stands for “Open Authorization.” It is an open standard for token-based authentication and authorization on the internet. OAuth allows an end user’s account information to be used by third-party services, such as Facebook, without exposing the user’s password. OAuth acts as an intermediary on behalf of the end user, providing the service with an access token that authorizes specific account information to be shared. Instead of using username and password, the users approve or deny the request to share their personal data from one website to another.

What are the benefits of using OAuth?

Here are some of the main benefits of using OAuth:

Users can allow third-party applications to access their data without sharing their passwords.
It provides secure delegated access to private resources.

It works over HTTPS and provides good security with encrypted tokens.
It is an open standard and decentralized protocol.
It enables authorization flows for web applications, desktop applications, mobile phones, etc.

It provides flexibility in handling user authentication.

How does OAuth 2.0 work?

OAuth 2.0 involves interactions between four parties – the resource owner (user), the client (application requesting access), the authorization server and the resource server (API server). Here is how OAuth works at a high level:

The client application requests authorization from the user to access their account.

If the user authorizes the request, the application receives an authorization grant.
The application uses the authorization grant to request an access token from the authorization server.
If the authorization is valid, the authorization server returns an access token to the application.

The application uses the access token to access the user’s account information from the resource server.

The core workflow happens between the client, the authorization server, and the resource server. The user just has to approve or deny the initial request from the client.

OAuth 2.0 Roles

There are four main roles in the OAuth flow:

Resource Owner – The end user who authorizes the client application to access their account. The resource owner’s protected resources reside on the resource server.
Client – The application that wants to access the user’s account. Before it can access resources, it must get permission and an access token from the user.
Authorization Server – The server that authenticates the user, issues access tokens after getting user authorization.

Resource Server – The API server that houses the protected user resources. It accepts access tokens from the client and allows access to the resources.

Here is a diagram showing the abstract OAuth 2.0 flow:

Resource Owner	Client	Authorization Server	Resource Server
User	Client Application	OAuth Provider	API Server

OAuth 2.0 Grant Types

OAuth 2.0 defines several grant types for different use cases. The most common grant types are:

Authorization Code

The authorization code grant type is used by confidential clients such as web applications. It provides an authorization code as a credential, which is exchanged for an access token.

The client redirects the user to the OAuth server for authentication and authorization.
The OAuth server authenticates the user and gets authorization.

The OAuth server redirects the user back to the client with an authorization code.
The client exchanges the authorization code for an access token.
The client uses the access token to access protected resources.

Implicit

The implicit grant type is optimized for user-agent-based clients such as single page JavaScript apps. The access token is returned directly without an intermediate authorization code.

The client redirects the user to the OAuth server for authentication and authorization.
The OAuth server authenticates the user and gets authorization.

The OAuth server redirects the user back to the client with an access token in the redirect URI fragment.
The client accesses protected resources with the access token.

Resource Owner Password Credentials

The resource owner password credentials grant lets the client collect the user’s username and password and exchange them for an access token. It is suitable for highly trusted clients.

The client collects the user’s username and password.
The client exchanges the username and password for an access token.
The client uses the access token to access protected resources.

Client Credentials

The client credentials grant type provides an access token by authenticating the client credentials rather than user credentials. This grant is suitable for machine-to-machine authentication where a specific user’s permission is not required.

The client authenticates with the authorization server using its client ID and client secret.
The authorization server authenticates the client and issues an access token.

The client uses the access token to access protected resources.

OAuth 2.0 Flows

Based on the grant types, OAuth 2.0 defines four common authorization flows:

Authorization Code Flow

This is the most common OAuth 2.0 flow used for web apps and is used by confidential clients. It provides an authorization code that is exchanged for an access token.

The client redirects the user to the OAuth server authorization endpoint.
The user authenticates and authorizes access.
The OAuth server redirects back with an authorization code.

The client exchanges the code for an access token.
The access token can be used to access user resources.

Implicit Flow

The implicit flow is intended for user-agent-based apps like single page apps. The access token is returned directly without an authorization code.

The client redirects the user to the OAuth server authorization endpoint.
The user authenticates and authorizes access.
The OAuth server redirects back with an access token in the URL fragment.

The client can use the token to access user resources.

Resource Owner Password Credentials Flow

The resource owner password credentials flow allows exchanging user credentials for an access token directly. It is suitable for highly trusted clients.

The client collects the user’s username and password.

The client exchanges user credentials for an access token.
The access token can be used to access user resources.

Client Credentials Flow

This flow is suitable for machine-to-machine authentication. The client credentials are exchanged for an access token.

The client authenticates with the authorization server using its client ID and client secret.
The authorization server authenticates the client credentials and issues an access token.
The client uses the access token to access protected resources.

OAuth 2.0 Tokens

OAuth uses tokens to allow access to protected resources. The main tokens are:

Access Token – The access token allows access to the user’s protected resources. It is passed in API requests to the resource server.
Refresh Token – The refresh token allows renewing an expired access token. It is used to get a new access token without user interaction.

Authorization Code – The authorization code is returned from the authorization server and used to obtain an access token.
Client Credentials – Client ID and client secret used by the authorization server to authenticate the client.

OAuth 2.0 Authorization Server

The authorization server performs several tasks in OAuth:

Authenticate users and clients that are requesting access
Validate authorization requests
Prompt users to grant access to clients

Return authorization codes
Validate codes and tokens
Provide refresh tokens

Revoke authorization and tokens

Common OAuth authorization servers include Facebook, Google, GitHub, etc. There are also open source implementations like OAuth2orize, Apache Oltu, and more.

OAuth 2.0 Security

OAuth utilizes several security best practices and features:

Client registration – Registered and validated clients get a client ID and secret for authentication
Short-lived tokens – Access tokens expire after short periods and can be renewed
TLS for transport security – OAuth requires TLS for secure communication

Cryptographic signing – Tokens are cryptographically signed to prevent tampering
Client type – Confidential clients can securely maintain secrets unlike public clients

However, there are some vulnerabilities to consider:

Authorization code interception – Authorization codes could be intercepted over the wire
Weak client secrets – Using weak client secrets makes Client Authentication pointless
Session fixation – Session cookies could be hijacked before token issuance

Cross-site request forgery – CSRF could be used to force authorization by victim users

OAuth vs OAuth 2.0

OAuth 2.0 is the next evolution of the OAuth protocol standardized in 2012. Here are some key differences from OAuth 1.0:

OAuth 1.0	OAuth 2.0
Specified 3 token types – request, access and signature tokens	Uses access and refresh tokens
Built-in MAC based authentication	Delegates client authentication to TLS
Specified specific signature methods	No specific signature methods
Added oauth_ parameters to API calls	Access token provided in Authorization header
Consumer key and secret identify client	Client ID and client secret identify client

Overall, OAuth 2.0 simplified and standardized the protocol, addressing weaknesses in OAuth 1.0.

Conclusion

OAuth 2.0 has become an indispensable standard for access delegation and securing APIs. Its ability to enable authorization flows without sharing user credentials has led to widespread adoption. Implementing OAuth properly requires care around vulnerabilities like token hijacking, CSRF, and client authentication. When done right, OAuth enables users to easily grant limited access to their resources across services.