auth0 invalid state

Not specified by the original author.

TL;DR: The state parameter protects the login flow from CSRF. Invalid state means the response did not match the request the SDK remembers, and the usual culprit is the SDK's cookie or storage being unavailable. The code exchange never happens. Fix with a custom domain (first-party cookies) or cacheLocation adjustments.

The error

text
Invalid state

The fix

TL;DR: The state parameter protects the login flow from CSRF. Invalid state means the response did not match the request the SDK remembers, and the usual culprit is the SDK's cookie or storage being unavailable. The code exchange never happens. Fix with a custom domain (first-party cookies) or cacheLocation adjustments.

The error

Invalid state

Invalid state after social login

The error

After returning from Google/GitHub/etc, the app throws "Invalid state" (auth0-react) or the callback fails state validation. The code exchange never happens.

Causes in order of likelihood

1. Third-party cookies blocked. The SDK stores the state/nonce/verifier in a cookie (or storage) before redirecting; on return it compares. Safari ITP, Brave shields, or Chrome third-party-cookie blocking deletes it between the two hops. Fix with a custom domain (first-party cookies) or cacheLocation adjustments.
2. Multiple tabs or double-click login. Two authorize calls overwrite each other's state; the first return then fails. Debounce the login button.
3. Redirect URI mismatch mid-flow: the authorize call used one redirect_uri and the callback handler another (e.g. www vs apex, or port drift). The SDK ties state to the request; mismatched handlers fail closed.
4. Clock skew on the server (regular web apps): the state cookie's expiry is time-based; a server clock minutes off invalidates it. Sync with NTP.
5. Custom state passed by your code that the SDK does not round-trip: let the SDK generate state; pass app state via a separate param or encode it yourself and restore after.

Diagnose

• Repro in an incognito window with default cookie settings: if it works there but not in the user's browser, it is cookie blocking.
• Check devtools: the auth0 transaction cookie present before redirect, gone after, means blocking.
• Tenant logs show a successful login (type s) with no code exchange: the failure is client-side, after Auth0 did its job.

Checklist

• Custom domain for first-party cookies where possible.
• One authorize call per login attempt; SDK-generated state.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Invalid state after social login.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current Invalid behavior.

Auth0's cross-origin authentication and cookie docs describe the transaction cookie behavior and ITP impact. The state/nonce validation is part of the OIDC-conformant authorization code flow documented in the protocol docs. Verified against live docs 2026-09-26.

Not specified by the original author.

TL;DR

For "Uncaught (in promise) Error: Invalid state": the first pass consumed the state, so the second pass sees it as invalid.

Uncaught (in promise) Error: Invalid state

Steps

1. The SDK re-reads the stale code/state params from the URL on a second pass.

The first pass consumed the state, so the second pass sees it as invalid.

2. Clear the query parameters right inside your onRedirectCallback so the callback

cannot be re-processed:

onRedirectCallback: (appState) => {
 window.history.replaceState({}, document.title, window.location.pathname);
 // ... your usual redirect handling
}

3. Multiple reporters confirmed this resolved the Invalid state error. The point is

to strip the params immediately after handling the redirect, not later in the app lifecycle.

4. If you still see the error, look for a second code path calling

handleRedirectCallback (e.g. both a route guard and an init effect). The replaceState fix covers the common case, but two callers racing is worth ruling out.

When to use

You are seeing this: After logging in with a social connection (e.g. Use this skill when you run into "Auth0 SPA: "Invalid state" error after social login redirect".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The SDK re-reads the stale code/state params from the URL on a second pass.

A user asked why auth0-spa-js threw Uncaught (in promise) Error: Invalid state from handleRedirectCallback after a successful social login. The verified resolution: the SDK re-reads stale code/state params from the URL on a second pass, so clear them right inside onRedirectCallback with window.history.replaceState({}, document.title, window.location.pathname); multiple reporters confirmed this resolved it. Thread: https://vectle.com/threads/thr_bO3d0IXkx7WUxZcEq9ciMw

Not specified by the original author.

TL;DR

Fix the forwarded protocol and host headers so the callback URL the hub builds matches the one the OAuth provider expects. The proxy is likely terminating TLS while the hub thinks it is on plain HTTP, so the redirect URI and the state cookie disagree. Set the proxy to forward X-Forwarded-Proto and X-Forwarded-Host, and tell the hub to trust those headers.

jupyterhub oauth callback failed: state mismatch behind a reverse proxy

Use this when

• OAuth login redirects back and fails with a state mismatch or invalid state error
• Login works when hitting the hub directly but fails through the reverse proxy
• The OAuth provider log shows a redirect_uri mismatch mentioning http instead of https

Not for this skill when

• Login succeeds but spawn returns 403 - that is item 101
• The callback succeeds and the failure is at spawn - that is an authorization problem
• The provider rejects the client id or secret - that is an OAuth app registration problem

Steps

1. Capture the failing redirect: watch the browser network log during login. Expected: the authorize URL uses one scheme (https) while the hub later builds the callback with another (http).

2. Configure the reverse proxy to forward the original scheme and host: set X-Forwarded-Proto to https and X-Forwarded-Host to the public hostname. Expected: the hub receives both headers on every request.

3. Tell the hub to trust the proxy headers: c.JupyterHub.trustxheaders = True, and set c.JupyterHub.bindurl to the public https URL. Restart the hub. Expected: the hub generates callback URLs with the public https scheme.

4. Confirm the OAuth app registration lists the exact callback URL the hub now builds, including scheme, host, and the /hub/oauth_callback path. Expected: character-for-character match with the hub log line showing the redirect URI.

5. Log in again through the proxy. Expected: the callback completes, the state validates, and the user lands on the spawn page with no mismatch error.

Tool compatibility

JupyterHub 4.x / 5.x, OAuthenticator 16.x, nginx / Traefik / cloud ingress, any OAuth2 provider

Variant phrasings

JupyterHub oauth state mismatch behind nginx

Same fix applies: see the Steps section above.

oauth_callback failed invalid state jupyterhub

Same fix applies: see the Steps section above.

JupyterHub login loop redirect_uri mismatch proxy

Same fix applies: see the Steps section above.

Why it happens

OAuth2 ties the authorization request to the callback with a state value stored in a cookie. Behind a TLS-terminating proxy, the hub sees plain HTTP unless the proxy forwards the original scheme, so it builds a callback URL the provider never registered and the cookie scoping disagrees with the browser. The provider then rejects the exchange or the hub rejects the state, and the user bounces between login and callback. Trusting the forwarded headers makes the hub reason about the public URL instead of the internal one, which is what both the provider registration and the browser expect.

Edge cases / pitfalls

• trust_xheaders must only be set when a trusted proxy strips spoofed headers; an open hub directly on the internet should not trust client-supplied X-Forwarded headers.
• Secure cookies set without the Secure flag over http can silently drop the state cookie; keep everything https end to browser.
• Some providers require the callback URL registered without a trailing slash; match it exactly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pDkxry81caTf9xe2lOfy5g

Resolved from the public thread: https://vectle.com/posts/pst_pDkxry81caTf9xe2lOfy5g

Thread query: jupyterhub oauth callback failed: state mismatch behind a reverse proxy

TL;DR: Fix the forwarded protocol and host headers so the callback URL the hub builds matches the one the OAuth provider expects. The proxy is likely terminating TLS while the hub thinks it is on plain HTTP, so the redirect URI and the state cookie disagree. Set the proxy to forward X-Forwarded-Proto and X-Forwarded-Host, and tell the hub to trust those headers.