An employee is let go at 10:00. IT disables their account in the identity provider at 10:05. At 10:20 they are still in the all-hands video call, and their app still works.
Nothing failed here. Single sign-on did its job: it checks identity when someone signs in, and they had signed in that morning. Removing them is a different job, done by different machinery, on a different clock. That is why enterprise video SSO and SCIM come up together in every security review, and why the second one is where the hard questions are.
The admin and provisioning APIs check names this area as one of six things an enterprise buyer tests. This post opens it up: the questions IT will actually ask, and what a good answer looks like.
Question 1: SAML or OIDC?
IT will ask which single sign-on protocol you support. The two in use are SAML 2.0, the XML-based standard most enterprise identity providers have supported for years, and OpenID Connect, built on OAuth 2.0 and common in newer setups and mobile apps.
SAML 2.0 | OpenID Connect | |
|---|---|---|
Format | Signed XML assertions | Signed JSON tokens (JWT) |
Typical fit | Established enterprise IdPs, browser sign-in | Modern IdPs, mobile and single-page apps |
Logout signal | Single Logout | Back-Channel Logout (final spec, 2023) |
The practical answer is both, or at least the one this customer's identity provider prefers. Two follow-ups matter more than the protocol: can SSO be enforced, so no one keeps a password login that bypasses it, and does the same identity work in your mobile apps, not only in the browser?
Question 2: How Do People Get Out?
This is the question that fails reviews. SSO checks identity at sign-in and says nothing afterwards. Just-in-time provisioning, where an account is created on first SSO login, has the same blind spot: it learns when someone arrives, never when they leave.
Leaving is what SCIM is for. It is a REST protocol where the identity provider pushes changes to your app: create user, update user, change group membership, deactivate user. The SCIM core schema in RFC 7643 gives every user an active attribute; false generally means the account is suspended, though each service decides exactly what that does.
Microsoft's guide to building a SCIM endpoint for Entra ID shows what that looks like in practice: disabling a user arrives as a PATCH that sets active to false, and a hard delete arrives as DELETE. The same guide sets out what Entra expects from your endpoint, including filtering users by userName and supporting PATCH, and notes that provisioning cycles run approximately every 40 minutes.
Large video vendors follow the same pattern. Zoom's SCIM guide describes deactivation in Entra or Okta flowing through to the Zoom account automatically.
So the good answer to question 2 is: we support SCIM 2.0, deactivation suspends the account and everything attached to it, and here is what "everything" means.
The Deprovisioning Window
"Everything" is where video differs from most SaaS. A suspended account blocks the next login. It does not, by itself, remove someone from a call they are already in, because live media runs on a token issued earlier.
That gives three clocks between "disabled in the IdP" and "out of the call":
Step | What decides how long it takes |
|---|---|
IdP to your app | The provisioning cycle: approximately 40 minutes on Entra ID |
Your app stops issuing tokens | Immediate, if your token service checks account status |
The live call ends for that user | Token expiry, unless you remove them from the room |
The last row is the one teams miss. On LiveKit, removing a participant does not invalidate their token, so the token's lifetime matters as well as the removal. On Twilio, tokens can last up to 24 hours, and Twilio recommends long tokens so reconnection keeps working. A team that only suspends the account, issues day-long tokens and never removes anyone from live rooms has a worst case of about 24 hours 40 minutes.
Closing the window takes three pieces of work, all in your backend:
- React to the SCIM deactivation. Suspend the account, revoke your own app sessions and stop issuing video tokens to that user.
- Remove them from live rooms. Use the platform's server API to disconnect the participant from every room they are in.
- Keep tokens short where you can. A token lifetime is also a revocation window, so pick one that limits how long a removed user can rejoin.
Do all three and the window is the provisioning cycle, about 40 minutes on Entra's schedule, or minutes if an admin triggers provisioning by hand. That is an answer IT can sign.
Question 3: How Do Groups Become Roles?
IT will want permissions driven by groups it already manages, not by a second admin console. SCIM carries group membership, and your app maps groups to roles: "Video-Hosts" can start webinars and record, "Support-Agents" can join customer rooms, everyone else can join meetings they are invited to.
Two details save trouble later. Map roles from groups at token-issuing time, so a group change takes effect on the next token rather than the next login. And don't let video permissions live only in the vendor's console. If roles are set there by hand, every org change becomes a ticket, and the identity system stops being the source of truth.
Question 4: What About People Outside the Directory?
Enterprise video has a population the identity provider doesn't know: customers in a support call, patients in a consultation, candidates in an interview, partners in a joint review. They can't sign in with SSO, and SCIM will never deprovision them.
A good answer separates the two populations clearly:
- Employees sign in with SSO and are governed by SCIM.
- Guests join through a single-room, short-lived link or token, with no publish rights beyond what the session needs, and nothing that outlives the meeting.
IT will also ask whether guests can be blocked entirely for some rooms, and whether a guest can ever be promoted to host. Both should be configurable, and the answer should be "only by an employee in that room".
Question 5: What Gets Logged?
The last questions are about evidence. Who joined which meeting, from where, with what rights? Who started a recording, and who watched it later? IT wants these in its own security tools, not on a vendor dashboard.
That means an export or streaming API for join, leave, role-change and recording events, keyed to the same identity SSO uses. Recordings need their own trail: an access log on every recording retrieval is part of a defensible pipeline. If your token service logs every token it issues, you already have half of this.
The Short Version of the Questionnaire
IT asks | A good answer |
|---|---|
Which SSO protocols? | SAML 2.0 and OIDC; SSO can be enforced; works on mobile |
How are accounts created and removed? | SCIM 2.0; deactivation suspends the account and stops token issuance |
What happens to someone already in a call? | Removed from live rooms via the server API; token lifetime caps rejoin |
How do permissions follow groups? | Group-to-role mapping applied when each token is issued |
What about guests? | Single-room, short-lived access; never promoted except by an employee |
What is logged? | Joins, roles, recordings and recording access, exportable to our SIEM |
The Bottom Line
SSO gets people into an enterprise video product; SCIM gets them out. Between the two sits the part specific to video: a live call runs on a token that outlives the account change unless you remove the user and keep tokens short. Answer that, plus groups, guests and logs, and the security review becomes a formality.
What's Next
Identity is one of the things that has to hold when the whole company joins at once. Next: what has to hold at org-wide peak.
Frequently Asked Questions
Do enterprise video platforms need both SSO and SCIM?
Yes, for different jobs. SSO checks identity at sign-in; SCIM creates, updates and deactivates accounts when the identity provider changes. Without SCIM, a departed employee's account stays active until someone removes it by hand.
Is just-in-time provisioning enough instead of SCIM?
It handles arrivals, not departures. JIT creates an account on first SSO login but gets no signal when someone leaves, so deactivation still needs SCIM or a manual process.
How long does SCIM deprovisioning take?
It depends on the identity provider. Microsoft documents Entra ID provisioning cycles running approximately every 40 minutes, so a disable can take up to that long to reach your app. Removing the user from live calls is a separate step your app has to take.
Does disabling a user end their current video call?
Not by itself. The call runs on a token issued before the change. Your app needs to remove the participant from live rooms through the platform's server API and stop issuing new tokens.
How should guests join an SSO-protected video platform?
Through single-room, short-lived access issued by your backend, with only the rights the session needs. Guests are outside the directory, so their access should expire with the meeting.
Where does identity live in a self-hosted video deployment?
In your own identity provider and backend, as with any platform. With an on-premise deployment, which Samvyo supports, the media servers that enforce tokens also sit inside your network. Ask any vendor, Samvyo included, how SCIM deactivation reaches users who are already in a call.
