OAuth 2.0 and OAuth 2.1 are the same framework, with 2.1 folding a decade of security best practices into one cleaner specification. The main changes: PKCE is now required for every authorization code flow, the implicit and password grants are removed, and redirect URI matching and token handling are stricter. If you already follow current OAuth 2.0 guidance, you are most of the way to 2.1 already.
The short version is that nothing about OAuth's core idea changed. What changed is that the risky, optional, and legacy parts were cut, and the safe patterns became the default. This article explains exactly what is different, whether 2.1 is a finished standard yet, and what, if anything, you need to do. It is part of our modern authentication series.
As of 2026, OAuth 2.1 is still an IETF Internet Draft, not a finalized RFC. The draft consolidates and obsoletes the original OAuth 2.0 framework (RFC 6749) and bearer token usage (RFC 6750), pulling in security guidance that had been spread across later documents.
In practice, though, it already behaves like the standard. The major identity providers treat the grant types it retired as deprecated, security tooling has adopted its recommendations, and new guidance assumes it. So you should build to OAuth 2.1 today even though the formal RFC number has not been assigned. Treat the draft status as a paperwork detail, not a reason to wait.
The differences are a small set of deliberate cuts and tightenings. Here they are side by side.
| Area | OAuth 2.0 | OAuth 2.1 |
|---|---|---|
| PKCE | Recommended, mainly for mobile | Required for all authorization code clients |
| Implicit grant | Allowed | Removed |
| Password grant (ROPC) | Allowed | Removed |
| Redirect URI matching | Loosely defined | Exact string matching required |
| Refresh tokens for public clients | Allowed as-is | Must be sender-constrained or one-time use |
| Bearer tokens in URL query strings | Tolerated by some | Not allowed |
Each of these closes a real attack path, and the next sections explain the two that matter most.
PKCE, Proof Key for Code Exchange, adds a step where the client proves that it is the same party that started the login, so an intercepted authorization code is useless to anyone else. In OAuth 2.0 it was recommended, especially for mobile and single-page apps. In OAuth 2.1 it is required for every client using the authorization code flow, including confidential server-side apps.
This is the single most important change. It means the default login flow is now resistant to code interception out of the box, rather than depending on developers knowing to add PKCE themselves. If you build only one habit from 2.1, make it always using the authorization code flow with PKCE.
The implicit grant returned tokens directly in the browser redirect, which exposed them to scripts and browser history. It existed because older browsers could not safely do the token exchange step, a constraint that no longer applies, so 2.1 removes it in favor of the authorization code flow with PKCE.
The resource owner password credentials grant, where an app collected the user's username and password directly and traded them for a token, is also removed. It defeated the whole point of OAuth, which is to avoid handing your password to third-party apps, and it broke down completely once multi-factor and federated login became normal. Both removals push everyone toward redirect-based flows where the provider, not the app, handles credentials.
For most teams, moving to OAuth 2.1 is less a migration and more a confirmation that you are already on the safe path. If your apps use the authorization code flow with PKCE, avoid the implicit and password grants, match redirect URIs exactly, and rotate refresh tokens, you are effectively running 2.1 today.
The work appears only if you still rely on a removed flow. An old single-page app on the implicit grant should move to authorization code with PKCE. A service using the password grant should switch to a redirect-based flow, or for machine-to-machine calls, the client credentials grant. A good identity provider makes both of these configuration changes rather than rewrites, because the flows are standard.
MonoCloud is built to the modern defaults, so you get OAuth 2.1 patterns without assembling them yourself: the authorization code flow with PKCE, no reliance on the removed implicit or password grants, exact redirect handling, refresh token rotation, and the client credentials grant for machine-to-machine and agent calls. To see how these pieces fit into the bigger picture, read Modern Authentication Explained, or start building on MonoCloud for free.