[tianzhou]

Summary

Adds type = "oidc" to [[auth.providers]] so any OpenID Connect provider that supports discovery (Authentik, Auth0, Authelia, Zitadel, VoidAuth, ...) works without a dedicated integration.

[[auth.providers]]
type = "oidc"
name = "Authentik"   # optional, sign-in button label (defaults to "SSO")
client_id = "pgconsole"
client_secret = "..."
issuer_url = "https://auth.example.com/application/o/pgconsole/"

Closes #38

Changes

• server/lib/oauth/oidc.ts: new provider. Resolves authorization, token, and userinfo endpoints from <issuer_url>/.well-known/openid-configuration, cached after first success. Discovery failure returns 502 on the sign-in route. Token exchange and userinfo handling mirror the Keycloak and Okta providers.
• server/lib/config.ts: accept oidc, require issuer_url for it, parse optional name.
• server/lib/auth.ts: widen idp union.
• server/auth-routes.ts: register route; /api/auth/providers now includes label when a name is configured.
• src/components/AuthForm.tsx, src/lib/auth-client.ts: sign-in button using the label.
• Docs: new authentication/oidc page, config reference, overview, audit-log provider list, nav.

Design notes

• Discovery only, no per-endpoint override fields. Every provider named in the issue supports discovery.
• Scopes fixed to openid email profile; email is required as the identity key, same as the other providers.
• At most one oidc provider, consistent with lookup-by-type for the existing types.
• name follows the optional display-name convention already used by [[ai.providers]] and [[agents]].

Verification

• pnpm build:server, tsc -b, direct typecheck of server auth files, and eslint on changed files: clean.
• Smoke test against a mock IdP on localhost: providers endpoint returns the label; sign-in route 302s to the discovered authorization endpoint with correct redirect_uri, scopes, and state; two sign-in requests produce one discovery fetch; callback with mismatched state redirects to /signin?error=invalid_state.
• Config missing issuer_url for oidc fails to load with a clear error.
• Not tested against a real IdP. Issuer URL patterns in the docs table should be double-checked.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 4/5

[Critical impact] The PR adds a sign-in path that reaches account access in deployments that enable OIDC.

Support HTTP Basic authentication for token requests before merging so compatible OIDC providers can complete sign-in.

Findings

1.  Some providers reject token requests ▶
2.   Unverified emails select local accounts ▶
3.  Setup example omits required users ▶

Summary

Adds a generic OIDC sign-in provider with discovery and a configurable button label.

• Configured users can sign in through a provider that supports OIDC discovery.

Diagram

sequenceDiagram
  participant User
  participant Console as pgconsole
  participant Provider as OIDC provider
  User->>Console: Choose SSO
  Console->>Provider: Fetch discovery on first use
  Provider-->>Console: Authorization, token, and userinfo endpoints
  Console-->>User: Redirect with state
  User->>Provider: Sign in
  Provider-->>Console: Callback with code and state
  Console->>Console: Check state
  Console->>Provider: Exchange code
  Console->>Provider: Fetch userinfo
  Console->>Console: Check email against allowed users
  Console-->>User: Set session and redirect

Loading

_{Reviews (1) · Last reviewed commit: "feat: add generic OIDC auth provider" · Reviewed by Greptile}

[Copilot]

🟡 Changes recommended

The OIDC callback accepts explicitly unverified emails, enabling impersonation of allowlisted users when an identity provider permits self-registration or unverified email changes.

4 open issues

• Reject unverified email identities · New
• Merge OAuth parameters with existing authorization query · New
• Honor the issuer's token endpoint authentication method · New
• Add allowlisted users to the setup example · New

What changed in this PR

Adds a generic OIDC authentication provider to support discovery-based identity providers without dedicated integrations, addressing issue #38.

Changes:

• Implements OIDC discovery, sign-in, callback handling, and provider configuration.
• Adds configurable sign-in labels and OIDC identity-provider support.
• Documents setup, configuration, and audit-log integration.

File	Description
src/​lib/​auth-client.ts	Adds optional provider display labels.
src/​components/​AuthForm.tsx	Adds the OIDC sign-in button and custom labels.
server/​lib/​oauth/​oidc.ts	Implements discovery and the OIDC authentication flow.
server/​lib/​config.ts	Accepts OIDC configuration and optional names.
server/​lib/​auth.ts	Adds OIDC to user and token provider types.
server/​auth-routes.ts	Registers OIDC routes and exposes provider labels.
docs/​features/​audit-log.mdx	Updates the documented authentication provider list.
docs/​docs.json	Adds the OIDC guide to navigation.
docs/​configuration/​config.mdx	Documents OIDC fields and configuration examples.
docs/​authentication/​overview.mdx	Links OIDC from the authentication overview.
docs/​authentication/​oidc.mdx	Adds the OIDC setup guide.

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

OIDC sign-in can grant sessions for unverified allowlisted emails, while authorization URL construction and client authentication selection can also cause valid provider configurations to fail.

2 open issues

• Require verified email before issuing a session · New
• Respect registered client authentication method · New

4 resolved since last review

• Reject unverified email identities
• Honor the issuer's token endpoint authentication method
• Merge OAuth parameters with existing authorization query
• Add allowlisted users to the setup example

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The code always selects Basic when both methods are advertised, causing token exchanges to fail with invalid_client for clients registered to use POST, with no client-level override.

No open issues 🎉

2 resolved since last review

• Require verified email before issuing a session
• Respect registered client authentication method

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Critical concerns around OIDC issuer trust and ID-token/UserInfo identity binding require human security assessment before approval.

No open issues 🎉

_{Review effort: Balanced}