Why does a client that caches and replays one pushed-authorization request_uri get its authorization requests rejected?

## What the reference actually is When a client pushes an authorization request, the authorization server stores that **parameter set** and returns a handle to it. The handle identifies one prepared request. It is not a client identifier, not a session, and not a capability the client may keep. Everything about how it is specified follows from that: high entropy so it cannot be guessed, a short lifetime, and a binding to the client that pushed it. ## The two rules that defeat a cache **Lifetime.** The response carries `expires_in` beside the `request_uri`, and the lifetime the specification expects is short — its own example range of 5 to 600 seconds is illustrative, not a requirement, and a deployment sets its own. The window only has to cover the gap between the client pushing and the browser arriving. After it, the reference resolves to nothing and the authorization request is rejected. **Single use.** Some of the pushed values belong to exactly one attempt: the `state` the client will match on the way back, and the challenge bound to the code exchange. Replaying the reference replays those values. The specification therefore splits the obligation: - The **client** is required to use a `request_uri` value only once. - The **authorization server** is expected to treat it as one-time use, but is **permitted** to allow a duplicate — because a resource owner reloading or refreshing the page produces a second, entirely innocent presentation of the same reference. That is a genuine SHOULD/MAY split and it is worth stating precisely, because it explains the symptom: the cached reference sometimes works, which is exactly what makes the bug survive testing. ## The checks a server runs on a presented reference 1. Does the reference resolve to a stored request at all? 2. Was it issued to the `client_id` presenting it? A reference issued to one client is not usable by another. 3. Has its lifetime passed? 4. Has it already been consumed, and is this a case the server chooses to tolerate? Only then are the stored parameters used to run the authorization flow. ## Why replay fails even when the endpoint tolerates it Suppose the server allows the duplicate. The flow proceeds with the **stored** parameters — including the original `state` and the original challenge. Two things then go wrong downstream: - The client's own `state` check compares the returned value against whatever it generated for the current attempt, and a cached reference returns yesterday's. - The code exchange presents a verifier that must correspond to the challenge inside the stored request. A client that generated a fresh secret for this attempt cannot satisfy a challenge pushed for an earlier one. So the failure moves rather than disappearing, which is the classic shape of this bug report: "authorization works, the token call fails". ## What the correct pattern looks like | Mistake | Symptom | Correct behaviour | |---|---|---| | Caching one reference at startup | Works briefly, then every login fails | Push once per authorization attempt | | Sharing one reference across users | Wrong `state` returned, or cross-user confusion | One reference per attempt, per user agent | | Treating a tolerated refresh as permission to replay | Intermittent success that hides the defect | Treat tolerance as a courtesy to the browser, never a contract | | Retrying the redirect after a long delay | Rejection with no obvious cause | Re-push and redirect with a fresh reference | ## The diagnostic When authorization requests fail intermittently and the failures correlate with elapsed time or with repeated sign-ins from the same client instance, look at where the reference is produced. A push per attempt costs one back-channel round trip and removes the entire class. If the round trip is genuinely the problem, the answer is to push later — as close to the redirect as possible — not to reuse what was pushed.