SSO Offboarding: A Vendor Checklist Beyond the Login

An SSO offboarding checklist tests what happens after you remove someone’s access at the identity provider. Check new sign-ins, existing sessions, API tokens, connected assistants, and manually invited members. Record when workspace access actually stops, which exceptions remain, and who can remove access if directory synchronization fails.

Your vendor demo probably includes a successful login. Ask for a departure demo too. For an applicant tracking system holding candidate records, interview notes, and private team discussions, both outcomes belong in your buying decision.

Why test offboarding during an SSO evaluation?

A successful single sign-on demo proves an entry path works. It does not show what happens to access that already exists when a person leaves.

The current SAML debate gives you a reason to ask now. In his September 21 article, SAML: A fractal of bad design, Trail of Bits researcher Matt Schwager critiques SAML’s complexity and recommends moving toward OpenID Connect. The Hacker News discussion brings that protocol choice back into view for software teams.

That is a reason to examine your vendor’s identity design. It is not evidence that every SAML deployment is compromised, or that choosing OpenID Connect settles employee offboarding. The buying question extends beyond the protocol used at the login screen.

Imagine a recruiter leaving your company. Their account is disabled in your directory. They also have an ATS tab open, a token used by a reporting script, and an assistant connected to the recruiting workspace. A fresh login may fail while those other paths need separate handling.

Treat that scenario as a test to run, not a claim about a particular product. Ask the vendor to demonstrate what its actual configuration does. Include the people who own recruiting access and the person who will receive a failed-sync alert, rather than leaving the review entirely with the person who installed SSO.

Leave the review with a short acceptance record: the access you tested, the result you expected, the result you observed, and any exception you accepted. It gives procurement and your future offboarding operator something more precise than “SSO supported.”

Separate login, provisioning, and application access

Authentication, membership management, and revocation answer different questions. Ask how the vendor connects them in the configuration you intend to buy.

OpenID Connect Core specifies authentication on top of OAuth 2.0 and claims about the user. Those capabilities do not themselves specify your company’s complete departure workflow.

Microsoft’s access-revocation guidance makes the application boundary explicit. An application can issue its own session token and control its own authorization. Disabling the identity in Microsoft Entra does not give Entra direct control over that application-issued session. Existing access depends on the application’s behavior and configuration.

Provisioning needs the same scrutiny. SCIM, a standard for exchanging identity-management information, includes an active attribute. Its core schema leaves that attribute’s definitive meaning to the service provider. Seeing active=false in a successful request does not independently prove that every application credential has stopped working.

Logout also has a scope. The separate OpenID Connect Back-Channel Logout specification describes notifying applications to clear matching sessions. Support is optional, and the specification normally treats refresh tokens with offline access differently from session-linked refresh tokens. Do not translate “supports logout” into “revokes every credential.”

You do not need to become a protocol implementer to evaluate this. Ask the vendor to explain each row in plain language, then demonstrate the important paths. A useful answer names the trigger, affected identity types, expected delay, and exceptions.

Agree the removal trigger and time limit

An offboarding test needs a defined starting event and a clear access boundary. Otherwise, buyer and vendor can observe the same demonstration and disagree about what passed.

Write down the configuration first: product plan, identity provider, SSO enforcement, provisioning connection, and how the test member joined. A manually invited guest may follow a different removal path from a directory-provisioned employee. Use the arrangement you will actually operate.

Next, choose the trigger. Disabling a directory user, removing an application assignment, removing a group membership, and deleting a local workspace membership are different actions. Test the action your departure procedure will use. Add separate tests where your business relies on other triggers.

Agree an acceptable maximum delay for each important surface. This is your acceptance criterion, not a universal industry SLA. Ask the vendor what it commits to, what it merely schedules, and what an operator should do if the normal path fails.

For example, you might require an emergency operator to remove access directly in the application rather than wait for a scheduled sync. Write that requirement as a procedure with an owner and the necessary permissions. Do not assume the procedure exists because an administrator can usually edit users.

Record three moments separately: when the directory action happened, when the application received or processed it, and when a protected request was denied. A connector’s success message is useful evidence of delivery. It is not the same evidence as a failed attempt to read a protected record.

Finally, decide what “removed” means. Losing access to your company workspace need not mean losing an unrelated personal workspace or being logged out of the vendor everywhere. Conversely, a redirected browser is not sufficient if the same person’s token still reads your candidate records.

Run this SSO offboarding acceptance test

Use a disposable identity and synthetic records in a vendor-approved test workspace. Establish working access before removal, then repeat the same harmless operations afterward.

Keep another administrator available to recover the configuration. Do not turn a live employee’s account or real candidate information into a demonstration. The worksheet below is our suggested test design, not a certification or a test report generated by Kit.

Establish the baseline

Create a synthetic candidate or another harmless protected record. Confirm the test member can read it through each supported access path you intend to evaluate. If an operation never worked before removal, its later failure tells you nothing about revocation.

Use a separate browser for the member and the administrator. Record the member’s role, membership origin, and any relevant group assignments. Inventory the credentials you created without copying their secrets into the worksheet.

Then perform the agreed removal action and record its time. Keep the existing browser session open. A fresh browser alone would miss the behavior you need to inspect.

Repeat the relevant access paths

For OAuth clients, ask the vendor to distinguish the credential used for resource access from any refresh token used to obtain another one. RFC 7009 defines token revocation separately and discusses effects on related tokens. Your acceptance record should say which credentials were exercised, not merely that “OAuth was tested.”

Do not mistake an old page for continuing access. Text already rendered in a tab may remain visible after permission has ended. Request fresh protected content and inspect whether the server returns it. Equally, do not accept a cosmetic “signed out” message if protected requests still succeed.

Keep evidence that another operator can interpret

For each surface, record the last observed allowed response and the first observed denied response. Your checks bracket what you observed; they do not establish the exact moment access changed between checks. One successful run also does not prove the vendor’s worst-case delay.

A compact record can use these fields:

Keep tokens and private response bodies out of the record. An authorized reviewer needs enough evidence to reproduce the reasoning, not a new collection of credentials or candidate data.

If a row fails, name the operation that still works. “Existing browser can read newly created candidate notes after the accepted limit” is more useful than “SSO is broken.” It directs the vendor toward the access boundary you actually need fixed.

Record exceptions before you accept the vendor

Exceptions and failure handling belong in the acceptance decision. A successful directory-managed employee test does not cover every person, credential, or outage.

Start with membership origin. Okta’s deactivation documentation describes application deprovisioning prerequisites and exceptions. That reinforces a practical buying question: which applications and identities does your configured connection actually manage?

List manually invited members, external collaborators, service accounts, and emergency administrators where they exist. Give each a removal path and an owner. Do not treat an intentional emergency account as an invisible exception; document who controls it and how its use is reviewed.

Test failure and recovery deliberately

Ask how an operator learns that directory synchronization stopped or rejected a change. A timestamp from yesterday may be more useful than a green “connected” label. Request the vendor’s supported way to simulate a failure, or review documented failure evidence if a safe simulation is unavailable.

Run the manual fallback and repeat the relevant access checks. A fallback is only useful if the designated operator can execute it while the normal integration is unavailable. Confirm which administrator permissions it requires and where the instructions live.

Also test a role reduction and a rejoin as separate scenarios. After a role reduction, check the protected operation the person should have lost. After a rejoin, compare permissions with the newly approved role. Neither automatic restoration of old grants nor permanent loss of all access should be assumed.

State what the decision covers

Ask for the vendor’s explanation in writing alongside the configuration and observed results. Distinguish a product capability from a contractual commitment and a measured test outcome. If an unresolved exception affects sensitive candidate data, decide whether to change the configuration, add a workable control, or defer acceptance.

Revocation cannot pull back information someone has already copied simply by denying the next request. Treat downloaded files, exports, and retained copies as a separate data-handling problem. Keep this evaluation focused on stopping further access to the workspace.

The evidence discipline resembles closing a leaked-credential report: identify the affected access path and verify its outcome. Here, the purpose is planned departure and vendor acceptance, rather than incident response.

Apply the same checklist to Kit

Evaluate the product you will actually configure, including its limits. Use the same departure test on Kit that you would ask another vendor to run.

Kit supports SAML single sign-on and a separate Google Workspace directory-sync connection. The directory integration polls Google; it is not a generic SCIM endpoint. Its reconciliation job is scheduled hourly, and the directory page offers Sync now. A schedule is not a guaranteed access-removal deadline: upstream errors, job delays, and safeguards can prevent a successful pass.

The connection manages memberships it provisioned. It does not remove the account owner or manually invited members. Disconnecting synchronization stops future syncs without removing existing members. These boundaries belong in your worksheet before testing. See SSO and directory provisioning for setup and supported behavior.

There is also a deliberate mass-removal safeguard. A sync that would remove every directory-managed member is stopped, including when the managed set contains only one person. Removal of more than half the managed set is also stopped when that set contains at least four members. Legitimate departures caught by these guards need operator review and the manual removal route.

When directory removal successfully deletes a membership, Kit’s implementation removes that user’s API tokens for the account, revokes account-scoped OAuth/MCP credentials, and disconnects that user’s live connections to the account. The scope is the removed workspace. This does not delete the person’s global user identity or promise logout from every other workspace.

For manual departures, team access control documents Remove from account and access review. For protected sole-owned work, choose a successor or explicitly leave the item unassigned before removal. The owner remains protected from removal; required SSO also retains an owner emergency-access exception. Review that exception alongside your sign-in security settings.

Those are documented and source-reviewed behaviors, not a claim that this article performed a live acceptance test of your deployment. Your review should still exercise the applicable rows, including manual members and failed synchronization.

A useful SSO decision ends with a demonstrated removal path, recorded timing, and an operator who can handle exceptions. Take this worksheet into a Kit trial or your next vendor review, and test the departure as carefully as the login.