SSO & identity
Two different things live under this heading, and they are worth keeping apart because one is Mesa's and one is not.
- Sign-in and enterprise SSO come from Clerk, the identity provider Mesa uses. Mesa implements none of it.
- Identity linking — recognising the same person across Telegram and email — is Mesa's own, and is implemented here.
Sign-in
Day to day, users sign in with an emailed code, an SMS code, or Google. There is no password. See Accounts & sign-in.
Enterprise SSO
Clerk supports SAML 2.0 (Okta, Azure AD, OneLogin, PingFederate) and OIDC (Google Workspace, custom providers), and a Mesa deployment inherits whatever its Clerk instance is configured for.
There is no SAML or OIDC implementation in Mesa — no code, no endpoints, no configuration surface. Enabling enterprise SSO is entirely a matter of your Clerk plan and your Clerk dashboard, performed by whoever administers that account.
Mesa's schema carries sso_enabled and scim_enabled flags on the record that maps a Clerk
organization to a tenant. Both are written as false and read by nothing. They do not gate,
enable or reflect anything. If you are auditing whether SSO is on, those columns are not the
answer; your Clerk configuration is.
The Mesa-side step, once SSO is working in Clerk, is mapping the Clerk organization to a tenant so that the people arriving through it land in the right workspace.
SCIM provisioning
The same applies. SCIM 2.0 — automatic account creation when someone is added to your identity provider, and deprovisioning when they are removed — is a Clerk capability, configured in Clerk. Mesa has no SCIM endpoints and does not implement the protocol.
Treat both SSO and SCIM as questions about your identity provider, not about Mesa. What Mesa guarantees is that whoever Clerk says you are is who you are, and that your tenant scope follows from that rather than from anything you send.
Identity linking across channels
This part is Mesa's own, and it solves a problem SSO does not touch: the same person appears as a Telegram account in one place and an email address in another, and nothing about those two identifiers says they are the same human.
Linking is confirmed, not inferred. A verification code proves control of the address or account being linked; a matching display name or a similar-looking address is never enough. Once linked, a person carries one identity across the channels they use.
Administrators can review and manage links in the admin console under Identity links.
Organization membership
Membership is administered rather than self-service: there is no invitation screen in the web app, and joining, leaving and role changes are done by whoever runs the deployment. A Clerk organization maps to a Mesa tenant, and membership of that organization is what places a user in that tenant.