Why Auth Fly: own your IdP, skip the telemetry
A self-hosted SSO construction kit, built around one principle: identity belongs on your own origin, with no third-party update channels in the critical path.
Journal
Notes on building Auth Fly: protocol design, UI migration from Hanko Elements to UI8Kit, adaptive SDKs, the SSO SPI, and the pre-flight security checklist.
A self-hosted SSO construction kit, built around one principle: identity belongs on your own origin, with no third-party update channels in the critical path.
How a single signed idp_session cookie bridges SAML Service Providers and OIDC Relying Parties on the same Identity Provider — and why it stays simple.
A walk through the Auth Fly SAML implementation: AuthnRequest parsing, ACS pinned to SP config, XMLDSig with SHA-256 and RS256 — and the hardening still on the runway.
What a small OIDC provider looks like: Discovery, /authorize, one-shot codes, /token with no-store, /userinfo, /jwks — and the hardening list before public clients.
Replacing the third-party login web component with our own bundle — same UX, same i18n, same dark theme, served from the IdP origin with no CDN dependency.
Inside AuthKit: how Renderer, ViewConfig and StaticFS keep the hosted login UI provider-agnostic — and why the page itself never imports a credential backend.
Why the Auth Fly stack splits into core, authkit and authkit-hanko — and how that split lets us swap Hanko for Supabase or a custom Postgres backend without touching the UI or the IdP.
How AuthKit TS becomes a portable core for browser auth flows — and how per-provider, per-language adapters keep that core useful from React to Go to PHP.
How the CredentialVerifier contract becomes a Service Provider Interface — letting you swap the credential backend without rewriting the IdP, the UI, or the security invariants.
The full Auth Fly hardening list, in the open — what is already strong in the PoC, and the four staged wave of fixes that take us from PoC to a production-shaped MVP.