What does a live session cookie prove about who is at the keyboard right now?
answer
- acceptance in the past, not presence now
- the ceremony happened once, at issuance
- possession is the whole test afterwards
- auth_time and amr describe a past moment
basics
~20 sOnly that the sender holds a value the service issued earlier and has not expired. The factors were checked once, at issuance; every later request is honoured on possession alone. A session proves acceptance in the past, not presence now.
solid answer
~40 sIt proves only that whoever sent the request holds a value the identity provider issued earlier and has not yet ended. The factors - a password, a one-time code, a FIDO2/WebAuthn assertion - were presented once, during the issuance ceremony; the provider accepted them and minted a session. Every request after that is honoured on possession of the session alone, and nothing in it re-checks a human. So the correct reading is *a credential was accepted at some earlier moment*, not *this person is here now*. An identity provider writes that moment into the token as `auth_time`, and the methods used as `amr`, and both are statements about the past. Phishing resistance is a property of the ceremony, not of the artefact the ceremony mints.
go deeper
Be ready to state plainly what a session is honoured on: possession. Know that factors are checked once, when the session is issued, and not on the requests that follow it.
Explain the two separate events - the authentication ceremony and the artefact it mints - and name what carries the ceremony forward, such as the auth_time and amr claims in an OpenID Connect ID token.
Expect to be pushed on consequences: if possession is the whole test, which operations in your tenant must refuse to run without a recent ceremony, and how you enforce that on every path to them.
Own the framing that factor strength is a property of the ceremony while exposure is a property of the artefact's lifetime, and be able to say which of the two your spending has actually improved.
## Two things that both get called "authentication" Signing in to a SaaS tenant is really two events, and most wrong answers here come from merging them. The first is the **authentication ceremony**. You present factors - a password, a one-time code from an authenticator app, a FIDO2/WebAuthn assertion from a security key - and the identity provider decides whether to accept them. This is an *event*: it has a moment in time and a set of methods. The second is **issuance**. Having accepted the factors, the provider mints an *artefact*: a session cookie, a server-side session entry with an identifier, an access token, or all three. That artefact accompanies every request afterwards. The ceremony is over in seconds. The artefact can live for weeks. Everything interesting about this subject lives in the gap between them. ## What the artefact is honoured on At presentation time the service asks a far smaller question than the ceremony asked. Is this value one I issued? Is it still within its validity? Has it been ended? If those pass, the request proceeds. There is no step in which a human is checked again, because there is nothing inside the artefact to check a human against. Possession is the whole test. That fixes the direction of the claim, and interviewers listen for it: **a valid session proves that a credential was accepted at some earlier moment, not that the account's owner is making this request**. A service accepting a credential tells you the credential was acceptable, never that a particular person was at the keyboard. ## The claims that describe the ceremony OpenID Connect carries the ceremony in two claims worth naming precisely: - `auth_time` - when the end user actually authenticated. - `amr` - authentication methods references, with values such as `pwd`, `otp` or `hwk` (RFC 8176 registers them). Both look backwards. `amr: ["pwd", "mfa"]` means a second factor was accepted at `auth_time`; it does not mean a second factor was involved in the request in front of you, and it stays exactly the same when a token is reissued by renewal. `iat` and `exp` describe the token, not the human: a token minted this morning can sit on a ceremony from a month ago. ## Why a hardware key does not change the answer WebAuthn is strong precisely where the ceremony is weak. The assertion is bound to the origin, so it cannot be replayed at a different site, and the private key never leaves the authenticator, so it cannot be copied out. That makes it hard for someone to *complete a ceremony* on your behalf. But the property belongs to the ceremony. The session minted afterwards is an ordinary artefact honoured on possession, exactly like the one a password-only sign-in would have produced - unless the session itself is sender-constrained, bound to a key the client must demonstrate it still holds, which is a different and much rarer design. "We use phishing-resistant factors" is a claim about the front door, not about what the front door hands out. ## What follows Two consequences fall straight out. 1. **Anything reachable with the session is reachable with no factor at all.** For someone holding one live session and nothing else - no code running anywhere, no host owned - that is still one whole identity's worth of access: mail, files, chat, approvals, whatever that account reaches in the tenant. 2. **The only way to bring a human back into the loop is a precondition on an operation.** The service refuses to perform something unless authentication happened recently. That has to be a comparison against the current time, because the session cannot vouch for its own freshness. ## Answers that lose marks - "Multi-factor is enforced, so the session is protected." The enforcement sits on the ceremony that already happened. - "The session expires, so it re-checks the user." Expiry ends an artefact; while the artefact lives nothing is re-checked, and renewal can keep pushing expiry away. - "`amr` says `mfa`, so this request is multi-factor protected." That claim is a historical statement carried forward, not a property of the request.
- Does it change anything if the sign-in used a FIDO2/WebAuthn security key?Not for the session. WebAuthn makes the ceremony hard to complete on someone else's behalf: the assertion is bound to the origin and the private key never leaves the authenticator. But the artefact minted afterwards is an ordinary session honoured on possession, unless the session itself is bound to a key the client must keep proving it holds.
- Which OpenID Connect claims record that earlier ceremony?`auth_time` carries when the end user authenticated, and `amr` lists the methods used - values such as `pwd`, `otp` or `hwk`. Both describe that past moment. A token minted weeks later by renewal still carries the original `auth_time`, which is why neither claim tells you anything about the request currently being served.
- If possession is the whole test, what can still force a human back into the loop?Only a precondition attached to an operation: the service refuses to run it unless authentication happened within some recent window. Nothing inside the session can supply that, because the check is a comparison between now and when authentication last actually occurred.
A wristband at a festival. Staff checked your ticket and your face once, at the gate; after that the band is the entire test, and it works just as well on whoever is wearing it.
saying these in an interview costs you the question
- Says a valid session proves the user is present
- Thinks multi-factor at sign-in applies to every later request
- Treats session expiry as a re-check of the human
- Assumes a hardware key makes the resulting session unstealable
- Reads amr as a statement about the current request