OAuth 2.1 tightens identity security defaults for apps and agents

At a glance

What this is: OAuth 2.1 is a security-focused update that removes risky OAuth 2.0 choices and makes stronger defaults mandatory for modern app and agent authentication.

Why it matters: It matters because IAM teams now have a cleaner baseline for human, workload, and agent access patterns, especially where token leakage or delegation risk can undermine governance.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read WorkOS's guide to OAuth 2.1 migration and secure defaults

Context

OAuth 2.1 is the identity layer update that narrows the choices developers have to make during authorization. The key security problem is not new functionality but too much flexibility in OAuth 2.0, which left room for unsafe flows, weak redirect handling, and token exposure in implementations that looked valid but were hard to govern.

For IAM and NHI programmes, that matters because the same token patterns now span web apps, SPAs, APIs, and AI agent tool access. When a protocol starts to govern both human-facing sessions and machine-to-machine delegation, the baseline controls have to be strict enough to survive both use cases.

Anthropic's use of OAuth 2.1 in MCP is a sign that authorization patterns for software agents are converging on identity controls that were originally built for applications, not autonomous execution. The governance question is no longer whether OAuth applies, but whether the implementation assumptions are still strong enough for modern delegated access.

Key questions

Q: How should security teams migrate existing apps from OAuth 2.0 to OAuth 2.1?

A: Start by inventorying every authorization flow, then remove implicit and password grants, enable PKCE for all authorization code clients, and tighten redirect URI validation to exact string matching. After that, shorten token lifetimes, rotate refresh tokens, and confirm storage never exposes bearer tokens to logs, URLs, or browser history.

Q: Why do OAuth 2.0 implementations create more governance risk than OAuth 2.1?

A: OAuth 2.0 leaves too many security choices optional, which creates inconsistent implementations across teams and products. OAuth 2.1 reduces that variance by removing legacy flows and making safer defaults mandatory, so governance teams can enforce one baseline instead of chasing local exceptions.

Q: What breaks when redirect URI validation is too permissive in OAuth?

A: Permissive redirect URI handling can misroute authorization codes or tokens to unintended endpoints, which expands the attack surface for open redirect abuse and token interception. Exact string matching closes that loophole and makes the callback path auditable rather than approximate.

Q: Which identity controls matter most when OAuth is used for AI agent tool access?

A: Exact redirect matching, short-lived tokens, PKCE, and refresh token rotation matter most because agent tool access is a delegated path with real replay and misuse potential. If the agent is connecting to tools through MCP or similar patterns, treat the OAuth flow as privileged NHI delegation, not ordinary app login.

Technical breakdown

PKCE and authorization code interception

PKCE, or Proof Key for Code Exchange, binds the authorization request to the token request with a code verifier and code challenge. That closes off a common interception path where an attacker steals an authorization code and redeems it elsewhere. OAuth 2.1 makes PKCE mandatory for all authorization code flows, which removes a major source of implementation variance. In practice, the security win comes from reducing trust in a code alone and forcing proof that the same client that started the flow is finishing it.

Practical implication: require PKCE everywhere and reject clients that do not generate and validate a fresh code verifier per login.

Refresh token rotation and bearer token replay

OAuth 2.1 keeps bearer tokens but tightens how they are handled. Bearer tokens are still usable by whoever holds them, so storage and transport remain the critical control points. Refresh token rotation reduces replay value by replacing the old token on every use, while sender-constrained tokens bind usage to a specific client or key. For SPAs and other public clients, this shifts the design problem from avoiding refresh tokens entirely to managing them with stronger containment and stricter session lifecycle control.

Practical implication: pair short-lived access tokens with refresh token rotation or sender-constrained tokens where replay risk is material.

Redirect URI exact match and removed legacy grants

OAuth 2.1 removes the implicit grant and the password grant, then requires exact string matching for redirect URIs. Those changes matter because both legacy grants and loose redirect validation created broad error surfaces that were easy to misuse and hard to audit. Exact matching blocks wildcard abuse and misrouted token delivery, while removing deprecated grants narrows the protocol to patterns that centralize user authentication at the authorization server instead of the client.

Practical implication: inventory every redirect URI, remove wildcards, and retire any flow that still depends on implicit or password grants.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth 2.1 is a control-layer correction, not a feature upgrade. The protocol does not add new expressive power; it removes ambiguous paths that repeatedly produced insecure implementations in OAuth 2.0. That matters because the failure mode was not theoretical weakness in the standard, but the governance burden created by optional security choices. Practitioners should read OAuth 2.1 as a hardening baseline for delegated identity, not as a new capability tier.

PKCE everywhere closes one class of OAuth implementation drift, but it does not solve trust visibility. A cleaner authorization code flow reduces interception risk, yet teams still need to know where tokens are stored, who can use them, and how clients are registered. In NHI terms, the control gap is not just issuance, but lifecycle visibility into every token-bearing integration. The practitioner conclusion is that safer protocol defaults only help when the surrounding entitlement model is equally explicit.

OAuth 2.1 exposes the fragility of mixed human and machine delegation patterns. The same token mechanics now govern browser apps, service-style integrations, and AI agent tool access. That means identity teams can no longer treat OAuth as a single-app authentication concern; it is a cross-domain delegation standard that now sits inside NHI governance, application security, and federated access policy at once. Practitioners should align protocol policy with actor type before implementation sprawl sets the rules.

Tool access for AI agents should inherit the strictest OAuth defaults, not the loosest legacy ones. MCP-style delegation depends on authorization being understandable at runtime, but OAuth 2.0 flexibility often let teams improvise around the controls. OAuth 2.1 reduces that ambiguity by making the safer path the default. The implication is that agentic tool access should be governed as a high-discipline NHI pattern, with no tolerance for deprecated grant types or weak redirect handling.

Identity blast radius becomes smaller when the protocol removes optional insecurity. Identity blast radius: the amount of access and replay value an attacker can extract from a single token or authorization mistake. OAuth 2.1 shrinks that blast radius by narrowing flow choices, forcing exact redirect matching, and reducing replay utility. For practitioners, the relevant question is no longer whether OAuth can be secured in theory, but whether the deployed implementation still leaves room for old 2.0 assumptions.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is why delegated access remains hard to govern at scale.
• That same visibility gap is why readers should also review Ultimate Guide to NHIs - Why NHI Security Matters Now for the broader lifecycle and breach context.

What this signals

Identity teams should treat OAuth 2.1 as a governance floor, not an implementation detail. The practical shift is that protocol decisions now need to be aligned with actor type, especially when the same authorization pattern supports both human sessions and NHI delegation. Programs that still tolerate optional security choices in OAuth are carrying avoidable policy drift into their application and integration estate.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, delegated access is already a control problem. That figure shows why token lifecycle, client registration, and redirect governance cannot be left to application teams alone. The pattern fits the broader NHI visibility gap, and OAuth 2.1 helps only if the surrounding inventory and review process are equally disciplined.

Agent tool access will force a stricter interpretation of least privilege for OAuth-backed identities. As more software uses delegated tokens to reach external tools, teams need a named concept for the control surface: delegation drift: when an OAuth integration continues to operate beyond the scope, client assumptions, or review cadence that originally justified it. The answer is not more flexibility, but tighter authorization governance backed by standards such as NIST Cybersecurity Framework 2.0.

For practitioners

• Audit every OAuth flow against the 2.1 baseline Map each client to its grant type, PKCE status, redirect URI pattern, and token storage method. Remove any remaining dependence on implicit or password grants, and flag flows that still allow broad redirect matching or token handling outside HTTPS.
• Enforce PKCE for all authorization code clients Require a fresh code verifier for every login, validate the code challenge on the token request, and reject clients that still rely on static or reused verifier values. This should apply to confidential clients as well as public clients.
• Rotate or bind refresh tokens by default Use refresh token rotation for public clients and high-risk applications, and evaluate sender-constrained tokens for regulated or high-value integrations. Treat long-lived reusable refresh tokens as a replay liability, not a convenience feature.
• Remove wildcard redirect URIs and test exact matches Inventory all registered redirect URIs, convert any wildcard or partial patterns to explicit strings, and test authorization requests against the exact callback values your identity provider will accept. This limits open redirect exposure and token misdelivery.
• Apply stricter OAuth policy to AI agent tool access Treat MCP and other agent tool connections as high-risk delegated access paths. Require the same exact-match redirect handling, short-lived tokens, and rotation rules that you would apply to privileged NHI integrations.

Key takeaways

• OAuth 2.1 reduces implementation ambiguity by removing legacy grant types and making secure defaults mandatory for authorization code flows.
• The biggest practical gains are in PKCE enforcement, exact redirect validation, and better token handling, which lower interception and replay risk.
• For IAM and NHI programmes, OAuth 2.1 should be treated as a baseline for delegated access governance across apps, SPAs, APIs, and AI agents.

Key terms

• OAuth 2.1: OAuth 2.1 is a tightened version of OAuth that removes unsafe legacy flows and makes modern security defaults mandatory. It keeps the basic delegation model but narrows implementation choices so teams are less likely to ship insecure authentication paths for web apps, APIs, SPAs, and agents.
• PKCE: PKCE, or Proof Key for Code Exchange, is a method that binds an authorization request to the token exchange using a verifier and challenge. It prevents intercepted authorization codes from being redeemed elsewhere, and in modern OAuth it is a baseline control rather than an optional enhancement.
• Refresh Token Rotation: Refresh Token Rotation replaces a refresh token with a new one each time it is used, and invalidates the old token immediately. This reduces replay risk if a token is stolen and helps identity teams limit the value of long-lived delegated access in browser and public-client contexts.
• Redirect URI Exact Match: Redirect URI exact match means the authorization server only accepts the specific callback URL that was pre-registered, with no wildcards or loose patterns. This removes ambiguity in where authorization responses are delivered and closes off a common route for open redirect and token misdelivery attacks.

Deepen your knowledge

OAuth 2.1 migration, PKCE enforcement, and delegated token governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are standardising authentication across apps, APIs, and AI agent integrations, it is worth exploring.

This post draws on content published by WorkOS: OAuth 2.0 vs OAuth 2.1: What changed, why it matters, and how to upgrade. Read the original.