Single Sign-On (SSO)¶

Sign in admins through an external identity provider via OpenID Connect (OIDC). The integration is discovery-based, so it works with any standards-compliant provider: Keycloak, Authentik, Azure AD / Entra ID, Google Workspace, Auth0, Zitadel and others.

Found under System → Single Sign-On (admin only).

Admin login only

SSO signs in admin accounts only. Resellers and customers keep using the normal login. Local password login always stays enabled — a misconfigured provider (wrong issuer URL, expired client secret) can never lock you out.

Setup in three steps¶

Create a client at your provider (a confidential OAuth2/OIDC client using the authorization-code flow). As the allowed redirect URI, enter exactly the URL the SSO page shows you:

https://<your-panel-host>/api/v1/auth/oidc/callback

Enter the credentials in the panel: Issuer URL (e.g. https://keycloak.example.com/realms/enconf), Client ID and Client Secret. Test connection verifies OIDC discovery (<issuer>/.well-known/openid-configuration).
Enable SSO and save. A Single Sign-On button now appears on the login page.

The issuer URL must use HTTPS; SSO cannot be enabled without a stored client secret.

Restricting access¶

Optional, on top of the always-enforced admin-role requirement:

Allowed e-mail domains — comma-separated (e.g. example.com). Empty = any domain.
Allowed e-mail addresses — an explicit allowlist. Empty = none.
Required group — if set, the ID token must contain the group in the configured groups claim (default groups).

An explicit email_verified: false from the provider is rejected. A missing claim (many enterprise IdPs omit it) is accepted.

Account mapping¶

The verified e-mail from the provider is mapped to a panel account:

Existing account: if the e-mail exists and the account is an active admin, login proceeds. If it is not an admin, it is rejected.
Auto-create (JIT): when enabled, first login for a verified, allowed e-mail creates an admin account. Default: off — only pre-existing admins may sign in (the safer default).

JIT-created admins get a random local password; login is via SSO only.

Security¶

CSRF/replay protection: the authorization flow uses a signed, short-lived state (double-submit cookie) plus an OIDC nonce checked against the ID token.
The client secret is stored encrypted (AES) and never sent to the frontend.
2FA: multi-factor is handled by the identity provider. The panel's local TOTP for password login is untouched.
In the demo instance (DEMO_MODE), SSO is disabled.