Implement the first OIDC authorization-code login flow
Implementation started. Use a synthetic standards-library local relying party for validation before modifying Kaukus. Initial claims are stable sub plus scope-controlled name/email, without asserting email verification; use configured persistent RS256 signing keys and retain configured retired public keys through token expiry. Build the first working OIDC authorization-code flow on top of committed project-scoped public/confidential client registrations (7d5363f). Reuse email-first browser authentication, revocable sessions, localized native forms, current account/credential checks, project assignments, restricted SQL entry points and synthetic fixtures. OIDC must not require identity-admin eligibility. Implemented first slice: - One explicitly configured issuer for the served identity realm. Publish discovery and public JWKS, plus authorize, token and UserInfo endpoints. Configure a durable signing key and kid outside source control; do not generate a new identity on each restart. Use a maintained JOSE/signing implementation rather than custom cryptography; propose RS256 for initial interoperability. - Support response_type=code, grant_type=authorization_code and mandatory S256 PKCE for both public and confidential clients. Public token requests use client_id without a secret; confidential clients authenticate with client_secret_basic. No implicit/password/client-credentials grants or refresh tokens. - Validate client, exact registered redirect URI, scope and bounded request parameters before any client redirect. Use standard OAuth/OIDC errors; never redirect to an unvalidated URI. Keep state/nonce opaque and bounded. Bind single-use short-lived codes to issuer/realm, client, exact redirect URI, subject, authentication time, requested scopes, nonce, PKCE challenge and credential/session state. Store code/access-token digests, not bearer values. Handle replay and concurrent redemption safely. - Extend browser login with opaque server-side authorization continuations, including session rotation, expiry, multiple tabs and safe recovery/registration behavior; never accept arbitrary return URLs. Reuse existing login/password/registration views and retain the normal standalone admin login behavior. Recheck active account, credential/session, client/project and active project assignment at authorization, code redemption and UserInfo. - Signed short-lived ID tokens use stable realm-local user IDs as sub, exact issuer, client ID as audience, exp/iat/auth_time and nonce when supplied. Opaque short-lived access tokens initially authorize UserInfo only, not Kaukus APIs or the prototype management API. Scope claims to openid/profile/email; do not claim email_verified=true without an actual verification guarantee. Keep roles and organization claims out until the relying-party contract is agreed. - Confirmed by user: trusted, operator-registered first-party applications only, with no consent screen in this slice. Third-party applications may come later. Keep application trust/consent policy separate from public/confidential client type; do not treat lack of a client secret as lack of trust or automatically extend consent bypass to a future third-party registration path. Define supported prompt/reauthentication semantics and reject unsupported optional features rather than silently ignoring them. Third-party consent, external identity federation, refresh/offline access, API audiences, introspection/revocation endpoints and RP-initiated logout are later slices. Acceptance criteria: - A synthetic local relying party completes real authorization-code login with PKCE and validates discovery/JWKS/signature/issuer/audience/nonce before using UserInfo. Cover both client types, existing SSO sessions and non-admin project-assigned users. - Missing/invalid/replayed/cross-client codes, incorrect verifier/secret/redirect URI, disabled or revoked account/project/client/assignment, concurrent redemption and transaction failure fail safely without secret leakage or partial issuance. - No-JavaScript localized browser login, expired/multi-tab continuations and unchanged admin login are covered. Signing identity survives restart; retired public-key retention/rotation behavior is specified and tested as appropriate for the slice. - Unit, synthetic PostgreSQL/HTTP, real-browser relying-party integration and standard validation gates pass. Update authentication/project/architecture docs and correct stale documentation that still calls client registration deferred. Verified outcome: - Added discovery, JWKS, authorize, token and GET/POST UserInfo with first-party code/S256 PKCE, public and confidential Basic clients, scoped claims, 60-second one-use codes and five-minute ID/access tokens. No identity-admin eligibility is needed; live project/client/account/credential/session/assignment checks apply. - Added private session-bound continuation/grant/token/event tables and restricted client-secret/subject functions. Pending continuations transfer atomically through login rotation. A same-origin 200 continuation page with Refresh and native link avoids Chromium blocking POST-to-external redirect chains while preserving form-action self and no-JavaScript support. Password steps are continuation-bound; competing tab selections fail closed. - Added persistent PKCS8 RSA configuration and exclusive mode-0600 key generation; stable JWK-thumbprint kid, current/retired public-only JWKS, restart/rotation/key-permission tests and explicit local issuer/browser-origin compatibility checks. Canonicalize browser OIDC routes before issuing cookies; no backchannel redirects. - Verified code replay/concurrent redemption and rollback, scope/redirect/nonce/issuer/audience/signature boundaries, live revocation/expiry, confidential-secret rotation, aggregate committed peer-wide rate budgets and an in-flight logout regression. Session row locks prevent logout races; resume takes session-before-grant locks to match login transfer order. - Real Chrome relying-party tests use openid-client with explicit non-repudiation/signature checking, both client types, SSO, non-admin access, English/Norwegian/Danish transitions, hostname aliases, light/dark and JS on/off. Screenshots inspected. Existing admin/registration/reset browser journeys remain green. Validation passed on final implementation: cargo fmt --check, strict workspace/all-target/all-feature Clippy, cargo test --workspace --all-features, python3 dev/run.py test (seven new OIDC integration tests plus signing/CLI unit coverage), and python3 dev/run.py browser-test (existing preview/auth journeys plus four OIDC theme/JS relying-party cases). git diff --check passed. Added docs/oidc.md and updated README/authentication/project/architecture/frontend/development guides. Existing database diagrams remain explicitly bounded to the migration-0011 snapshot. Static review limitation: previous verified findings (peer-wide limits, advertised query mode, bridge test, issuer/browser mismatch) are fixed with regressions. Last review returned no verified findings but remained PARTIAL: the testing agent did not inspect service.rs; other categories reviewed all 31 diffs. No whole-project security approval or conformance certification is claimed. Runtime validation above was performed independently of static review. Changes remain uncommitted on feature/oidc-authorization-code. Kaukus and production services were not changed. Deferred: refresh/offline access, third-party consent/federation, CORS SPA support, API audiences and OIDC logout. Already-issued signed ID tokens remain valid until bounded expiry; external application sessions are relying-party-owned.
Checklist
5 of 5 complete- Agree first-party trust, first relying party, claims and signing-key lifecycle; document the supported OIDC subset.
- Implement and verify issuer/discovery/JWKS and persistent signing identity, reusing registered client configuration.
- Implement authorization with safe login continuations, SSO and project-access checks without requiring admin access.
- Implement and verify atomic single-use code redemption, client authentication, PKCE, ID/access tokens and UserInfo.
- Validate the full relying-party browser flow and failure/concurrency boundaries; update docs and pass project validation gates.