Advancements in OAuth: A Deep Dive into OAuth2 and OAuth2.1

“OAuth2 and it’s team deciding who’s allowed to the party” — @jabronidude

Since its inception, the OAuth authorization framework has been a cornerstone of secure user data access. The most widely used version, OAuth2, offers an abundance of features and grant types, suitable for various use cases. However, with the ever-evolving technology landscape and security practices, the OAuth community has put forth an effort to consolidate and simplify the OAuth2 specification. This initiative is known as OAuth2.1.

OAuth2: The Bedrock of Modern Authorization

OAuth2, short for Open Authorization version 2, is an authorization framework that allows third-party applications to obtain limited access to a user’s resources or data on another service provider. OAuth2 is about permissions — what a validated user is allowed to do.

A familiar example of OAuth2 at work is when websites offer the option to log in using a Google or Facebook account. In these instances, Google or Facebook is the service provider that possesses your data, while the website you’re trying to access is the third-party application. The website doesn’t need to know your Google or Facebook login credentials to access your basic profile data. This is where OAuth2 shines.

The core of OAuth2 involves a series of “flows” (also called grant types) that involve multiple redirections between the third-party application, the user, and the service provider. The most common flow, the Authorization Code Grant, is used by web and mobile apps. This flow involves an authorization request, user login, authorization grant, access token request, access token response, and finally, resource access.

The Evolution: OAuth2.1

Since the original publication of OAuth2, detailed in a Request for Comments document (RFC 6749) in 2012, there have been several new specifications that either add or remove functionality from the core spec. This includes OAuth 2.0 for Native Apps (RFC 8252), Proof Key for Code Exchange (RFC 7636), OAuth for Browser-Based Apps, and OAuth 2.0 Security Best Current Practice. OAuth2.1 is an ongoing effort to consolidate these changes to simplify the core document.

Here are the major differences between OAuth2 and OAuth2.1:

• PKCE: Proof Key for Code Exchange (PKCE) is now required for all OAuth clients using the Authorization Code flow. This is a significant change aimed at enhancing security for mobile and native applications.
• Redirect URIs: These must now be compared using exact string matching. This change prevents potential security loopholes where a redirect URI that closely resembles the legitimate one could be used.
• Omission of Implicit and Resource Owner Password Credentials Grants: Both these grants are removed from OAuth2.1 due to their inherent security vulnerabilities. The Implicit Grant, for instance, exposes the access token directly to the user agent, increasing the risk of it being leaked. The Resource Owner Password Credentials Grant, on the other hand, encourages clients to handle user credentials directly, contradicting the principle of credential handling separation that OAuth2 promotes.
• Bearer Tokens: The use of bearer tokens in the query string of URIs is omitted, further enhancing security. This prevents the token from being leaked through browser history or logs.
• Refresh Tokens: For public clients, refresh tokens must either be sender-constrained or one-time use. This reduces the chances of token theft and replay attacks.
• Simplified Client Definitions: The definitions of public and confidential clients have been simplified to only refer to whether the client has credentials. This makes it easier to understand the difference and when to use each type.

Conclusion

OAuth2.1 is not a new version of OAuth, but rather a consolidation of OAuth2 and its subsequent extensions. By simplifying the specification and removing less secure features, OAuth2.1 aims to make it easier for developers to understand and securely implement the protocol.

These changes, while they may seem minor, have significant implications for application security. The increased security measures reduce the risk of token leakage and make the protocol more robust against attacks, ensuring that user data remains secure.

As we anticipate the finalization of OAuth2.1, it’s crucial for us, as developers, to stay updated and understand these changes. After all, maintaining user trust through secure data access is paramount in the digital age.

What are your thoughts on these changes in OAuth2.1? Do you believe they will significantly impact the way you implement authorization in your applications? Share your experiences with OAuth2 and your anticipations for OAuth2.1 below. I’d love to hear your thoughts!

• IETF. (2023, March 13). The OAuth 2.1 Authorization Framework. Retrieved from https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08
• IETF OAuth Working Group. (2022). The OAuth 2.1 Authorization Framework (draft-ietf-oauth-v2–1–08). Internet Engineering Task Force. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08