Teams that rule out Keycloak still have open-source authentication options worth a serious look, and two names come up repeatedly: SuperTokens and Hanko. Both are open source, both can be self-hosted, and both offer a managed cloud for teams that would rather not run the backend themselves. The similarity mostly stops there. Hanko is passkey-first, designed from the ground up around WebAuthn and FIDO2. SuperTokens is a full-stack authentication platform where passkeys are one capability among many, sitting alongside multi-tenancy, session security, and enterprise SSO.
\nThis comparison covers where each one fits, what the licensing actually obligates, and roughly what the bill looks like at scale.
\n| \n | SuperTokens | \nHanko | \n
|---|---|---|
| License | \nApache 2.0 | \nBackend API AGPL v3; Elements + SDKs MIT | \n
| Self-hosting | \nFree, unlimited users | \nFree, unlimited users (AGPL v3 applies to backend) | \n
| Free tier (cloud) | \n5,000 MAU | \n10,000 MAU | \n
| Paid tier (cloud) | \n~$0.02/MAU above free tier | \n~$0.01/MAU above free tier | \n
| Passkeys / WebAuthn | \nSupported | \nPrimary focus, FIDO2-certified | \n
| Multi-tenancy | \nFirst-class, API-driven | \nBasic, developing | \n
| SAML SSO | \nNative (SAML recipe, paid feature) | \nNative | \n
| SCIM | \nNot native (build on top) | \nNo | \n
| Session security | \nRotating refresh tokens, theft detection | \nStandard sessions | \n
Hanko treats passkeys as the default enrollment path, not an add-on. Its WebAuthn implementation covers platform authenticators (Touch ID, Windows Hello) and roaming authenticators (hardware security keys), supports cross-device flows, and falls back to email one-time codes when a passkey is not available. The underlying passkey infrastructure is FIDO2-certified, which is the credential that matters most when a security review asks who actually built the WebAuthn layer.
\nThe sharper differentiator is the Hanko Passkey API, a standalone product. It exposes a lightweight HTTP API and an SDK for adding passkeys to an authentication stack that already exists, whether that stack is Firebase, Auth0, or something custom. It handles both first-factor passkeys and second-factor WebAuthn, including hardware keys, without forcing a full migration off the current provider. SuperTokens has no equivalent bolt-on passkey product.
\nSuperTokens does support passkeys through standard WebAuthn, and for a team already on SuperTokens that is usually enough. The distinction is one of focus rather than capability: passwordless UX is Hanko’s core product, whereas for SuperTokens it is one recipe inside a broader platform. Full docs for the standalone product live on the Hanko Passkey API page.
\nLicensing is where the two projects diverge most, and it deserves more than a one-line table entry.
\nSuperTokens ships under Apache 2.0, a permissive license. Building on top of it, modifying it, and deploying it as a closed-source service carries no obligation to release source code.
\nHanko splits its licensing, and the split is the important part. The backend API is AGPL v3, while Hanko Elements and the JavaScript SDKs are MIT-licensed. The MIT components are the pieces that get embedded in the frontend, so those carry no copyleft at all. The AGPL v3 obligation attaches only to the self-hosted backend: modifying that backend and running it as a network service triggers the network copyleft clause, which requires publishing the modifications. A team that self-hosts Hanko unmodified is unaffected. A team that forks and alters the backend for a networked service takes on the AGPL obligation. Hanko Cloud sidesteps the question entirely, at the cost of the infrastructure dependency that self-hosting was meant to avoid.
\nFor organizations with a strict policy against copyleft anywhere in the stack, Apache 2.0 is the safer default and removes the analysis entirely. For everyone else, the practical exposure comes down to a single question: does the backend get modified or not.
\nFor B2B SaaS, the balance tips toward SuperTokens.
\nMulti-tenancy is first-class in SuperTokens: isolated user pools per tenant, per-tenant login methods and SSO, data isolation between tenants, all driven through the API. Role-based access control is built in through its user-roles recipe. Session security is the standout feature, with rotating refresh tokens and token theft detection modeled on the OAuth 2.0 specification, an area where most authentication providers stop at basic session handling.
\nHanko’s multi-tenancy is still developing and is not yet comparable for a platform that needs to onboard many isolated business customers. Both products support SAML natively. SuperTokens has a first-party SAML recipe (Core 12.0+, Node.js and Python SDKs, listed as a paid feature in its docs), and its older SAML Jackson (BoxyHQ) route is now documented as legacy. Hanko supports SAML on its Pro plan as a $49/month per-connection add-on. Neither product ships native SCIM. SuperTokens’ own guidance is to build SCIM endpoints on top of it, and Hanko has no SCIM story at present.
\nSuperTokens is also highly customizable. Its override system lets you modify any backend or frontend function, such as sign-up, sign-in, or session creation, directly in your own code, without routing logic through webhooks. Hanko typically extends behavior via webhooks, which adds a network hop and an external endpoint to maintain, and on Hanko Cloud webhooks are only available on the paid Pro plan, not the free Starter tier.
\nThe takeaway is clean: SuperTokens is the stronger fit for multi-tenant B2B SaaS, and Hanko is aimed squarely at B2C passwordless-first consumer apps.
\nThe figures below are estimates for illustration, not vendor quotes. Both providers price the managed cloud per monthly active user above a free tier, and both may layer add-ons or a base subscription fee on top, so treat these as directional.
\n| MAU scale | \nSuperTokens Cloud | \nHanko Cloud | \n
|---|---|---|
| 5,000 | \nFree | \nFree | \n
| 10,000 | \n~$100/mo | \nFree | \n
| 50,000 | \n~$900/mo | \n~$400/mo | \n
| 100,000 | \n~$1,900/mo | \n~$900/mo | \n
| 500,000 | \n~$9,900/mo | \n~$4,900/mo | \n
SuperTokens cloud is free under 5,000 MAU, then roughly $0.02 per MAU beyond that. Hanko cloud is free under 10,000 MAU, then roughly $0.01 per MAU, half the per-user rate at every paid tier. SuperTokens prices some capabilities, notably MFA and account linking, as paid add-ons, so a realistic invoice can sit above the raw per-MAU line. Hanko’s Pro plan may carry a base subscription fee on top of the per-MAU rate, which matters most at low volumes where the fixed cost dominates.
\nThe number that reshapes the comparison for early-stage teams is Hanko’s Startup Program: up to 1 million MAU free for qualifying startups, in place until the company reaches roughly $500k in ARR or raises more than $1 million in funding. For a pre-revenue consumer app, that keeps the authentication cost line at zero well past the point where most providers begin charging. It is worth putting on the table early rather than treating it as fine print, because it changes the total cost picture materially for the exact stage of company Hanko targets. Details sit on the Hanko Startup Program page.
\nSelf-hosting is free on both sides. There, cost is not the differentiator at all; licensing is.
\nSuperTokens ships pre-built UI components that are React-first and tightly coupled to its backend SDK, which handles the full authentication flow with minimal wiring. SDKs exist for other frontends, but the drop-in component experience is strongest in React and Next.js, where a working login flow comes together in minutes.
\nHanko takes a framework-agnostic route. Hanko Elements are native custom elements (Web Components), so they drop into Vue, Svelte, plain HTML, or React without a framework-specific adapter. For any frontend that is not React, that difference removes a genuine integration hurdle rather than a cosmetic one.
\n