What does the OAuth 2.0 `state` authorization-request parameter protect a client against, and what does it not prove?

## What `state` is `state` is an authorization-request parameter defined by RFC 6749. The client generates it, puts it on the request to the authorization endpoint, and the authorization server is required to return it **unmodified** on the authorization response: ```http GET /authorize?response_type=code&client_id=s6BhdRkqt3&scope=journeys.read&state=af0ifjsldkj&redirect_uri=https%3A%2F%2Fclaims.example.rail%2Foauth%2Fcallback HTTP/1.1 Host: as.example.net ``` The authorization server treats it as opaque. It never interprets it, never validates it and has no opinion about it. Every bit of security value in `state` comes from what the **client** does with it. ## The attack it stops Take the rail operator's delay-repay claim service. A passenger links their ticket-retailer account so the service can read their journey history and fill in claims automatically. Without a `state` check, an attacker runs the flow themselves against the retailer, gets an authorization response for **their own** retailer account, and stops before redeeming it. They then cause the victim's browser to visit the claim service's redirection endpoint carrying that response - a link in an email, an image tag, any cross-site navigation. The claim service sees a callback with a code, redeems it, and attaches the **attacker's** retailer account to the **victim's** logged-in claim-service account. Now every journey the victim's account reads comes from the attacker's data, and anything the victim files, uploads or authorises against that link is visible to the attacker. This is cross-site request forgery aimed at the callback, and the general class of forged cross-site requests is a subject of its own; what is specific here is that the OAuth callback is a GET with a credential in it, so it is trivially forgeable unless the client insists it asked for this. ## Binding is the whole point A `state` value that is not tied to the user agent is decoration. The check has to be: *the value on this callback equals the value stored for this browser's session*. - Generate it from a cryptographically secure random source, per request, and make it long enough not to be guessed. - Store it **server-side against the session**, or in a cookie whose value the server compares - not merely echoed back out of the same URL. - Compare, then **consume** it, so the same authorization response cannot be replayed a second time. - Reject a callback with a missing value, an unknown value, or no stored value for that session. All three are the same answer: do not redeem the code. - Give the stored value a short expiry, so an abandoned flow does not leave a usable slot open for hours. | Check | What it proves | What it does not prove | |---|---|---| | `state` matches the session's stored value | This browser started this flow, and the response is the one it was waiting for | Anything about who issued the response | | `state` is present and well-formed | Nothing on its own | That it was ever bound to a user | | `state` is consumed after use | The response cannot be replayed at the callback | That the code was not also delivered elsewhere | The limit in the right-hand column matters. `state` is request binding and CSRF protection. It is **not** integrity protection over the response, and it is **not** a check of which authorization server answered - that is a separate mechanism owned by a different subject. A client that treats a matching `state` as "the response is genuine and from the right place" has drawn a conclusion the parameter does not support. ## When `state` is not the CSRF defence The common advice is "always send `state`", and as a default it is right. The specification is more precise. RFC 9700 section 2.1 says that a client which has **established** that the authorization server supports the proof-key mechanism MAY rely on that mechanism's CSRF protection instead of `state`, in which case `state` is free to carry application state - the page the user was on, the claim they were mid-way through. "Established" is doing real work in that sentence: assuming support you have not confirmed leaves you with neither protection. ## Failure modes worth recognising - A constant `state`, or one derived from the user identifier, so any value passes the comparison. - A value put in the URL and compared only against itself on return, which an attacker supplies on both sides. - A value stored in a shared cache without the session in the key, so two concurrent flows in two tabs validate each other's responses. - Logging the failure with the code still attached, which puts the credential in the log while investigating the attack.