A server-side relying party redirects a depot supervisor to the fleet operator's identity provider — what must it keep until the callback arrives?

## An authorization-code login is two requests, not one A server-side relying party runs a federated login as two separate HTTP exchanges. In the first, the dashboard builds an authorization request and redirects the browser away to the fleet operator's identity provider. In the second — seconds or minutes later, after the supervisor has typed a password and possibly answered a second factor — the browser arrives back at the dashboard's callback endpoint. Nothing in HTTP connects the two. The callback is an ordinary request from a browser that has just been somewhere else. So "what must the server keep" is really "what does the callback fail to bring". ## What the browser actually brings back The provider echoes only what it is supposed to echo: - the authorization **`code`**, single-use and short-lived; - the **`state`** value your authorization request carried, returned unchanged; - from providers that implement it, an **`iss`** value naming which authorization server answered. That is the payload. The provider is not holding your application's memory for you, and the browser is not a place to keep it. Everything the second half of the login needs has to be waiting on your side, findable from the one value you know will come back. ## The record, as one object Hold it as a single record per sign-in attempt rather than as four loose values in four places — one write when the authorization request is built, one read-and-delete when the callback lands: - **the value you sent as `state`** — this is the record's key, not a field inside it; - **the `nonce`** you generated for the authorization request, kept so the ID-token check at the callback has something to compare against; what that comparison proves is the specification's subject, not yours; - **the `code_verifier`**, because the token request has to present the original random value whose derived `code_challenge` went out earlier, and nothing in the callback carries it; - **which provider the request went to**, the moment the dashboard offers more than one sign-in button; - **the destination** the supervisor was originally heading to, so the login lands them on the vehicle list they clicked rather than the home page; - **a creation timestamp**, so the record can expire on its own. Everything in that list is either random, and therefore unrecoverable, or contextual, and therefore unknowable from the callback. That is the test for what belongs in the record. ## What the callback endpoint does, in order 1. Read the `state` query parameter and look up the record by it. 2. If there is no record — absent, expired, already consumed — stop and render a page saying the sign-in expired, offering to start again. This is a normal outcome, not a server error. 3. Consume the record: delete it, atomically, before any further work, so a concurrent or replayed callback finds nothing. 4. Exchange the `code` at the token endpoint, presenting the `code_verifier` from the record. 5. Run the checks the specification requires on what comes back, using the `nonce` you kept. 6. Hand the resulting subject to your own session layer, issue your own session, and redirect to the destination from the record. The relying party's work ends at step 6. What the session layer then does with that subject — where the resulting credential rests in the browser, how long the session lives, whether a local account is created on first sight — is a separate concern with a separate owner. ## Lifetime and single use The record's TTL is **minutes, not hours**. It must be long enough for a realistic authentication at the provider, including a second factor and the occasional password reset; ten to fifteen minutes is defensible and an hour is not. A long TTL buys nothing and leaves a large pile of half-finished logins sitting in a store. Single use matters as much as expiry. A callback can arrive twice for entirely ordinary reasons: a double-clicked link, a refresh, a back button, an over-eager link prefetcher. Delete-on-read makes the second arrival find nothing, which is right — the first attempt either issued a session or failed, and either way the second has nothing to do. If a session was already issued, notice that and send the supervisor onward rather than showing an error. The token endpoint is a second line of defence here: an authorization code redeemed twice comes back as `invalid_grant`, not as a second set of tokens. ## Where this goes wrong first - Keeping the record in a process-local map, which is wrong the moment there is a second instance and is emptied by every deploy. - Trying to derive the `code_verifier` from something deterministic instead of storing the random value. - Pushing the post-login destination into the callback URL instead of into the record. - Writing records and never expiring them, so the store grows for the life of the service.