Alternatives for developer-friendly sign-in come in three kinds: open-source tools you can host yourself, auth bundled inside a backend or SaaS platform, and hosted identity platforms. Whichever you pick, ask before you sign whether you can export your users with their password hashes, or every user may have to reset their password when you move.
Sign-in is the one feature every user touches and nobody wants to rebuild. That's why switching authentication provider feels so risky, and why so many startups stay with the first one they picked, including Clerk, long after it stopped fitting.
If you're looking now, it's usually for one of three reasons: you'd like the user data in your own database, you're already using a backend that includes sign-in, or you're starting to sell to bigger companies that ask for single sign-on. Here are ten options in no particular order, list first, then how they group, then the question most teams forget to ask.
Ten sign-in tools, A to Z
Alphabetical, in no particular order. Product claims are each vendor's own; none of this is a security or compliance guarantee.
Appwrite Auth
Best for: Teams using or considering an open-source backend, with email, OAuth, SMS, magic links, MFA, teams and passkeys included in every deployment, self-hosted too (vendor wording).
Auth0
Best for: B2B SaaS teams that expect enterprise SSO, SCIM, multi-tenancy and fine-grained permissions, including for AI agents, from a long-established identity platform (vendor wording).
Better Auth
Best for: Developers who want sign-in to run inside their own app as a framework, adding passkeys, magic links, SSO, SAML and SCIM through plugins.
Descope
Best for: Teams that want to design signup, login, MFA, SSO and step-up journeys in a drag-and-drop builder, for customers, business customers, partners and AI agents.
Firebase Authentication
Best for: Mobile and web apps that want ready-made sign-in, with SDKs and an open-source drop-in sign-in UI that works across platforms.
Hanko
Best for: Anyone who wants open-source, passkey-first sign-in, self-hosted or on the vendor's cloud with the option to move between them; built in Germany with EU hosting (vendor claim).
Kinde
Best for: SaaS founders who'd like authentication, access management, billing and feature flags in one developer platform, with SSO for Entra ID and SAML (vendor wording).
Logto
Best for: SaaS or AI apps that need multi-tenancy, enterprise SSO and role-based access built on OIDC and OAuth, open source and ready to self-host (vendor claim).
Stytch
Best for: Developers who want to build sign-in through APIs and SDKs, with passkeys, SAML SSO, an embeddable admin portal and device-aware invisible MFA (vendor wording).
Supabase Auth
Best for: Apps on a Postgres backend that want sign-ups and logins tied to Row Level Security, with TOTP multi-factor and enterprise SSO through SAML.
Side-by-side summary
| Tool | Type | Good for |
|---|---|---|
| Appwrite Auth | Sign-in inside an open-source backend | Sign-in that comes with a self-hostable backend |
| Auth0 | Established identity platform | B2B SaaS needing enterprise SSO and SCIM |
| Better Auth | Open framework in your own code | Developers who want auth living inside their app |
| Descope | No-code login flows | Designing login journeys with drag and drop |
| Firebase Authentication | Google's mobile and web sign-in | Mobile and web apps already on Google's platform |
| Hanko | Open source, passkey-first | Passkey-first sign-in you can self-host or not |
| Kinde | Sign-in plus billing for SaaS | Products wanting sign-in and billing together |
| Logto | Open source, self-hostable | Multi-tenant SaaS and AI apps with enterprise SSO |
| Stytch | API-first auth | Building sign-in through APIs and SDKs |
| Supabase Auth | Sign-in inside a Postgres backend | Apps already using a Postgres backend |
Self-hosted, bundled with a backend, or fully hosted
Open source and self-hostable. Logto, Better Auth, Hanko and Appwrite Auth all say on their own pages that you can run them yourself. That's the route if you'd like your user table in your own database. They differ in shape: one is a framework living inside your code, one is passkey-first, one is built around multi-tenant SaaS, and one comes as part of a wider open-source backend.
Bundled with a backend or SaaS platform. Supabase Auth is part of the wider Supabase backend, so it makes most sense if you're already on it. Kinde pairs sign-in with billing and feature flags, which suits a SaaS founder who doesn't want three vendors for three jobs.
Hosted identity platforms. Auth0 is the long-established name, aimed at B2B SaaS with enterprise SSO and SCIM. Stytch is API-first. Descope lets you design login journeys with drag and drop. Firebase Authentication is Google's option for mobile and web apps, with a drop-in sign-in screen. If you're comparing whole backends rather than sign-in alone, my Supabase alternatives page covers that side.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
The password-hash question nobody demos
Most teams compare sign-in screens, social login buttons and SDKs. Very few ask how they'd leave, and that's where switching goes wrong.
Your users' passwords shouldn't be stored as passwords at all. NIST's digital identity guidelines on passwords describe the usual method: each password is combined with a random salt and run through a hashing function, preferably a slow, demanding one, so anyone who steals the hashes still faces a long guessing job. That's good security, and it creates a moving problem.
A hash can only move to a new provider if the old one lets you export it and the new one accepts that hash format. If either says no, every user has to reset their password on the day you switch, and some of them won't bother. So my advice, which is advice and not a NIST finding, is to ask every vendor two things before you choose: can I export my users including their password hashes, and which hash formats can you import? With the open-source tools, also ask whether the user data can sit in your own database from day one.
My advice for startups picking a sign-in provider
Start from where your app already lives. If you're on a backend that includes sign-in, use it unless there's a clear reason not to. If you want your users in your own database, shortlist the open-source tools. If you're selling to larger companies who'll ask for SSO and provisioning, one of the hosted platforms will save you building those features yourself.
Then check the exit before the entrance: run the password-hash question past your top two, and get the answer in writing. If you're also thinking about how your users protect their own accounts, my guide to authenticator apps covers the other side of two-factor sign-in, and my list of phone number verification APIs helps if SMS codes are part of your plan.
A cut-over plan for your user table
When you do move, don't flip everyone at once:
- Export your full user list, with password hashes if the old provider allows it, and keep a copy somewhere safe.
- Import a small test group into the new provider and check they can sign in with their existing passwords.
- Run both systems side by side for new sign-ups for a short period.
- Move existing users in batches, and send a clear reset email to anyone whose hash couldn't come across.
- Switch off the old provider only once nobody has signed in through it for a while.
Requirements for storing personal data vary by country, so check what applies to you with your data protection regulator.
Do you make an authentication or sign-in tool? Tool makers can ask to be considered for a featured place on this list.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
Can I move users between authentication providers without a password reset?
Only if the old provider exports password hashes and the new one accepts that hash format. Ask both vendors before you commit, or plan for users to reset their passwords.
Is open-source authentication safe to self-host?
It can be, but you take on updates, backups and security patches. If nobody on the team can own that work, a hosted version is the safer choice.
What's the difference between an auth framework and an auth service?
A framework runs inside your own code and stores users in your database. A hosted service runs sign-in for you on its servers and you connect to it through an SDK or API.
Do startups need single sign-on?
Not at first. SSO usually becomes a need when you sell to larger companies who want staff to sign in with their own identity provider. Check a tool supports it before that first big deal.
What are passkeys?
Passkeys let people sign in with their device's fingerprint, face or screen lock instead of a password. Several tools on this list support them alongside passwords.
Should sign-in come from my backend provider?
If your backend already includes sign-in, using it keeps things simple. A separate provider makes sense when you need features the bundled version lacks, such as enterprise SSO.
