OAuth 2.1 and NHI governance: what changed for practitioners

At a glance

What this is: OAuth 2.1 tightens browser and app authentication by making several security best practices mandatory while eliminating flows that were routinely misused.

Why it matters: IAM and NHI teams still need separate controls for service accounts, workload identity, and secret lifecycle management because OAuth 2.1 does not solve those problems.

👉 Read Aembit's analysis of OAuth 2.0 to 2.1 migration and workload identity

Context

OAuth 2.1 is the updated authorization standard that narrows long-standing implementation mistakes in delegated access, but it does not replace broader identity governance. The primary NHI governance gap is that human-facing authentication can be hardened while service accounts, API keys, and client secrets remain static and difficult to retire safely.

The practical distinction matters for IAM teams. OAuth 2.1 closes several token exposure paths for user authentication, yet workload identity still depends on lifecycle discipline, rotation, and proof of possession outside the standard itself. That makes the topic highly relevant for organisations modernising access controls across both human and non-human identities.

Key questions

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

A: Start by removing the highest-risk legacy flows, especially implicit grant and password credentials, then enforce PKCE and exact redirect matching on every remaining authorization code client. After that, tighten refresh token handling and scan for tokens stored in URLs, browser storage, or CI/CD variables. Migration is complete only when the old patterns are gone, not just disabled in one environment.

Q: Why does OAuth 2.1 not solve workload identity risk?

A: OAuth 2.1 improves delegated authorization for user applications, but workloads still rely on client secrets, service accounts, and other static credentials. Those credentials must be stored, rotated, and revoked manually, which creates the same lifecycle exposure the standard was designed to reduce for humans. Workload identity needs its own control plane, not a user-authentication retrofit.

Q: What is the difference between OAuth 2.1 and workload identity controls?

A: OAuth 2.1 governs how applications obtain delegated access tokens, while workload identity controls govern how software proves who it is without relying on long-lived secrets. The first reduces token abuse in user flows. The second addresses service accounts, automation, and AI agents that need authenticated access without persistent credentials.

Q: When should organisations prioritise OAuth 2.1 over other IAM work?

A: Prioritise OAuth 2.1 when browser-based apps still use implicit flow, tokens appear in URLs, or redirect matching is loose enough to create exploitation risk. That work usually belongs early because the fixes are clear and the exposure is immediate. But it should run alongside, not instead of, secrets management and workload identity remediation.

Technical breakdown

What OAuth 2.1 changes in delegated authorization

OAuth 2.1 is best understood as a consolidation release rather than a new authorization model. It folds in PKCE, browser-based app guidance, and the OAuth 2.0 Security Best Current Practice, then removes flows that were repeatedly misapplied, especially implicit grant and password credentials. The architecture now assumes authorization code flow with PKCE across client types, which reduces interception risk and removes token handling patterns that depended on browser URLs or weak client assumptions. The exact redirect matching requirement also closes a common open redirect abuse path. Practical implication: teams should treat OAuth 2.1 as a forcing function to retire legacy client patterns, not as a simple configuration toggle.

Practical implication: Inventory every OAuth client and remove any flow that depends on implicit grant, password credentials, or flexible redirect matching.

Why OAuth 2.1 still leaves a static credential problem for NHIs

OAuth 2.1 improves how tokens are issued and transported for user applications, but it does not solve machine identity. Service accounts and workloads still often rely on client IDs and client secrets, which are static secrets that must be stored, rotated, and eventually revoked. That creates the same lifecycle exposure that OAuth 2.1 was designed to reduce for end-user sessions. The problem becomes sharper in containers, serverless functions, and CI/CD jobs, where credentials can outlive the workload instance or get copied into automation. Practical implication: teams need a separate workload identity model rather than extending OAuth 2.1 beyond its design boundary.

Practical implication: Use OAuth 2.1 for user authorization, but pair workloads with secretless or short-lived identity controls.

How PKCE, refresh rotation, and exact redirect matching reduce attack surface

PKCE binds the authorization code exchange to the original client by requiring proof of possession of a verifier, which blocks code interception attacks. Exact redirect matching removes the ambiguity that attackers exploit through wildcard or loosely matched callback URLs. Refresh token rotation limits the value of a stolen refresh token by making each token single-use or sender-constrained. Together, these requirements shift OAuth from a best-practice model to a stricter baseline, but they only govern the authorization exchange itself. Practical implication: harden the OAuth boundary first, then address secrets storage and workload trust separately.

Practical implication: Validate PKCE, redirect URIs, and refresh rotation in production, then assess where long-lived credentials remain in the stack.

Threat narrative

Attacker objective: The objective is durable delegated access that survives user logout and extends into connected systems through stolen tokens or secrets.

1. Entry occurs when attackers exploit implicit grant token leakage, weak redirect URI matching, or tokens exposed in URLs.
2. Escalation follows when stolen refresh tokens or authorization codes are replayed to obtain ongoing API access.
3. Impact is sustained access to applications, data, and connected workloads until tokens or client secrets are revoked.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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 cleanup of user authentication, not a complete identity security model. The standard removes unsafe legacy flows and makes several security controls mandatory, but it remains scoped to delegated authorization. That means practitioners should stop treating OAuth conformance as a proxy for NHI governance maturity. The field still needs separate controls for service accounts, API keys, certificates, and workload trust.

Static client secrets are the unresolved NHI problem hidden behind OAuth 2.1 adoption. Even when user-facing authentication becomes cleaner, machine-to-machine access can still depend on long-lived credentials stored in automation or environment variables. That creates lifecycle risk, replay risk, and revocation delay. Practitioners should read OAuth 2.1 as a signal to redesign workload identity, not merely to update application code.

Exact redirect matching and PKCE reduce implementation risk, but they do not eliminate trust assumptions in the surrounding stack. Applications still need secure secret storage, callback registration governance, and monitoring for token misuse after issuance. A migration that stops at the authorization server leaves the most operationally painful risks untouched. Teams should use the migration to tighten the full authentication path.

Ephemeral session safety is now easier than ephemeral workload safety. User sessions can be made more resilient with modern OAuth defaults, while workloads often remain anchored to static secrets and manual rotation. That gap widens as AI agents and automation platforms inherit execution authority. Practitioners should align migration work with workload identity programmes rather than running them as separate initiatives.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That gap makes the Guide to the Secret Sprawl Challenge the natural next resource for teams mapping where static credentials still live.

What this signals

Ephemeral credential trust debt: OAuth 2.1 lowers risk in delegated user flows, but many organisations will still accumulate trust debt in static client secrets, service accounts, and automation tokens. The operational question is no longer whether the authorization standard is modern enough, but whether the surrounding identity estate can be rotated, revoked, and monitored at the same pace. That is a governance problem, not a protocol problem.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, per the Ultimate Guide to NHIs, OAuth 2.1 migration can only reduce part of the attack surface. Practitioners should expect hidden credentials to remain the dominant residual risk unless inventory and offboarding improve.

The strategic signal is clear: IAM programmes are moving toward two tracks, hardened user authorization and separate workload identity governance. Teams that merge those tracks into one migration risk missing the static-secret problem that OAuth 2.1 leaves untouched. The next control conversation should be about lifecycle ownership, not just protocol compliance.

For practitioners

• Remove legacy OAuth flows from production first Inventory every application that still uses implicit grant, password credentials, or token-in-URL patterns, then set a firm retirement date for each one. Prioritise internet-facing applications and any client that handles sensitive data.
• Enforce PKCE and exact redirect matching everywhere Require PKCE for all authorization code clients and register every redirect URI explicitly. Separate development, staging, and production callback lists so flexible matching does not reappear through convenience settings.
• Rotate refresh tokens and audit token storage paths Use one-time or sender-constrained refresh tokens where possible, then search code repositories, browser storage, and CI/CD variables for tokens that should never be there. Treat any surviving localStorage or query-string token use as a migration defect.
• Separate workload identity from user authorization Do not extend OAuth 2.1 user patterns to service accounts and automation. Use short-lived or secretless workload credentials, with lifecycle controls that cover provisioning, rotation, and revocation.

Key takeaways

• OAuth 2.1 removes several recurring implementation mistakes, but it is only part of the identity security problem.
• Static client secrets and workload credentials remain the main gap for NHI governance even after OAuth 2.1 migration.
• Practitioners should use the migration to enforce PKCE, exact redirects, and token cleanup while separately redesigning workload identity.

Key terms

• OAuth 2.1: OAuth 2.1 is a consolidation of secure OAuth 2.0 practices into a stricter authorization baseline. It removes flows that were repeatedly misused, makes PKCE mandatory, and tightens redirect handling so implementation errors are harder to exploit.
• PKCE: PKCE, or Proof Key for Code Exchange, binds the authorization request to the token exchange using a cryptographic verifier and challenge. It reduces authorization code interception risk by proving that the party redeeming the code is the one that started the flow.
• Workload identity: Workload identity is the method software uses to prove who it is without depending on a user login or a long-lived shared secret. In practice, it underpins service accounts, automation, and AI agents that need authenticated access across systems.
• 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.

Deepen your knowledge

OAuth 2.1 migration, PKCE enforcement, and workload identity boundaries are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are modernising delegated access while still relying on static workload credentials, it is worth exploring.

This post draws on content published by Aembit: OAuth 2.0 vs 2.1: What Changed and How to Migrate. Read the original.