Enterprise Identity: SSO and SCIM
By the Syncfusion DevTutorials team · Last updated
Customers bring their own identity provider. Follow a SAML and an OIDC login message by message, provision users with SCIM, and close the gap where a leaver keeps access.
Sign In With the Company Account
Litware's security team has two rules for every tool their 750 staff use. Staff sign in with their company account, with the company's MFA. And when someone leaves, IT disables one account and that person loses access to everything, within minutes.
The first rule is single sign-on (SSO). The second is provisioning, usually with SCIM. Without both, Northwind does not pass Litware's security review, and the deal does not close.
The main idea: the customer's identity provider (IdP) proves who the user is (SSO), and pushes every change to the user list to you (SCIM). Your app maps both to the right tenant, and ends sessions and tokens the moment a user is deactivated.
TL;DR
- An identity provider (Entra ID, Okta, Google Workspace, Keycloak…) holds the customer's users and passwords.
- SAML 2.0 and OpenID Connect (OIDC) are the two SSO protocols. Your app (the service provider or relying party) never sees the password.
- Tenant discovery: before redirecting, find which tenant (and so which IdP) the user belongs to, by email domain or a tenant-specific URL.
- SCIM is a standard REST API the IdP calls to create, update and deactivate users in your app.
- SSO alone is not enough: a deactivated user keeps any session and API token your app already gave them. De-provisioning must end both.
A Real-World Example
An employee leaves a company on Friday. IT disables her account. On Monday a security audit finds she downloaded a customer list on Saturday from a SaaS tool, using an API token she had created months earlier. SSO worked perfectly: she could not sign in again. Nobody told the SaaS tool that she had left, and her token never expired.
What You Will Learn
- How a SAML login and an OIDC login work, message by message.
- How to pick the right tenant and IdP for a login.
- What SCIM does, and the de-provisioning gap.
- How to end sessions and tokens on deactivation.
SSO happens at login. SCIM keeps the user list in step all the time. You need both.
Step Through a Login
In both protocols your app ends up with a signed statement from the customer's IdP: "this is priya@litware.com, in these groups". Your app checks the signature, the audience (it was meant for you), the time window, and that it has not been used before. Then it starts its own session.
Which Tenant Is This?
A multi-tenant app has many IdPs: one per customer. Before the redirect, it must pick the right one. Common ways: the email domain the user types, or a tenant URL such as litware.northwind.example.
Make customers verify a domain (for example with a DNS record) before you route its emails to their IdP. Otherwise a tenant could claim gmail.com and send every Gmail user to an IdP it controls.
SCIM: Keep the User List in Step
SSO only tells you about a user when they sign in. SCIM (System for Cross-domain Identity Management) lets the IdP push changes at any time, with plain REST calls:
| IdP event | SCIM call to your app |
|---|---|
| New hire assigned to Northwind | POST /scim/v2/Users |
| Name, email or group changed | PATCH /scim/v2/Users/{id} |
| Employee leaves | PATCH /scim/v2/Users/{id} with {"active": false} (or DELETE) |
The SCIM endpoint is per tenant and authenticated with a token the customer creates in your admin screen. It must only ever change users in that tenant.
Group membership usually drives roles. Map the IdP's groups to Northwind roles in the tenant's SSO settings, and re-apply the mapping on every login and every SCIM update:
The De-Provisioning Gap
An 8-hour session cookie and a long-lived API token both outlive the IdP account. If your app is not told, or is told but only flips an active flag, the leaver keeps working.
Try It: Close the Gap
Pass rule: no access more than 5 minutes after IT deactivates Priya, including through her open session and her API token.
Short sessions and re-checks shrink the gap but never close it for API tokens. The reliable fix is an event: SCIM tells you, and your app ends every session and revokes every token for that user at once.
Some customers cannot run SCIM. Offer just-in-time provisioning (create the user on first SSO login) plus an admin screen and an API to deactivate users, and keep sessions short for those tenants.
Check Yourself
Common mistakes
| Mistake | Wrong | Correct | Why it happens |
|---|---|---|---|
| Unverified domains | Any tenant can claim acme.com | DNS-verified domains | Discovery by domain is added without abuse cases |
| Soft deactivation | active = false, sessions still valid | End sessions and revoke tokens | The flag is checked only at login |
| Long-lived tokens | API tokens that never expire | Expiry, rotation and revocation | Scripts break when tokens expire, so nobody sets one |
| Partial assertion checks | Signature checked, audience not | Check every field | Libraries make some checks optional |
| Cross-tenant SCIM | One SCIM endpoint for all tenants | Per-tenant endpoint and token | Built quickly for the first customer |
Practice
What to Remember
- SSO: the customer's IdP proves who the user is; your app checks the signed result and starts its own session.
- Find the tenant (and its IdP) before the redirect, from a verified domain or tenant URL.
- SCIM pushes creates, updates and deactivations to your app.
- On deactivation, end every session and revoke every token.
Further Reading
- SCIM 2.0 Protocol (RFC 7644): the provisioning API.
- OpenID Connect Core 1.0: ID tokens and the authorization code flow.
- OASIS SAML 2.0 Technical Overview: assertions, bindings and profiles.
- Keycloak: Server Administration Guide: an open-source IdP, used in this section's identity case study.
Next: Audit Logs and Compliance. Every action must be traceable: who changed what, and when, in a log nobody can quietly edit.