TL;DR: OAuth 2.1 removes risky grant types, makes PKCE mandatory for all authorization code flows, and requires exact redirect URI matching plus refresh token rotation, according to WorkOS. Those changes matter because they turn once-optional OAuth hardening into a safer baseline for apps, APIs, SPAs, and AI agent tool access.
At a glance
What this is: OAuth 2.1 is a curated update to OAuth that removes risky flows and makes core protections mandatory for authorization code usage.
Why it matters: IAM, IGA, PAM, and platform teams need to understand the shift because OAuth 2.1 changes the secure baseline for app logins, delegated access, and agent-to-tool authentication.
Context
OAuth 2.1 is an authentication and authorization update that narrows OAuth 2.0’s flexibility so secure patterns become the default. The main governance problem is not new capability, but reduced ambiguity: teams no longer need to decide whether to allow flows that expose credentials, tokens, or redirect handling to avoidable risk.
For identity programmes, the shift matters across human, NHI, and agentic access patterns because the same protocol often underpins app sign-in, API delegation, and workload or agent-to-tool access. WorkOS frames OAuth 2.1 as a better baseline for modern implementations, especially where PKCE, refresh token handling, and exact redirect validation are now expected rather than optional.
Key questions
Q: What should teams do first when they still rely on OAuth 2.0 flows that OAuth 2.1 removes?
A: Start by inventorying every authorization flow in use, then replace implicit and password grants with authorization code plus PKCE. That sequencing matters because deprecated flows are the most likely to leak tokens or credentials, and they are the easiest place to remove risk before wider protocol changes.
Q: Why do PKCE and exact redirect URI matching reduce OAuth abuse?
A: They reduce abuse because both controls narrow the points where an attacker can intercept or misroute authorization data. PKCE binds the code to the intended client, while exact redirect URI matching closes off callback ambiguity that can be exploited through open redirect patterns or permissive registration logic.
Q: How should organisations judge whether their OAuth deployment is still too permissive?
A: Look for any place where login success depends on optional security features, wildcard callback handling, long-lived refresh tokens, or bearer tokens stored where they can be copied. If those conditions exist, the deployment still depends on implementation discipline rather than protocol-enforced safeguards.
Q: What is the difference between refresh token rotation and sender-constrained tokens?
A: Refresh token rotation changes the token on each use and invalidates the previous one, which reduces replay value after theft. Sender-constrained tokens bind use to a specific client or key, so the token is harder to replay from another system. Both reduce abuse, but they protect different parts of the exchange.
Technical breakdown
Why PKCE becomes the default trust check
PKCE, or Proof Key for Code Exchange, binds the front-channel authorization request to the back-channel token request by using a generated verifier and hashed challenge. That stops an intercepted authorization code from being redeemed by a different client, which is why OAuth 2.1 requires it for every authorization code flow, not just public clients. The practical effect is to move trust from the browser redirect alone to a proof the client must present at token exchange time. This is a protocol-level answer to code interception and replay, not just a configuration preference.
Practical implication: treat PKCE as mandatory across every OAuth client, including server-side applications.
Why exact redirect URI matching closes a common redirect weakness
Redirect URIs are the handoff point where the authorization server sends the code back to the client. OAuth 2.1 requires exact string matching so wildcard and partial-match logic cannot be abused through open redirectors or misrouted token deliveries. In practice, loose redirect validation often turns a legitimate login path into a token exfiltration path because the callback endpoint becomes attacker-controlled or attacker-influenced. Exact matching is a narrow control, but it removes a whole class of implementation errors that thrive on overly permissive callback rules.
Practical implication: inventory every registered callback and remove wildcard or pattern-based redirects.
How refresh token rotation reduces replay risk for long-lived sessions
Refresh tokens are designed to renew access without forcing the user back through primary authentication every time. The security problem is persistence: if a refresh token is stolen and never changes, it can be replayed until it expires or is revoked. OAuth 2.1 addresses this by requiring rotation or sender-constrained use, so each refresh produces a new token and invalidates the prior one, or binds the token to a proof of possession. That shrinks the replay window and makes theft materially less useful.
Practical implication: enable refresh token rotation wherever session continuity matters, especially for SPAs and higher-risk apps.
Threat narrative
Attacker objective: The attacker wants to hijack delegated access without needing the user’s password or a second authentication step.
- Entry begins when a client relies on an authorization code flow without PKCE or on a redirect path that accepts weak URI matching, creating a chance for intercepted codes to be reused or misdelivered.
- Credential abuse follows when a bearer token or refresh token is exposed through insecure storage, logging, URL handling, or replayable refresh logic, allowing the token holder to act as the client.
- Impact occurs when delegated access is used to reach user resources, APIs, or AI tool connections that were never meant to be reachable through a stolen or replayed token.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
OAuth 2.1 is really a removal of unsafe choice, not an expansion of capability: the protocol is narrowing implementation variance so the same baseline applies across apps, APIs, and agent connections. That matters because most OAuth failures come from optionality, not complexity alone. Practitioners should read OAuth 2.1 as a governance standardisation move that reduces the space for insecure local interpretation.
PKCE for all authorization code flows changes the trust model at the exchange boundary: a client now has to prove continuity between request and token redemption, which is exactly where interception attacks thrive. That makes code interception materially harder for both browser-based and server-side clients. The implication is that identity teams should stop treating PKCE as a public-client feature and start treating it as a universal exchange control.
Redirect URI strictness is a lifecycle control for callback trust, not a syntax preference: exact matching forces teams to inventory every redirect entry and remove ambiguity from the authorization path. Wildcards and partial matches have historically let benign-looking endpoints become abuse points. The implication is that callback governance should be treated as part of access design, not as an application afterthought.
Refresh token rotation is a replay-control pattern that becomes more important as sessions outlive a single browser interaction: longer-lived delegated access is now normal for SPAs, SaaS integrations, and agent-mediated workflows. That means token persistence has to be governed as a lifecycle issue, not an implementation detail. The implication is that organisations need to know where token reuse is allowed, and where it is an unbounded risk.
OAuth 2.1 is becoming the safer baseline for agent and MCP access because the protocol assumption is shifting from user-paced interaction to tool-paced delegation: once an agent can request tools and reuse tokens on its own timeline, the security model cannot rely on sporadic reauthentication or human review of every exchange. The implication is that identity architecture for agents must treat delegated access as a governed runtime state, not a static permission grant.
From our research library:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
What this signals
OAuth 2.1 turns secure defaults into governance pressure: teams no longer get much value from treating PKCE, redirect validation, and token rotation as optional hardening. The practical question is whether existing IAM standards, app templates, and developer guardrails now encode those defaults by design.
Agent and MCP use cases expose the next governance boundary: once tools exchange delegated access on behalf of a model-driven runtime, access tokens become part of a machine-run workflow rather than a human login journey. Identity teams should test whether their OAuth policies still assume a person is always present to review the next step.
Callback governance is an identity control, not just an app setting: exact redirect matching means every registered callback is now part of the trusted access path. That makes callback sprawl, stale redirect registrations, and unmanaged environment-specific URIs a direct IAM concern.
For practitioners
- Audit OAuth grant usage Identify every app, API, SPA, and integration still depending on implicit or password-based flows, then map each to authorization code plus PKCE or an appropriate replacement.
- Enforce exact redirect matching Remove wildcards and partial matches from registered callback URIs and validate each redirect_uri as an exact string on every authorization request.
- Rotate refresh tokens by default Require refresh token rotation or sender-constrained tokens for any client that persists sessions beyond a single login exchange, especially SPAs and delegated integrations.
- Harden bearer token handling Keep access tokens out of URLs and browser history, store them only in controlled client locations, and scope them narrowly to the minimum access needed.
- Review agent and MCP delegation paths Check where AI agents or tool brokers obtain OAuth tokens, how long those tokens persist, and whether any step assumes a human will review each use.
Key takeaways
- OAuth 2.1 reduces implementation ambiguity by removing weak grant types and making safer flows mandatory across modern application patterns.
- PKCE, exact redirect matching, and refresh token rotation are the practical controls that turn OAuth from flexible to defensible.
- Identity teams should treat OAuth 2.1 as the new baseline for apps, SPAs, APIs, and agent integrations rather than as a future migration target.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | OAuth 2.1 hardens delegated authentication for non-human access paths and removes weak grant types. |
| NHI-07 — Long-Lived Secrets | Refresh token rotation addresses the risk of long-lived bearer material being replayed after theft. | |
| Recommendation — Apply NHI-04 by replacing weak OAuth flows with stronger authorization code patterns and proof-bound exchanges. Apply NHI-07 by shortening token lifetime and rotating refresh tokens on every use. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent and MCP use cases depend on delegated identity, where abuse of tokens becomes a runtime threat. |
| Recommendation — Constrain agent token use so delegated privileges cannot be reused outside the intended session boundary. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth token handling is a credential lifecycle issue governed by authenticator management. |
| Recommendation — Manage OAuth tokens under IA-5 with rotation, revocation, and secure storage requirements. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The article’s threat path centers on token theft, interception, and replay as credential access tactics. |
| Recommendation — Map OAuth token theft and replay to TA0006 and watch for interception points in redirects and storage. | ||
Key terms
- 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.
- Refresh token rotation: Refresh token rotation replaces a reusable refresh token with a new one each time it is used. This limits the value of token theft because a stolen token becomes useless after the legitimate exchange, assuming the implementation handles revocation and concurrency correctly.
- 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.
- Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org