Single sign-on
Your own Okta, Entra or Auth0, by SAML or OIDC.
Single sign-on
Section titled “Single sign-on”Connect your own identity provider and your people sign in with the account they already have.
Single sign-on is an Enterprise capability. See Plans.
What is supported
Section titled “What is supported”| Protocol | Providers it covers |
|---|---|
| SAML 2.0 | Okta, Entra ID, and any SAML provider |
| OIDC | Auth0, Google Workspace, and any OIDC provider |
The credential is yours, not ours
Section titled “The credential is yours, not ours”Your directory’s configuration is stored per workspace, encrypted, alongside your other connected accounts. It is your credential, not this deployment’s, so it is never in an environment variable and never shared between customers.
Email domains
Section titled “Email domains”Associate one or more email domains with the workspace. Somebody entering an address at that domain is sent to your provider rather than asked for a password.
How an identity is keyed
Section titled “How an identity is keyed”By the pair (workspace, external id), never by the bare subject.
Two reasons:
- a subject is unique within one directory, and two workspaces may use directories that mint the same one;
- the external id is stored rather than the email address, because an address changes when somebody marries and the directory is still talking about the same person.
First sign-in
Section titled “First sign-in”Somebody who signs in through your directory and is not yet a member gets a membership, at the default role you set.
What it does not do
Section titled “What it does not do”Danger
Single sign-on never removes anybody. Deprovisioning is SCIM, and SCIM is not built.
Remove somebody from your directory and:
- the door shuts. They cannot sign in through it again.
- the membership row stays.
- they still appear in People.
- they still count against your seats.
- the weekly letter still goes to them, by name, summarising your internal documentation.
That last line is the one that matters. Remove the person in People as well as in your directory.
SCIM provisioning is designed and quoted, and it is listed as on request
because it does not exist. Do not plan a rollout around it.
What a deactivation would mean
Section titled “What a deactivation would mean”When SCIM ships, the recommended behaviour is that active: false does what
pressing Remove in People does: the membership goes, and the person’s authored
pages stay with their name on them.
An audit row will record that a directory did it rather than a person.
Recovering from a broken configuration
Section titled “Recovering from a broken configuration”Password and magic-link sign-in continue to work for members who have them. A misconfigured directory does not lock an owner out of their own workspace.