External Providers
External providers let people sign in with an identity they already have, so the platform never holds their password.
Where to find it
Architect Panel → Integration & Connections:
- SAML Identity Providers — enterprise single sign-on
- OpenID Connect Provider — OIDC
- Azure AD Tenants — Microsoft directory
- SCIM User Provisioning — automatic joiners, movers and leavers
- OAuth Tokens — issued tokens
Architect Panel → Security:
- Certificates — signing certificates
- Authentication Methods — enabling the route
What you gain
- No password held here, so no password to leak from here.
- Your directory's own policy — complexity, rotation, conditional access — applies without being reimplemented.
- Disabling somebody centrally disables them here.
- One fewer credential for people to manage, which measurably reduces reuse.
Provisioning is the other half
Single sign-on controls authentication. Provisioning controls account lifecycle — creating accounts, updating them, and deactivating them when somebody leaves.
Without provisioning, a leaver disabled in your directory can no longer sign in, but their account, its group memberships and its record grants all remain. That is usually acceptable, but it should be a decision rather than a surprise — and it means your access reviews still have real work to do.
Certificates expire
SAML depends on signing certificates with expiry dates, and an expired certificate stops all sign-in at once for everybody using that provider.
It is a known date, so put it in a diary well ahead. This is the most common single-sign-on outage there is, and it is entirely preventable.
Test what happens when the provider is down
Before you switch over, establish how you get in when the provider is unavailable. A directory outage that also locks every administrator out of the platform turns somebody else's incident into yours.
Keep at least one local administrative account, protected by a passkey or a second factor, and confirm it works — not by assuming, but by signing in with it.
Map groups deliberately
Where directory groups drive platform access, the mapping is a security boundary. Somebody added to a directory group by a colleague who does not know what it means here can be granted access nobody reviewed.
Keep the mapping small and explicit, and review it when either side changes.
Watch the first fortnight
Attribute mismatches, people with two identities, and users whose directory record is missing something the platform expects all surface early. Check the error log and the sign-in activity daily for the first couple of weeks.
Worked example
An organisation moves staff to Microsoft single sign-on with SCIM provisioning. Leavers are deactivated automatically the day they leave. Two local administrator accounts with passkeys are retained and tested, and the SAML certificate expiry is diarised 60 days ahead. When the directory has a two-hour outage six months later, administrators still get in.
Recommendations
- Add provisioning, not just single sign-on.
- Diary certificate expiry well in advance.
- Keep and test a local administrative fallback.
- Review the group mapping whenever either side changes.