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.
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
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.
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.
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.
Interested in learning more? Sign up for a demo today.