[mikolaj92]

Summary

Replace the web dashboard login gate with OIDC while keeping password login as a fully supported fallback.

Scope (minimal sensible):

• Only the dashboard/MANAGEMENT gate (/dashboard, /api/auth/* for login).
• No changes to /v1/* proxy traffic, API keys, managementPassword, managementPolicy, MCP, CLI, or proxy auth.
• Single-admin model preserved.
• Uses existing auth_token JWT (30 days, { authenticated: true }, same cookie attributes).

Changes

• src/lib/db/settings.ts: OIDC config fields (oidcEnabled, oidcIssuer, oidcClientId, oidcClientSecret, oidcScopes, oidcRedirectPath, oidcAllowedSubjects).
• src/shared/constants/publicApiRoutes.ts: /api/auth/oidc/* marked public.
• src/shared/utils/apiAuth.ts: hasConfiguredOidc(); isAuthRequired treats full OIDC config as valid auth method (password still works).
• src/app/api/settings/require-login/route.ts: exposes oidcEnabled.
• src/app/login/page.tsx: conditional OIDC button when configured.
• New routes:
  • GET /api/auth/oidc/login — builds authorize URL via discovery, sets oidc_state.
  • GET /api/auth/oidc/callback — code exchange, ID token validation via jose + createRemoteJWKSet, optional subject/email whitelist, mints identical auth_token, clears state, redirects to /dashboard.
• src/app/api/auth/oidc/callback/route.ts: added test seam oidcCallbackInternals.getCookieStore, all redirects made absolute (originEarly), setupComplete: true on first successful OIDC login (bootstrap parity with password path).
• Tests:
  • tests/unit/oidc-callback.test.ts — 8 focused integration tests (happy path + all major error paths using mocked fetch + real jose-signed tokens).
  • Updated assertions in public-api-routes.test.ts and api-auth.test.ts.

Constraints followed

• No new dependencies (jose + fetch already present).
• Password path untouched and remains available.
• Bootstrap/misconfig behavior preserved (partial OIDC config does not satisfy isAuthRequired).
• Same JWT/cookie shape as password login.
• All NextResponse.redirect use absolute URLs (Next.js 16 compatibility).

Verification

• Focused test run (53 tests across OIDC + auth surface): 53 pass / 0 fail.
• No package/lock changes for the feature itself.
• Exact same auth_token JWT payload and cookie attributes as password login.

Manual testing (recommended before merge)

1. Configure OIDC in Settings (Issuer, Client ID, Secret, optional Allowed Subjects).
2. Log in via OIDC button.
3. Verify redirect to dashboard and auth_token cookie.
4. Password login should still work as fallback.
5. Test error cases (invalid state, subject not allowed, misconfigured, etc.).

Closes the dashboard OIDC login gate request while preserving the existing password mechanism.

[gemini-code-assist]

Code Review

This pull request implements optional OpenID Connect (OIDC) authentication for the dashboard admin gate, adding login and callback API routes, updating the login UI, and extending settings and authentication utilities to support OIDC configuration. The review feedback focuses on enhancing the robustness, performance, and security of this new authentication flow. Key recommendations include caching the JWKS client globally to prevent redundant network requests, wrapping token exchange fetches in try-catch blocks with timeouts to avoid unhandled exceptions, performing case-insensitive email comparisons for the subject whitelist, and dynamically applying the secure attribute to the state cookie based on the request protocol.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

To avoid recreating the JWKS client on every request and to leverage jose's built-in caching of retrieved keys, we should define a module-level cache for JWKS clients. This prevents unnecessary network roundtrips to the OIDC provider's JWKS endpoint on every login attempt.

export const oidcCallbackInternals = {
  getCookieStore: cookies,
};

// Cache JWKS clients globally to reuse retrieved keys and avoid fetching JWKS on every login request.
const jwksClientsCache = new Map<string, ReturnType<typeof createRemoteJWKSet>>();

function getJwksClient(jwksUri: string) {
  let client = jwksClientsCache.get(jwksUri);
  if (!client) {
    client = createRemoteJWKSet(new URL(jwksUri));
    jwksClientsCache.set(jwksUri, client);
  }
  return client;
}

[gemini-code-assist]

Use the globally cached JWKS client helper instead of instantiating a new one on every request.

Suggested change

	const JWKS = createRemoteJWKSet(new URL(jwksUri));
	const JWKS = getJwksClient(jwksUri);

[gemini-code-assist]

The token exchange fetch and the subsequent tokenResp.json() call are not wrapped in a try-catch block. Any network error or malformed JSON response will throw an unhandled exception and crash the route with a 500 error. Wrapping these in try-catch blocks ensures graceful error handling and redirects the user back to the login page with a clean error code. Additionally, we should add a timeout to the fetch request to prevent hanging connections.

  let tokenResp: Response;
  try {
    tokenResp = await fetch(tokenEndpoint, {
      method: "POST",
      headers: { "Content-Type": "application/x-www-form-urlencoded" },
      body: tokenParams.toString(),
      signal: AbortSignal.timeout(10000),
    });
  } catch {
    return NextResponse.redirect(`${originEarly}/login?oidc_error=token_exchange`);
  }

  if (!tokenResp.ok) {
    return NextResponse.redirect(`${originEarly}/login?oidc_error=token_exchange`);
  }

  let tokenData: unknown;
  try {
    tokenData = await tokenResp.json();
  } catch {
    return NextResponse.redirect(`${originEarly}/login?oidc_error=token_response`);
  }

  if (!tokenData || typeof tokenData !== "object") {
    return NextResponse.redirect(`${originEarly}/login?oidc_error=token_response`);
  }

[gemini-code-assist]

Add a timeout to the discovery fetch request to prevent the connection from hanging indefinitely if the OIDC provider is unresponsive.

    const wellKnownResp = await fetch(`${issuer}/.well-known/openid-configuration`, {
      signal: AbortSignal.timeout(5000),
    });

[gemini-code-assist]

Email addresses are case-insensitive by nature. Performing a strict case-sensitive comparison (v === email) can cause unexpected login failures if there is a casing mismatch between the OIDC provider's response and the configured allowed subjects. Comparing emails case-insensitively resolves this usability issue.

    // Optional subject / email whitelist
    const allowed = Array.isArray(settings.oidcAllowedSubjects) ? settings.oidcAllowedSubjects : [];
    if (allowed.length > 0) {
      const sub = typeof payload.sub === "string" ? payload.sub : "";
      const email = 
        typeof (payload as Record<string, unknown>).email === "string"
          ? ((payload as Record<string, unknown>).email as string).toLowerCase()
          : "";
      const ok = allowed.some((v: unknown) => {
        if (typeof v !== "string") return false;
        return v === sub || v.toLowerCase() === email;
      });
      if (!ok) {
        return NextResponse.redirect(`${originEarly}/login?oidc_error=subject_not_allowed`);
      }
    }

[gemini-code-assist]

Add a timeout to the discovery fetch request to prevent the connection from hanging indefinitely if the OIDC provider is unresponsive.

    const wellKnownResp = await fetch(`${issuer}/.well-known/openid-configuration`, {
      signal: AbortSignal.timeout(5000),
    });

[gemini-code-assist]

To ensure consistent cookie security, the oidc_state cookie should be marked secure dynamically when running over HTTPS, matching the logic used for the auth_token cookie in the callback route.

  const isHttpsRequest = scheme === "https";
  const useSecureCookie = process.env.AUTH_COOKIE_SECURE === "true" || isHttpsRequest;

  res.cookies.set("oidc_state", state, {
    httpOnly: true,
    sameSite: "lax",
    path: "/",
    maxAge: 60 * 10,
    secure: useSecureCookie,
  });

[diegosouzapw]

Thanks for this — solid core implementation. jose-based JWKS/signature/issuer/audience validation, CSRF state cookie, sanitized error redirects, and the 49 unit tests hold up.

Two things need to land before merge:

1. No way to configure it. updateSettingsSchema (src/shared/validation/settingsSchemas.ts) is .strict() and has no oidc* fields, and no settings UI or API route in this PR writes oidcEnabled/oidcIssuer/oidcClientId/oidcClientSecret/oidcAllowedSubjects. As shipped, an operator cannot turn this on short of raw SQLite writes.
2. oidcClientSecret isn't encrypted at rest. It goes through updateSettings() → plain JSON.stringify, unlike provider credentials which run through encryptConnectionFields (AES-256-GCM) in src/lib/db/providers.ts.

Also worth addressing while wiring the settings path: gate oidcEnabled behind the existing SECURITY_IMPACTING_KEYS re-auth check, and consider requiring a non-empty oidcAllowedSubjects before allowing oidcEnabled: true (the empty default currently lets any subject from the configured IdP become dashboard admin). Once configurable, a live test against a real IdP completes the validation per the repo's testing protocol.

[mikolaj92]

All Gemini Code Assist review comments addressed (JWKS cache, token exchange try/catch+timeout, discovery timeouts, case-insensitive email, dynamic secure cookie). Ready for re-review. Tests: 53/53 pass.

[mikolaj92]

@diegosouzapw

All Gemini Code Assist review comments have been addressed:

• Added module-level JWKS client cache + getJwksClient helper (avoids recreating client on every request)
• Wrapped token exchange fetch + .json() in try/catch with 10s timeout
• Added 5s timeout to discovery fetch in both /login and /callback routes
• Made email comparison case-insensitive in oidcAllowedSubjects whitelist
• Made oidc_state cookie secure flag dynamic based on request protocol (matches auth_token logic)

Tests: 53/53 pass.

Ready for re-review.

[mikolaj92]

@diegosouzapw

All points from the Gemini Code Assist review have been addressed:

• Module-level JWKS cache + getJwksClient helper (prevents recreating the client on every login)
• Token exchange fetch and .json() wrapped in try/catch with 10s timeout
• 5s timeout added to discovery fetch in both /login and /callback
• Email comparison made case-insensitive in oidcAllowedSubjects whitelist
• oidc_state cookie now sets secure dynamically based on request protocol (same logic as auth_token)

Tests: 53/53 pass.

Ready for re-review.

[mikolaj92]

I’ve addressed the points from your review in the latest commit. When you have a chance, could you please take another look? Thank you!

[diegosouzapw]

This PR is now behind release/v3.8.49 and shows conflicts — could you rebase onto the current tip? No competing OIDC work has landed, so the conflicts look like plain drift rather than anything superseding your change.

[diegosouzapw]

Validated in local merge-train on 192.168.0.113 @ 9d2b92a63acdf6915dbcb5d9ae7a4b18caf79d6d (FAST gates green: static + changed tests + vitest; today's full-suite parity ran in trains 4+5)