[Feature]: Add native OpenID Connect login

[madsbergstroem]

Related Problem

Fredy currently supports only local username/password login. This requires a separate credential even when an installation already has an OpenID Connect identity provider.

This is related to #362, but proposes native OIDC rather than trusting identity headers from a reverse proxy. Native OIDC keeps authentication inside Fredy's trust boundary and works independently of a specific proxy.

The configurable session TTL also does not currently remove the frequent-login problem completely: the session cookie uses settings.sessionTTL in lib/api/api.js, while authorization separately enforces a hard-coded two-hour maximum in lib/api/security.js.

Proposed Feature

Add optional, standards-based OpenID Connect login using Authorization Code Flow with PKCE.

Suggested first scope:

1. Configure an issuer URL, client ID, client secret, and redirect URL through server-side configuration/environment variables.
2. Use issuer discovery (.well-known/openid-configuration) and the provider's authorization, token, JWKS, and optional end-session endpoints.
3. Add a login endpoint that stores cryptographically random state, nonce, and the PKCE verifier in the server session before redirecting to the identity provider.
4. Add a callback endpoint that exchanges the code and validates the signature, issuer, audience, expiry, state, nonce, and PKCE challenge before creating the normal Fredy session.
5. Identify users by the immutable (issuer, subject) pair. Do not use proxy headers or email alone as the authentication key. Account linking or auto-provisioning should be explicit and disabled by default.
6. Keep local password login as a fallback by default, with an option to hide/disable it only after OIDC has been verified.
7. Derive Fredy's hard session expiry from the same sessionTTL setting used for the cookie so both checks agree.

Possible endpoints:

• GET /api/login/oidc
• GET /api/login/oidc/callback
• existing POST /api/login/logout destroys the local session and may optionally redirect through the provider's end-session endpoint

Security and Failure Behavior

• OIDC is opt-in; incomplete configuration must leave the existing password flow unchanged.
• Discovery, token exchange, or validation failures return to the login screen without creating a session.
• Callback state is single-use to prevent replay.
• Client secrets remain server-side and are never returned by the settings API.
• Unknown subjects are rejected unless an administrator explicitly enables a constrained provisioning policy.
• Existing local admin access remains available during setup to prevent lockout.

Acceptance Tests

• successful discovery, PKCE login, callback validation, and Fredy session creation
• invalid/replayed state and invalid nonce are rejected
• wrong issuer, audience, signature, or expired token is rejected
• existing (issuer, subject) mapping resolves the correct Fredy user
• unknown users are rejected by default
• password login still works when enabled and when OIDC is unavailable
• configured session TTL is honored consistently by both cookie and authorization checks
• logout destroys the Fredy session

Benefits

• one identity and MFA policy across self-hosted services
• no reverse-proxy-specific trusted-header contract
• no repeated Fredy password entry while an identity-provider session is already active
• a generic implementation compatible with any standards-compliant OIDC provider

Additional Context

If this direction matches the project, I am happy to help with an implementation PR after the account-linking/provisioning policy is agreed.