Introduction
The OAuth 2.0 Authorization Framework (RFC7649) is a protocol that enables third-party applications to access a user's resources on a resource server, without the need for the user to share their credentials with the third-party application. OAuth 2.0 operates through the exchange of tokens between an OAuth Client (the third-party application), an Authorization Server, and a Resource Server.
OAuth 2.0 is widely used in modern web and mobile applications to enable secure and delegated access to APIs and user data. It allows users to grant permissions to third-party applications without compromising their security, privacy or password credentials.
One of the advantages of OAuth 2.0 is its support for various authorization flows, including implicit, authorization code, client credentials, and resource owner password credentials flows, which cater to different use cases and security requirements. OAuth 2.0 also supports scopes, which allow for fine-grained access control based on the resources that the client is authorized to access.
Overall, OAuth 2.0 is a widely adopted protocol for enabling secure and delegated access to resources across different domains and applications, and is a foundational technology for modern app development and API management.
Who are OAuth 2.0 players?
OAuth 2.0 involves four key players: the Resource Owner, the Client, the Resource Server, and the Authorization Server. Here is a more in-depth explanation of each player:
Resource Owner: The resource owner is the entity that owns the resource (e.g., user data) that the client wants to access. The resource owner has the ability to grant or deny access to the resource. In most cases, the resource owner is a user.
Client: The client is an application that wants to access the resource on behalf of the resource owner. The client initiates the OAuth 2.0 flow by requesting authorization to access the resource from the resource owner. The client can be a web or mobile application, a desktop application, or even a server.
Resource Server: The resource server is the server that hosts the resource that the client wants to access. The resource server is responsible for accepting and responding to requests for the protected resource.
Authorization Server: The authorization server is the server that authenticates the resource owner and issues access tokens to the client. The authorization server is responsible for verifying the identity of the resource owner and determining whether the client is authorized to access the requested resource. The authorization server is also responsible for managing access tokens and handling token revocation and expiration.
In an OAuth 2.0 flow, the client requests authorization to access the resource from the resource owner. The resource owner then authenticates with the authorization server, and if authorized, the authorization server issues an access token to the client. The client then uses the access token to make requests to the resource server, and the resource server verifies the access token before responding to the client's request.
What are OAuth 2.0 flows?
OAuth 2.0 support different authorization flows called grant types. The most common are:
Authorization Code: The Authorization Code Grant is the most commonly used grant type in OAuth 2.0. It involves the client first redirecting the resource owner to the authorization server's authorization endpoint, where the resource owner can grant permission to the client. If the resource owner grants permission, the authorization server responds with an authorization code. The client then exchanges this code for an access token by sending a request to the authorization server's token endpoint. This grant type is useful for web applications that can securely store the client secret. To improve security, a variation of this grant type called PKCE (Proof Key For Code Exchange) has been introduced in the Proof Key for Code Exchange by OAuth Public Clients (RFC7636) specification. This variation adds an additional layer of protection against authorization code interception attacks. In this variant, the client generates a random code verifier and hashes it using SHA-256. The client then sends the hashed code challenge to the authorization server's authorization endpoint, and includes the unhashed code verifier when exchanging the authorization code for an access token at the token endpoint. The authorization server can then verify that the code verifier matches the code challenge, providing an additional layer of security. The following diagram illustrates how informations are exchanged in the Authorization Code flow.
Implicit: The Implicit Grant is a simplified flow for clients that are unable to securely store the client secret, such as JavaScript-based applications. In this flow, the client directly requests an access token from the authorization server's authorization endpoint, without first obtaining an authorization code. The access token is returned in the URI fragment of the response. The implicit flow can be visualized in the diagram below, which depicts the sequence of information exchanges involved in this OAuth 2.0 flow.
- Client Credentials: The Client Credentials Grant is used when the client is requesting access to its own resources, rather than on behalf of a user. In this flow, the client sends its own credentials (client id and client secret) directly to the authorization server's token endpoint to obtain an access token. The diagram presented below offers a clear visualization of the information exchange that takes place during the Client Credentials flow in OAuth 2.0.
Resource Owner Password Credentials: The Resource Owner Password Credentials Grant is used when the client has direct access to the resource owner's username and password, and can authenticate on behalf of the resource owner. In this flow, the client sends the resource owner's username and password directly to the authorization server's token endpoint to obtain an access token. To depict the sequence of information exchanges that occur during the Resource Owner Password Credentials flow, we have created the following diagram.
Device Authorization: The Device Authorization Grant is a newer grant type introduced in the OAuth 2.0 Device Authorization Grant (RFC 8628) specification, designed to enable devices with limited input capabilities to obtain an access token for accessing protected resources. It allows users to authenticate on a separate device with a web browser and supports user interaction, which is important for maintaining security and ensuring that the user is aware of which resources the device is accessing on their behalf. An illustration of the information exchange process involved in the Device Authorization flow can be seen in the following diagram.
What is an access token?
In the context of OAuth 2.0, an Access Token is a string of characters that represents the authorization granted by a resource owner to a client application to access their protected resources.
The access token is typically issued by an authorization server after the resource owner has granted consent to the client application. Once the client application receives the access token, it can use it to make requests to the resource server on behalf of the resource owner. The resource server validates the access token to ensure that the client application is authorized to access the requested resources.
Access tokens are usually short-lived, and they can be invalidated or revoked by the authorization server at any time. This allows the resource owner to control access to their protected resources and to revoke access if necessary. Access tokens are an important part of the security architecture of many modern applications and APIs, as they enable secure and controlled access to resources.
What is a refresh token?
In the context of OAuth 2.0, a Refresh Token is issued to a client application along with an access token by the authorization server during the initial authorization process.
The refresh token allows the client application to obtain a new access token after the current access token has expired or become invalid, without requiring the resource owner to go through the entire authorization process again. When the client application needs to obtain a new access token, it sends the refresh token to the authorization server and requests a new access token. If the refresh token is valid, the authorization server issues a new access token to the client application.
Refresh tokens are usually long-lived and can be used to obtain multiple access tokens over an extended period of time. Because refresh tokens have the potential to grant long-term access to a user's resources, they are typically subject to stronger security controls than access tokens, such as encryption and storage in secure storage.
Refresh tokens are an important component of the OAuth 2.0 protocol, as they enable seamless and secure access to resources without requiring the resource owner to repeatedly authenticate. However, their use also introduces additional security considerations, such as protecting refresh tokens from theft or misuse.
Token introspection
Token introspection is a security mechanism used in OAuth 2.0 to enable an application to validate an access token presented to it by a client. It involves the use of an introspection endpoint provided by the authorization server to allow the application to query the authorization server and determine the status and validity of an access token.
The token introspection process typically involves the application sending an HTTP POST request to the introspection endpoint with the access token as a parameter. The introspection endpoint then responds with information about the token, such as its expiration time, associated scopes, and any other relevant metadata. The application can use this information to determine whether the token is still valid and can be used to access protected resources.
Token introspection provides an additional layer of security to OAuth 2.0 by allowing applications to verify that the access token presented to them by a client is valid and has not been revoked. This helps to prevent unauthorized access to resources by malicious actors who may have obtained an invalid or revoked token.
Token revocation
Token revocation is a security mechanism used in OAuth 2.0 to enable an application or resource owner to revoke an issued access or refresh token before it expires. Token revocation is an important security feature that helps to prevent unauthorized access to protected resources in situations where a token has been compromised, lost, or stolen.
Token revocation typically involves sending an HTTP request to the token revocation endpoint provided by the authorization server with the token to be revoked. The authorization server then revokes the token and any associated refresh tokens and updates its internal records accordingly. Once a token has been revoked, it can no longer be used to access protected resources, even if it has not yet expired.
The revocation endpoint can be used by a variety of parties, including the resource owner, the client application, or the authorization server itself. The resource owner may use the revocation endpoint to revoke access for a specific client or user, while the client may use it to revoke its own access token in case of a security breach. The authorization server may also revoke tokens in certain circumstances, such as when a user account is terminated or when a token has been deemed compromised.
Token revocation is an important security measure in OAuth 2.0, as it allows access to resources to be quickly and effectively terminated in case of a security incident. It also enables resource owners to have more control over the access granted to client applications and ensures that access is granted only when it is necessary and authorized.