Cybersecurity glossary
What is OAuth `state`?
Learn what the OAuth state parameter is, how it prevents login CSRF and session fixation-style attacks on redirects, and how to generate and validate state securely.
Definition
OAuth `state` is an opaque value the client includes in the authorization request and must verify on the callback; it binds the redirect response to the user’s browser session and mitigates cross-site request forgery against the OAuth redirect endpoint.
Why OAuth redirects need a CSRF brake
Browser OAuth flows return through a redirect URI you control. Without a binding value, an attacker can start an authorization request and trick a victim’s browser into completing it—linking the victim’s session to the attacker’s account or injecting an attacker-controlled login. The state parameter exists to stop that class of attack.
How state is supposed to work
Generate opaque state
Create a high-entropy random value when the user starts login.
Persist it in the user session
Store state server-side or in a secure, integrity-protected cookie.
Send state to the authorization server
Include it on the authorize redirect with client ID, PKCE, and scopes.
Compare on callback
Reject the response unless returned state exactly matches the stored value.
Invalidate after use
One-time state prevents replay of captured callbacks.
Attacks state helps prevent
Login CSRF
Attacker forces victim to complete attacker-started OAuth and bind accounts incorrectly.
Unsolicited callbacks
Random authorization codes posted to your redirect URI are ignored without matching state.
Session mismatch
State ensures the browser finishing login is the one that began it.
Simple replay
Single-use state reduces reuse of intercepted callback URLs.
State vs nonce vs PKCE
| Control | Primarily protects | Checked where |
|---|---|---|
| state | Redirect CSRF / session binding | Client on callback |
| nonce | ID token replay/injection | Client validating ID token |
| PKCE | Authorization code interception | Authorization server on token exchange |
Implementation checklist
- Generate state with a CSPRNG; treat it as a secret, not a sequential ID.
- Bind state to the browser session that started the flow.
- Reject callbacks with missing, duplicate, or mismatched state.
- Make state single-use and short-lived.
- If embedding return paths in state, protect integrity and allowlist destinations.
- Use state together with PKCE for public clients—not as a substitute.
- For OIDC, also generate and validate nonce on the ID token.
- Log state failures without logging full authorization codes.
The practical takeaway
OAuth state is the CSRF token of the authorization redirect. Skip it—or check it weakly—and browser login flows become forgeable.
Generate strong random state, bind it to the session, validate strictly on return, and combine it with PKCE and OIDC nonce for a complete front-channel defense set.
Related security terms
Authorization Code
Returned on the callback that must be paired with validated state.
OIDC `nonce`
Related binding value for ID tokens; complements state but serves a different purpose.
OAuth 2.0
Framework that recommends state for CSRF protection.
OAuth Misconfiguration
Includes missing or weak state validation.
Cross-Site Request Forgery (CSRF)
Attack class that OAuth state is designed to mitigate on redirects.
Frequently asked questions
What is the OAuth state parameter in simple terms?
It is a secret random string your app remembers when starting login. When the user comes back from the identity provider, your app checks that the returned state matches—so attackers cannot force a victim’s browser to finish an attacker-started login.
Is state required?
OAuth security best current practice treats CSRF protection on the redirect as mandatory. Using a strong state (or equivalent) is expected for browser-based flows.
How is state different from nonce?
State protects the redirect/callback against CSRF. Nonce binds an OIDC ID token to the client session to prevent certain ID token replays. Use both in OIDC authorization code flows.
How should state be generated?
Use a cryptographically secure random value with high entropy, store it server-side or in a sealed cookie tied to the session, and invalidate it after use.
Can state carry return URLs?
You may encode application context, but sign/encrypt it or keep a server-side map. Never trust an unsigned return URL inside state for open redirects.
What if state validation fails?
Abort the login, do not exchange the authorization code, and log the event as a potential CSRF attempt.
Do native apps need state?
Yes for redirect-based flows. Combine with PKCE; state still helps bind the callback to the initiating session.
References
Explore authoritative guidance and frameworks related to oauth `state`.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.