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.

Operator browser 1 · sign in Admin UI admin readonly 2 · redirect 3 · role Your identity provider Keycloak · Okta · Azure AD · … IdP groups map to admin or readonly, the session never outlives the ID token, and break-glass local login can stay on
The standard authorization-code flow: your IdP authenticates, SeaweedFS maps groups to one of two roles.

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.