Authentication Methods Overview
An authentication method is a route by which somebody proves who they are. The platform supports several at once, and an identity records which route was used.
Where to find it
Architect Panel → Security:
- Authentication Methods — the console — which routes are enabled
- Two-Factor Authentication — the second factor, independent of the route
- Passkeys — device-bound credentials
Architect Panel → Integration & Connections:
- SAML Identity Providers — enterprise single sign-on
- OpenID Connect Provider — OIDC
- Azure AD Tenants — Microsoft directory
- SCIM User Provisioning — automatic account lifecycle
Identity has three parts
Everywhere the platform records who did something — audit entries, grants, clearances, break-glass events — it stores three values rather than a username:
- Method — how they signed in.
- Unique identifier — who they are within that method.
- Domain — which population they belong to.
Why three
Because a bare username cannot answer the questions that matter after the fact.
The same person may exist as a local account and as a single sign-on identity. An API client acting on somebody's behalf is not the same event as that person signing in and doing it themselves. Two different populations — staff and customers — may legitimately contain the same identifier.
Recording the method means the audit trail distinguishes all of these, and it does so permanently. It also survives renaming: an identity built on a stable identifier still resolves after somebody changes their name or e-mail address.
Methods coexist
You are not choosing one. A typical installation runs single sign-on for staff, local accounts for a handful of service or break-glass identities, and something else again for external users.
What matters is knowing which populations use which route, because that determines where an account is disabled when somebody leaves — the commonest gap in an otherwise sound setup.
The second factor is separate
Two-factor authentication and passkeys sit alongside the method rather than replacing it. A local password and a single sign-on identity can both carry a second factor, configured independently.
Know your leaver path per method
For each method in use, be able to say what happens when somebody leaves. Directory-backed methods usually handle it automatically; local accounts do not, and they are exactly the accounts most likely to be privileged.
Write this down. It is the question an auditor asks and the one that most often has no confident answer.
Keep one local route working
If every administrator signs in through an external provider and that provider is unavailable, nobody can get in to fix anything. One local administrative account, strongly protected and rarely used, is worth having.
Worked example
An organisation runs single sign-on for its 400 staff, with two local administrator accounts held for emergencies and protected by passkeys. The audit trail distinguishes staff activity from the nightly integration and from the two local accounts, so a question about who changed a record has an unambiguous answer.
Recommendations
- Document which population uses which method.
- Define the leaver path for every method, especially local accounts.
- Keep one protected local administrator as a fallback.
- Read the method, not just the name, when investigating.