Your SaaS Has 10,000 Users. Who Removes Their Access When They Leave?

TL;DR

The customer's administrator or identity provider may initiate the process, but your SaaS application must enforce the removal of access to its own resources. Your identity platform can help coordinate the process, depending on how you've implemented authentication and provisioning.

• When an employee leaves: The customer's identity provider or administrator can disable the account or remove the user from the relevant application.
• When your SaaS receives the change: Your application must update the user's access, revoke applicable sessions, and prevent further unauthorized requests.
• When SSO is enabled: Blocking sign-in at the identity provider helps, but existing application sessions and issued tokens need to be handled too.
• When customers use SCIM: Automated provisioning and deprovisioning can communicate user and membership changes between an identity provider and your application.
• When your SaaS grows: Keycloak can provide a centralized identity layer for authentication across customer organizations. If you want to use Keycloak without operating the identity infrastructure yourself, Skycloak offers managed Keycloak hosting . Your application still needs to handle provisioning, authorization, and access revocation according to your architecture.

The key takeaway: removing a user's ability to sign in again doesn't automatically guarantee that every existing session or permission has been revoked. Your SaaS needs a defined offboarding process that covers the access your application actually controls.

What Happens When a SaaS User Leaves?

Let's follow a realistic example. A company uses your SaaS product to manage internal projects. One of its employees leaves, and the company's IT administrator disables that employee's account in the corporate identity provider.

That action changes what the employee can do, but the result depends on how your product integrates with the identity provider.

SaaS user deprovisioning is one of those responsibilities that's easy to overlook when you're building an authentication system. A user leaves a customer’s company, an administrator removes their account, and everyone assumes their access has been taken care of. But has it?

Imagine your SaaS product has 10,000 users across hundreds of customer organizations. One of those customers tells you that an employee has left the company. Their administrator removes the employee from the organization, expecting their access to disappear immediately.

What happens next depends on how your application handles account status, active sessions, access tokens, and connected services. If those pieces aren't coordinated, a user who should have lost access may still be able to reach parts of your product.

This becomes harder to manage as your customer base grows. Enterprise customers may use single sign-on (SSO), central identity providers, and automated user provisioning. Your SaaS application still needs a reliable way to respond when someone loses access, changes roles, or leaves the organization entirely.

Blocking the Next Login Is Only the First Step

If the employee tries to sign in again through the corporate identity provider, the disabled account should prevent a successful new login. That's an important first step, but your SaaS may already have an authenticated session for that user.

For example, the application may have issued its own session cookie after the original SSO login. Disabling the identity-provider account doesn't necessarily invalidate that application session automatically. The application needs a way to detect the account's changed status and reject access when appropriate.

The same concern applies to access tokens. A self-contained token, such as a JWT, can remain valid until it expires unless the resource server has a mechanism to check revocation or current authorization. The exact behavior depends on your token design and validation process.

Removing Access Across the Product

There's another layer to consider: what the user was allowed to do after signing in. A former employee might have had access to shared projects, customer records, API credentials, or administrative functions. If their membership or role remains active in your application, blocking their next login alone doesn't clean up those permissions.

A reliable offboarding flow needs to address the relevant parts of the account lifecycle:

• Authentication: Prevent the user from establishing new sessions when their account is disabled or access is withdrawn.
• Active sessions: Invalidate applicable sessions and account for tokens that may remain valid.
• Authorization: Remove organization membership, roles, and permissions that the user should no longer have.
• Connected systems: Revoke or update access to integrations, API keys, and other resources where your application manages those credentials or permissions.

Not every product needs the same implementation. A simple SaaS application may have a single user account and a few organization roles. An enterprise platform with multiple integrations may need a coordinated workflow across several systems. The important part is defining what offboarding means for your product and ensuring that each relevant layer enforces it.

Why Manual Offboarding Breaks as Your SaaS Grows

When you have a handful of customers, removing a user might be a simple database update. An administrator disables the account, your application blocks access, and the process is complete. At 10,000 users across hundreds of organizations, the same approach becomes harder to maintain.

The problem is that user changes can originate in different places. One customer manages accounts directly in your product, another relies on Microsoft Entra ID or Okta, and a third connects an external identity provider through SSO. Each setup creates a different path for communicating that a user's access has changed.

Manual processes also introduce delays. An IT administrator might disable an employee's corporate account but forget to remove their membership from your SaaS application. A customer might notify your support team, which then has to locate the correct account and make the change manually. Every additional step creates another opportunity for access to remain active longer than intended.

Three challenges tend to become more significant as your customer base grows:

• Inconsistent account management: Different customers use different identity providers, account policies, and offboarding procedures.
• Delayed access removal: Your application may not learn about an account change until someone manually updates it or the user attempts to sign in again.
• Unclear ownership: Your team may assume the customer's identity provider handles everything, while the customer assumes your application removes all access automatically.

A scalable approach needs a clear source of identity information, a reliable way to communicate account changes, and application logic that applies those changes correctly. That's where automated provisioning becomes useful.

How SCIM Helps Automate SaaS User Deprovisioning

System for Cross-domain Identity Management (SCIM) is a standard for exchanging identity information between systems. It allows an identity provider to create, update, and deactivate user accounts in a connected application through a defined API.

For enterprise SaaS products, SCIM can reduce the manual work involved in managing customer users throughout their lifecycle. When an employee joins an organization, the identity provider can provision an account in your product. When that employee changes roles or leaves, the provider can send an update that your application processes.

A typical workflow looks like this:

1. An administrator changes the user's status. The customer's IT team disables the employee or removes their assignment to your application in the identity provider.
2. The identity provider sends a provisioning request. Depending on the provider and configuration, it may deactivate the SCIM user resource, delete it, or update its attributes.
3. Your application processes the change. It identifies the correct user and organization, updates the account's status, and applies the appropriate access-removal rules.
4. The application handles existing access. It invalidates applicable sessions, updates memberships and permissions, and addresses tokens or credentials according to its security design.
5. The operation is recorded. Logs and provisioning status help administrators investigate failures and confirm whether the change was applied.

SCIM standardizes communication between systems, but it doesn't automatically secure every layer of your application. Your implementation must correctly interpret incoming changes, handle errors, and enforce the resulting access decisions.

What Happens When a SCIM Request Fails?

Consider an identity provider that sends a deactivation request while your application is temporarily unavailable. If your endpoint returns an error and the provider retries the request, the change may eventually succeed. If your system drops the event without recording it, the user could remain active.

For that reason, a production-ready implementation should handle retries, duplicate requests, and partial failures. Processing the same deactivation request more than once should not cause problems, and your system should make failures visible to the appropriate administrators.

You should also distinguish between disabling a user account and deleting its record. Deactivation can preserve the user's historical activity, audit records, and references in shared resources. Permanent deletion may be appropriate in some situations, but it can introduce complications when other records depend on that user.

The right behavior depends on your product's data model, retention requirements, and customer agreements. Define these rules before connecting SCIM to your production environment.

The key benefit is consistency. SCIM gives your SaaS a standard way to receive identity lifecycle changes, while your application remains responsible for enforcing those changes.

Where Keycloak Fits Into SaaS User Deprovisioning

If your SaaS supports enterprise SSO, a centralized identity platform can simplify authentication across customer organizations. Keycloak is one option for managing authentication, identity brokering, and access-related configuration through a common identity layer.

For example, your application can use OpenID Connect (OIDC) or SAML to authenticate users through Keycloak. Depending on your configuration, Keycloak can connect to an external identity provider and manage the authentication flow between that provider and your application.

This provides a useful foundation, but authentication and deprovisioning are related responsibilities, not the same operation .

Centralized Authentication Doesn't Remove Every Application Permission

Imagine a customer uses its corporate identity provider to authenticate employees through Keycloak. When an employee leaves, the corporate account is disabled. Your SaaS still needs to determine how that change reaches Keycloak and the application, and what happens to existing access.

Depending on the integration, you may need to account for:

• Identity synchronization: How changes from the customer's identity provider reach Keycloak or your application.
• Session management: How applicable Keycloak sessions and application sessions are invalidated when access is withdrawn.
• Application authorization: How your product removes organization memberships, roles, and permissions that are no longer appropriate.
• Provisioning integrations: How users and their lifecycle changes are synchronized through SCIM or another supported mechanism.

The exact setup depends on your architecture. Keycloak's authentication protocols don't, by themselves, guarantee that every customer identity change will trigger complete deprovisioning in every connected system.

Keycloak 26.6 and later includes a native SCIM 2.0 API for user and group provisioning. Skycloak makes SCIM provisioning available on all plans, allowing teams to synchronize user lifecycle changes through a standard interface.

How Keycloak Handles User Logout and Token Expiration

When an administrator disables a user in Keycloak, the user cannot establish new authenticated sessions, and refresh-token requests for that disabled user fail. However, an access token that has already been issued can remain valid until it expires. Keycloak's default access-token lifespan is five minutes, although this value can be changed in the realm settings.

To terminate the user's Keycloak sessions immediately, an administrator can open Users → select the user → Sessions → Sign out . The same operation is available through the Admin REST API:

POST /admin/realms/{realm}/users/{id}/logout

To close the user's application session as well, configure the client's Backchannel Logout URL and implement the corresponding logout endpoint in your application. Keycloak can then send a logout request to the application when the user's session is terminated. Your application must process that request and invalidate its own session.

This distinction matters for SaaS user deprovisioning: terminating a Keycloak session and revoking access to every application resource are separate steps. Your application must also enforce its authorization rules and account for access tokens that remain valid until expiration.

Managing Your Keycloak Infrastructure with Skycloak

Building a reliable SaaS user deprovisioning workflow requires an identity platform that supports your authentication and provisioning needs as your customer base grows. Self-hosting Keycloak gives your team control over the deployment, but your team is also responsible for the infrastructure, updates, monitoring, and ongoing maintenance.

Skycloak provides managed Keycloak hosting , handling the identity infrastructure while your team focuses on its application. Every plan includes unlimited users and full Keycloak admin acce