Sign-out destroys the stored session record — what else must end with it, and which item do teams forget?

## Sign-out is a teardown, not a redirect "Logout did not log out" is the oldest complaint in this subject, and almost every instance of it is the same root cause: the code treated sign-out as a navigation — clear the reference, send the user to the sign-in page — when it is a teardown of everything that was created under one authentication. The stored record is the first item on that list and the easiest one. The value of the question in an interview is not the list itself but knowing which line gets skipped and why. The frame that makes the list memorable: **anything that can act as that user after the button is pressed must be ended, and anything that can *create* a new session for that user must be ended first.** ## The checklist | Item | Why it outlives the record | What it costs if skipped | |---|---|---| | The stored session record | nothing deletes it but you | the reference keeps authenticating | | A per-instance copy of that record | a local cache in front of the shared tier has its own lifetime | one server keeps honouring a destroyed session | | The reference in the client's cookie jar | the client holds it until told otherwise | a value that still gets presented, and is readable on a shared console | | A persistent-login cookie | it is a separate credential, by design | the next request silently creates a **new** authenticated session | | The anti-forgery token for that session | it was issued against a session that is now gone | confusing failures for the next user of the console | | A connection authenticated at its handshake | it was checked once, at the start | it keeps delivering data after sign-out | | Credentials obtained downstream for that user | they live in their own store with their own lifetimes | the server keeps acting for a signed-out user | | Pages already rendered to the client | they were delivered before the button was pressed | previously-shown data is re-displayable | The last two rows are deliberately shallow here, because each is a mechanism in its own right — revoking stored downstream credentials, and how a client or an intermediary holds an already-delivered authenticated page, are separate subjects with their own rules. What belongs on *this* checklist is that neither of them ends by itself when you delete a row. ## The item teams forget, and why It is the **persistent-login cookie**. Two reasons it is missed and one reason it matters more than the rest: - It is missed because it was built by a different change, for a different purpose — convenience — and often lives in a different store from the session record, so a sign-out written against the session tier simply never touches it. - It is missed because testing sign-out usually means clicking sign-out in a browser that then sends *both* references on the next request, gets rejected on the session one, and looks correct. - It matters more because of asymmetry: a stale rendered page discloses data the user already saw, while a surviving long-lived credential is **exchanged for a fresh authenticated session** on the very next request. The user pressed sign-out and is signed in again, with a new identifier and a full set of clocks. On a console that several people use across a shift this is the whole point of the button. The test that catches it is blunt: sign out, throw away the session reference, replay only the persistent-login credential against an authenticated endpoint, and require a rejection. ## Ordering: destroy before you respond The teardown happens **before** the response is written, not after it. The window between "we sent the redirect" and "we deleted the row" is small and entirely real — a request already in flight from another tab, or a background poll on the console, lands inside it and authenticates successfully against a session the user believes is over. Do it in this order: 1. Destroy the stored record, and invalidate any local copy of it in front of the shared tier. 2. Revoke the separate credentials created under that session, the persistent-login cookie first. 3. Close the connections that were authenticated at handshake time. 4. Write the response, clearing the client's references as a courtesy. Step 4 is last and is the weakest step in the list: clearing a client-side copy stops a well-behaved client re-presenting a value, and does nothing at all about a value that has already been copied elsewhere. That is why the deletions above it are the ones that matter. ## What sign-out honestly cannot reach An answer that claims sign-out reverses everything is wrong, and saying so is part of the answer. Bytes already delivered to a client have been delivered. A stateless credential handed to another system keeps validating until its own lifetime ends unless that system is told otherwise. What sign-out does guarantee is narrower and worth stating plainly: **no new request authenticates, and nothing left behind can mint a session.** Design the surfaces on the console with that guarantee in mind rather than pretending to a stronger one.