Feature Request: OIDC Web UI Login (Authorization Code flow)

[mxdev88]

Problem

Nora's OIDC support is limited to CI/CD workload identity (JWT Bearer token
validation via JWKS). There is no way to authenticate in the Web UI using an
external identity provider. This forces operators to manage htpasswd users
manually, which does not scale:

• No self-service registration or password reset
• No integration with existing SSO (Authentik, Keycloak, Google, Azure AD)
• Every user must be pre-provisioned in users.htpasswd on every replica
• No support for MFA, password policies, or account lifecycle management

Context

• Nora version: 0.9.5
• Deployment scenario: Production with Authentik as the central IdP,
  currently usable only for CI/CD pipelines (OIDC workload identity) but
  missing Web UI login for human users.

Proposed Solution

Add OIDC Authorization Code flow with PKCE for Web UI login.

Flow

1. User clicks "Log in with SSO" on the Nora login page
2. Browser redirected to the configured IdP's authorization endpoint
3. IdP authenticates the user and redirects back with an auth code
4. Nora exchanges the code for an ID token + access token
5. Nora validates the ID token (iss, aud, exp, signature via JWKS)
6. A Web UI session is created (signed cookie or in-memory token)
7. User is now authenticated in the UI

Configuration Sketch (TOML)

[auth.oidc]

  [[auth.oidc.ui_providers]]
  name = "authentik"
  display_name = "Log in with Authentik"
  issuer = "https://auth.example.com/application/o/nora/"
  client_id = "..."
  client_secret = "..."
  scopes = ["openid", "profile", "email"]
  role_claim = "groups"
  role_map = { "nora-admin" = "admin", "nora-write" = "write" }
  auto_provision = true
  link_claim = "email"

Design Considerations

Session management

Nora currently has no concept of Web UI sessions. A simple signed-JWT cookie
(httpOnly, SameSite=Lax) stored in a sessions/ directory would work
for single-replica. Multi-replica might need a shared session store (Redis, DB).

Role mapping

The IdP groups claim (or similar) should map to Nora roles (read/write/admin).
This lets the IdP be the source of truth for authorization.

Coexistence

Must work alongside existing htpasswd auth and existing OIDC workload identity
(CI/CD JWT Bearer). They are independent authentication methods.

PKCE

Required for public clients (SPA). The Nora Web UI is a SPA served from the
same origin, so Authorization Code + PKCE is the recommended OAuth 2.0 BCP.

admin_users integration

OIDC-authenticated users who map to the admin role should also be able to
mint admin tokens via POST /api/tokens (currently restricted to htpasswd
users listed in auth.admin_users).

Alternatives Considered

• ForwardAuth (Traefik/Authentik): Breaks Docker CLI, pip, npm — they need
  HTTP 401/WWW-Authenticate, not a redirect. Not viable.
• htpasswd-only: Works but imposes manual user management burden that does
  not scale.

Prior Art

Harbor, Nexus, Artifactory, and the GitLab Container Registry all support
OIDC Web UI login alongside token-based registry auth. The common pattern:
the IdP handles authentication, the registry issues short-lived tokens for
protocol clients (Docker/PyPI/npm) and sessions for the Web UI.

Related Registry

UI/Dashboard

[devitway]

Thanks for the detailed write-up — this is a well-scoped request and it's on the
roadmap. A few notes on direction:

Accepted for consideration, and it will be a Community Edition feature. SSO
login for human operators belongs in the free edition, alongside the existing
OIDC workload-identity support — not behind a paywall.

One scope decision worth setting up front for v1. The "mint admin tokens via
POST /api/tokens" part won't be driven directly by an IdP group. That endpoint
stays gated on the config-file admin_users allowlist. The reason: an
OIDC identity's username is the IdP-controlled sub, so letting an IdP group
implicitly grant admin-token minting would move the admin trust boundary into
whoever manages group membership in the IdP. A web session can still carry the
admin role for UI authorization — it just can't forge persistent admin API
credentials without being on the config allowlist.

A couple of design points that differ slightly from the issue, for visibility:

• The web UI is server-rendered, not a SPA, so NORA acts as a confidential
  client (it holds the client_secret and does the code exchange server-side).
  Authorization Code applies; PKCE will be implemented as defense-in-depth, not
  because a public client requires it.
• Sessions will use a stateless signed cookie (no Redis/DB), which keeps the
  single-binary model and works across replicas. The trade-off is that logout is
  best-effort (no instant server-side revocation); we'll mitigate with a short
  session lifetime.

This is a non-trivial chunk of auth work, so it'll land in stages rather than in
one drop. Tracking it here. Thanks again for the thorough proposal.