Single sign-on (SSO)
Let members sign in with your identity provider via SAML or OIDC
Single sign-on lets members authenticate through your own identity provider instead of a Bitelio password. A project can run one SSO connection at a time, using either SAML or OIDC — Bitelio acts as the service provider (SAML) or relying party (OIDC) throughout.
Domain verification
Before SSO can provision anyone, you verify ownership of the email domain your members sign in with:
- Add the domain in Settings → SSO.
- Publish the DNS TXT record Bitelio gives you:
bitelio-sso-verification=<token>. - Verify — Bitelio checks the record and marks the domain verified.
SSO only provisions users whose email address is on a verified domain. This is what stops a leaked or misconfigured IdP from taking over an account that belongs to a different organization: an assertion for alice@other-company.com is rejected unless other-company.com is verified on this project.
The allowUnverifiedDomains toggle, set per connection, relaxes this rule only for brand-new users — someone signing in for the first time on an unverified domain can still be provisioned. It can never attach an SSO login to an existing account on another domain; that anti-hijack rule always holds, toggle or not.
JIT provisioning
Bitelio provisions members just-in-time: the first successful SSO login creates the user (or, if the email already has a Bitelio account, adds that user to the project) and assigns the connection's configured default role. There's no separate invite step to run first.
Signing in
SSO is initiated from a per-connection login URL — there's no email-domain auto-discovery in v1, so members use the link you share with them rather than typing their email on the regular sign-in page. SSO is optional: it doesn't replace password or OAuth sign-in, and enabling it doesn't force existing members to switch.