Cybersecurity glossary
What is an Authorization Code?
Learn what an OAuth authorization code is, how the code grant exchanges a short-lived code for tokens, why PKCE matters for public clients, and how to keep authorization codes safe.
Definition
An authorization code is a short-lived, one-time credential issued by an OAuth 2.0 authorization server to a client after a resource owner grants consent; the client redeems it at the token endpoint for access tokens (and optionally refresh or ID tokens).
Why authorization codes exist
OAuth needs a way to move user consent from a browser to a client without exposing long-lived credentials in URLs. The authorization code is that bridge: a disposable credential delivered on the front channel, then exchanged on a safer token request.
This pattern underpins most modern web, mobile, and OIDC login flows.
Authorization code grant at a glance
Client starts authorize request
Redirects the user to the authorization server with client ID, redirect URI, scopes, state, and PKCE challenge.
User authenticates and consents
The authorization server verifies the user and records which permissions are granted.
Code returned on redirect
A short-lived code is sent to the registered redirect URI, typically as a query parameter.
Client redeems the code
The token endpoint receives the code, redirect URI, client authentication, and PKCE verifier.
Tokens issued
Access token, optional refresh token, and—for OIDC—an ID token are returned to the client.
Properties of a well-issued code
Short lifetime
Minutes or less reduce the window if a code leaks from logs or history.
One-time use
Replay of a spent code must fail; some servers revoke related tokens on reuse detection.
Redirect-bound
Redemption must match the exact registered redirect URI from the authorize request.
Client-bound
Confidential clients authenticate; public clients rely on PKCE to bind the flow.
Scope-limited
The eventual access token should reflect consented scopes—not ambient admin rights.
Front-channel only
Codes travel via redirect; tokens should not be copied into the same channel.
Threats specific to authorization codes
| Threat | How it works | Primary mitigation |
|---|---|---|
| Code interception | Malicious app or open redirect captures the code | PKCE + exact redirect URI allowlists |
| CSRF on callback | Attacker tricks user into completing attacker-started flow | Cryptographically strong `state` validation |
| Code replay | Stolen code redeemed twice or late | Single-use codes and short TTL |
| Mix-up / wrong AS | Client confused about which issuer to trust | Issuer identification and OAuth security BCP controls |
Implementation checklist
- Use authorization code with PKCE for browser and native apps; avoid implicit grant.
- Register exact redirect URIs; reject wildcards that enable open redirects.
- Keep authorization codes single-use with very short expiration.
- Authenticate confidential clients at the token endpoint with strong credentials.
- Validate `state` (and OIDC `nonce` when applicable) on every callback.
- Never log full authorization codes in access logs or analytics beacons.
- Detect authorization code reuse and treat it as a potential theft signal.
- Prefer sender-constrained access tokens for high-risk APIs after the exchange.
The practical takeaway
An authorization code is not API access—it is a brief, one-time ticket that unlocks tokens. Its security depends on strict redirects, short life, single use, and PKCE or client authentication at redemption.
Get those details right and the authorization code grant remains the safest mainstream OAuth front-door for user consent.
Related security terms
OAuth 2.0
The authorization framework that defines the authorization code grant.
Proof Key for Code Exchange (PKCE)
Extension that binds the code to the client that started the flow.
OAuth `state`
CSRF protection parameter used alongside the authorization request.
Refresh Token
Longer-lived token often returned when the code is exchanged.
OAuth Misconfiguration
Redirect URI and client mistakes that leak authorization codes.
Frequently asked questions
What is an OAuth authorization code in simple terms?
It is a temporary ticket your browser receives after you approve an app. The app quickly trades that ticket with the authorization server for real access tokens.
Why not send access tokens in the redirect?
Browser redirects and history leak easily. A short-lived code keeps tokens on a back-channel token request, especially when combined with PKCE and confidential clients.
How long should an authorization code live?
Only long enough for the client to complete the token exchange—often seconds to a few minutes—and it should be single-use.
What is PKCE and why pair it with authorization codes?
PKCE proves the same client that started the authorize request is redeeming the code, mitigating interception on public clients like native and single-page apps.
Can authorization codes be stolen?
Yes, via open redirectors, misconfigured redirect URIs, referrer leakage, or malicious apps. Stealers still need to redeem the code before it expires—PKCE and strict redirects raise the bar.
Does the authorization code itself grant API access?
No. It only authorizes the token endpoint exchange. Resource servers expect access tokens, not authorization codes.
Is the implicit grant still recommended?
No for new systems. Prefer authorization code with PKCE instead of returning tokens directly in the front channel.
References
Explore authoritative guidance and frameworks related to authorization code.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.