An OAuth 2.0 login method that lets an application obtain a user’s access token without seeing the user’s password. The user authenticates with the authorization server, which returns a short-lived code to the client, then the client exchanges that code for tokens through a back-channel request.
How the Authorization Code Flow Works
The OAuth 2.0 authorization code flow splits the login journey into two steps, user sign-in at the authorization server and a later code exchange by the client. That separation is what keeps the user’s password away from the application while still allowing the app to receive tokens.
The first leg happens through the browser, where the user authenticates directly with the authorization server and approves access. The server then issues a short-lived authorization code instead of exposing tokens in the front channel, which reduces the chance of token leakage during redirects and browser handling.
The second leg is a back-channel exchange between the client and the token endpoint. Because the code is short-lived and intended for one-time use, the flow depends on keeping the redirect, client identity and token exchange tightly bound to the same transaction.
Why This Flow Exists
The main design goal is to let an application obtain delegated access without handling the user’s password. That matters because the application does not need to become a credential custodian, and the authorization server remains the system that actually authenticates the user.
This is also why the flow is commonly treated as the default OAuth pattern for browser-based and server-side applications. It gives a safer separation of duties than flows that expose tokens too early or rely on the client to collect credentials directly.
The flow is often discussed alongside OpenID Connect when authentication is also needed, but OAuth itself is about delegated authorization. In practice, teams should be clear about whether they are using the code flow for API access, sign-in, or both, because the security assumptions are different.
Security Properties and Failure Conditions
The main security benefit is front-channel minimisation. The code is easier to protect than an access token, and the actual token exchange can be performed over a direct server-to-server request that is less exposed to browser interception, referer leakage, and URL handling mistakes.
The flow becomes unsafe when the code can be stolen, replayed, or swapped into the wrong client. Redirect URI mismatch, weak client authentication, poor state handling, and missing proof that the same client is completing the exchange are the kinds of failures that turn a safe pattern into a token theft path.
Because the flow is foundational to modern OAuth deployments, readers should anchor their implementation choices in the IETF baseline for the protocol, especially RFC 6749: The OAuth 2.0 Authorization Framework and the security guidance in RFC 9700: Best Current Practice for OAuth 2.0 Security.
Where It Sits in Modern OAuth Deployments
The authorization code flow is the parent pattern behind many current OAuth designs, including public clients with PKCE, confidential clients with stronger client authentication, and federated sign-in patterns where OpenID Connect adds an ID token on top. Its usefulness comes from being flexible enough for both user-facing apps and backend integrations while preserving a clean trust boundary.
That flexibility also means deployment choices matter. The same flow can be implemented well or badly depending on how strictly the client is identified, whether the redirect URI is exact, whether the code exchange is bound to the intended client, and whether tokens are scoped tightly to the target resource.
For teams comparing implementation details, the most useful next references are the OAuth 2.0 and OpenID Connect guide for roles, grants, PKCE and token handling, and the OpenID Connect Core specification when the flow is being used as a sign-in mechanism rather than only as an authorization mechanism.
Good practitioner reference points are OAuth 2.0 and OpenID Connect Guide for Identity Teams and OpenID Connect Core 1.0, which help separate OAuth authorization from authentication and show where the code flow fits.
Risk and Threat Considerations
The main risks are code interception, consent phishing, redirect URI abuse, and token replay after a successful exchange. These failures matter because the code flow is often the path to durable access, so a single weak handoff can expose API access, mailbox access, or other delegated privileges.
Failure mechanism: An attacker steals the authorization code, tricks the user into approving a malicious client, or abuses a weak redirect and then redeems the code before the legitimate client does.
Impact: The attacker can obtain tokens, impersonate the user to downstream services, and preserve access until the tokens are revoked or expire.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth code flow depends on secure credential and token handling across the exchange. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | The flow supports external end-user sign-in and delegated access. | |
| AC-3 — Access Enforcement | OAuth tokens enforce what the client may access after authorization. | |
| Recommendation — Protect code and token lifecycle with secure issuance, storage, rotation, and revocation controls. Authenticate external users through the authorization server rather than exposing passwords to the client. Enforce least-privilege token scopes and resource access decisions at the protected resource. | ||
| OWASP ASVS | V10 — OAuth and OIDC | ASVS directly covers OAuth authorization code handling and related federated sign-in security. |
| V7 — Session Management | The flow creates and depends on short-lived browser and token-session relationships. | |
| Recommendation — Verify redirect handling, token exchange, and client authentication against OAuth and OIDC requirements. Bind authorization and token sessions tightly and prevent token leakage through browser handling. | ||
Practitioner Guidance
Why practitioners should care: The code flow is secure only when the full transaction is treated as one trust boundary, not as a loose series of browser redirects and token calls. Teams should pay close attention to redirect validation, client authentication, code lifetime, and whether the deployment uses PKCE or another binding mechanism appropriate to the client type.
Practitioner takeaway: Treat a successful code exchange as a high-value security event, because the strength of the whole pattern depends on preventing code theft and making token issuance auditable.
Related resources from NHI Mgmt Group
- How should security teams implement the OAuth authorization code flow safely?
- How do organisations decide between OAuth Authorization Code flow and Client Credentials?
- How do organisations decide whether to move from implicit flow to authorization code flow in web applications?
- What is the difference between implicit flow and authorization code flow with PKCE?