Enhancing Security with OAuth 2.1: What You Need to Know

OAuth is a standard for sharing user account authentication data across various platforms. The name of this technology is quite literal - it's called Open Authorization. OAuth is an open standard that has been in development since 2006 when software engineer Blaine Cook worked on Twitter's OpenID implementation. Google joined in 2007, and OAuth 1.0 was released in 2010. Since then, many tech companies, including Facebook (Meta) and Microsoft, as well as smaller platforms, have adopted the open standard. OAuth 2.0 was published in 2012 and has been the most widely used open standard for user account federation ever since.

It's convenient to use a single login for multiple web and mobile apps, eliminating the need to enter your password for each service. Simplifying and streamlining user authentication processes can be highly beneficial for cybersecurity. If security systems are too complicated and frustrating, they are less likely to be used, particularly in education. Users often reuse passwords, which makes security controls less secure and facilitates credential-stuffing attacks. Unfortunately, even some cybersecurity professionals have confessed to reusing passwords.

Since OAuth 2.0’s publication and initial release in 2012, some additions have been made to the specification. The most significant of these additions is PKCE (Proof Key for Code Exchange), which was introduced to enhance security while authenticating into mobile applications. PKCE allows the use of the Authorization Code flow in an OAuth session without requiring a client secret. It is recommended to transmit sensitive authentication data discreetly and infrequently, and PKCE helps achieve this. Another important addition to the OAuth 2.0 specification is Device Grant, which enables OAuth usage on devices that do not support traditional user input methods.

OAuth 2.0 has been around for over 12 years now. Although there have been some updates to the specifications, a lot has changed in the world of online services and application security during this time. OAuth 2.1 is long overdue as some outdated encryption standards have been around for a while. The good news is that new standards undergo a lot of work before they are published as RFCs (Request for Comments in Internet Standardization). Let's take a look at how OAuth 2.1 will enhance the features of OAuth 2.0.

• PKCE will be mandatory for transmitting Authorization Codes. It's better to transmit client secrets infrequently to reduce the attack surface of sensitive authentication data.
• For the same reasons, refresh tokens must be either one-time use or sender-constrained. OAuth sessions can be quite long, which minimizes an attacker's ability to acquire tokens in a man-in-the-middle attack.
• To prevent cyber attackers from hijacking OAuth sessions, OAuth 2.1 requires that "redirect URIs must be compared with exact string matching." URLs are the most common type of URI, and they are addressed to resources on the internet. The exact string-matching redirect requirement makes it more difficult for an attacker to redirect data sent in a session to their own malicious internet resources, such as malicious websites.
• The Implicit Grant for access tokens has been removed because granting access tokens implicitly can lead to them being stolen by attackers. Implicit Grant also exposes tokens in single-page applications through the URL string or in a client-side area that's accessible to any JavaScript applet that may be running on the page.
• In OAuth 2.1, access tokens are forbidden in query strings, which are the extra-long URLs with funny code that you might have seen in your web browser. It is a security risk to expose access tokens.
• The resource owner password credentials grant was added to OAuth 2.0 to make it easier to migrate web applications to OAuth-compliant servers. The grant means application servers send passwords and other credentials to OAuth servers. However, it's not great for authentication security and has been removed in OAuth 2.1, which should encourage developers to improve their backend application security.

At present, no application can use OAuth 2.1. We will have to wait until the first RFCs of OAuth 2.1 are published, which may happen later in 2024. However, there is no official publication time frame available as of now. Until OAuth 2.1 is available, you can restrict the usage of access tokens with OAuth 2.0 and take advantage of some of the other security features that will be available with OAuth 2.1.