The Authentication surface is the configuration root for how users sign in. Open it: Authentication in the sidebar. You see a list of configured methods and connections.
Methods are what's offered to users on the sign-in page. Each can be on or off; each has its own configuration.
Standard methods
Section titled “Standard methods”The platform ships with these out of the box:
- Password — email + password sign-in. Always available; you can disable it but most tenants keep it on. See Password authentication.
- Email OTP — passwordless sign-in via a code emailed to the user. See Email OTP.
- SMS OTP — passwordless sign-in via a code sent by text message. The user types their phone number; the platform sends a six-digit code; they type the code; they're in. No password. Requires a phone trait in your identity schema and a configured SMS gateway. See SMS OTP.
- Magic link — passwordless sign-in via a link emailed to the user. See Magic link.
When more than one is enabled, the sign-in page shows a tab strip and the user picks their preferred method.
Social providers
Section titled “Social providers”For "Sign in with Google", "Sign in with GitHub", etc. Each provider is a configured connection that the user can pick from the sign-in page. See Social providers.
You configure once per provider; the user gets a button on the sign-in page that says "Continue with Google" (or whatever you named it).
Enterprise SSO (OIDC + SAML)
Section titled “Enterprise SSO (OIDC + SAML)”For B2B scenarios where your customer's IT team runs an IdP (Okta, Entra, Ping, etc.) and demands SSO. Configure a connection per customer; their users sign in via their own IdP.
Two flavours:
- OIDC connection — for IdPs that speak OIDC. Most modern IdPs (Okta, Auth0, Keycloak) prefer this. Simpler setup; cleaner protocol.
- SAML connection — for IdPs that speak SAML 2.0. Some legacy enterprise IdPs only support this.
See the developer-side docs on Federation for the protocol detail; the configuration screens in the admin console match the connection types.
Not on this page — MFA has its own surface in the sidebar. The Authentication page is for the FIRST factor (what the user starts with); MFA is for the second factor. See MFA overview.
How decisions interact
Section titled “How decisions interact”A few orthogonal axes you control:
- Which methods are offered — checkboxes on each method's settings page.
- Per-method policy — password complexity, OTP length, etc.
- Tenant-wide policy — what % of users must complete MFA, what AAL is required for sensitive actions, etc. See Authentication policy.
- Per-application policy — an individual application can override tenant defaults (rarely useful; mostly for tightening security on sensitive applications).
The combination is: tenant policy says "MFA required"; application X overrides to "MFA required AND step-up to AAL 3 for sensitive routes"; the application's UI handles the AAL-3 prompts.
The sign-in page experience
Section titled “The sign-in page experience”The user-facing sign-in page surfaces every enabled method. When more than one is on, the page shows the picker (a "Continue with email" + "Continue with Google" + "Continue with SSO" stack). Customise the order in Authentication → Sign-in page → Method order.
For a single-method tenant (e.g., SAML-only, no password), the picker is suppressed; the user is sent directly to the IdP.
Branding
Section titled “Branding”The colours, logos, and copy on the sign-in page are in Branding, not here. The Authentication page is about what happens; Branding is about how it looks.