OAuth is an authorization protocol that allows delegated access, enabling systems to scale securely. The OAuth 2.0 standard is defined in RFC 6749. OAuth 2.1 is currently a draft and is described in draft-ietf-oauth-v2-1.
OAuth is an authorization protocol that provides a secure way to grant access to resources without sharing credentials. It defines various methods to obtain tokens representing the permissions of users or machines.
In OAuth, an access_token is typically an opaque string that has a defined scope and expiration time.
It allows delegated access to resources.
A common example involves allowing an application to read your Gmail contacts without accessing your email. This illustrates how scopes restrict access. Access is usually time-limited and can be revoked.
OAuth 2.0 was published in October 2012 as RFC 6749, replacing the original OAuth 1.0 protocol. While OAuth 1.0 required clients to sign requests using cryptographic keys, OAuth 2.0 focused on simplicity and flexibility, shifting to bearer tokens and supporting a wider variety of client types and use cases.
Over time, OAuth 2.0 became the industry standard for delegated authorization, enabling users to grant third-party applications limited access to their resources without sharing passwords. It introduced multiple "authorization flows" to accommodate different client types, such as web servers, mobile apps, and JavaScript-based single-page applications (SPAs).
In OAuth 2.0, authorizations are granted through access tokens, which are obtained via specific authorization flows:
Also known as the password flow, this method involves exchanging a username and password directly for an access_token.
This flow is considered obsolete and insecure, as it requires users to share their credentials with the client.
In the client credentials flow, a client_id and client_secret are exchanged for an access_token.
This flow does not involve user interaction and is suitable for machine-to-machine communication.
The implicit flow was designed for single-page applications (SPAs) that run entirely in the browser.
Users are redirected to the authorization server to authenticate and then redirected back with an access_token
included in the URL fragment.
This flow is now considered insecure and obsolete because tokens can be exposed via browser history or interception. Modern applications are encouraged to use the Authorization Code flow with PKCE instead.
The Authorization Code flow is designed primarily for server-side web applications.
The user is redirected to the authorization server to authenticate and is then redirected back to the application with an authorization code.
The application exchanges this code, along with its client_id and client_secret, for an access_token.
Despite the success of OAuth 2.0, it received criticism for its complexity, security pitfalls, and lack of guidance around common issues. As a result, some flows like the Implicit Flow and Resource Owner Password Credentials Flow are now considered insecure and deprecated.
To address these issues, the OAuth working group introduced OAuth 2.1—currently a draft—which consolidates best practices, removes deprecated flows, and recommends modern security enhancements such as PKCE and redirect URI validation by default.
Although OAuth 2.1 is still officially a draft, it is intended to replace OAuth 2.0 by consolidating best practices and removing deprecated flows.
OAuth 2.1 removes the Implicit Flow and the Resource Owner Password Credentials Flow, while adapting the Authorization Code Flow to support public clients through the use of PKCE. As a result, OAuth 2.1 defines the following supported flows:
Unlike the Resource Owner Password Credentials Flow, the Client-Credentials Flow is still available in OAuth 2.1. It is still intended to be used for machine to machine connectivity.
Learn what the Client-Credentials Flow is and how it works.
The Authorization Code Flow has been improved for modern use cases.
Unlike the Implicit Flow, it is inherently more secure: a code is exchanged for a token using both the code and a client_secret.
However, to replace the Implicit Flow in public clients such as single-page or mobile applications, the Authorization Code Flow had to be adapted.
Public clients cannot securely store client_secrets, so an alternative mechanism was needed.
With Authorization Code Flow and PKCE (Proof Key for Code Exchange), a temporary, one-time-use secret—called a code verifier—is generated at the start of the authorization request. This value is transformed into a code challenge and sent to the authorization server when the user is redirected to the login page. When the user returns to the application with an authorization code, the app must present the original code verifier to exchange the code for a token. This ensures that only the original client that initiated the request can complete the flow.
Learn what the Authorization Code Flow + PKCE is and how it works.
The security of any protocol depends on the context in which it is used. While some flows such as the Implicit Flow have historically served specific use cases — particularly in browser-based applications — the industry has steadily shifted toward more robust alternatives.
OAuth 2.1 reflects current best practices by deprecating certain flows and emphasizing stronger mechanisms like PKCE. These updates help reduce implementation errors and improve baseline security across diverse environments.
At Entrypage, we choose to support OAuth 2.1 exclusively. This decision aligns with our commitment to security, simplicity, and maintainability. We encourage teams to evaluate their needs and consider migrating to more modern flows where appropriate.
Written by: Albert Starreveld
IAM Architect / Cloud Architect / Founder @ Entrypage.io
Published on: 24-04-2025