Immediate Access Shutdown for Profile Updates and Global Session Revocation (3 Rules)

A healthtech signup flow can pass its captcha and still leave a dangerous gap: an account is banned in the profile database while an already-issued session keeps working. That is an access-control incident waiting for a clock to run out. Short answer: model a ban as an auditable profile-state transition, then revoke every session as a separate, explicit lifecycle action. Keep the short-lived access credential and its refresh capability under different risk controls, and make “this device” and “all devices” distinct operations. The incident lesson: a profile flag is not a kill switch The operational constraint is immediate shutdown. When abuse review marks a user as banned, the system must stop new work and invalidate existing access without relying on a browser logout button. I have been paged for missed jobs and duplicate deliveries; the same lesson applies here: a state change is only useful if every consumer observes it. The invariant is simple: every authentication action is a checkable, auditable, recoverable state transition. Signup protection (including captcha verification) is one transition. Session creation, verification, refresh, and revocation are four more. Treating them as one giant “auth request” makes it impossible to answer an audit question such as “which session was active after the ban?” Write the ban first, with an audit record that ties the user to the operator, reason, and request ID. Then issue the global revoke command. The ordering matters because a revoke without a durable profile state can be undone by an automatic refresh; a profile update without revocation leaves the old bearer credential alive until expiry. That sounds obvious. It is often missed. How should profile state updates trigger global session revocation? Use two explicit calls and one transaction boundary in your own service. changes the profile state. invalidates sessions on every device. They are separate verbs because they have separate audit semantics and retry behavior. The caller should attach an idempotency key to the write path, persist the decision before making the network call, and record both responses. A retry after a timeout must replay the same decision, not create a second ban event or silently switch from one user to another. On HTTP 429, honor and back off; a tight loop during an abuse spike can become its own denial-of-service. In practice, I keep the audit row, the chosen user ID, the policy version, and the idempotency keys in one durable record, then let a worker replay the exact pair of calls until both outcomes are known. That worker also emits a metric for “profile updated, sessions still active,” because a green response from the first call is not evidence that the shutdown is complete; support staff need a bounded, observable handoff between those two states. Here is a compact Go handler. The surrounding application owns authorization, audit storage, and the policy that decides whether a profile is banned. The API calls are deliberately limited to the two operations relevant to shutdown. The example assumes a trusted backend has already authenticated the abuse reviewer. It does not put a key in source, and it surfaces a non-2xx body so an operator can correlate the failure with the audit record. Your mileage may vary on retry windows; choose one that is shorter than the time your incident policy allows, and alert when the revoke call remains pending. Short credentials, long consequences Access tokens should be short-lived because they are presented frequently and are hard to recall once copied. Refresh capability deserves a different control: bind it to a session record, rotate it on use, and revoke that record when the user is banned. A token verifier should check both signature and the session's current status; signature validity alone is not proof that access is still allowed. Verification and refresh are independent lifecycle actions. A successful refresh should not resurrect a revoked session, and a fail