Notifications
Clear all
Topic starter
08/06/2026 4:23 pm
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.
NHIMG editorial — based on content published by WorkOS: OAuth 2.0 vs OAuth 2.1: What changed, why it matters, and how to upgrade
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step PKCE implementation guidance for different client types, including where code verifier handling goes wrong.
- Concrete examples of secure refresh token rotation and sender-constrained token choices for higher-risk deployments.
- Exact redirect URI configuration patterns and migration examples for teams removing wildcard matching.
- Implementation notes for SPAs, native apps, and MCP-connected services that need OAuth 2.1-compatible flows.
👉 Read WorkOS's guide to OAuth 2.1 migration and secure defaults →
OAuth 2.1 and PKCE: what IAM teams need to change now?
Explore further
08/06/2026 6:00 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OAuth 2.1 tightens identity security defaults for apps and agents
