Identity is settled when a broker connection is opened, so what does that mean for a client holding a short-lived signed token?

## Authentication is an event, not a state A broker client is not a browser. It opens a connection and keeps it, often for days, pushing and pulling records over the same connection the whole time. The proof it presented was evaluated once, at the moment the connection was established, and what the connection carries afterwards is the **principal** the broker derived from that proof. This is the structural difference from a request-per-call interface, where every call re-presents the credential and every call is therefore a fresh decision. Some clusters expose both shapes, and the same credential behaves differently on each. ## What expiry does to an already-open connection There is no single answer, and saying so is the answer: | Design | What happens when the credential's validity ends | |---|---| | Re-authenticate in place | The protocol lets the client hand over a fresh credential on the live connection; nothing drops | | Close on expiry | The broker records the credential's end time and terminates the connection when it passes, forcing a reconnect | | Never re-check | The connection is untouched; the credential matters only the next time the client connects | Three consequences follow, and they are what interviewers are after: - **Expiry is not revocation.** On a design that never re-checks, ending a credential's validity does nothing to sessions already established. The checkpoint is the next reconnect, and a client that never reconnects never reaches it. - **An open connection proves nothing about the present.** "It is still connected, so its credential must be fine" is a false inference on two of the three designs. - **A long-lived connection hides the failure.** A misconfigured refresh path can be invisible for as long as nothing reconnects, and then surface everywhere at once — on a deployment, a rolling restart, or a network blip that drops many connections together. ## What the operator has to build around it 1. **A refresh ahead of expiry, not after a failure.** The client fetches a new credential while the old one is still valid and uses it for the next connect or in-place re-authentication. A client that only refreshes on an authentication error has made every expiry into an error first. 2. **Leeway for clock disagreement.** The party that mints a short-lived credential and the broker that checks it do not share a clock. Both a too-tight validity window and a refresh that cuts it fine turn a few seconds of skew into refusals, and the symptom — intermittent connect failures with a credential that looks valid — is one of the more confusing ones to diagnose. 3. **Spread the moment.** When many clients were started together they refresh together, so their credentials end together and they all take the connect path at the same instant. Adding jitter so that expiry times differ turns one sharp event into a smear. 4. **A path for the client that cannot refresh.** Batch jobs, operational tools and anything a human runs by hand tend to acquire a credential once and hold it. They are the population that fails first when an estate moves to short-lived credentials. ## Why this is a broker question, not a general one On a web service the request is the unit, so a credential's lifetime and a session's lifetime are close to the same thing. On a broker the connection is the unit, and connections routinely outlive by days the credentials that established them. That gap is where the surprises live: a fleet that appears healthy while half its credentials have long since expired, an incident where the response "we ended that credential" turns out to have had no effect on anything already connected, and a restart that reveals, all at once, that a refresh path has been broken for a week. ## What a strong answer sounds like Name the split — re-authenticate in place, close on expiry, or never re-check — say which one turns expiry into a reconnect-time event, then draw the operational conclusions: refresh ahead, allow for clock disagreement, jitter the expiry times, and stop treating a live connection as evidence that anything about its credential is still true.