SSO
Configure single sign-on so users authenticate through your organisation's identity provider.
SSO lets users sign in to Automate through your organisation's identity provider instead of managing separate passwords. Use it when your company requires central MFA, conditional access, or directory-driven user lifecycle.
Open Admin Panel → SSO.
When to use SSO
SSO is recommended when:
- Automate is used by more than a small pilot group.
- Your organisation already uses an identity provider such as Microsoft Entra ID, Okta, Keycloak, or Google Workspace.
- Security policy requires central MFA or session rules.
- User access must be removed quickly when someone leaves.
Configure SSO safely
Prepare identity provider details
In your identity provider, create an OIDC or supported SSO application for Automate. Keep issuer, client ID, client secret, and redirect/callback details ready.
Open SSO
In Admin Panel, go to Authentication → SSO.
SSO under Authentication is where identity provider settings are configured or reviewed. Add provider settings
Enter the provider details from your identity platform. Use exact values from the provider rather than retyping from memory.
Test with one admin user
Test sign-in before rolling out to the whole workspace. Keep a break-glass SuperAdmin path available during setup.
Rollout checklist
| Check | Why it matters |
|---|---|
| SuperAdmin break-glass access exists | Prevents lockout if the provider is misconfigured |
| Test user can sign in | Confirms the provider and redirect settings work |
| Roles and workspace access are correct | Authentication alone does not prove the user has the right permissions |
| Offboarding process is clear | Identity provider disablement should remove access quickly |
| Users know which sign-in method to use | Reduces support requests during rollout |
SSO and roles
SSO proves who the user is. Roles decide what they can do after sign-in. Review Users and roles when you enable or change SSO.