Two years ago, your Auth0 bill was a few dozen dollars a month. Today that number might be several hundred, or more.
It is not because your user base grew dramatically. It is because after Okta acquired Auth0, the pricing structure was quietly rebuilt. The free tier dropped from unlimited MAUs to 7,500 monthly active users. Beyond that, you pay on a tiered scale. Add B2B features, Organizations, or MFA (things most products eventually need) and you jump to an even higher plan. Many teams end up paying a substantial “auth tax” before their product has made a single dollar.
The money is not even the whole issue. The deeper problem is that your user data, your authentication logic, your entire session management: all of it lives on a platform you do not control. If Okta reprices again tomorrow, you either accept it or go through a painful migration.
That feeling is familiar to a growing number of engineering teams.
Four Different Answers to the Same Problem
The authentication market has four main approaches, each reflecting a different philosophy about ownership and control.
Auth0 is the “managed everything” option. You do not touch the infrastructure. Features work out of the box, documentation is thorough, and SDK coverage is broad. The cost is that your user data lives on Okta’s servers, pricing is layered by feature tier, and the deeper you integrate, the harder you leave. It is a textbook vendor lock-in: the better the product feels, the more expensive the exit.
Firebase Authentication makes sense if you are already deep in the Google ecosystem: Firestore, Cloud Functions, Firebase Hosting. Within that stack, the auth integration is smooth. But the product was designed to serve Google’s infrastructure, not yours. User data goes to Google. The management UI is sparse. Customization is limited. For teams that do not want to go all-in on Google, Firebase Auth is a convenient on-ramp with a less obvious exit. Email and social login are free, but phone verification caps at 10,000 verifications per month before you pay, and that ceiling arrives quickly at any meaningful scale.
AWS Cognito is the most “technical” option of the three. The first 50,000 MAUs are free, then roughly $0.0055 per MAU after that, which is considerably cheaper than Auth0 at scale. But cheap has a cost. Cognito has a steep learning curve. User Pools and Identity Pools are two overlapping concepts that consistently confuse developers. Configuration options are excessive. The UI is widely considered poor, and the SDKs have a reputation for being counterintuitive. The migration situation is the real trap: Cognito stores passwords in its own format and does not export password hashes. Teams that decided to leave Cognito have described discovering that every user would need to reset their password. There is no other path out.
Then there is SuperTokens.
—
What SuperTokens Actually Is
SuperTokens is an open-source authentication framework. You can self-host it on your own servers, or use their managed cloud. The self-hosted version is free: no MAU limits, no feature tiers, MIT license, code on GitHub.
It handles email and password login, social login (Google, GitHub, Apple, and others), passwordless flows (Magic Links, OTP), session management, MFA, and multi-tenant B2B setups. The core service is written in Node.js. SDKs cover Node, Python, Go, and Java. Frontend support includes React, Vue, Angular, and native mobile.
Self-hosting means your user data stays in your own database. PostgreSQL or MySQL, your choice. The auth service runs in your own container. You can read the code, modify it, and control the entire stack.
That is a fundamentally different kind of choice.
—
Side-by-Side Comparison
Here is how the four options stack up on the dimensions that tend to matter most when making a switching decision:
| Feature | Auth0 | Firebase Auth | AWS Cognito | SuperTokens |
|---|---|---|---|---|
| Free MAU limit | 7,500 | Unlimited (email/social) | 50,000 | Unlimited (self-hosted) |
| Cost beyond free tier | Tiered, grows fast | Pay per feature | ~$0.0055/MAU | $0 (self-hosted) |
| Where data lives | Okta servers | Google servers | AWS servers | Your own |
| B2B / multi-tenant | Paid feature | Not supported | Limited | Open-source version |
| MFA | Paid feature | Basic support | Supported | Open-source version |
| Difficulty leaving | High | Medium-high | Very high | Low |
| Custom UI | Restricted | Restricted | Very restricted | Full control |
| Open source | No | No | No | Yes (MIT) |
The table is a starting point. What actually drives the decision is your answer to one question: how much does owning your authentication stack matter to you?
—
What Self-Hosting Actually Costs
“Self-hosted” sounds like you are taking on more operational burden. That concern is worth taking seriously, so here is what running SuperTokens actually looks like.
The core SuperTokens service is a Docker container. Memory footprint is around 200–300MB. CPU usage is low. A $10/month VPS or a small task in your existing container cluster handles it without issue. For the database, SuperTokens uses your existing PostgreSQL or MySQL instance, with no separate managed database required.
For a team that already has servers, the marginal cost of adding SuperTokens is close to zero. You are adding one container.
You do take on responsibility for updates, backups, and monitoring. That operational overhead is real. But when teams compare it against an Auth0 bill that starts climbing once they pass 10,000 MAU, the trade often looks reasonable.
—
Migrating from Auth0
SuperTokens provides a migration tool built around “lazy migration.” You do not need to export all users at once or force password resets. Instead, you configure SuperTokens to handle login. When a user authenticates with their existing password, SuperTokens validates it against Auth0’s API, then writes that user into its own database. Users never see a reset prompt. Migration happens gradually, one login at a time.
This is a sharp contrast to leaving Cognito. Because Cognito does not export password hashes, lazy migration is effectively impossible. Most teams that left had to force every user through a password reset.
Auth0 migrations do have complexity. If you have built significant logic in Auth0 Rules or Actions, that code needs to be ported to SuperTokens’ equivalent hooks. If you use Auth0 Organizations heavily, the tenant model is different and requires careful mapping. There is no zero-cost migration, but SuperTokens has put more thought into the exit path than most alternatives.
—
Who Should Actually Consider This
Self-hosting is not the right answer for everyone.
If you are a two- or three-person team without a stable server setup, the free tier of Firebase Auth or Auth0 is probably the pragmatic choice. Get the product running first. Revisit this when the auth bill becomes a real constraint.
If your application is already deep in AWS and you went in knowing Cognito’s exit limitations, Cognito’s pricing advantage at scale is real. The math just works if you accept the trade-off.
SuperTokens is worth serious consideration if you fit a few criteria: you already have a server or container environment where adding one more container is not a burden; your product is a B2B SaaS where multi-tenant isolation is a real requirement; you have a principled position on where user data lives and do not want to send it to a third-party platform; or your user base is growing and you can see what the Auth0 cost curve looks like over the next two years.
For those teams, SuperTokens self-hosted delivers the full feature set, including B2B and MFA, without the recurring bill.
—
A Few Things Worth Knowing
SuperTokens’ management dashboard is noticeably simpler than Auth0’s. The functionality is there, but the polish is not at the same level. If you are used to Auth0’s admin console, the initial adjustment is real.
The community is smaller. Auth0 has years of Stack Overflow coverage that SuperTokens cannot match. SuperTokens has an active Discord and reasonable response times, but the depth of coverage for edge cases is different.
The SuperTokens cloud offering (for teams that prefer not to self-host) is priced below Auth0, but it is still maturing. It is not as feature-complete as the self-hosted version.
And SuperTokens is a smaller company. Open-source projects can lose momentum. MIT licensing means you can fork and maintain it yourself if that ever happens, but it is a factor to keep in mind before you commit.
—
The Question Before You Switch
Authentication is the security layer your application is built on. Swapping it out is not like updating a dependency. It touches passwords, session management, and permission checks. An error in any of those places is more consequential than most other bugs.
Before committing to a migration, ask yourself what is actually driving the decision. Is it the bill? The ownership question? A specific feature gap? The answer shapes whether SuperTokens is the right fit or whether a different adjustment makes more sense.
More teams are choosing SuperTokens not because it is more polished than Auth0, but because it takes the ownership question seriously. In an environment where SaaS pricing has become harder to predict, that is worth something.
[SEO]
seo_title: SuperTokens vs Auth0: Open Source Self-Hosted Authentication Compared 2026
seo_desc: Auth0 pricing increased? We compare SuperTokens, Auth0, Firebase Auth, and AWS Cognito to help you decide whether self-hosting your authentication makes sense.
seo_kw: SuperTokens, Auth0 alternative, open source authentication, self-hosted auth
[/SEO]
Related reading
- Self-Hosted Auth for Developers: Better Auth vs Authelia vs Supabase Auth
- OpenObserve vs SigNoz: Which Self-Hosted Observability Stack Fits a Small Team?
- n8n vs Activepieces: Choosing an Open-Source Workflow Automation Tool for Self-Hosted Teams
- Authentik Alternatives: Self-Hosted Identity Providers Compared (Authelia, Keycloak, Zitadel)
Stay updated with our latest AI insights
