Single sign-on

Single sign-on

Configure OIDC with your identity provider, register the redirect URI, and how the PKCE one-time-code sign-in flow works.

Configure your identity provider

Under Settings → Sign-in, enter your identity provider’s issuer URL, client ID and client secret. Scopes default to openid profile email groups; the role claim (default groups) is matched against a role map you define, translating claim values to Admin, Operator or Viewer, with a default role for anyone that matches nothing. A Test button saves your changes and checks the provider’s discovery document before you rely on it.

Sign in with your own identity provider (OIDC with PKCE); no shipped default administrator password.

The redirect URI

Two addresses come from Settings → Deployment, not from this form: the redirect URI your identity provider must send the browser back to — register it exactly, path included — and the post-login landing address the console picks the session up at. Change the deployment’s public address there and both follow, with no restart.

The sign-in flow

“Sign in with…” sends the browser to your identity provider with a PKCE code challenge, a per-login state and a nonce. On success the identity provider redirects back with a one-time authorization code — never a bearer token in a URL, so a link opened in someone else’s browser signs no one in. The console redeems that code once, server-side, against the session it started with; replaying a spent code is refused.

OIDC sign-in uses PKCE, nonce and state, and hands the session over with a one-time cookie-bound code — never a bearer token in a URL.

Example: Keycloak

The acceptance suite exercises a real Keycloak realm end to end — no mocked identity provider. The shape is the one you will fill in: issuer https://idp.example.com/realms/<realm>, a client ID of your choosing, and a groups claim mapped through a client scope — a user in the Keycloak group admins signs in as Admin, and a user in no group at all falls back to the configured default role. Local email-and-password sign-in keeps working once SSO is enabled; it does not replace it.

All documentation