Most auth SDKs are written once per language and copy the same orchestration logic everywhere. We are inverting that: one TypeScript core for the browser, with thin adapters per provider and per language for everything else.
Browser side
- authkit-ts core — the flow state machine: start, challenge, verify, complete, error.
- Provider adapters — bind the core to a credential backend (Hanko first). The adapter knows the backend; the core does not.
- Distribution — UMD bundle published as
ui8kit.jsnext to AuthKit; npm package onnpmjs.com/org/authfly.
Backend side
- Go — first-class, since the IdP is Go. Reuses
corecontracts. - TypeScript / Node — server-side helpers for OIDC clients and session validation.
- Python, PHP, .NET — thin SDKs over the same Management API and OIDC endpoints.
Adapter pattern
Every adapter implements three functions: turn user input into a credential challenge, verify the response, and surface a normalized identity to the caller. The orchestration loop stays in the core, so behaviour is identical across stacks.
Why this beats per-language rewrites
- One bug-fix lands in one place.
- Behaviour parity is testable by replaying the same flow against every adapter.
- New providers ship as adapters, not as forks.
