Admin UI OIDC Login

SeaweedFS Enterprise lets operators sign in to the admin UI through an existing identity provider — Keycloak, Okta, Authentik, Auth0, Google, Azure AD, or any standards-compliant OIDC service — instead of managing a separate admin password. The admin server runs the standard authorization-code flow, maps the user’s OIDC groups to an admin or readonly role, and issues a session capped at the ID token’s lifetime.

SeaweedFS Admin UI – OIDC Login (SSO): the admin server runs the standard authorization-code flow with your identity provider, maps OIDC groups to admin or read-only roles, and issues a session capped at the ID token expiration. Compatible with Keycloak, Okta, Auth0, Google, Azure AD, and other OIDC-compliant providers.

When to use it

  • You already run an identity provider — reuse the same Keycloak/Okta/Azure AD your other internal apps use, instead of a standalone admin password.
  • You need centralized access control — grant or revoke admin access through IdP groups, with no SeaweedFS-side user edits.
  • You want to cut credential sprawl — stop storing a separate admin password for every operator.
  • You want safer sessions — the admin session can’t outlive the source ID token.
  • You still need a break-glass account — run OIDC alongside local credentials so you keep a recovery path during rollout or IdP outages.

How to use it

  1. Register a client with your identity provider, with the callback URL https://admin.example.com/login/oidc/callback.
  2. Enable OIDC in security.toml under [admin.oidc] — issuer, client ID/secret, redirect URL — and add at least one role-mapping rule (e.g. group seaweedfs-admin → role admin).
  3. Restart the admin server. A Sign in with OIDC button appears on the login page; if local credentials are also configured, both options show.
  4. Users sign in through the IdP, get mapped to admin (full read/write) or readonly (view-only), and receive a session capped at the token’s expiration.

Benefits

  • Single sign-on — one identity provider for the admin UI and your other internal tools.
  • No new permission model — OIDC users map onto the same two admin UI roles SeaweedFS already has.
  • Centralized, revocable access — manage admin rights from IdP groups, not per-operator passwords.
  • Coexists with local login — keep a break-glass admin account for when the IdP is unavailable.

Want the internals — the full security.toml config, role mapping, redirect-URL rules, and startup/TLS behavior? See the Admin UI OIDC Login technical reference.