Notifications
Clear all
Topic starter
08/06/2026 4:43 pm
TL;DR: OAuth 2.0 authorization code flow uses a browser-based consent step, a short-lived authorization code, and a backend token exchange, while OAuth 2.1 makes PKCE mandatory to block interception attacks, according to WorkOS. The security model is only as strong as redirect validation, state checking, and secret handling, not the protocol label.
NHIMG editorial — based on content published by WorkOS: OAuth 2.0 Authorization Code Grant: What it is and how it works
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Enforce PKCE on every authorization code flow Require code_challenge and code_verifier support for all clients, including confidential applications.
- Validate redirect URIs exactly Register and compare redirect_uri values byte-for-byte, and reject any callback that does not match the expected destination.
- 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.
What's in the full article
WorkOS's full guide covers the implementation detail this post intentionally leaves for the source:
- Step-by-step request and callback examples for the /authorize and /token endpoints.
- Node.js code for generating PKCE verifier and challenge values.
- Concrete parameter handling for client_id, redirect_uri, state, and code_verifier.
- OAuth 2.1-specific notes on why PKCE is now mandatory for confidential clients.
👉 Read WorkOS's guide to the OAuth authorization code grant and PKCE →
Authorization code grant and PKCE: are your OAuth controls current?
Explore further
08/06/2026 6:30 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OAuth authorization code flow and PKCE harden delegated access
