OAuth 2.1

What is OAuth 2.1?

OAuth 2.1 is a proposed update to the OAuth 2.0 authorization framework. It involves a series of changes and recommendations to the existing OAuth 2.0 specification which consolidates the best practices and security improvements that have been widely adopted in the industry over the years.

The primary updates of OAuth 2.1 are to:

1. Deprecate implicit grant and Resource Owner Password Credentials (ROPC) grant due to security concerns.
2. Enforce the use of Proof Key for Code Exchange (PKCE) for all clients, including confidential (private) clients .
3. Exact matching of redirect URIs .
4. Clear definition of client types (public and confidential clients).
5. Security requirements for refresh tokens .

Deprecation of implicit grant

The implicit grant was designed for single-page applications (SPAs) and browser-based applications that cannot securely store client secrets. However, its security risks have led to its deprecation: the grant returns the access token in the front channel (URL fragment), which can be exposed to attackers through browser history and referrer headers.

OAuth 2.1 recommends using the authorization code grant with Proof Key for Code Exchange (PKCE) for browser-based applications.

Deprecation of ROPC grant

The ROPC grant allows the client to exchange the user’s credentials directly for an access token. It was designed for legacy applications that cannot support the authorization code flow. However, the grant poses security risks by:

• Exposing the user’s credentials to the client.
• Bypassing the authorization server’s consent screen.
• Limiting the authorization server’s ability to enforce other security measures, such as Multi-factor authentication (MFA) .

OAuth 2.1 recommends using the authorization code grant with Proof Key for Code Exchange (PKCE) for user authentication and authorization.

Enforcing PKCE for all clients

Proof Key for Code Exchange (PKCE) is a security extension to the authorization code flow that mitigates the risk of authorization code interception attacks. It involves the client generating a code verifier and a code challenge, and the authorization server verifying the challenge during the token exchange.

Here’s a simplified sequence diagram of the authorization code flow with PKCE:

It was initially recommended for public clients to use PKCE, but OAuth 2.1 extends this recommendation to a mandatory requirement for all clients, including confidential (private) clients .

Exact matching of redirect URIs

Redirect URIs are used by the client to receive authorization responses from the authorization server. OAuth 2.1 introduces a new requirement that the redirect URI used in the authorization request must match the redirect URI registered by the client with the Authorization server exactly, including the scheme, host, and path.

In some OAuth 2.0 implementations, the redirect URI matching was lenient, allowing partial matches or wildcard characters. However, this flexibility can introduce security risks, such as open redirect vulnerabilities.

Clear definition of client types

OAuth 2.0 does not explicitly define client types. You may see various categorizations in the industry, such as by access level (public vs. confidential) or by application type (web app vs. mobile app). To the OAuth framework, it does not matter how the client is implemented (since they are more about the client’s business attributes), but the access level makes a difference in the security requirements.

Thus, OAuth 2.1 introduces a clear definition of client types:

• Public clients : Clients that CANNOT maintain the confidentiality of its credentials (e.g., SPAs, mobile apps).
• Confidential clients : Clients that CAN maintain the confidentiality of its credentials (e.g., server-side web apps, native desktop apps).

Security requirements for refresh tokens

Refresh tokens are long-lived tokens used by the client to obtain new access tokens without user interaction. In the mean time, they are also high-value targets for attackers. As public clients cannot securely store credentials, OAuth 2.1 specifies that the Authorization server should using one of the following methods to secure refresh tokens:

• Issue sender-constrained refresh tokens .
• Use refresh token rotation to limit the usability and lifetime of refresh tokens.

OAuth 2.1 and OpenID Connect (OIDC)

Since OpenID Connect (OIDC) is built on top of OAuth 2.0, the changes introduced in OAuth 2.1 also apply to OIDC. For example, all OIDC clients should use authorization code flow with PKCE for user authentication and authorization.

See also

• OAuth 2.0
• Authorization code flow
• Proof Key for Code Exchange (PKCE)
• Implicit flow
• OpenID Connect (OIDC)