OAuth 2.1: How Many RFCs Does it Take to Change a Lightbulb?

The OAuth working group agreed last month in Singapore (IETF 106) that work will begin to update the current OAuth 2.0 Framework to a potential version 2.1 encompassing all the latest recommendations and best practices around the specification. This is in part due to the maze of documentation that developers need to understand when getting started on the topic to choose the correct flow and implement the best security posture for their application landscape.

By consolidating the most recent Best Current Practice (which is in a last call review stage) into a new 2.1 version of the framework it is hoped that developers have a single place where they can refer to digest the latest documentation and spend more time coding the underlying application. Although there is still some debate about the exact form of the new consolidated specification, it is a positive step for the development community that there is a commitment now to work towards some simplification.

What’s Changing in OAuth 2.1?

The biggest changes since the original RFC6749 specification was published in 2012 are that implicit flow and resource owner password flow are now deprecated. Other flows introduced later such as Authorization Code Flow with PKCE (RFC7636) are now replacing the initial recommendations for certain use cases and additional security countermeasures to protect against CSRF type attacks and redirect based flows recommendations have offered a solution to avoid incidents such as the Azure account takeover vulnerability.

Okta has already implemented the proof key code exchange recommendations for single page apps as well as only allowing explicit pre-registered redirect URIs.

You can learn more about the specifics of the OAuth 2.1 proposal by reading Aaron Parecki’s post It’s Time for OAuth 2.1.

Will there be an OAuth 3.0?

There is also work beginning on a potential OAuth 3.0 specification by several people in the OAuth working group. While it’s likely that these RFCs wouldn’t be available in the short term and the implementation by authorization server vendors such as Okta would occur at some point in the future, it is interesting to stay up to date on what kinds of rich authorization data models could be used by developers and underlying applications in the future.

Learn More about OAuth

If you’d like to learn more about OAuth, check out these other resources from our blog!

• Is the OAuth 2.0 Implicit Flow Dead?
• What’s Going On with the OAuth 2.0 Implicit Flow? (video)
• 7 Ways an OAuth Access Token is like a Hotel Key Card
• Why OAuth API Keys and Secrets Aren’t Safe in Mobile Apps
• Implement the OAuth 2.0 Authorization Code with PKCE flow

Like what you learned today? Follow us on Twitter and subscribe to our YouTube channel for more awesome content!