When someone loses access to a SaaS account, change the application's authoritative membership or permission state first, then make every protected request check that current state. For account removal, cut that account's authority from sessions, token renewal, jobs and downloads. Revoke entire sessions and refresh credentials when policy or suspected compromise calls for that broader action. Those steps address different paths: deleting a browser cookie does not invalidate a copied bearer token, and disabling a user at the identity provider does not necessarily end a separate application session. NIST SP 800-63B-4 describes IdP and relying-party sessions as independently managed; OWASP's session guidance calls for server-side invalidation.
The design changes with the authority model. A server-side session can be looked up and denied immediately. A self-contained access token may remain cryptographically valid until expiry unless the resource server checks a live revocation or authorization record. A signed download URL may bypass the application entirely. Decide what “removed” must mean for each delivery path, then measure the interval until that path refuses access. No system can withdraw content already delivered to a person.
Illustrative case: a departing incident responder
Illustrative company, account, timings and identifiers. At Alder Cloud, Mira belongs to the Northstar customer account. She can read incident reports and has a running export job. An administrator removes her membership at 14:00. The browser holds an application session, an access token with 20 minutes remaining, a refresh token, and a report link that a background worker generated earlier. The SSO provider still has an active login session.
The administrator wants a clear outcome: requests after the removal decision must not release more Northstar data to Mira. A UI redirect at 14:00 is useful feedback, but it is not the authorization boundary. The API, export worker, report download, and any alternate client must each enforce the removal. NIST's federation discussion explains why ending an IdP session and ending an application session are separate operations.
| Path | What can remain after the UI logs out? | Necessary control |
|---|---|---|
| Browser/API session | A copied session identifier or unexpired server record | Server-side invalidation plus current membership check |
| Access/refresh tokens | A valid signature and a refresh credential | Live authorization at the resource server; revoke refresh and stop new issuance |
| Export job | Work already admitted to a queue | Check authority before processing and again before releasing output; cancel or fence the work |
| Report link | A reusable bearer URL | Route downloads through current authorization; a bounded URL lifetime alone leaves a revocation window |
| SSO login | An IdP session outside the application | Deny application re-entry from the removed membership even if SSO succeeds |
Choose the revocation boundary deliberately
Three common designs provide different guarantees. A server-side session record permits direct invalidation, but every protected endpoint must consult the current record. A signed access token with a short lifetime limits that token's remaining reuse window, provided the attacker cannot renew it or mint a replacement, but short expiry alone does not meet an immediate removal requirement. A signed token plus a live membership version, session deny record, or equivalent authorization check can reject a once-valid token before its expiry. The check must happen at the actual resource server or at a gateway that all paths cannot bypass.
Revoking an OAuth refresh token prevents future access tokens from being minted; it may not kill access tokens already issued. RFC 7009 specifies refresh-token revocation support and discusses access-token revocation behavior. RFC 9700 covers refresh-token rotation and protection. Inspect your issuer's actual revocation behavior and test the resource server, rather than treating a successful revocation API response as proof that every bearer credential is unusable.
If the application supports multiple organizations, bind authority to person plus selected organization plus current membership and resource. Removing Mira from Northstar should not erase a different legitimate membership, and her remaining membership elsewhere must not authorize a Northstar report. A tenant identifier in a token or URL selects a record to check; it is not a fresh grant.
Draw the human credential graph before deleting anything
Mira also belongs to Birch, where she remains an authorized analyst. Northstar removal should cut Northstar authority without pretending every credential is one object. The following graph is an illustrative inventory, not a product implementation:
IdP login session I-1
└─ can initiate fresh application authentication
application browser session S-1
├─ Northstar membership M-41
└─ Birch membership M-72
refresh family F-3
└─ can issue access tokens A-8, A-9...
access token A-8
└─ resource server checks current selected-account membership
Deleting the browser cookie affects the browser's copy of S-1. It does not revoke F-3 or A-8. Revoking F-3 stops renewal under the issuer's actual semantics; it may leave A-8 cryptographically valid. Ending I-1 addresses IdP reauthentication, but Northstar's membership decision must still deny re-entry even if I-1 survives. NIST describes independent IdP/RP session lifecycles, and RFC7009 distinguishes token revocation behavior.
Choose the scope of the revocation event
For Northstar-only removal, set M-41 inactive and ensure every Northstar resource request and renewal decision uses that state. If S-1 and F-3 are global to the application, either invalidate them and let Mira reauthenticate for Birch, or retain them with Northstar authority removed. The latter requires all consumers to enforce current account membership; a token whose embedded roles alone authorize Northstar cannot meet that requirement.
For suspected identity compromise, the response may deliberately revoke all of Mira's application sessions and refresh families, not just M-41. That is a different authorized action with a wider availability impact. Record which event the administrator actually requested. A button labeled “remove from account” should not silently erase unrelated legitimate memberships, and a button labeled “sign out everywhere” should not merely clear one local cookie.
The account-specific expected outcomes are:
| Attempt after M-41 removal | Expected result |
|---|---|
| S-1 requests Northstar report | Denied by current membership |
| A-8 requests same report | Denied even if signature/expiry are valid |
| F-3 requests a Northstar-scoped token | Denied or issued without Northstar authority under the documented design |
| I-1 completes fresh SSO for Northstar | Identity may validate; account entry denied |
| S-1 requests permitted Birch report | May remain allowed if the session itself was retained and Birch policy holds |
These are planned synthetic outcomes. A real review records the durable removal time and actual refusal evidence separately for each credential path, without storing token values.
Handle an authority-store outage without reopening the account
Suppose the API cannot read M-41 immediately after removal. Falling back to A-8's old member=true claim defeats the promised cutoff. The resource server should withhold affected protected operations when it cannot meet its freshness requirement. If the design instead permits a bounded cached-grant window, state that window and assess it against the removal policy; do not call it immediate revocation.
Recovery also matters. When the authority store returns, an old queued refresh request must not recreate M-41 or mint stale account rights from a cached session. Persisted removal and current policy must win over earlier authentication success. Track the session, token family and membership as related records with separate statuses, not as one boolean named logged_out.
Jobs, artifacts and bearer download links extend beyond the human credential graph. The stale-permission guide works through publication and delivery ordering. This article's closure is narrower: identify every human credential that can mint or exercise account authority, and demonstrate that none can regain the removed membership through refresh or fresh SSO.
What if a path cannot check live authority?
If a provider-hosted URL, third-party integration or legacy API accepts a bearer secret without a current check, document its maximum lifetime and scope. Shorten the lifetime, disable issuance, revoke at the provider if supported, and schedule a migration to a delivery path that can check membership. If no reliable revocation endpoint exists, state the remaining exposure window and avoid promising immediate cut-off. A long-lived URL carrying a full report is a materially different risk from a short-lived link that still requires an authorized application request.
If revocation propagation fails or the authoritative store is unavailable, decide in advance whether the resource path fails closed. A stale local cache silently treating removal as optional is not a safe fallback. If the system cannot show when the change committed or whether a worker saw it, keep the outcome uncertain, investigate the audit trail, and avoid marking offboarding complete. OWASP's session management guidance makes server-side invalidation and timeout enforcement part of the session design; a cosmetic client logout is insufficient.
Make the offboarding result a set of observations
Alder's operator needs a completion record that matches the requested removal. Record when M-41 became inactive, which credential paths were checked, and which remained outside the review. A row marked “revocation request accepted” is different from “new Northstar report request denied.” Both may be useful, but only the latter directly addresses the resource-delivery boundary for that observation.
Use nonsecret identifiers for sessions and token families. The reviewer should be able to connect A-8 to the relevant issuance family without copying its bearer value into a ticket. For each path, capture the assessed build or configuration and the expected account-specific result. A request using an already expired token does not establish whether the live membership check would deny a still-valid one.
The permitted Birch case matters too. If the chosen action was Northstar-only removal with the global session retained, Birch should still follow its own membership policy. A universal error caused by a broken session service proves neither successful Northstar isolation nor intended Birch continuity. The paired observations help distinguish a deliberate policy decision from an outage.
Prevent delayed administration from restoring old authority
An offboarding event may race with a queued invitation, a role synchronization, or a support action. Identify the provisioning paths that can create or reactivate membership and make them consult the removal policy. A successful fresh authentication should establish identity only; it must not erase M-41's inactive state because an older job still carries an approved-looking account claim.
For the synthetic example, a delayed group-sync message should be evaluated against the current authoritative policy before creating Northstar rights. If the organization deliberately allows a particular synchronization source to restore membership, that authority must be explicit and visible to the operator. Otherwise “removed from account” becomes an ambiguous temporary state.
The same review should define a legitimate restoration path. An authorized administrator may later regrant Northstar membership, but the new decision should be distinguishable from replaying an old session or invitation. Record the scope of the new grant and what happens to previously cancelled jobs. Restoring account access need not automatically resume every historical export.
This closes the lifecycle around the human credential graph. The application can recognize the same person, retain another account's legitimate access, and still enforce a durable removal from Northstar. The review's conclusion should name those separate outcomes instead of reducing them to one logged_out flag.
For the next offboarding review, take one removed account and fill the path table above with real endpoints, owners and observed refusal times. Then read how to review authentication and session security for SaaS and how to audit service credentials separately from human accounts. The latter matters because a machine credential created by a former employee may have its own authority and expiry.