The PoC runs on Hanko. The MVP needs to run on whatever the customer already operates — most often Supabase or a custom Postgres. We treat that as an SPI problem, not a fork problem.
What the SPI guarantees
- Verify a session or bearer token and return normalized identity claims.
- Expose a FlowConfig the UI can render (API URL, cookie name, logout path, SDK script).
- Support a feature-flag surface so the UI can hide or show registration entry points.
- Preserve security invariants: signed cookies, JWKS-based JWT validation, allowlisted origins.
Backends on the roadmap
- Hanko — the PoC. Credentials, JWKS, WebAuthn out of the box.
- Supabase — common in greenfield products; SPI maps Supabase Auth tokens to
IdentityClaims. - Custom Postgres — for teams that already manage users, passwords or passkeys themselves; the SPI wraps their existing storage.
What does not change when you swap backends
- The IdP — SAML and OIDC endpoints behave identically.
- The hosted UI — same login, logout and error pages.
- The security checklist — every backend must satisfy the same JWT, cookie and origin checks.
What does change
- The adapter package implementing
CredentialVerifier. - The browser bundle URL pointed to by
SDKScript. - Operational concerns — where users live, how passwords or passkeys are stored, how Admin APIs are reached.
