PoC живёт на Hanko. MVP должен запускаться на том, что уже эксплуатирует заказчик — чаще всего это Supabase или собственный Postgres. Мы рассматриваем это как задачу SPI, а не задачу форка.
Что гарантирует SPI
- Проверить сессионный или bearer-токен и вернуть нормализованные identity claims.
- Отдать FlowConfig, который UI сможет нарисовать (API URL, имя cookie, путь логаута, скрипт SDK).
- Поддержать поверхность feature flags, чтобы UI мог скрывать или показывать точки регистрации.
- Сохранить инварианты безопасности: подписанные cookie, JWT-валидация через JWKS, allowlist-ы origin.
Бэкенды в дорожной карте
- Hanko — PoC. Credentials, JWKS, WebAuthn из коробки.
- Supabase — частый выбор для greenfield-продуктов; SPI мапит токены Supabase Auth в
IdentityClaims. - Собственный Postgres — для команд, уже управляющих пользователями, паролями или passkey самостоятельно; SPI оборачивает существующее хранилище.
Что не меняется при смене бэкенда
- IdP — эндпоинты SAML и OIDC ведут себя одинаково.
- Hosted-UI — те же страницы входа, выхода и ошибок.
- Чек-лист безопасности — каждый бэкенд должен удовлетворять одним и тем же проверкам JWT, cookie и origin.
Что меняется
- Пакет адаптера, реализующий
CredentialVerifier. - URL браузерного бандла, на который указывает
SDKScript. - Операционные вопросы — где живут пользователи, как хранятся пароли или passkey, как добраться до Admin API.
