State / Nonce Generator

Generate cryptographically secure state and nonce values for OAuth2 and OpenID Connect flows

16–128 characters (32 recommended)
state CSRF protection
Click generate
nonce Replay protection (OIDC)
—
Usage in Authorization Request
Generate values first to see the example

State & Nonce in OAuth2 / OIDC

Why these parameters matter for secure authorization flows

What is State?

The state parameter binds the authorization request to the callback. It prevents CSRF attacks by ensuring the response matches the request you initiated. Store it in a session or cookie before redirecting, then verify it when the user returns.

What is Nonce?

The nonce parameter is used primarily in OpenID Connect flows. It is sent with the authorization request and must appear in the id_token claim. It prevents replay attacks by ensuring the ID token was issued in response to your specific request.

Character Set

Both values use the unreserved character set from RFC 3986: A-Za-z0-9-._~. This makes them URL-safe and suitable for query parameters or fragments without encoding.

State and nonce in OAuth2 and OIDC

State prevents CSRF on the callback

Generate a random state, store it in the user's session, and include it on the authorization request. When the callback arrives, check the returned value matches what you stored, then discard it.

Without this, an attacker can feed a victim an authorization code from the attacker's own account. The victim's browser completes the callback and gets logged into the attacker's account — where any data they then enter belongs to the attacker. Session fixation, via the login flow.

Nonce binds the ID token to your request

The nonce is an OIDC concept. You send it on the authorization request, and the provider embeds it in the ID token as a claim. Your client verifies the claim matches what it sent.

This defends against token replay: an ID token captured from one flow can't be injected into another, because the nonce won't match. It's required for the implicit and hybrid flows and remains good practice with the authorization code flow.

They are not interchangeable, and neither is PKCE

state protects the callback from forgery. nonce binds the ID token to the request. PKCE binds the authorization code to the client instance. Three parameters, three different attacks.

Use all three. They're each a random value and a comparison — the total cost is negligible relative to what they cover.

Frequently asked questions

At least 128 bits of entropy — 16 random bytes, which is about 22 base64url characters. Longer is fine. What matters is that the value is unpredictable and generated with a cryptographically secure random source.

No. Generate a fresh value per authorization request. A reused or predictable state is guessable by an attacker, which defeats the CSRF protection it exists to provide.

In the user's session, server-side where possible, or in a cookie or sessionStorage for a SPA. It only needs to survive the redirect round trip, and should be deleted once validated so it cannot be replayed.

They cover different things. PKCE protects the authorization code; nonce binds the ID token to your specific request. With the authorization code flow the overlap is partial, and using both is the recommended practice.

It's a common pattern — encoding a return URL, for example — but the state must still be unguessable and validated. If you encode data, sign it, and never trust its contents without verifying. A separate random value plus a server-side lookup is cleaner.

Next steps

Related tools

In the docs

All developer tools

State and nonce are table stakes

Generating them is easy; validating them correctly on every callback is where CSRF bugs live. Our SDKs do it for you by default.

Start free Read the flow guide

Free, unlimited users. No credit card required.