Hanko is an open-source authentication and user management backend, written in Go, that gives teams a self-hostable or fully managed alternative to Auth0, Clerk, WorkOS and Stytch for adding passwords, passkeys, MFA, social login and enterprise SSO to an application.

What it is

Hanko is an authentication and user management solution built around a Go backend API that handles login, onboarding flow states, user and session management, and JWT issuing. It describes itself as framework-agnostic and API-first, and it is built on privacy-first principles such as data minimalism and phishing resistance. The project ships as three main building blocks: the backend authentication API, the Hanko Elements web components for onboarding, login and user profile, and the hanko-frontend-sdk client package. A quickstart reference app and a set of framework example implementations live in the same repository.

The concrete problem it solves is replacing a paid identity vendor in the CIAM (customer identity and access management) layer of an application. Instead of wiring an application to a commercial auth service, a team can run the Hanko backend itself, or use Hanko Cloud as a managed backend, and connect its own frontend through the provided web components or SDK. It sits in the Go ecosystem on the server side, with npm-distributed frontend packages, and covers the authentication methods that would otherwise require several separate integrations: passwords and passcodes, passkeys and FIDO2, TOTP and security-key MFA, OAuth social sign-in, SAML enterprise SSO, and custom OIDC/OAuth connections.

Key capabilities

• Passwordless and password-based sign-in, including passkeys, passcodes, passwords, and passkey-only configurations.
• Multi-factor authentication through TOTP and security keys, with 2FA listed as a core topic.
• OAuth SSO with providers such as Apple, Google and GitHub, plus custom OIDC/OAuth connections.
• SAML Enterprise SSO for business customers.
• Hanko Elements, published as @teamhanko/hanko-elements, providing web components for onboarding, login and user profile that are customizable with CSS.
• A JavaScript client package, @teamhanko/hanko-frontend-sdk, for calling the API directly.
• Server-side sessions with remote session revocation, JWT issuing, webhooks, and i18n with custom translations.
• Configurable flexibility such as passkey-only, OAuth-only, and user-deletable passwords.

Who uses it and how

• Product teams replacing a hosted identity provider with an open-source backend they can run themselves, using the backend directory in the repository as the deployment entry point.
• Teams that prefer not to operate infrastructure, using Hanko Cloud as the managed backend while keeping the same API and web components.
• Frontend developers who want a drop-in login and profile experience, integrating @teamhanko/hanko-elements web components rather than building custom authentication UI.
• Teams building custom frontends against the API directly, relying on the documented onboarding and authentication flow states via @teamhanko/hanko-frontend-sdk.
• Evaluators and integrators who want to see the experience first, using the quickstart app, the framework examples in frontend/examples, the live example at example.hanko.io, or passkeys.io.

Getting started

The README points to two paths: run the project locally either bare metal, following the backend README to get it running for your own project, or with Docker. A hosted backend is available through Hanko Cloud at cloud.hanko.io, and the quickstart app provides a reference implementation of the full login experience.

How it compares

Hanko positions itself directly as an open-source alternative to Auth0, Clerk, WorkOS and Stytch, which are proprietary, vendor-hosted identity services. The difference the facts support is deployment and control: Hanko is available for self-hosting as well as as a fully managed service on Hanko Cloud, so a team can keep authentication data in its own infrastructure instead of a vendor's. Its privacy-first principles, including data minimalism, are stated as design goals rather than add-ons, and the cost model of self-hosting is therefore a matter of running the backend rather than paying per-user identity pricing.

When to use it — and when not to

Choose Hanko when the goal is a self-hostable or managed authentication backend for web applications that need passkeys, MFA, OAuth and SAML SSO behind one API and a reusable web component layer; a self-hoster must be prepared to operate the Go backend themselves, which is the trade-off for keeping authentication data in-house. It is a poor fit today for teams that need Organizations, Roles and Permissions, which are marked as in progress rather than shipped, or that need iOS, Android, React Native or Flutter SDKs, which are listed as planned. Two further caveats are visible in the facts: the licence is reported as NOASSERTION rather than a clear named licence, and the README excerpt provided is truncated, so the getting-started detail is thinner than the feature set implies.