What SuperTokens Is and Who It's For
SuperTokens is an open-source authentication solution built around one strong opinion: session management should be secure by default and owned by you. Rather than shipping a single monolith, it splits into three cooperating layers — a frontend SDK, a backend SDK, and the SuperTokens Core, an HTTP microservice that holds the auth logic and talks to your database. You add authentication by enabling modular "recipes" for the login methods you actually need, then wire in either the pre-built UI or your own. The project positions itself as a developer-first alternative to hosted platforms, and its Core repository has drawn roughly 15k GitHub stars, signalling steady adoption among teams that want control without building auth from scratch.
It fits engineering teams that treat authentication as core infrastructure and want to keep user data inside their own systems. Startups running on Node.js, Python, or Go can stand up email/password or social login quickly, while regulated or privacy-sensitive teams can self-host the Core against their own PostgreSQL or MySQL and keep 100% of credentials in-house. Because the same recipes run on both the free self-hosted path and the managed cloud, a project can start self-hosted and later migrate — or vice versa — without re-architecting. It is a weaker fit for teams that want a fully managed identity platform with a large integration marketplace, or non-technical buyers who expect an enterprise IdP with turnkey federation.
Auth Recipes and a Session-Management Core
SuperTokens organizes capabilities as recipes you compose per application. The core recipes cover email/password sign-up and login, passwordless (magic-link and OTP over email or SMS), and third-party/social login through providers like Google, GitHub, and Apple. On top of these sit session management, email verification, user roles and permissions, account linking, multi-factor authentication, and multi-tenancy. Each recipe can be initialized independently, so a small app might ship only email/password, while a larger product layers social login, MFA, and per-tenant login methods. Both a pre-built, customizable UI and a fully custom-UI path are supported, letting teams trade speed for control — drop in React components to launch fast, or drive the APIs directly for bespoke flows on web and mobile.
Session management is where SuperTokens concentrates its attention, and it is the clearest reason to choose the tool. Sessions use short-lived access tokens paired with rotating refresh tokens: every time a refresh token is spent, it is replaced, which lets the Core detect token theft. If a stolen refresh token and the original are both used, SuperTokens can flag the reuse and revoke the entire session's tokens. Access tokens are verified quickly on each request, refresh happens through a dedicated backend endpoint, and tokens are stored in httpOnly cookies by default. The documentation frames this design as protection against common session attacks — XSS, CSRF, session fixation, and brute force — an area many hand-rolled auth stacks get wrong.
Self-Hosted vs Managed, SDKs, Multi-Tenancy and MFA
The two deployment paths share one codebase. Self-hosting means running the SuperTokens Core yourself — via Docker or a binary — connected to your own PostgreSQL or MySQL instance, with no cap on monthly active users and full data residency. The managed cloud runs the Core for you, trading operational work for a per-MAU fee. On the backend, official SDKs cover Node.js (with guides for Express, Fastify, NestJS, Next.js, Hapi, Koa, and AWS Lambda), Python (FastAPI, Flask, Django), and Go. If your backend framework isn't directly supported, you can run the SDK as a standalone auth server. The Core is licensed Apache 2.0 outside its enterprise directory, so the essentials stay genuinely open-source.
On the frontend, React gets first-class treatment with pre-built UI components, while Vue, Angular, and vanilla JavaScript are served through a framework-agnostic SDK, and mobile apps integrate via the custom-UI APIs. Multi-tenancy is a full recipe: each tenant can have its own login methods, third-party providers, user pool, and data isolation, all administered from a tenant-management view inside the user-management dashboard. Multi-factor authentication supports factors such as TOTP and OTP and can be required per tenant or per user. Roles and permissions are assigned through the dashboard or API. These enterprise-leaning capabilities exist natively rather than through plugins, though on the managed cloud several of them — MFA, account linking, multi-tenancy — are billed as paid add-ons rather than included in the base tier.
Developer Experience and Pricing
Developer experience leans on the recipe model and copy-paste quickstarts: pick your frontend and backend, initialize the recipes you want, and the pre-built UI plus a hosted or self-hosted Core get a login flow working with modest code. The documentation is task-oriented and organized by recipe, and the user-management dashboard gives a browser view of users, roles, and tenants without building admin screens. The trade-off is architectural surface area — you reason about three layers and their frontend-driver and core-driver interfaces, and self-hosters also own the Core service and its database. Teams comfortable operating a small service tend to find the model clean; those wanting zero infrastructure will prefer the managed cloud or a fully hosted competitor.
Pricing is deliberately split. Self-hosting is free with no MAU limit — you pay only for the infrastructure you run. The managed cloud is free under 5,000 monthly active users, then charges $0.02 per MAU. Several capabilities are priced as add-ons: multi-factor authentication at $0.01/MAU (minimum $100/month), account linking at $0.005/MAU (minimum $100/month), and additional dashboard users at $20/user/month after the first three. Multi-tenancy and SSO, machine-to-machine auth, unified cross-domain login, and the Attack Protection Suite are enterprise features quoted through sales, with discounts noted above 10,000 MAUs. The headline advantage is that the core authentication and session logic carry no license fee at all when you self-host, which is unusual among comparable commercial-backed auth tools.
Limitations and When Auth0, Clerk, or Keycloak Fit Better
The limitations follow from the focus. SuperTokens' ecosystem — pre-built integrations, community size, and third-party tutorials — is smaller than Auth0's or Keycloak's, so unusual identity providers or niche enterprise connectors may need custom work. The pre-built UI is React-centric; Vue and Angular teams lean on the generic SDK or custom UI, making DX uneven off React. Self-hosting shifts real operational responsibility onto you: running, upgrading, and scaling the Core plus its database is work that fully managed platforms absorb. And on the managed tier, the features that make an auth platform enterprise-ready — MFA, multi-tenancy, account linking, attack protection — arrive as paid add-ons or sales-quoted tiers, so the "free under 5K MAU" headline narrows once those are switched on.
Auth0 is the better pick when you want a mature, fully managed platform with a deep marketplace of integrations, extensive enterprise SSO, and rules/actions extensibility, and you accept per-user pricing for that breadth. Clerk suits product teams — especially React and Next.js shops — that prioritize polished, drop-in UI components, organizations, and user-management UX over self-hosting and data ownership. Keycloak is the stronger choice for organizations that need a full open-source identity provider with rich federation, LDAP/Active Directory integration, fine-grained admin, and standards like SAML and OIDC across many clients, and that have the operational capacity to run it. SuperTokens sits deliberately between them: more open and self-hostable than Auth0 or Clerk, more narrowly focused on auth and sessions than Keycloak.
Verdict
SuperTokens is a strong choice for developer-led teams that want secure authentication and, above all, robust session management without surrendering their user data or paying per active user. Its rotating-refresh-token model with theft detection is a genuine differentiator, the recipe architecture keeps the surface area proportional to what you enable, and the Apache-2.0 self-hosted path gives real ownership rather than a trial that expires into a paywall. For a Node.js, Python, or Go backend paired with a React frontend, it can get a hardened login flow into production quickly and cheaply, and the managed cloud offers a low-friction on-ramp for teams that would rather not operate the Core themselves.
Weigh it against three questions: are you willing to run a small service and database if you self-host; is your frontend React-friendly; and do the enterprise features you need sit in the free tier or behind add-ons and sales? If self-hosting or the sub-5K-MAU cloud tier covers your needs and React is in your stack, SuperTokens is one of the best-value, most privacy-preserving auth options available. If you need a vast integration marketplace, turnkey enterprise federation, or a fully managed platform with no infrastructure of your own, Auth0, Clerk, or Keycloak will likely serve better. For everyone else, SuperTokens earns a place on the shortlist.
