← Back to all posts

UI migration

From Hanko Elements to UI8Kit: a one-to-one migration

12 min

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.

The PoC originally embedded <hanko-auth> from a third-party bundle. It worked, but it tied the login screen to assets fetched from a domain we did not control and made theming a workaround instead of a feature. We migrated the entire surface to UI8Kit one-to-one.

Why migrate

  • Login is a security-critical page. Fewer origins, fewer scripts, fewer third parties.
  • UX consistency. AuthKit pages now share the same design tokens as the rest of UI8Kit.
  • Build hygiene. One ui8kit.js bundle, served from /static/js, versioned with the IdP.

What we kept

  • Email + passcode flow, identical to the previous UI.
  • WebAuthn / passkey support through the same backend contract.
  • Embedded i18n (English, Russian).
  • Dark theme toggle and reduced-motion defaults.

What changed under the hood

  • The browser SDK lives in authkit-ts; the Hanko-specific binding is a thin adapter.
  • AuthKit (Go + templ) renders the page and points the browser to SDKScript from FlowConfig — the page itself does not import Hanko.
  • Static assets ship through StaticFS(); nothing is fetched from a CDN.

Cost of migration

One person-week to reach feature parity, then a second week of polish. The biggest win is not visible: the login page is now boring HTML with one local bundle, which is exactly what we want for a security-critical surface.


Auth Fly logo

Auth Fly

Open auth construction kit

About Auth Fly