OAuth authorization code flow and PKCE harden delegated access

At a glance

What this is: This is a practical explanation of the OAuth 2.0 authorization code grant and why PKCE is now required to secure the exchange.

Why it matters: It matters because IAM teams need to govern delegated access patterns that span web apps, backend services, and identity providers without weakening token security or consent controls.

👉 Read WorkOS's guide to the OAuth authorization code grant and PKCE

Context

OAuth authorization code flow is the standard delegated access pattern for apps that need API access without collecting user passwords. The article explains the browser consent step, the redirect back with an authorization code, and the backend exchange that turns that temporary code into tokens.

For IAM teams, the key issue is not the flow itself but the trust boundary it creates between browser, backend, and authorization server. PKCE tightens that boundary by binding the initial request to the token exchange, which reduces interception risk and makes modern OAuth deployments safer for confidential and public clients alike.

Key questions

Q: How should security teams implement the OAuth authorization code flow safely?

A: Use the authorization code flow only when the application can keep client credentials on the backend, validate redirect URIs exactly, and check the state value on return. The browser should handle consent, not token handling. Add PKCE for every client so the code exchange is bound to the original request and cannot be replayed by an interceptor.

Q: Why does PKCE matter if a client already has a secret?

A: A client secret protects the application, but it does not prove that the entity redeeming the authorization code is the same one that requested it. PKCE adds that proof. It prevents intercepted codes from being exchanged elsewhere and reduces the risk created by modern browser, mobile, and distributed app delivery models.

Q: What do teams get wrong about OAuth redirect and consent controls?

A: They often treat redirect URIs and consent screens as formality checks rather than security controls. In practice, redirect validation stops code redirection abuse, while state protects the request from CSRF-style tampering. If either is weak, the authorization code flow can be manipulated before the backend ever sees the token request.

Q: Should organisations use refresh tokens in authorization code flows?

A: Use refresh tokens only when the application genuinely needs long-lived sessions and the storage path is tightly controlled. They reduce repeated logins, but they also increase the value of a stolen credential set. If refresh tokens are issued, protect them like high-value secrets and limit their scope wherever the authorization server allows it.

Technical breakdown

How the authorization code grant separates consent from token issuance

The authorization code grant splits login and token issuance into two different channels. The browser handles user consent and receives only a short-lived authorization code, while the backend server exchanges that code for tokens at the token endpoint. This separation matters because the access token never needs to pass through the browser if the flow is implemented correctly. The redirect URI, state value, and client credentials are the control points that keep the exchange trustworthy. When any of those are weak, the flow can be redirected, replayed, or abused.

Practical implication: validate redirect URI, state, and backend credential handling as core parts of OAuth governance, not as implementation details.

PKCE in OAuth 2.1 and code interception risk

PKCE adds a proof step to the authorization code grant by binding the initial authorization request to the later token request. The client creates a high-entropy code verifier, derives a code challenge, and sends the challenge up front. At token time, the verifier must match the stored challenge before tokens are issued. This prevents an intercepted authorization code from being replayed by a different client, because the attacker would not know the original verifier. OAuth 2.1 makes PKCE mandatory because the older assumption that a backend client secret alone is enough no longer holds across modern delivery patterns.

Practical implication: require PKCE on every authorization code flow and treat code interception as a first-order design risk.

Why client secrets, refresh tokens, and exact redirect matching still matter

PKCE does not replace the rest of OAuth hygiene. A confidential client still needs a securely stored client secret, exact redirect URI matching, and careful refresh token handling. Refresh tokens extend sessions and therefore expand the value of a stolen credential set if they are poorly protected. The flow remains secure only when each control supports the others, especially in apps that straddle browser and backend execution. OAuth 2.1 raises the baseline, but deployment quality still determines whether the implementation is resilient or merely standards-compliant.

Practical implication: review token storage, redirect handling, and refresh token issuance together, because weak handling in any one of them can undermine the whole flow.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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 authorization code flow is an identity boundary, not just an app pattern. The article makes clear that the browser, redirect, and backend exchange each carry different trust assumptions. That matters because IAM teams often treat OAuth as a convenience layer, when in practice it is a delegated access control plane for user-approved API access. Practitioners should govern it as part of identity architecture, not as a developer convenience feature.

PKCE closes a class of interception risk, but it also exposes how much OAuth still depends on disciplined implementation. The flow remains sensitive to redirect URI matching, state validation, and secret handling. OAuth 2.1 raises the minimum bar, yet the surrounding controls still decide whether delegated access is actually secure. The practical conclusion is that protocol compliance is necessary, but not sufficient, for trustworthy authentication and authorisation.

The named concept here is authorization-code replay resistance. PKCE turns the code exchange into a one-time, possession-bound transaction instead of a reusable bearer handoff. That design is especially relevant where browser delivery, mobile clients, or mixed frontend-backend architectures create interception opportunities. Identity teams should recognise this as a control that protects the exchange itself, not just the token after issuance.

OAuth governance increasingly sits at the junction of human identity and application identity. End users grant consent, but applications and backend services receive the credentials that actually move data. That means IAM teams need shared ownership between application security, identity, and platform teams. The conclusion is that delegated access programmes should be reviewed as identity governance, not only as API security.

The strongest signal in this article is that modern OAuth assumes layered trust, not a single secret. The authorization server, redirect path, backend client, and proof-of-possession step each carry part of the assurance. That layered model is now the baseline for secure enterprise integration. Practitioners should treat OAuth 2.1 and PKCE as the floor for delegated access governance.

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 Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
• For a broader NHI governance baseline, see Ultimate Guide to NHIs , Key Challenges and Risks, which connects visibility gaps, over-privilege, and lifecycle control.

What this signals

Authorization-code replay resistance: PKCE is now the minimum viable proof that a token exchange belongs to the client that started it. That same design logic is showing up across identity security because static trust assumptions are failing faster than traditional remediation cycles can absorb. For programmes that still rely on long-lived credentials, the control gap is not theoretical, especially when 91.6% of secrets remain valid five days after notification, according to the Ultimate Guide to NHIs.

IAM teams should expect more scrutiny on backend handling of OAuth state, refresh tokens, and session material as identity governance shifts closer to application runtime. The practical question is no longer whether OAuth is supported, but whether it is governed as a lifecycle-controlled credential path with clear ownership across app, platform, and identity teams.

For practitioners

• Enforce PKCE on every authorization code flow Require code_challenge and code_verifier support for all clients, including confidential applications. Make OAuth 2.1 compliance a deployment gate so no new integration ships without proof-of-possession.
• Validate redirect URIs exactly Register and compare redirect_uri values byte-for-byte, and reject any callback that does not match the expected destination. This closes a common interception path and prevents token leakage through redirect abuse.
• Treat state as a CSRF control Generate a unique state value for each authorization request, store it server-side, and verify it before exchanging the authorization code. Do not reuse state across sessions or flows.
• Harden token and secret handling Store client secrets only on the backend, keep refresh tokens short-lived where possible, and restrict where session data and verifier material can live. The token endpoint should be reachable only through authenticated server logic.

Key takeaways

• The authorization code grant remains the right OAuth pattern for delegated access, but only when the browser, redirect, and backend boundaries are governed carefully.
• PKCE is no longer optional hardening. It is the control that keeps intercepted authorization codes from becoming usable credentials.
• Enterprises should treat OAuth configuration as identity governance work, because weak redirect, state, or token handling can undo the security promised by the flow.

Key terms

• Authorization Code Grant: An OAuth flow that lets an application receive user-approved access without collecting the user’s password. The browser handles consent and redirection, while the backend exchanges a short-lived code for tokens. For identity teams, the control question is whether the exchange is bound tightly enough to the original request.
• Pkce: Proof Key for Code Exchange is an added verification step for OAuth authorisation code flows. The client creates a secret verifier, derives a challenge, and proves possession during the token exchange. In modern deployments, PKCE protects both public and confidential clients from intercepted authorization codes.
• Redirect URI: The registered callback destination where an authorization server sends the browser after user approval. It is a security control, not just a routing setting, because exact matching helps prevent code redirection and token theft. Misconfigured redirect handling is a common cause of OAuth abuse.
• Refresh Token: A credential that allows an application to obtain new access tokens without forcing the user to log in again. It extends session continuity, but it also increases the value of the credential if stolen. Governance should treat refresh tokens as sensitive long-lived secrets with scoped use and tight storage controls.

Deepen your knowledge

OAuth authorization code flow and PKCE are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are governing delegated access across web apps and backend services, it is a practical place to build that baseline.

This post draws on content published by WorkOS: OAuth 2.0 Authorization Code Grant: What it is and how it works. Read the original.