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
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.
Magic link — passwordless sign-in via a link emailed to the user. See Magic link.
These are baseline; most tenants run with all three on. The user picks which they prefer on the sign-in page.
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)
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.
MFA
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
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
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
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.