OAuth 2.1 and NHI governance: what changed for practitioners

At a glance

What this is: OAuth 2.1 tightens user-facing authorization flows, but the central finding is that workload authentication still depends on static client secrets and unresolved lifecycle controls.

Why it matters: IAM and NHI teams need to treat OAuth 2.1 as a user-authentication baseline, not a complete answer for service accounts, workloads, or ephemeral runtime identities.

By the numbers:

• The spec is in late-stage IETF draft as draft-ietf-oauth-v2-1-15 and has not yet been published as a final RFC.

Context

OAuth 2.1 is the tightened version of OAuth 2.0, built to remove patterns that repeatedly caused token leakage and weak authorization decisions. In this article, the primary identity question is not whether the user flows are safer, but whether the same controls adequately govern workloads and service accounts.

For practitioners, the security gap is governance, not just protocol choice. OAuth 2.1 improves browser and app authorization for humans, yet static client secrets, ephemeral workloads, and lifecycle control for non-human identities remain outside the standard's core protections.

Key questions

Q: What breaks when organisations keep using legacy OAuth 2.0 flows after migrating to OAuth 2.1?

A: The main failure is that the application still depends on flows OAuth 2.1 deliberately removed because they exposed tokens or relied on weak defaults. That creates backward-compatibility breakage, but it also removes whole classes of attack paths. Teams should expect implicit grant, password flow, and token-in-URL behaviour to stop working by design.

Q: Why do static client secrets remain risky even after OAuth 2.1 adoption?

A: Static client secrets create durable machine access that survives the original session and remains usable until manual rotation. OAuth 2.1 improves delegated authorization for users, but it does not remove the lifecycle problem of secrets that must be stored, protected, and eventually revoked for workloads.

Q: What are the signs that an OAuth deployment is still configured too loosely?

A: The warning signs are flexible redirect matching, tokens appearing in query parameters, and applications that still depend on implicit grants or browser-stored bearer tokens. Those patterns indicate the deployment has not fully moved to the tighter OAuth 2.1 baseline and is still vulnerable to code interception or token leakage.

Q: How should security teams separate OAuth 2.1 migration from workload identity governance?

A: Treat them as related but distinct programmes. OAuth 2.1 should clean up user-facing authorization flows, while workload identity governance should address how service accounts and ephemeral jobs authenticate without standing secrets. If the same controls are used for both, one side will be under-governed.

Technical breakdown

Why OAuth 2.1 removes unsafe legacy OAuth 2.0 flows

OAuth 2.1 deletes the implicit grant, resource owner password credentials, and token-in-URL patterns because they repeatedly produced avoidable exposure. The spec also makes PKCE mandatory, requires exact redirect URI matching, and tightens refresh token handling so the authorization server enforces safer defaults instead of leaving them optional. That matters because OAuth 2.0 failures were often configuration failures, not protocol failures. The standard now encodes the safer behaviour directly, which reduces implementation drift across teams.

Practical implication: treat OAuth 2.1 as a hardening baseline and remove any remaining reliance on legacy OAuth 2.0 flows.

Why PKCE and exact redirect matching change the attack surface

PKCE binds the authorization code exchange to the original client by requiring proof of possession of a secret verifier, which blocks code interception attacks. Exact redirect matching closes the gap created by wildcard or flexible redirect URI rules that attackers could abuse to divert codes to hostile destinations. Together, these controls reduce the chance that a valid authorization request is completed by the wrong endpoint or the wrong client. The result is tighter control over the exchange step, which is where many OAuth implementations historically broke down.

Practical implication: register every redirect URI explicitly and enforce cryptographically strong PKCE generation across all client types.

Why OAuth 2.1 still leaves workload identity exposed

OAuth 2.1 secures user-oriented authorization, but service-to-service access still commonly relies on the client credentials flow with static client secrets. Those secrets are pre-provisioned, stored somewhere, and kept valid until manual rotation, which creates the same long-lived credential problem the standard works to eliminate for user tokens. Ephemeral workloads make the gap sharper because containers, serverless functions, and CI/CD jobs do not fit a model that assumes a stable secret can be safely parked in configuration. That is a workload identity problem, not an OAuth syntax problem.

Practical implication: separate user OAuth migration from workload identity design and do not assume client credentials solve machine authentication lifecycle risk.

Threat narrative

Attacker objective: The attacker wants durable access through token theft, redirect abuse, or compromised client secrets that outlive the original session.

1. Initial exposure occurs when applications rely on legacy OAuth 2.0 patterns such as implicit grants, tokens in URLs, or flexible redirect matching.
2. Escalation occurs when stale or static client secrets remain valid across workloads and environments, extending the attack window beyond a single authorization event.
3. Impact is persistent unauthorized access to user or workload resources through tokens or secrets that remain usable after the original weakness is discovered.

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 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 better user-authorization baseline, but it is not a workload identity model. The standard closes several long-standing implementation hazards for browser and app sign-in, yet its protections stop where service accounts and ephemeral workloads begin. That split matters because many organisations will mistake a safer user protocol for a complete identity strategy, when the workload side still depends on separate governance.

Static client secrets are the unresolved fault line in OAuth 2.1. They preserve the old assumption that a machine credential can be provisioned once and safely managed later, which is precisely the lifecycle problem that modern NHI governance is trying to remove. The implication is that teams must stop treating OAuth migration and workload identity design as the same programme.

Ephemeral workloads expose a control model built for stable identities. Containers, serverless jobs, and CI/CD tasks often exist for shorter periods than credential review and recertification cycles. That means the decisive security variable is no longer only what the protocol allows, but whether the identity layer can issue access without creating a standing secret to govern afterward.

OAuth 2.1 validates the move away from optional security defaults, but it also sharpens the category boundary between human IAM and NHI governance. Human authorization can be standardised through PKCE and exact redirect matching, while workloads still need lifecycle, provenance, and secretless authentication controls. Practitioners should use the standard as a hardening floor, not as evidence that workload identity has been solved.

OAuth 2.1 is becoming the safer transport for user delegation, while NHI governance remains the control plane for machine access. That division is useful because it forces teams to map which identities are actually being governed. The practical conclusion is that user auth modernisation and workload identity modernisation must be measured separately, or the organisation will overstate its security maturity.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: NHI Authentication Guide

What this signals

Static secrets are the part OAuth 2.1 does not retire. The standard reduces user-side authorization risk, but service accounts and runtime jobs still need a governance model that does not rely on a stored secret surviving long enough to be reused. That is where workload identity management becomes the next control boundary, not an optional enhancement.

Secretless access becomes the more useful design target once user OAuth flows are hardened. If an organisation modernises PKCE and redirect handling but leaves client credentials untouched, it has improved one half of the problem while preserving the other half's standing access window. The better programme lens is to separate delegated user authorization from machine authentication lifecycle.

For practitioners

• Harden user OAuth flows first Remove implicit grants, password credentials, and tokens in URLs from every application path that still depends on OAuth 2.0 behaviour.
• Register redirect URIs explicitly Replace wildcard or flexible redirect matching with exact, environment-specific redirect URI registrations for development, staging, and production.
• Separate workload identity from OAuth migration Inventory every service account and workload that still uses client credentials, then classify whether it needs secret-based access or a secretless alternative.
• Review token handling paths Audit API calls, logs, and client code to ensure access tokens are never passed in query strings or stored in unsafe browser locations.

Key takeaways

• OAuth 2.1 closes several common implementation gaps in user authorization, but it does not by itself solve workload identity or service account governance.
• The protocol's strongest changes are mandatory PKCE, exact redirect matching, and the removal of legacy flows that repeatedly leaked tokens or passwords.
• Practitioners should modernise user auth and machine identity controls in parallel, because static client secrets remain outside OAuth 2.1's scope.

Key terms

• OAuth 2.0: The industry-standard authorisation framework enabling applications to obtain limited, scoped access to user accounts or services via access tokens, without exposing credentials. The preferred authentication standard for modern NHI integrations.
• 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.
• Client Credentials Flow: An OAuth 2.0 grant type used for machine-to-machine authentication where an application authenticates directly using its own client ID and secret to obtain an access token. The standard pattern for service-to-service NHI authentication.
• Exact Redirect Matching: Exact redirect matching requires the authorization server to accept only explicitly registered callback URIs with no wildcard or loose pattern matching. This prevents attackers from redirecting authorization codes to unintended destinations and is especially important in multi-environment deployments.

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 building or maturing an IAM programme, it is worth exploring.