Neon Law Navigator speaks the standard Authorization Code + PKCE flow against the provider (/auth/login →
/auth/callback) and discovers every endpoint from <issuer>/.well-known/openid-configuration, so no provider URL is
hard-coded. Worked examples for Keycloak, Google, Auth0, and Okta live in .env.example.
Why we delegate rather than store. A legal-services portal holding its own password hashes would own a breach
liability, a reset / MFA / lockout system to build and operate, and an account-recovery support burden — none of which
serve the mission. Delegating to a provider that already does identity well keeps that surface off our plate, and the
identity/authorization split keeps it clean: the provider asserts only who you are (a stable sub and an email),
while your persons row owns what you can do (the single role). Granting or revoking access is one SQL statement,
never a provider reconfiguration — see docs/oidc.md for the full model.
Email/password without Google — bring a provider that hosts its own login. The person a clinic serves may have no
Google account, and "Sign in with Google" cannot be the only front door of a public legal-services portal. Any standards
OIDC provider that hosts its own email/password login page works with the env-swap above and zero Neon Law Navigator
code changes — because email/password is a feature of the provider, not of Neon Law Navigator. Keycloak is the
same open-source IdP the local KIND loop already runs; it serves email/password, self-registration, password reset, and
email verification from its own hosted pages, runs in your cluster with no per-user fee, and is the recommended
no-Google path. Auth0 / Okta are hosted SaaS equivalents: same four env vars, same redirect flow, their own login +
reset pages.
GCP Identity Platform — the Google-managed option. If you want Google to own the account store (NeonLaw's own prod
choice — see docs/gke-prod.md), Identity Platform is Google's customer-identity service, with
multi-tenancy that maps one tenant per white-label client. One honest caveat to plan for: its first-party
email/password is the client-SDK + ID-token-verify model (tokens issued by https://securetoken.google.com/<project>),
a different integration than the pure redirect env-swap above — follow Google's setup for it. For the shortest no-code
email/password road, a hosted-login IdP like Keycloak is the simpler choice.