What is OAuth 2.1?


The challenge with creating web standards and frameworks is that technology evolves so quickly that within a short amount of time your framework is already out of date. This is especially true for web-based application development, given how different the world looks today than it did in 2012 when the spec was first introduced. Native apps are the preferred method for users to bank, shop, and manage their lives and browserless devices like AppleTV and Smart TVs are more commonly found in consumer households. Understanding what changes are proposed as part of OAuth 2.1 and ensuring that your current authorization server supports the demands of single-use token minting is critical to securing your applications from the latest cybersecurity threats.

What is OAuth 2.1

OAuth 2.1 represents the next step for the OAuth framework by combining Security Best Common Practices (BCPs) with removal of irrelevant and deprecated specifications. As Aaron Parecki—a member of the OAuth working group—writes on his blog post, the goal of 2.1 is to simplify implementation given that the framework has undergone revisions and has added new specifications over the years, making adoption feel like navigating a maze of best practices and new standards.

OAuth maze
Navigating OAuth RFCs. Credit to Aaron Parecki (https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-dot-1)

Today OAuth looks much different than what was originally proposed in the RFC in 2012 (RFC-6749), with the introduction of PKCE and the deprecation of flows like implicit code grant and password for public applications. Along with these changes, the biggest update to OAuth 2.1 comes by way of recommendations on the reuse of refresh tokens. This change will require authorization servers to significantly scale to accommodate token minting requirements.

Deprecation of the Implicit Code Grant Flow

As web browsers began adopting support for Cross Origin Resource Sharing (CORS), the implicit code grant flow was no longer necessary for javascript-only applications like Single Page Applications (SPAs). The application could access the authorization token endpoint to exchange the authorization code and it was no longer necessary—or advisable—to include the authorization token as part of the URL response. Additionally, examples of access token leaks and access token replay attacks were found in the wild resulting in the IETF OAuth working group to officially declare implicit code grant flow as vulnerable and recommend migrating any applications over to the authorization code grant flow. With OAuth 2.1, the implicit code grant flow will be removed entirely and replaced with the Authorization Code Grant Flow with PKCE, putting to rest any doubt as to the status of implicit code grant flow.   

Authorization Code Grant with PKCE

PKCE (or Proof Key Code Exchange) was first introduced in 2015 as a way to protect against authorization code injection attacks that resulted in malicious applications getting access to authorization tokens, enabling them to connect to a resource server (i.e. API) and access user data. PCKE was developed as a means to create a transaction-specific, securely bound and sender-constrained access tokens that would provide an additional validation through the use of a secret-key generated by the application. Originally built as a way to add additional security measures to SPAs and native applications (mobile), OAuth 2.1’s draft recommends adopting the PKCE extension as part of the authorization code grant flow and leveraging the additional security for all web-based applications.   

Authorization Code Hijack
An Authorization Code Hijack Attack.

Single-Use Refresh Tokens – Refresh Token Rotation

The OAuth working group have started to provide clear guidance and instruction around the use of refresh tokens, based on recent BCPs and RFC-6819. Refresh tokens are long-lived by nature, meaning that their use and expiration is meant to be longer than that of short-lived access tokens. The logic behind this is to provide a way for the application to reauthenticate with the authorization server after an access token has expired without having to prompt the user for consent and restart the flow all over again. This provides a better user experience and adds additional security by ensuring that access tokens—which are inherently vulnerable—are short-lived, limiting the value that an attacker would gain from hijacking the token. Over time, the nature and use of refresh tokens have needed some attention as applications with indefinite refresh tokens were having tokens compromised effectively giving unlimited access tokens to attackers. Additionally, data privacy laws like GDPR require that consent for data sharing be specific and time-bound meaning that indefinite refresh tokens fall short of meeting the standards. For public applications—including browser-based applications—where the refresh token could be intercepted, the threat is particularly high so the OAuth working group have published recommendations around how best to secure and protect refresh tokens from compromise. [Best Current Practice]

OAuth 2.1 adopts the latest BCPs as part of the standard practice for implementation, with the recommendation that refresh tokens be set to a maximum lifetime. Additionally, they suggest an approach where refresh tokens are recycled—refresh token rotation—and replaced on a continual basis. For many teams, this means that refresh tokens will likely be limited to single-use and token minting and exchange will need to happen on a continuous basis. For many “build your own” auth servers, the throughput needed to scale the process and support distributed applications might require additional resources to deliver.

Wrap Up

At Cloudentity, our Authorization Control Plane is built to provide support for the highest levels of security, as recommended by the OAuth working group, with performance that’s capable of supporting massive scale. As OAuth adoption continues to flourish and teams add authorization to distributed architectures, it’s critical that your authorization server handle the increased demand of single-use refresh tokens used in refresh token rotation. OAuth can be challenging to implement correctly. Fortunately, Cloudentity is here to help.

Workspace Authorization Server Settings within Cloudentity

Interested in learning more? Sign up for a demo today.