What’s New with OAuth 2(.1)?

Since its release in October 2012 (RFC6749), OAuth 2.0 has provided a mechanism for secure access to protected resources, and the authorization framework has risen to become the modern authorization framework. It also serves as the foundation for the authentication layer added by OIDC for web, mobile, and desktop applications. 

However, as is commonly the case in security, the efforts didn’t stop there. Cybersecurity is a constant cycle of improvements as time goes on and new vulnerabilities are discovered or created due to new tech becoming available or new use cases. 

To stay secure, you must continuously evolve, and with over a decade since the OAuth 2.0 release, new security challenges, use cases, insights, and lessons learned have been added as supplementary specs. But, it’s also reached the point of becoming difficult to know what exactly the most up-to-date best security practices are without sifting through a bunch of specifications and following the timeline of updates. And, even if you do, the details are spread out over several different docs that you need to selectively extract from. 

OAuth 2.1 aims to take a snapshot of the most up-to-date best practices and consolidate it all into a single spec rather than introducing anything strictly new. This blog post delves into the key differences and improvements between OAuth 2.1 and OAuth 2.0, providing developers with a comprehensive understanding of this evolution.

OAuth 2.1 includes OAuth 2.0 modified with updates from:

• OAuth 2.0 for Native Apps
• Best Current Practice for OAuth 2.0 Security
• OAuth 2.0 for Browser-Based Apps

With Best Current Practice for OAuth 2.0 Security including a conglomeration of key security improvements over the original spec.

Introduction to OAuth

Before diving into the specifics of OAuth 2.1, it might be helpful to revisit the foundational aspects of OAuth 2.0 for those not as familiar (feel free to skip ahead to the next section otherwise). It enables applications, or clients, to obtain limited access as authorized by the resource owner to certain protected resources like private data or privileged actions. It works by delegating user authentication to a mutually trusted third party, the authorization server, authorizing third-party applications, or clients, to access the user account.

A common confusion is describing OAuth 2 as an authentication framework. It’s not. OAuth 2.0 is an authorization framework. This distinction is important because they provide different outcomes. However, it’s a common confusion because authentication is indeed required by the spec, but it’s a necessary step that’s outside the scope of what OAuth 2 prescribes.

Authentication is required to ensure the actual resource owner is the one granting authorization to access the protected resources because it matters that the right user has authorized access vs. someone or something giving the thumbs up. The details, however, of how that authentication is done or information about who the resource owner is is out of scope. OIDC was created to fill this need and is a layer built on top of OAuth 2.

Since OAuth 2 is most often used with OIDC, the two frameworks are often used interchangeably, and, similarly, authentication and authorization are often conflated or used interchangeably. So, while it’s a necessary requirement that the resource owner is authenticated in the OAuth 2 flow, for the purposes of OAuth 2, it’s more like a task to check off and it only matters whether the current user (whether human or machine) providing authorization was authenticated.

A quick refresher on authorization and authentication

Regarding a user or subject X, they seek to answer two different questions:

• Authorization: what can X access?
  • This is the purpose of the authorization framework, OAuth 2
• Authentication: who is X?
  • This is the purpose of the authentication framework, OIDC
  • Since OIDC is a layer built on top of OAuth 2, you necessarily have authorization available along with the authentication provided by OIDC

One of the key changes is from the 4 original grant types, each with their own flow, defined in OAuth 2.0: 

1. Authorization code
2. Implicit
3. Resource owner credentials
4. Client credentials

But, implicit and resource owner credentials didn’t make the cut in OAuth 2.1, albeit for good reasons that’ll be touched on further down.

Key updates in OAuth 2.1

Below are some key differences between OAuth 2.1 and OAuth 2.0:

1. Deprecation of the Implicit Grant:

• OAuth 2.0: Allowed the use of the implicit grant for public clients.
• OAuth 2.1: Deprecates the implicit grant due to its inherent security vulnerabilities, such as token leakage through browser history or referral headers.

2. Mandatory PKCE (Proof Key for Code Exchange):

• OAuth 2.0:
  1. PKCE was optional, and intended for public clients.
• OAuth 2.1:
  1. PKCE is now mandatory for all clients.

PKCE supplements the authorization code flow to mitigate the risk of authorization code interception attacks. This change improves the basic security and standardizes it across all OAuth 2 implementations.

3. Exact redirection URI matching:

• OAuth 2.0:
  1. Public clients and confidential clients using implicit grant type must register redirect URI. It’s recommended for other clients.
  2. Clients are recommended to provide their complete redirect URI.
  3. Simple string matching of redirect URI’s was optional.
• OAuth 2.1:
  1. All clients must register a redirect URI.
  2. Clients are required to provide their complete redirect URI.
  3. Strict string matching of redirect URI’s is mandatory.

Detailed Exploration of Improvements

1. Deprecation of the Implicit Grant

The implicit grant in OAuth 2.0 was designed for simplicity but came with significant security drawbacks. Access tokens were returned directly in the URL fragment, exposing them to potential leakage through browser history or the HTTP Referer header. OAuth 2.1 deprecates the implicit grant, encouraging the use of more secure alternatives like the authorization code flow with PKCE (Lodderstedt, et al., 2019).

2. Mandatory PKCE

PKCE was introduced to protect the authorization code during the OAuth 2.0 authorization code flow, particularly for public clients that cannot securely store a client secret. PKCE works by the client creating a secret (code verifier) and transforming it into a challenge (code challenge) sent to the authorization server.

In OAuth 2.1, making PKCE mandatory for all public clients ensures a consistent security posture. This requirement eliminates the risk of authorization code interception attacks, where an attacker could potentially exchange an intercepted code for an access token (Lodderstedt, et al., 2019).

3. Clearer Security Recommendations

OAuth 2.1 provides more explicit security guidelines compared to its predecessor. For instance, it mandates the use of stricter rules for validating redirection URIs to prevent open redirector attacks. These measures aim to standardize security implementations and reduce vulnerabilities stemming from ambiguous requirements.

Migration considerations

When migrating from OAuth 2.0 to OAuth 2.1, several factors should be taken into account:

1. Assess current implementation: Evaluate your current OAuth 2.0 implementation to identify areas that need to be updated to comply with OAuth 2.1 requirements.
2. Implement PKCE: Ensure that PKCE is implemented for all clients, not just public ones. Libraries and SDKs supporting OAuth 2 should support PKCE with the SHA256 method.
3. Update error handling: Modify your error handling mechanisms to accommodate the new error codes and response formats specified in OAuth 2.1.
4. Refresh token strategy: Implement refresh token rotation if not already in place, to enhance the security of your authentication system.
5. Evaluate other OAuth enhancements: Consider the benefits of using enhancements added after the original OAuth 2.0 release but not explicitly required by OAuth 2.1 like Pushed Authorization Requests for clients that cannot use front-channel redirects, dynamic client registration, token introspection, private JWT’s, and more.
6. Secure redirect URIs: Enforce strict URI matching.

Conclusion

OAuth 2.1 represents a significant simplification as the OAuth authorization framework has started to experience some pains of entropy of the decade-plus since its original release in 2012. It addresses key ambiguities and vulnerabilities present in OAuth 2.0. By making PKCE mandatory, providing clearer security guidelines, and deprecating insecure grant types, OAuth 2.1 resets the security standard for modern applications in a single reference.

For developers, adopting OAuth 2.1 means embracing these improvements to enhance the security and reliability of their Identity systems. While migration may require some effort, the benefits of a more secure and standardized authentication process are well worth it. By understanding and implementing the changes introduced in OAuth 2.1, developers can build more secure applications and better protect user data in an increasingly complex digital world.