OAuth 2.0 Authorization Code Grant

What the Authorization Code Grant Does

The authorization code grant is the OAuth 2.0 flow most often used when an application can safely redirect a user to an identity provider, receive a short-lived code, and exchange that code server-side for tokens. It is designed to separate user authentication from token delivery.

That separation matters because the browser only sees the temporary authorization code, while the back-end component performs the token exchange. In practice, this makes the grant suitable for web applications that can keep a client secret or another strong proofing method out of the user agent.

How the Flow Works

At a high level, the app sends the user to the authorization server, the user authenticates and consents, and the authorization server returns an authorization code to the redirect URI. The application then redeems that code at the token endpoint and receives an access token, and sometimes a refresh token, depending on the client type and policy.

The code itself is intentionally short-lived and single-use. That design reduces the value of interception compared with handing tokens directly to the browser, and it is one reason the flow replaced older approaches that exposed bearer tokens too early.

For modern deployments, RFC 6749: The OAuth 2.0 Authorization Framework remains the base standard for the grant, while OpenID Connect Core 1.0 layers authentication on top when the application also needs an identity token.

Why It Is the Preferred Web App Pattern

This grant is preferred for confidential web applications because it keeps higher-value secrets and token exchange logic on the server side. That reduces exposure in the browser, where scripts, extensions, and redirect handling create a much larger attack surface.

It also supports delegated access cleanly. The user consents to specific scopes, the application receives only the permissions it needs, and the resulting token is bound to the authorization server’s policy decisions rather than to the browser session alone.

For teams comparing OAuth patterns, NHIMG’s OAuth 2.0 and OpenID Connect Guide for Identity Teams explains where the authorization code grant fits among PKCE, client types, scopes, and token handling.

Security Properties and Common Variants

The grant is often paired with PKCE so that even public clients can prove possession of the code verifier when redeeming the authorization code. That closes an important gap for apps that cannot safely hold a client secret, including many mobile and single-page application patterns.

Additional protections can further narrow token exposure. Sender-constrained tokens, audience restriction, and strict redirect URI validation all help ensure that an intercepted code or token cannot be replayed as easily or used against the wrong resource.

When implementers need guidance on the surrounding controls, RFC 9700: Best Current Practice for OAuth 2.0 Security is the most useful companion for hardening token handling, while RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) shows one way to reduce replay risk for stolen tokens.

Risks and Failure Conditions

Authorization code grant security depends on the integrity of the redirect, the token exchange, and the client’s ability to keep secrets and verifier material protected. If any of those assumptions fail, an attacker may steal the code, complete the exchange, or pivot from a compromised browser session into API access.

Failure mechanism: weak redirect URI validation, code interception, token leakage in logs or front-end code, and poor client authentication can all turn a normally safe flow into a practical account or API compromise path.

Impact: the attacker may obtain delegated API access, abuse user consent, exfiltrate data, or persist through long-lived refresh tokens if revocation and scope controls are weak.

Practitioner Guidance

Why practitioners should care: This grant is the default choice for most web and enterprise OAuth integrations, so small implementation mistakes have a large blast radius. The flow is only as strong as its redirect hygiene, client authentication, and token handling discipline.

Common misunderstanding: Many teams treat the authorization code as harmless because it is temporary, but a stolen code is still valuable if the exchange path is weak. The safer mental model is that the code is a protected credential exchange artifact, not merely a routing token.

Practitioner takeaway: Use the grant as designed, then harden the exchange path and the token lifecycle rather than assuming the flow itself makes the integration secure.

Related resources from NHI Mgmt Group

• What is the difference between Authorization Code and Implicit grant types in OAuth?
• How should security teams implement the OAuth authorization code flow safely?
• How do organisations decide between OAuth Authorization Code flow and Client Credentials?
• What is the difference between an authorization code and an access token in OAuth?