OAuth 2.1 hardens redirect and flow controls for modern IAM

At a glance

What this is: OAuth 2.1 is an update to OAuth 2.0 that tightens client, redirect, and flow requirements while folding in modern security guidance.

Why it matters: IAM teams need to treat OAuth client behavior, token exposure, and redirect integrity as governance issues for both human and non-human identities.

👉 Read Curity's analysis of OAuth 2.1 client, redirect, and PKCE changes

Context

OAuth 2.0 is often deployed as if token issuance alone solves authentication risk, but the real gap is governance around how clients are registered, how redirects are validated, and how tokens are protected after issuance. That gap matters for NHI because service applications, automation, and AI agents increasingly rely on OAuth-style delegation to reach APIs and data sources.

OAuth 2.1 does not change the core model, but it narrows the unsafe edges that had accumulated around the original framework. For practitioners, the important question is not whether OAuth exists in the stack, but whether client trust, PKCE, and redirect discipline are enforced with enough rigor to support modern workload and agent identities.

Key questions

Q: How should security teams implement PKCE across OAuth clients?

A: Apply PKCE to every authorization code flow, including confidential clients, and make it non-optional in your authorization server policy. Pair it with exact redirect URI registration and session binding so an intercepted code cannot be replayed into a different context. For workloads and agents, treat this as baseline identity hardening, not an advanced feature.

Q: When does OAuth token risk become an NHI governance problem?

A: OAuth token risk becomes an NHI governance problem whenever tokens are issued to automation, services, bots, or AI agents that can act without human presence. At that point, lifetime, scope, rotation, and revocation are access governance controls, not just secrets hygiene. The issue is blast radius, because a stolen token can operate exactly as the identity it represents.

Q: What is the difference between redirect URI validation and PKCE?

A: Redirect URI validation confirms that the authorization response returns to the correct registered endpoint, while PKCE binds the authorization request to the later token exchange. Validation blocks code delivery to the wrong place, and PKCE limits what a stolen or intercepted code can do. Secure deployments need both controls because they solve different failure modes.

Q: Should organisations still rely on bearer tokens for sensitive workloads?

A: Only with strong compensating controls. Bearer tokens are easy to use but easy to replay if exposed, so sensitive workloads should use short lifetimes, tight scopes, rotation, and sender-constrained patterns where possible. If a token can unlock high-value APIs, treat it as a standing privilege that needs active reduction, not passive storage.

Technical breakdown

How OAuth 2.1 changes client trust assumptions

OAuth 2.1 keeps the same roles, resource owner, client, authorization server, and resource server, but it removes assumptions that made client classes too rigid. A confidential client is now simply a client with credentials, while a public client has none. That matters because browser-based and native applications can still behave like confidential clients when a backend for frontend pattern or runtime registration is used. The technical shift is that the authorization server must evaluate how credentials were issued and whether they can be trusted, not just whether they exist. That reduces reliance on static client taxonomy and pushes more responsibility into runtime policy and registration controls.

Practical implication: Treat client trust as a runtime decision and require stronger registration and credential governance for any OAuth client that can act on behalf of users or workloads.

Why redirect URI exact matching and PKCE matter

OAuth 2.1 tightens redirect handling because the authorization code is only safe if it returns to the correct endpoint. Exact string matching for pre-registered redirect URIs reduces ambiguity, while HTTPS and stricter custom scheme rules close off common abuse paths. PKCE adds a second binding factor between the authorization request and token exchange, which prevents code injection and limits what an intercepted authorization code can do. The current draft also expects clients to prevent open redirects and defend against CSRF at the redirect endpoint. In practice, these are not usability details. They are the controls that keep an OAuth flow from being redirected into an identity pivot.

Practical implication: Enforce exact redirect registration, PKCE by default, and session-bound response handling for every OAuth client that exchanges authorization codes.

How token exposure changes the risk model

OAuth 2.1 does not eliminate token risk, it makes the remaining risk more explicit. Once a client holds an access token or refresh token, the security posture depends on token lifetime, scope, rotation, and whether the token is sender-constrained. The draft points practitioners toward short-lived tokens, one-time refresh tokens, and patterns such as phantom tokens or split tokens to reduce blast radius if a token is exposed. This is especially relevant when unauthenticated or weakly trusted clients are involved, because the authorization server must assume that token theft is a normal failure mode, not an edge case.

Practical implication: Minimise token usefulness after issuance by shortening lifetimes, rotating refresh tokens, and using sender-constrained or split-token patterns where exposure risk is material.

Threat narrative

Attacker objective: The attacker seeks token-based access to protected resources under a different or higher-trust identity context.

1. Entry occurs when an attacker intercepts or injects an OAuth authorization response at a weak redirect endpoint or mix-up-prone client session.
2. Escalation follows when the client fails to validate the authorization server, allowing a stolen or substituted code to be exchanged for tokens under the wrong identity context.
3. Impact is unauthorized access to protected APIs, with the attacker operating through legitimate token-based requests rather than noisy credential abuse.

Breaches seen in the wild

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

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 really a governance update, not just a protocol revision. The core logic of delegation stays intact, but the draft narrows the implementation space so teams have fewer excuses for insecure defaults. That matters because many identity failures are not caused by broken cryptography, but by permissive registration, sloppy redirects, and overly broad trust in client behavior. For practitioners, the question is whether their OAuth estate can actually enforce the protocol they think they have deployed.

Redirect integrity is a form of identity control, not a web-only concern. Exact URI matching, PKCE, and CSRF protection are often discussed as application security details, but they determine whether an authorization code remains bound to the intended session. In NHI environments, the same pattern shows up wherever automation or agents exchange tokens across services. Teams should treat redirect governance as part of the trust boundary for any workload that can obtain delegated access.

Sender-constrained and short-lived tokens should be the default security posture for modern OAuth estates. OAuth 2.1 makes it harder to justify long-lived bearer token sprawl, especially when clients are not strongly trusted. That aligns with the broader NHI problem: once a token exists, its value exceeds the session that created it. Practitioners should assume token exposure happens and design for reduced blast radius rather than perfect secrecy.

Dynamic client treatment is the right model for agentic and workload identities. OAuth 2.1 moves away from fixed assumptions about what a client type can or cannot do, which fits a world where services, bots, and AI agents may need different trust levels over time. Static labels are not enough when credentials are issued, distributed, and consumed in different ways. The practical takeaway is to manage client trust as policy, lifecycle, and runtime telemetry, not as a one-time registration choice.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 27% of organisations report that overprivileged machine identities create higher remediation costs than human account exposure, according to internal NHIMG research.
• For a broader control model, see Ultimate Guide to NHIs: Static vs Dynamic Secrets for how ephemeral credentials reduce exposure but do not remove governance requirements.

What this signals

Identity blast radius is the operative risk metric for OAuth estates. As OAuth 2.1 tightens the protocol, the remaining failure modes shift toward how long a token stays useful after exposure and how far it can travel before revocation. With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025, the wider identity ecosystem is already proving that exposure is normal, not exceptional.

OAuth governance is converging with broader secret and workload identity control. Teams that already map credentials through lifecycle, rotation, and revocation can absorb OAuth 2.1 with less friction, while teams that treat tokens as static implementation artefacts will keep accumulating risk. The practical shift is to audit client registration, token lifetime, and revocation workflows together, not as separate programmes.

Ephemeral credential trust debt: short-lived tokens still create long-lived exposure when the surrounding lifecycle is weak. That is why OAuth modernisation should be paired with stronger secret discovery and automated revocation discipline, especially where bots, services, and AI agents rely on delegated access. The control objective is not just better issuance, but faster loss containment.

For practitioners

• Mandate PKCE for every authorization code flow Require PKCE across confidential and public clients, and reject code flows that do not bind the authorization request to the token exchange.
• Register exact redirect URIs only Use pre-registered HTTPS redirect URIs with exact string matching, and review any custom URI scheme exceptions for abuse potential.
• Shorten token lifetime and scope Limit access token lifetime, reduce scopes to the minimum needed, and rotate refresh tokens so stolen credentials lose value quickly.
• Separate client trust from client type Assess how the client was issued, registered, and distributed before granting trust, especially when the client represents a workload or AI agent.
• Adopt sender-constrained token patterns Use sender-constrained tokens or split token architectures where token replay would create unacceptable blast radius.

Key takeaways

• OAuth 2.1 reduces ambiguity in client and redirect handling, but it does not remove the need for strong token governance.
• PKCE, exact redirect validation, and tighter token lifetimes are the practical controls that shrink exposure in delegated access flows.
• For NHI programmes, OAuth modernisation should be treated as lifecycle and blast-radius work, not as a protocol upgrade alone.

Key terms

• OAuth 2.1: OAuth 2.1 is an updated version of OAuth 2.0 that consolidates modern security guidance into the core protocol. It keeps the same delegation model but tightens requirements around flows, redirects, PKCE, and token handling so implementations are less dependent on optional best practices.
• PKCE: Proof Key for Code Exchange is a binding mechanism that links the authorization request to the later token exchange. It helps stop authorization code interception and injection by requiring proof that the same client that started the flow is the one completing it.
• Redirect URI: A redirect URI is the endpoint where an authorization server sends the user back after a login or consent step. In secure OAuth implementations, it must be pre-registered and matched exactly so an attacker cannot divert the response to a malicious destination.
• Sender-constrained token: A sender-constrained token is tied to a specific client or cryptographic proof, rather than being usable by anyone who steals it. This reduces replay risk and is especially important where tokens can reach automation, services, or agents with broad API access.

Deepen your knowledge

OAuth 2.1 redirect governance, PKCE enforcement, and token lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are tightening delegated access for workloads or AI agents, it is a useful place to start.

This post draws on content published by Curity: OAuth 2.1 and secure implementation guidance. Read the original.