OAuth 2.0 was published as a framework with many options, several of which turned out to be bad ideas. Over the following decade, security guidance accumulated in separate documents: use PKCE, stop using implicit flow, rotate refresh tokens, match redirect URIs exactly. Everyone doing this properly already followed that guidance. Everyone not doing it properly was still technically compliant with OAuth 2.0.
OAuth 2.1 closes that gap by making the guidance the specification.
What changed in 2026
- Adoption pressure increased. Identity providers and API platforms began requiring 2.1-conformant behavior rather than merely recommending it, which turned an optional upgrade into a deadline for some integrations.
- Legacy grant removal became concrete. Providers started disabling implicit and password grants on real endpoints rather than only marking them deprecated.
- Agent and machine clients raised new questions. As automated clients proliferated, the question of how to authorize software acting on a user's behalf gained practical urgency.
- Documentation caught up. Provider guides converged on a single recommended flow, which reduced the historical confusion about which of six options to pick.
What is actually different
| Change |
OAuth 2.0 |
OAuth 2.1 |
| PKCE |
Optional; recommended for public clients |
Required for all authorization code flows |
| Implicit grant |
Available |
Removed |
| Resource owner password grant |
Available |
Removed |
| Redirect URI matching |
Various strategies permitted |
Exact string match required |
| Bearer tokens in query strings |
Discouraged |
Prohibited |
| Refresh tokens for public clients |
Permitted |
Must be sender-constrained or one-time use |
None of these will surprise anyone who has read the security best current practice documents. That is the point — 2.1 is the consolidation, and if you built your integration in the last few years following current guidance, the migration is largely verification rather than work.
The redirect URI change catches the most people. Applications that relied on prefix or wildcard matching to handle multiple environments or dynamic paths need to register each URI explicitly. That is more registration overhead and it closes a genuine attack path where an attacker exploits loose matching to redirect an authorization code to a controlled endpoint.
Checking your integration
Four things to verify. Are you sending a PKCE code challenge on every authorization code request, including from confidential server-side clients? Are any flows still using implicit or password grants — often in older mobile apps or internal tools that nobody has touched? Are your redirect URIs registered as exact strings? And are refresh tokens for public clients rotated on use?
If all four are already true, you are compliant and the migration is a documentation update. If any are false, the fix is well-defined and the provider documentation will walk you through it.
Pay attention to the internal tools. The password grant survives longest in scripts and admin utilities written years ago by people who have moved on, and those break silently when a provider disables the grant. Inventory before the deadline rather than after. For the foundations, OAuth explained covers the flows themselves and OAuth vs JWT clears up a common confusion.
Common mistakes
- Thinking PKCE is only for mobile. 2.1 requires it everywhere, and it costs almost nothing to add.
- Leaving legacy grants in internal tooling. These are the integrations that break unnoticed.
- Using wildcards in redirect registration. Exact match is required and is a real security improvement.
- Storing tokens in browser local storage. Not a 2.1 change, but persistently bad practice worth fixing during the same review.
- Treating refresh token rotation as optional for public clients. It is the mechanism that limits damage from a stolen token.
FAQ
Do I have to migrate immediately?
That depends on your identity provider's timeline for disabling legacy grants. Check their deprecation notices rather than assuming you have time.
Is OAuth 2.1 backward compatible?
Clients following current best practice work unchanged. Clients relying on removed grants or loose redirect matching do not.
Does this affect OpenID Connect?
OpenID Connect builds on OAuth, so the same flow requirements apply. Provider guidance will specify the details for identity flows.
What about machine-to-machine authorization?
The client credentials grant remains and is the correct choice for service-to-service authorization with no user involved.
Where to go next
For the fundamentals, read OAuth explained and OAuth vs JWT. For agent-specific authorization concerns, AI agent permissions.