Table of Contents
Don't have the time to read the entire post? Our human writers will be sad, but we understand. Summarize the post with your preferred LLM here instead.
OAuth has long been the backbone of secure, delegated access, allowing third-party apps to access user data without ever handling passwords or other sensitive credentials. OAuth 2.0, introduced in 2012, remains the most widely used version today. But as threats grow more sophisticated, the standards we build on need to evolve.
That’s where OAuth 2.1 comes in.
OAuth 2.1 is a consolidation of OAuth 2.0 that folds the security best practices already recommended for 2.0 into the core standard: removing the implicit and password grants, requiring PKCE for all clients, and tightening redirect URI and refresh token handling.
OAuth 2.1 isn’t a full rewrite. It’s a security-focused update that consolidates proven best practices and deprecates outdated flows that can introduce vulnerabilities. While still a draft specification, OAuth 2.1 is already being adopted by many libraries and teams that want a cleaner, safer path forward. It’s particularly useful in AI agent ecosystems and is the preferred authorization approach in model context protocol (MCP) servers. Below, we’ll explain what OAuth 2.1 is and what to expect.
This article covers:
The context around OAuth 2.0
The changes OAuth 2.1 will bring
A comparison of OAuth 2.0 and 2.1
Migration considerations of OAuth 2.1
Why OAuth 2.1 matters for MCP
At a glance
The main changes from OAuth 2.0 to 2.1 are that PKCE is required for all clients, the implicit and password grants are removed, redirect URIs must match exactly, and refresh tokens must be rotated or sender-constrained.
OAuth 2.1 improves security by closing the flows and patterns most associated with token theft and phishing in OAuth 2.0.
Most teams that already follow current OAuth 2.0 best practices are close to OAuth 2.1 and should adopt these patterns now, since they are the direction the standard is moving.
OAuth 2.1 is a consolidating draft rather than a finalized standard, and it matters for AI agents and MCP servers because they rely on secure delegated access.
Quick refresher: OAuth 2.0
OAuth is an open-standard framework that allows third-party applications to request limited access to user data without ever seeing the user’s credentials. For a full breakdown of how the standard works, see What Is OAuth & How Does It Work. OAuth 2.0, introduced in 2012, became the go-to protocol for delegated authorization across web and mobile applications, powering everything from social logins to enterprise integrations.
It’s worth noting that OAuth 2.0 was itself a replacement for an earlier version, OAuth 1.0, published in 2010. The jump from OAuth 1 vs 2 was a much bigger change than the one from 2.0 to 2.1: OAuth 1.0 required every request to be individually cryptographically signed, a process that was secure but notoriously difficult to implement correctly, especially on mobile devices with limited native support for the required signature algorithms.
OAuth 2.0 traded that complexity for simplicity, relying on TLS to protect requests in transit instead of per-request signatures, and delegating security nuance to extensions and best practices published separately over the following decade. That decision made OAuth 2.0 dramatically easier to adopt, but it also left a wide gap between what the base spec technically allowed and what a secure implementation actually required.
OAuth 2.1 exists to close that specific gap, not to repeat the kind of ground-up redesign that separated OAuth 1.0 from OAuth 2.0.
At the heart of OAuth are four core roles:
Resource owner: The user who grants access to their data
Client: The application requesting that access
Resource server: The system that stores and protects the user’s data
Authorization server: The service that verifies user consent and issues the tokens used to access resources
OAuth uses short-lived access tokens to grant permission to specific resources, and refresh tokens to obtain new access tokens without requiring the user to reauthenticate. In an agentic system, an AI agent can use OAuth to request permission to call a tool through an MCP server.
Over the years, attackers have found ways to exploit misconfigured flows, steal tokens, and impersonate users. These vulnerabilities—and the inconsistent way OAuth 2.0 has been implemented—are a key reason why OAuth 2.1 was introduced: to streamline best practices and close common security gaps.
Read more: OAuth Vulnerabilities and Misconfigurations (and How to Fix Them)
What is OAuth 2.1?
OAuth 2.0 has been extended and adapted through community-driven best practices, optional security add-ons, and third-party library conventions. While flexible, this patchwork approach often led to inconsistent implementations and avoidable vulnerabilities.
OAuth 2.1 was introduced to improve security and simplicity across the ecosystem. Rather than reinventing the protocol, OAuth 2.1 streamlines it, retaining only the most secure, widely adopted practices while removing outdated and risky features like the implicit and password grant types. It formalizes what secure OAuth should look like today.
The result is a cleaner spec that’s easier to implement correctly and harder to get wrong, especially for developers building modern apps with high security expectations.
OAuth 2.1 remains an active Internet-Draft under the IETF OAuth working group rather than a finalized RFC. It consolidates changes already published across several separate specs, including PKCE (RFC 7636), OAuth 2.0 for Native Apps (RFC 8252), and the OAuth 2.0 Security Best Current Practice (RFC 9700), into a single, simplified core document. Several of these changes have already been adopted by many frameworks and security-conscious teams ahead of finalization, since they reduce the risk of common misconfigurations by hardcoding today’s best practices into the spec.
This is also why the OAuth 2.1 vs 2.0 comparison tends to confuse people who expect a version bump to introduce new capabilities. OAuth 2.1 doesn’t add new grant types, new token formats, or new endpoints. It removes options and narrows defaults. That makes it a smaller, more auditable spec, which is part of the point: a shorter, stricter document is easier for both humans and automated tooling to implement correctly.
How OAuth 2.1 improves security over OAuth 2.0
OAuth 2.1 improves security over OAuth 2.0 by requiring PKCE for every client, removing the implicit and password grants, enforcing exact redirect URI matching, and pushing refresh token rotation from an optional add-on to an expected default. Together, these changes close the flows and patterns most associated with token theft, credential exposure, and open redirect attacks in OAuth 2.0 deployments. Each change is detailed below.
PKCE is now required
Proof Key for Code Exchange (PKCE) is now mandatory for all clients using the authorization code flow. In effect, this protects against authorization code interception, and it’s especially important for public clients, mobile apps, and AI agents interacting with APIs.
Originally designed to secure native and mobile apps, PKCE prevents attackers from intercepting authorization codes and exchanging them for tokens. It works by having the client generate a random code verifier and a code challenge (a hashed version of the verifier) during the initial request. The authorization server stores the challenge, then verifies the client’s original code verifier before issuing tokens.
In OAuth 2.0, PKCE was recommended only for public clients. OAuth 2.1 removes that distinction, requiring it for all clients to close a critical attack surface across the board. With PKCE also being the recommended modality by the MCP specification, developers have all the more incentive to support this in their auth flows.
Implicit grant removed
The implicit grant flow has become obsolete and has been removed from OAuth 2.1.
Implicit flows allowed access tokens to be returned directly in the URL fragment, skipping the intermediate step of exchanging an authorization code. While convenient for early single-page apps (SPAs), this shortcut made tokens vulnerable to leakage via browser history, referrer headers, or malicious scripts.
With modern browser support for secure cross-origin requests (CORS) and the rise of frontend-backend architectures, the implicit flow is no longer needed and is now formally removed from OAuth 2.1. Moving forward, SPAs should use the authorization code flow with PKCE, which enables secure token handling and supports refresh tokens.
Password grant removed
The Resource Owner Password Credentials (ROPC) grant is also removed.
This flow required users to share their credentials directly with the client, which then exchanged them for access tokens. While it simplified things in tightly controlled environments, it introduced significant risks, exposing user credentials to third parties and making features like multi-factor authentication (MFA) or single sign-on (SSO) hard to enforce.
OAuth 2.1 removes the password grant to align with modern security models that minimize credential handling by third parties.
Exact redirect URI matching
OAuth 2.0 allowed flexible redirect URI matching using wildcards and substring patterns—intended to make development smoother. Unfortunately, this flexibility opened the door to open redirect vulnerabilities, where attackers could manipulate redirect URIs to steal tokens or impersonate apps.
OAuth 2.1 requires exact string matching for redirect URIs. Clients must pre-register every allowed redirect URI, and the authorization server must enforce an exact match. This eliminates ambiguity and makes unauthorized redirects far harder to exploit.
Refresh token rotation
Refresh tokens let clients renew access tokens without requiring the user to log in again. But if refresh tokens are not rotated, and an attacker steals one, they can bypass the entire authorization process indefinitely.
OAuth 2.1 requires that refresh tokens for public clients be either sender-constrained or rotated, using refresh token rotation, where each token is single-use and replaced on every request. If a rotated token is replayed, it’s immediately invalidated, stopping token replay attacks in their tracks.
Rotation is referenced in RFC 6819 and supported by most modern identity platforms. Combined with sender constraints or token binding, rotation significantly raises the bar for attackers attempting to abuse stolen tokens.
Side-by-side comparison: OAuth 2.0 vs. 2.1
OAuth 2.1 is not a complete overhaul of OAuth 2.0. It’s a more iterative update packed with quality-of-life features. It improves security by removing outdated protocols like ROPC and requiring exact URI matching. It supports best practices like refresh token rotation and PKCE auth flows. And it’s tailored to the specific needs of agentic workflows on MCP servers.
Here are the biggest differences between OAuth 2.0 and 2.1 at a glance:
OAuth 2.0 | OAuth 2.1 | |
|---|---|---|
Password Grant (ROPC) | Supported | Removed (deprecated for security and MFA incompatibility) |
Redirect URI Matching | Flexible (wildcards and substring matches allowed) | Exact string matching required |
Refresh Token Rotation | Optional | Required for public clients, sender-constrained or rotated |
Browser-Based SPA Support | Typically used implicit flow | Must use auth code flow with PKCE |
Spec Status | Finalized (RFC 6749) | Active Internet-Draft (consolidates best practices) |
Security Focus | Open to misconfigurations | Secure-by-default through enforced best practices |
AI/MCP Integrations | Possible but inconsistent | Preferred integration model |
Should you upgrade to OAuth 2.1?
Yes, or mostly yes: most teams should adopt the OAuth 2.1 patterns now, even before the draft finalizes, since they represent the direction the standard is moving and the security posture regulators and platforms increasingly expect.
OAuth 2.1 is designed for anyone building secure, modern applications. It’s especially relevant for new projects that want to start on solid ground: new SaaS products, API-first platforms, AI-heavy workflows on MCP servers, and companies modernizing their identity architecture.
For developers prioritizing security and simplified flows, adopting 2.1 patterns is a no-brainer.
For existing systems, the decision to migrate depends on your current setup. If you rely on flows removed in OAuth 2.1, you’ll need to evaluate the effort required to refactor, update your clients, and ensure compatibility with modern security requirements. Teams that already follow current OAuth 2.0 best practices—PKCE everywhere, no implicit or password grants, and exact redirect matching—have very little left to change.
Many popular OAuth libraries have already started adopting OAuth 2.1 defaults, making it easier to phase in best practices without a full rebuild. As security expectations rise across the industry, aligning with 2.1 isn’t just about compliance, it’s about staying ahead of known risks.
It helps to think about the upgrade decision in three separate buckets rather than one blanket yes or no.
The first bucket is new projects, where the answer is unambiguous: there is no good reason to build a new OAuth integration around the implicit grant or password grant in 2026, so new work should simply follow OAuth 2.1 patterns from day one, regardless of whether the draft has formally been published as an RFC by the time you ship.
The second bucket is existing systems that already follow current OAuth 2.0 best practices, meaning they use PKCE, avoid the deprecated grants, and enforce reasonably strict redirect matching. For this group, migrating to OAuth 2.1 is closer to a documentation and audit exercise than an engineering project, since the actual behavior of the system rarely needs to change.
The third bucket is legacy systems still running the implicit grant, the password grant, or loose redirect matching. This is where migration takes real planning, since removing these flows can break existing client integrations that were never updated, and it’s worth budgeting time for client outreach alongside the technical work.
One nuance worth calling out: OAuth 2.1 being a draft rather than a finalized RFC does not mean it is unstable or experimental. IETF specifications commonly see years of production use before formal publication. OAuth 2.1’s contents are, almost by definition, already running in production, since the draft consolidates practices pulled from specs and conventions that are themselves finalized or widely deployed.
Migration considerations
When considering whether to migrate to OAuth 2.1, consider the following checklist:
Current implementations – Audit your existing OAuth implementation. If you’re still using implicit or password grant types, begin planning a transition to supported flows like authorization code with PKCE.
Assess client compatibility – Confirm that all client applications—especially SPAs, mobile, or IoT apps—can securely handle the authorization code flow with PKCE. This is now required in OAuth 2.1.
Revise redirect URIs – Ensure that all pre-registered redirect URIs use exact string matching. Wildcards and flexible patterns are no longer supported.
Implement refresh token rotation – Check whether your refresh tokens are reused. If so, update them to rotate on every use, and consider using short lifespans and sender constraints for added protection.
Replace deprecated flows – Begin removing and disabling implicit and password grant flows. OAuth 2.1 assumes these are no longer part of your stack.
Educate your team – Make sure your developers understand the changes, especially those managing client registration, token handling, and security reviews. The shift to 2.1 is as much about education as it is about enforcement.
Why OAuth 2.1 matters for AI agents and MCP servers
OAuth 2.1 is critical for secure and efficient agentic workflows. AI agents operating within and across MCP servers need delegated, scoped authorization because they act on behalf of real-world users. Delegation allows for more granular control and supports privacy protection.
Especially through its new updates, OAuth 2.1 enables:
Secure delegated access via updated auth flows and best practices like PKCE
Scoped access tokens
Short-lived credentials that reduce the window of exposure if a token is compromised
User consent assurance through streamlined “allow” or “deny” prompts
Given these features, OAuth is better than API keys for agentic AI workflows. Descope’s own Agentic Identity Hub builds on this foundation, issuing scoped, short-lived credentials for AI agents and securing MCP servers with OAuth 2.1 and PKCE by default.
The reason OAuth 2.1 specifically—rather than OAuth 2.0 with some best practices layered on—matters so much for agentic systems comes down to how differently agents behave compared to human users in a browser.
A human clicking through an OAuth consent screen can visually verify a redirect URI, notice a suspicious domain, or simply abandon a login flow that feels wrong. An AI agent calling a tool through an MCP server has none of that judgment; it follows the protocol exactly as implemented, which means any gap between what OAuth 2.0 technically permits and what OAuth 2.1 requires becomes a gap an attacker can target without needing to fool a person at all. Requiring PKCE and exact redirect matching by default removes an entire category of attack that would otherwise depend on the agent, or the developer wiring up the agent’s auth flow, catching a subtle misconfiguration on their own.
There’s also a practical adoption angle specific to MCP: because the protocol is new and most MCP servers are being built from scratch rather than migrated from an older system, there’s very little legacy OAuth 2.0 code to work around. That makes MCP one of the cleanest places to see OAuth 2.1 patterns adopted natively, without the phased migration that older web and mobile applications typically need.
Embracing OAuth 2.1 for enhanced security
OAuth 2.1 isn’t about reinventing the wheel—it’s about making sure the wheel is bolted on securely. By consolidating years of hard-earned best practices and removing outdated, risky flows, it gives developers a cleaner, more reliable foundation for building secure auth systems.
Descope runs OAuth and OpenID Connect flows aligned with current best practices, so teams get OAuth 2.1-style security, including PKCE by default, without wiring it by hand. Sign up for a Free Forever account to start building secure, scalable auth flows today, or book time with our experts if you have questions about OAuth 2.1, 2.0, or MCP auth first.
