Single sign-on (OIDC)¶
Authenticate against any standards-compliant OpenID Connect provider — Microsoft Entra ID, Okta, Google Workspace, Keycloak, Authentik and others.
Authorization Code flow with PKCE. The server validates the ID token (JWKS signature plus
iss, aud, exp and nonce) and then issues the platform's normal session, so SSO
users get the same experience as local ones.
No environment variables and no redeploy — everything is configured in the UI, with the client secret encrypted at rest.
1. Register the application with your provider¶
Create an OIDC/OAuth web application and note:
- Issuer URL — the base that serves
/.well-known/openid-configuration - Client ID
- Client Secret — optional; public clients with no secret work via PKCE
Set the redirect / callback URI to:
https://<your-host>/api/auth/oidc/callback
The exact value is shown in the settings panel, which is worth copying from rather than typing.
2. Configure it in the app¶
As an admin, go to Settings → SSO / OIDC.
| Field | Purpose |
|---|---|
| Issuer URL | Your provider's base URL. Test discovery verifies it is reachable before you save. |
| Client ID / Secret | From step 1. The secret is write-only — leave it blank to keep the existing one. |
| Scopes | Default openid profile email. Add a groups scope if your IdP needs one to emit group membership. |
| Username claim | Default preferred_username |
| Email claim | Default email |
| Groups claim | Default groups |
| Group → role mapping | Map IdP groups to admin / operator / viewer, e.g. net-admins → admin. Highest-privilege match wins. |
| Default role | For users matching no mapping. Defaults to viewer. |
| Auto-provision | Create a local user automatically on first sign-in. |
| Link by verified email | Attach an SSO identity to an existing local account when the IdP's email_verified matches. |
| Allowed email domains | Optional allowlist restricting who may sign in. |
| Public base URL | Pin the redirect URI when your external URL differs from what the backend sees. |
| Button label | Text on the login button, e.g. "Sign in with Okta". |
Enable it and save. A Sign in with SSO button appears on the login page.
Behaviour and safety¶
Provisioning and linking. First sign-in creates a user when auto-provision is on, or
links to an existing local account when email_verified matches — no duplicate account.
SSO users have no local password and are labelled with an SSO badge under
Users & Roles.
Roles are resolved server-side at every sign-in. With a group mapping configured, the identity provider decides: a user's role is the one their groups map to, or the default role if none do, so removing someone from the admin group takes effect at their next sign-in. The one exception is the last admin account, which is never demoted, so a provider misconfiguration can't leave the install with no admin. With no group mapping configured, roles are managed here under Users & Roles and SSO never changes them. (Before 0.24.50 a user kept a mapped role after leaving the group.)
Allowed email domains need a verified email. A new user is admitted by domain only when
the provider says the address is verified (email_verified: true). An unverified address is
whatever the user typed in, so it can't vouch for a domain. Some providers, Microsoft Entra
ID among them, don't send email_verified; there, admit users with a group mapping instead
of a domain list. Users already linked to their SSO identity aren't affected.
Sign-in is tied to your browser. Starting a sign-in sets a short-lived cookie that only the SSO endpoints receive, and the sign-in can only be finished in the browser holding it. The provider's redirect brings back a one-time code, not a session; the app exchanges it for the session straight away and removes it from the address bar. So a sign-in link can't be used to log someone else in to your account, and no session token is left in browser history. A sign-in started before an admin turns SSO off is refused when it comes back.
Break-glass. Local username and password login stays available unless you turn it off (below). The seeded local admin can always get in, even if the IdP is misconfigured, expired, or unreachable. Do not delete that account.
SSO-only sign-in. Set PASSWORD_LOGIN=false in .env and restart to make SSO the only
way in. The login page then shows just the SSO button, and password sign-in, password
changes and two-factor setup are refused; My Account disappears from Settings. API tokens
keep working. It only takes effect while SSO is configured, so a typo can't lock everyone out.
If SSO breaks, set PASSWORD_LOGIN=true, restart, and sign in with the local admin: that is
the break-glass, and nothing inside the app can turn it off.
Turning SSO off while signed in through it. An admin signed in through SSO has no local password, so the app refuses to turn SSO off, or to point it at a different provider, from that session: it would lock them out at their next sign-in. Make that change from a local admin account.
Behind a reverse proxy. The redirect URI is derived from the host and scheme of the request. Behind a proxy set up as in Behind a reverse proxy that is your external URL. If it still differs (a tunnel, a proxy that rewrites the host), set Public base URL to pin it, or the provider will reject the callback.