SSO and access control

MobSession connects your identity provider to sessions, so teammates sign in with their corporate accounts, carry a verified identity, and hold a role that decides what they can do. It brings the access model from the rest of your stack to the sessions your team runs.

Preview. This is in early access and rolling out to teams.

How access works today

Today a session is reached by an unguessable link. Anyone with the link can open it, and identity is a self-entered display name each person types when they join. The link is the only gate, and names are taken on trust.

That model is fast and stays available. SSO-backed verified identity and role-based access are the early-access layer on top: instead of a shared link and a typed name, you tie session access to the accounts your team already uses.

Single sign-on

SSO lets members reach sessions through your identity provider instead of a raw link. MobSession supports both SAML and OIDC, so it works with the providers most teams already run:

• Okta
• Microsoft Entra ID
• Google Workspace

Connect a provider once from your organization's SSO settings, map the standard identity claims, and your team signs in with the credentials they use everywhere else. Sign-in, password policy, and multi-factor enforcement stay with your provider, so MobSession inherits the controls you have already set.

Domain capture

Domain capture lets you claim one or more email domains for your organization. When someone with a captured domain signs in, they are routed into your team automatically and authenticated through your provider instead of joining as an anonymous guest. This keeps stray personal accounts out and makes provider sign-in the default for everyone on your domain.

Verified identity vs display names

With SSO connected, a member's identity comes from your provider, not a text field. The name, email, and account shown next to a participant are the verified values your provider asserts.

This matters because everything else builds on it: roles attach to a real account, audit trails point at a known person, and you can trust who is in the room. Self-entered display names stay the experience for guests and the link-based flow, so casual and external participation still works without an account.

Roles and access control

Role-based access control gives each member one of four roles. Manage them from your organization's access settings.

• Owner - full control of the organization, including billing, SSO configuration, and role assignment.
• Admin - manage members, sessions, and security settings, without owner-level billing control.
• Member - create and run sessions and participate fully.
• Viewer - observe sessions in read-only mode without taking control.

Roles travel with verified identity, so a person carries the same permissions across every session instead of being granted access link by link. That is how SSO gates who can join: a session can require provider sign-in, and only accounts in your team holding a role that allows it get admitted.

Limit a session to your organization

Every session starts open: anyone with the link can watch and take part, which is what makes a quick mob easy to share. When a session is owned by an organization, the host can tighten that to org members only at any time, from the host controls in the browser.

• Anyone with link (the default) keeps the shared-link behavior unchanged.
• Org only limits viewing to signed-in members of the session's organization. The transcript, prompts, side-chat, presence, and pasted images are all withheld from anyone outside the org: a non-member who opens the link sees only a sign-in wall, never the room.

Switching a live session to Org only removes anyone currently watching who is not a member, so the host is asked to confirm. Switching back to Anyone with link reopens it immediately. Every change is recorded in the session's audit trail, so you can see who changed the policy and when.

This is the per-session control that does not need full SSO: as long as the session was started by an account that belongs to an organization, the owner can gate it. SSO and SCIM (below) extend the same idea to who is in the organization in the first place.

Provisioning with SCIM

SCIM provisioning keeps your roster in sync with your identity provider. Add someone in Okta or Entra ID and they appear in MobSession with the right role. Deprovision them and their access is removed automatically. This closes the gap where a departing employee keeps a working link, because access is bound to an account your provider controls.

SCIM also supports group-to-role mapping, so the groups you already maintain drive MobSession roles instead of being set by hand.

Getting set up

1. Open your organization's SSO settings and connect your SAML or OIDC provider.
2. Capture your email domains so provider sign-in becomes the default for your team.
3. Enable SCIM provisioning to sync members and groups.
4. Assign roles from your organization's access settings.

Because this is in early access, configuration and provider coverage keep expanding. To turn SSO and access control on for your team, reach out and we'll enable it.

Related

• Accounts, organizations, and teams
• Security model