ADR-0001 — OIDC via oauth4webapi

Full record: docs/adr/0001-oidc-via-oauth4webapi.md.

Decision: implement the OIDC protocol with oauth4webapi, wrapped by @smplcty/auth/oidc’s OidcHandler.

• Not Auth.js — it brings a parallel identity/session/authz model (accounts/sessions tables, its cookie, middleware) that conflicts with our sessions + RLS; we’d use only the protocol slice (which is oauth4webapi) while paying for a framework we’d ignore.
• Not a hand-rolled @smplcty/oidc — that package was a thin jose wrapper; oauth4webapi subsumes it and adds the full flow. It is deprecated.
• OTP / dev-OTP stay in the method router — oauth4webapi is OIDC-only.
• The consumer owns the transient login-state store and the callback route; the client_secret lives in the app’s secret store, not auth_domains.

Out of scope: CRM / data-connection OAuth (Salesforce, HubSpot in salez1) — delegated authorization whose outcome is a stored, refreshable per-tenant token, app-owned, outside @smplcty/auth/auth_domains. It can use the same oauth4webapi, but shares none of the sign-in config, sessions, or schema.

The investigation behind this (the legacy production-now OIDC was never wired in prod; Clyde uses Microsoft Entra ID) is recorded in the ADR.