How long does a GraphQL subscription's authorization stay valid, and where is it re-checked?

## Three moments, three different questions People talk about "authenticating the subscription" as if it were one act. It is three, and each answers a question the others cannot. **At connection establishment.** The server learns the caller's identity and attaches it to the socket. How the credential physically reaches the server at handshake time is a WebSocket transport concern and not what this question is about; what matters here is that the result is one identity, established once, for a connection that may live for hours. **At each subscribe.** One connection carries many independent operations, started at different times. A connect-time check has authorized *the caller*, not *the operations* — it cannot have, because none of them existed yet. Deciding whether this identity may run this document with these arguments has to happen when the operation arrives. In a warehouse inventory graph, a picker's socket is legitimately authenticated and their subscription to every purchase-order cost line is legitimately refused. **Per delivered payload.** Even an authorized subscription streams data that keeps changing. Whether the identity may see *this* event is a separate question from whether it could subscribe, and it is the only check positioned to notice that something changed since. ## The two clocks that do not match Here is the mismatch that makes this a real security question rather than a design preference. Access credentials are deliberately short-lived — fifteen minutes is a common figure. Subscriptions are deliberately long-lived: an operations dashboard on a wall screen holds one for a whole shift. Nothing reconciles those clocks by itself. The socket does not notice that a token's expiry passed. The subprotocols carry no expiry semantics — no field for it, no message meaning "your credential lapsed", no defined close reason for it. The GraphQL specification does not mention authorization at all, let alone its lifetime. So the default behaviour of a naive server is that a subscription authorized once at connect time keeps streaming privileged data indefinitely, long after the credential that justified it stopped being valid. That is the gap. ## Expiry is not revocation Two distinct failure modes, and they cost differently to detect. **Expiry** is a timestamp the server already holds from the credential it validated at connect time. Checking it is free: compare against the clock. No lookup, no network call. **Revocation** — a role removed, an account disabled, an item moved out of the caller's scope — is invisible in the credential. The credential still says what it always said. Catching revocation requires consulting current state, which is a lookup per check. That asymmetry drives the policy. Checking expiry on every event is cheap enough to be unconditional. Checking revocation on every event, for every subscriber, on a stream firing thousands of times an hour, is not — so it is usually done on a short cache TTL, or on a periodic sweep, or driven by an invalidation event when permissions change. ``` onSubscribe(connection, subscriptionId, operation): credential = connection.credential if credential.expiresAt <= now(): closeConnection("credential expired") return if not authorize(credential, operation): terminateSubscription(subscriptionId, "forbidden") return stream = start(operation) stream.onEvent(event -> if credential.expiresAt <= now() or not stillPermitted(credential, event): terminateSubscription(subscriptionId, "authorization expired") else: deliver(subscriptionId, event)) ``` ## The three workable policies **Terminate at expiry.** Record `expiresAt` when the credential is validated, and when it passes, end the subscriptions and close the connection. Simple, provably bounded, and it makes the maximum exposure window equal to the credential lifetime. The cost is a visible interruption the client must handle. **Accept a refreshed credential in-band.** Let the client send a new credential over the existing connection and re-evaluate. This keeps long streams alive without reconnecting, but be clear in an interview that it is an *application-level convention*: neither subprotocol defines such a message, so both ends must agree on it, and the server must re-authorize existing subscriptions against the new credential rather than merely storing it. **Re-authorize per event.** The strongest, and the only one that catches revocation rather than expiry. Because the cost is multiplied by every subscriber and every event, it is worth pushing the check into the same data access that produces the payload rather than adding a separate call. ## Making termination survivable Whichever you choose, the client experience decides whether the control is actually deployable. Terminate with a distinguishable signal so the client can tell "your credential lapsed, get a new one and resubscribe" apart from "the server is broken", and design the client to treat that as a reconnect-and-resync rather than an error to display. If termination looks like a crash, someone will raise the credential lifetime to make it stop, and the control will have made things worse. Cheap operational touch: log the identity, the subscription, and the reason on every authorization-driven termination, so the difference between an expiry storm and an actual attack is visible.