Choose a sign-in method
Set the same authentication mode on API and Web. Local accounts are the release template’s default; Hybrid adds organization sign-in without removing the password form.
Choose the experience
Section titled “Choose the experience”| Mode | Login page | Use it when |
|---|---|---|
Local | Email and password | You want an independent account store |
Oidc | Organization sign-in | All interactive users should use the identity provider |
Hybrid | Email/password and organization sign-in | You need both account types or are introducing SSO |
The application setting is Authentication__Mode. Values are explicit and case-insensitive. There is no Auto mode in this release.
The supplied Compose file hard-codes Local. Add an environment override to both services when changing it. A setting in .env has an effect only when your Compose file passes it into the container.
Start with local setup
Section titled “Start with local setup”The first-run wizard creates the initial local administrator. It needs no SMTP or identity provider. That account signs in with the email and passphrase chosen during setup.
Configure Hybrid while establishing your external users and role assignments. Verify the organization-sign-in path before choosing OIDC-only access.
Provider support in beta.17
Section titled “Provider support in beta.17”The browser OIDC path uses the Authentik configuration namespace and callbacks. Follow the OIDC guide for its required settings.
The API also retains Microsoft Entra bearer-token validation. That is separate from the browser provider flow; setting AzureAd values alone does not configure the Web login button. An existing Entra identity system can be federated into Authentik using its supported source integration.
Authentication and permissions
Section titled “Authentication and permissions”Signing in establishes the user’s identity. Roles and organization assignments determine which records and actions they can use.
Local accounts and verified external identities share that access model. Matching email addresses do not merge accounts or grant access. Customer contacts, login identities and role assignments serve different purposes.
CLI and MCP connections use separately issued integration credentials. A browser session or password is not an API bearer token.
Related pages
Section titled “Related pages”Release sources
Section titled “Release sources”Product home · Release downloads · Report a documentation issue