Revoke sessions after account deletion or credential recovery

Deleting an account or changing its password does not automatically invalidate every previously issued session. A browser may hold a signed token that remains cryptographically valid until expiry. A worker or API key may use a different credential. The account's identity lifecycle must be checked beyond the login request.

Consider an illustrative application with browser sessions and password recovery. After account deletion, the user must lose protected access. After recovery, the product policy may require existing sessions to end. Those policies need explicit implementation and test evidence. This article does not prescribe one universal token system; it explains how to connect lifecycle events with the authority that requests actually use.

Inventory every access credential

List browser sessions, refresh tokens, API keys, remembered devices, mobile tokens, and any long-lived provider connections. Identify what each credential proves, where it is validated, and how long it remains usable. A session table may cover browsers while leaving API keys untouched.

Write the intended effect of account deletion, suspension, password recovery, and role change for each credential type. Distinguish sign-out of one device from revocation of all devices. A practical artifact is a lifecycle matrix with event, affected credentials, invalidation mechanism, and maximum propagation delay. Without that matrix, a route may correctly delete the account while a different authentication path continues treating an old token as sufficient authority.

Distinguish token validity from current authority

A signed token can prove that an issuer created certain claims. It does not by itself prove that the account still exists, remains active, or holds the same permissions. Sensitive requests need a policy for checking current identity and privilege. This may involve server-side session lookup, account state, a session version, short-lived access tokens with revocable refresh credentials, or another deliberate design.

Choose the mechanism based on the acceptable revocation delay and operational requirements. Stateless access verification can reduce lookup work while accepting a period of continued validity. Immediate revocation usually requires some current state or centralized enforcement. State the tradeoff honestly. Do not describe a token as revoked if the application has no mechanism to reject it before its ordinary expiry.

Make lifecycle transitions atomic enough

For account deletion or credential recovery, coordinate the account state change and relevant session invalidation within a reliable boundary where possible. A separate revocation write that fails after password change can leave the product in an unexpected state. Define retry and recovery if the updates cannot share a transaction.

Keep recovery tokens single-use and expiry-aware. Their consumption and credential change must protect the intended invariant under concurrency. Avoid invalidating only the session that performs the change while leaving other sessions active when policy requires all-device revocation. Include refresh tokens and API keys according to the lifecycle matrix. The server response should reflect what actually completed rather than promising all access ended after only one partial update.

Apply the check on protected paths

Trace how authenticated identity becomes authorization at API routes, artifact downloads, and job-status endpoints. A deleted account should not retain access through a signed file URL indefinitely unless that behavior is an explicitly accepted limitation. Role-sensitive operations should use the intended current or bounded cached policy.

Review background work separately. A job accepted while the user was active may either continue under system authority or recheck current permission, depending on the product contract. Define that decision rather than assuming account deletion cancels every task automatically. Link tenant isolation when organization removal also changes access to records and derived artifacts.

Test with multiple sessions

Create a synthetic account and at least two independent sessions. Perform deletion or recovery through one session, then attempt protected reads and writes through the other. Assert both response behavior and unchanged durable state after denial. Test refresh behavior and any separate API credential according to the matrix.

Use a controlled clock where expiry is part of the policy. Confirm that a token rejected due to account state cannot regain access through a refresh path that fails to check the same state. Include a role downgrade case if privilege caching exists. A happy-path password change test does not establish revocation. The meaningful evidence is that previously valid credentials stop granting authority within the documented policy window.

Handle distributed caches and availability

If session or account state is cached, define invalidation and expiry. Revocation can be delayed by a cache even when the database is correct. Test that behavior in the relevant environment. Decide what happens when the authority store is unavailable: sensitive paths may need to fail closed, while public reads can remain available.

Avoid deleting all context needed to enforce or audit revocation before the system can reject old credentials. A tombstone or inactive state may be useful where immediate hard deletion complicates identity checks. Retention and privacy requirements must be handled deliberately. The design should explain which minimal state remains, why it is needed, and when it is removed, rather than preserving complete account records out of convenience.

Make user communication precise

Tell users which sessions or credentials are affected and what happens next. A confirmation saying signed out everywhere should match the actual mechanism and propagation policy. If the system permits a short access-token validity window, decide whether that behavior is acceptable and how it is communicated where relevant.

Do not expose detailed session identifiers or internal security state in public responses. Provide safe recovery guidance and clear failure states. Operational monitoring should detect revocation failures without logging credentials. For release verification, include the multi-session case in the evidence checklist when identity lifecycle changes. Session revocation is a cross-path behavior, so it needs evidence beyond the endpoint that initiated it.

Use AI to audit lifecycle gaps

Give an assistant the authentication middleware, session storage, refresh path, deletion handler, and recovery handler with secrets removed. Ask it to trace each credential type through the lifecycle matrix. Require file evidence and mark uninspected paths as unknown. Do not provide live tokens to make the explanation more concrete.

Have it propose negative tests for surviving sessions, stale role claims, and refresh after deletion. Verify suggested library capabilities against installed versions. AI can find forgotten credential paths and inconsistent checks, but the final revocation claim needs executed evidence across those paths. The useful result is a clear authority policy with an explicit delay and recovery mechanism, not a broad assertion that changing a password makes every old token disappear.

Sources

OWASP session management guidance is the primary session lifecycle reference.

OWASP authorization guidance supports checking current authority on protected operations. The lifecycle matrix and multi-session cases are illustrative.