I work at WorkOS and we naturally think AuthKit is the best solution. It's also free up to 1,000,000 users and supports advanced features like SAML/SCIM/RBAC/etc. https://AuthKit.com
Have you checked out Stytch? I'm more than a little biased as the founder but would love to hear any feedback you have if you do. I thought your blog post covered a lot of really important points that are often forgotten when evaluating auth.
We support both a user changing their own email and with our embeddable admin portal, you get an out of the box flow where your customers' admins can update the email (and any auth setting) for other team members.
SSOReady only does SAML. The rest of these are full identity solutions with the login box, email lifecycle, sessions, impersonation, users/orgs, RBAC, etc. Essentially "identity as a service" for your app.
It also seems like SSOReady is a yc pivot (single dev) that's just trying to clone WorkOS. Unclear if it's used by anyone in production yet.
You made it sound like it's a hobby project not ready for production — where do you see that in the README? Calling it a "WorkOS clone" because they mention it is an alternative also isn't fair — even if it solves the same problem! The fact that they previously worked on something else also doesn't work as an argument, not sure why you would present it as such.
Just be nice to each other, even when they're your competitors! It's not so hard.
I work at Pangea, and while I believe many of the other AuthN options listed are also easy to integrate into your apps, not many provide MFA and passkeys out of the box. Pangea offers MFA + passkeys out of the box and threat intel IP datasets to block bots from signing up / logging in. All of this comes out of the box :)
Stack Auth maintainer/co-founder here. Kinda disappointed by the lack of open-source solutions in this thread — if anyone's looking for managed auth like WorkOS/Clerk/Auth0, but wants it to be 100% open-source, you should give us a go. https://github.com/stack-auth/stack
Hi, blog post author here. This article is from Feb 2023, so quite dated at the moment.
I'll write an updated article for 2024 but as you've mentioned here, it's almost impossible to follow this landscape. So many solutions appeared during this time.
My recommendation right now would be to either:
- Use a reliable framework with a well-tested built-in solution like Rails/Django
- Choose WorkOS / AuthKit (1)
Some more thoughts:
- Clerk didn't turn out to what I thought when writing this article. Their offering is very much targeting the JS ecosystem, especially Next/Remix, it's not an universal solution.
- It's difficult to recommend hosted solutions when you see how much pricing changes even during 1.5 years. Like you decide on a solution then next year the company raises prices and you are stuck with it forever.
(1) Note for AuthKit: It's an amazing solution but it's a joke that users cannot change their emails. How can it be a production-ready solution, if it doesn't allow any app to offer email change for their users?
Clerk employee here - it's certainly the case that a lot of our users are JS ecosystem users, which is why those SDKs have received extra attention. That being said, I do want to note that we have greatly expanded the number of SDKs that we offer over the past year or so. I'm not sure which framework you were using when you tried it out, but we may have better support for it now! You can see all our supported SDKs if you scroll down in the docs: https://clerk.com/docs
Hey thanks for the shout-out. I work at WorkOS / AuthKit.
tl;dr - we know this feature is missing and we are working on it
Changing email address is of those simple sounding features that has a ton of complex edge-cases that are critically important to get right. The crux of it is how organization membership/invites and resource sharing typically works with unconfirmed email addresses in apps. What happens with the old email address? Can a different user claim it? Are you allowed to change your email address if your account comes from SAML/SCIM? If you get this behavior wrong, it will lead to inconsistencies that can even cause security vulnerabilities.
Solving this for thousands of different types of apps of course makes the problem significantly more complex. It turns out different developers actually want slightly different behavior, so we need AuthKit to be customizable to accommodate this. More than anything, want to avoid changing these APIs after launching them (even in beta) so there isn't developer thrash. We are working to make sure the solution is as complete as possible and that's taking longer than I would hope.
In the meantime we have some workarounds. e.g. popular apps like Cursor are built on AuthKit and work great.
Anyone can send me an email if you want to chat about this. We're also hiring if you want to work on it. :) mg@workos.com
- Beginning: My custom auth works great for last 7 years, but looking for auth provider in new project so I don’t have to “roll my own auth”
- Actual reviews: These are all awful, broken and/or incomplete. Clerk is expensive.
- Conclusion: Use clerk if you can afford it
We use PropelAuth, which doesn't get enough mentions in these types of comparisons.
I recently did a quick re-check of the landscape, and for our purposes, Propel still is the only provider that works. I was surprised to find that support for Machine-to-Machine API auth (ie., standard OAuth) isn't well supported.
Likewise, OIDC support is patchy amongst the other providers. I reached out to Clerk support, and for both these use cases, they weren't supported.
I'm not a huge fan of all the VC stuff, but Clerk gets kind of a bad rap. I get tired of hearing how it's just hosted JWTs or whatever their auth is wayyy more than that.
WorkOS always touts their 1,000,000 free users for Authkit...but you need to pay $100 for a custom domain. You're going to be paying for some of the features well before you get to 1,000,000 users. I've been coasting on Clerk's free tier with a custom domain for like 2 years...because let's face it I'm never getting 1,000,000 users.
Not trying to shill or anything but I forget that I use Clerk, which is kinda what I want I guess.
We took the Heroku approach. All apps get a free *.authkit.app domain for the hosted login page.
AuthKit never has any WorkOS branding. Clerk puts "Powered by Clerk" on your login page unless you pay. This feels gross. Imagine if Heroku/Vercel were injecting ads into your app?!
AuthKit has free MFA. I believe everyone should get secure auth. Clerk charges to enable MFA. They also charge for passkeys and features like impersonation. Why?
Custom domains cost us $ to run (we pay Cloudflare) so we charge for this. It's also designed for commercial apps. The authkit.app is great for any hobby app.
This isn't a criticism but feedback from someone that is looking for a 3rd party auth service.
I am starting up my own business, I have spent some time evaluating AuthKit and I can't justify investing time on it. Specifically, I want to target small to medium sized companies that want SSO built into my services.
The fact that the auth would be at an *.authkit.app domain is disconcerting, users would think they have been click-jacked because they have left the domain they were expecting. Your comment about custom domains costing because of Cloudflare is strange given how much CF charge verses the $99 per month cost you charge, there seems to be a big order of magnitude difference, since under the Pro plan they charge 10c per additional domain. Perhaps you have additional services behind that, but it seems strange:
https://www.cloudflare.com/en-gb/plans/
The "Powered By x" would actually be preferable, many people are used to seeing thing like that on payment screens.
Also, the SSO connectors being $125 per month per connection, rules out my target market. That is a lot in my market and it doesn't ease off as I grow, it's a fixed base cost. As I grow to 20-30 customers I'd be better off hiring a developer to implement the same features.
I get it that I am not the target market; that big businesses wouldn't bat an eyelid at that kind of costs. But for my purposes, I can't justify your costs. Good luck to you.
There are several open source options out there (several linked above) that could be a good fit for your business economics. I know lots of folks talk about Supabase and Auth.js on X.
If you have the time and patience, you can also certainly build it yourself. There's no miracles here, just complex engineering and solving a thousand edge cases.
If you decide to use open source, make sure you quickly update dependencies so you're always running latest. Ruby-SAML had a major vulnerability disclosed last month and thousands of apps were affected: https://workos.com/blog/ruby-saml-cve-2024-45409
The Clerk branding is a non issue really. I mean, you just use the components and remove it with CSS lol, easy peasy. Although, I left it on one of my apps because I actually thought it made it look more secure but that's just me. My users aren't in the "know" so ymmv.
Splitting hairs, but the authkit.app domain basically is an ad no?
Yeah, I agree on the MFA and Passkeys. Impersonation is a toss up for me, I understand where they're coming from but also would be nice if it was in the free tier.
Looking at the authkit docs, unless I'm using Next or Remix... I need to store the refresh token, manage refreshing the access token, verify the access token, manage revoking the session and deleting the cookies. Clerk does all that for me so that's a win in my book (I understand you folks are working on more SDKs, so that'll be cool).
I don't doubt that Authkit is good, and I like seeing the competition. Clerk has been good to me for quite some time now. I've had to go into their Discord a few times for help and they were awesome, so that's kept me around even through the problems I've had. I've never felt like I was getting inferior support for being a free customer. I guess I'm more ride or die for Clerk than I thought lol.
But hey, to your credit you've convinced me to try out authkit on my next project so that's a win for you there. I'm always open to seeing what's out there.
It's an old article, and things have changed quite a bit in the pricing and features landscape when it comes to auth. I'm working at SuperTokens, so here are some thoughts and updates from my angle:
- `create-supertokens-app` is primarily a learning tool to help you understand how SuperTokens works and how to best integrate it with your app. The reasoning behind this is fairly simple - apps usually don't start with auth as a first concern. It's added at some point, and in my opinion, having an example handy (especially in your stack or close to it) is one of the easiest methods to help you understand how to integrate SuperTokens in your app. The CLI tool isn't meant as a scaffold but can work as one. Although, I wonder - would a more barebones setup work as a scaffold better? It might be worth exploring.
- I'm not sure where the bundle size number (430kb) comes from, but our current version is nowhere near that.
- I agree that the NextJS example could be better. It's mostly just boilerplate, though, and it can be made to look better.
- I don't see why the 5 cookies are an issue, to be honest. Correct me if I'm wrong on this one, but I fail to understand how the number of cookies has security implications.
- I find myself disagreeing with most of the conclusion - SuperTokens isn't too different from how the classic SSR frameworks integrate auth - you still have to do all of that configuration just once.
Minor point, but the author says about Clerk that they’d glady pay 1% of revenue for a polished auth solution.
That might be true for a side project, but that would be an absurd figure for an established company. Can you imagine a company with $100M revenue paying Clerk $1M a year? I’d find that deeply concerning.
While I'd agree that $1M is a lot, it's not altogether that crazy. (Full candor: we are ourselves a managed auth company, so I naturally have a vested interest in people wanting to pay for auth)
We could start by drawing an analogy to another vendor: Stripe. Our company pays much more than 1% of gross sales to Stripe for handling our payments. I wince a little every time I see our revenue leaking out to them, but I also don't have a great alternative. It's basically fine, and it's just the cost of doing business.
Relatedly, if you're a $100M business, what alternatives do you have to Clerk (or equivalent vendors)? One option would be to run auth in-house. If you do that, you pretty quickly hit $1M in headcount costs alone by staffing ~3 engineers + ~1 product manager to build and maintain an auth service. (Bear in mind that the fully-loaded cost of a hire vastly exceeds base salary). I don't think many CFOs are going to lose sleep over the cost/benefit here.
And in practice, that's exactly where a lot of companies land. Lots of companies pay Auth0 seven figures annually. It's expensive, but it's still a pretty good deal for some companies.
Last I tried Clerk, it was completely broken if you had no internet access which makes local dev a massive pain if you are travelling for example. Is this fixed?
One thing I disagree with is the firebase recommendation. I’ve used it several times and it seems to consistently lead to misery. I haven’t worked with a single team in which everyone was glad they picked firebase. Auth has been part of the problem in several cases.
If you want to go with off the shelf features and behaviours, maybe you’ll be happy. React integration is definitely awkward as mentioned in the post.
I’m looking forward to the post on Ory. At the moment I use Clerk by default.
It’s possible to implement everything it does yourself, but it does such a solid job by default for such a low price that, unless your budget is $0, it’s hard to justify rolling your own. I believe they even have a fairly generous free tier, too.
That's really weird, I have created 5+ production application as part of my consultancy, out of which 2 are $1M+ ARR now. I am curious, what are the issues you ran into while using Firebase auth?
I should have prefaced this by saying if you follow the happy path, firebase auth is probably fine most of the time. But here are some issues I can recall (it has been a while too, so maybe some of this is fixed):
- No session management apart from the JWT
- No way to force-logout users across devices
- Can't easily track active sessions
- State sync across tabs can be weird
- 1000-byte limit for custom claims
- Claims require a token refresh
- No user impersonation
- RBAC is pretty miserable to implement with rules
- Auditing gets expensive quickly
- Auth emulator doesn't quite match production behaviour
- Quota limits for email sending are brutal
- Token revocation support isn't great
- Testing custom claims is messy
- Password policy customization doesn't seem to exist (maybe I'm bad at docs though)
- Backup/restore of auth is pretty ugly
- Probably not typical to need, but integrating with existing user databases is basically not a consideration in the design of the system, so glue code gets huge fast (think integrating with Stripe customers for example)
- Auth lifecycle events are pretty limited
- No support for custom auth providers
- Custom token signing is poorly documented and difficult to reason about
Most of this is due to firebase auth being opinionated. This is fine if you don't need it to be flexible.
I could also be behind the times, but this was my experience over many projects spanning many years, so I imagine it's probably similar today.
10,000 MAUs are now included in every plan. We also now offer "First Day Free", so if a user churns in their first 24 hours after signing up, they are never counted as active. For GenAI, this has led to 60-70% of sign ups never being charged as active users.
You could easily implement encryption on Supabase assuming you are doing server side / cookie auth, since you provide the storage adapter that actually saves it to and retrieves it from the cookies.
As far as random logouts — I assume the implementation used isn’t refreshing the JWT token, or they’re expecting longer supported refresh intervals. I haven’t had customers ask that their sessions don’t expire, so this hasn’t been an issue for me.
I’m a big fan of Supabase. I’ve written a Rails app that supports the same RLS that Supabase does and can interoperate with each other, and I think that’s a testament to its design. Simple and understandable, (mostly) single-concern abstractions that if you were to move off or self-host, you can take piecemeal with you.
In that regard, I don’t see the post-user-creation copying of the user data to the public table as lock-in… it’s trivial?
Today there are so many other solutions: Stytch, Descope, PropelAuth (For B2B companies), and others.
VCs went a bit ham on this category when Auth0 got bought. I sense that the general thought process was: Auth0 multi-billion dollar company -> Auth0 will become crappy under Okta > replace Auth0 and build a bit company.
What I need is something that has first class support for "guest" or "anon" accounts, that can easily be then converted to social login. E.g. a guest user starts using the app without any login wall, after some usage is promoted to login using google/github/etc to continue.
I recently made a hacky solution for that using Next Auth (which is now called Authjs) because the requirements changed up on me and it's literally the ugliest and hackiest piece of code I've written in a long while.
I hate it and I doubt I'm going to ever recommend Authjs to anyone.
Each user gets a token associated with them. On each request you first check if they are authenticated via your auth of choice. If so, you take the token associated with this auth from your database. If not, you take the token sent via cookie. If no token is available, you generate one and set it.
Then when a user "signs up" you do the same thing. If they sent a token via cookie, you associate this token with their auth in your database. If they somehow didn't have a token yet they were probably blocking cookies, but you can just generate a new one at that point.
If a user logs in again later while they already had a token you can choose to migrate all data from that token to their login token, so no data that was created prior to login gets lost.
The point is that there's essentially no difference between regular profiles and shadow profiles. Both are just profiles. And a profile can be authenticated with using its token, or using an associated auth provider.
I know this, but do you think all of these parts should need to be coded by hand? It's just a complete waste of time. That's what I meant by writing hacky and ugly code to achieve this.
Plus, in Next, there was no way to associate a token to a social login during the new login in the backend. The only way is to do it via a separate request in the frontend and then relogin the user.
I did the same thing a little while back and landed on using AuthKit (WorkOS) mostly because they offer a good free tier if you don't mind the authentication URL not having your domain.
Keycloak was mentioned, only very briefly. I've "had to" use it because it was chosen by my employer before I worked with them, but I've taken full ownership over installing and configuring it (a mix of helm values and follow up terraform for realms/roles/clients etc). Once you tame it, it's great. It's no way simple though. But I can't compare it in that respect to any of the others.
Am quite surprised at the auth issues apparent in Supabase considering the funding. I was looking at using this on my next project. Any official comments on the state of auth at Supabase? Anyone here had a good or bad experience with Supabase Auth?
Last year I went down a similar rabbit hole, and my conclusions were matched those in the article. If you have a project that you’re getting off the ground and don’t have funding for one of the more expensive options, you can either tie yourself to firebase or spend a lot of time configuring one of the open, self hosted options. Auth can be such a huge time sync even when trying to do “the right thing” of not rolling your own.
I was also similarly disappointed with the quality of Supabase’s auth offering considering all the praise I consistently see for Supabase on HN.
> I was also similarly disappointed with the quality of Supabase’s auth offering considering all the praise I consistently see for Supabase on HN.
Around the time you were trying it out, there were some issues with Supabase clients not authenticating properly in SSR environments like Next.js or Remix. I think those have been solved with the introduction of the `@supabase/ssr` library, and continuing to use a middleware for refreshing the session upon each request. This latter option was always available, but wasn't in the example, so I think a lot of folks didn't implement the auth middleware and thus didn't ever refresh their stored access token.
Particularly in the AI assisted era, I'm not sure I understand why you wouldn't just roll your own auth. Learn it once, use it everywhere. Best practices are well documented and now incredibly accessible via your LLM of choice.
You wouldn't just blindly implement what the LLM generates. You would use it more as an efficient way to go through all the necessary docs. From there you'd sanity check the recommendations and _then_ implement a solution, applying your judgment along the way.
is there any good solution for chrome extensions? clerk has a chrome SDK but documentation is sparse and OTP/vertification codes are not dispatched inside an extension popup for some reason.
There is an API to `signInWithCustomToken`[0] that makes it fairly straightforward to do from your client script.
The way I have it set up is:
- User clicks the Login action and is redirected to an app page which redirects to OAuth login
- User performs normal signup/login flow via the OAuth login and redirects back to the app page
- In my case, it is an SPA and I generate a custom token on the server side using the FirebaseAdmin SDK and write it to the page as a hidden `<div/>`
- The extension has a client script that loads for this page looking for this `<div/>`; when it shows up, it stores the token via the background worker
- User goes back to where ever the extension is loaded; now you can check with the background worker to see if it has a custom token and then use it to swap for an auth token
This only has to be done one time so it's not too onerous and quite seamless once you've set it up. This worked best for me since there are no restrictions once you can redirect to an app page for login and you don't have to fiddle around with figuring out the restrictions in Chrome extensions.
I use Firebase SDK with the FirebaseUI library on languagereactor.com. When users access the /login page, if the extension is detected, the signInSuccessWithAuthResult callback triggers getFirebaseSignInToken to obtain a custom token. This token is then passed to the Firebase SDK running in the extension’s background worker via messaging, where signInWithCustomToken() is called. The SDK in the background worker has an onAuthStateChanged() callback that notifies any listening tabs when the authentication state changes.
However, some users had been reporting issues related to third-party cookies and a few other minor problems. Recently, oeffectively running a 'DROP TABLE' on 400GB of Firestore data ended up costing $2,000.
I'm looking for an auth replacement. 2 million users, mostly free users. The system needs to support Google sign-in and email authentication, possible to integrate with React Native Expo, ability to issue API keys (thats probably separate). No vendor lock-in, under $500/month, happy to self-host. Any recommendations appreciated.
> However, some users had been reporting issues related to third-party cookies and a few other minor problems. Recently, oeffectively running a 'DROP TABLE' on 400GB of Firestore data ended up costing $2,000
This doesn't sound like an issue with Firebase Auth per se. You can still use the auth and move your storage to some other mechanism (one friend working on another project is using Firbase Auth with Supabase backend because he couldn't get Supabase auth to work with Claude generating most of his code).
In your case, depending on the document size vs number of documents, it might have been more economical to queue the deletions so that each day, you use exactly up to the free limit (20k deletes per day) and delete it over a number of days if there were no other constraints.
WorkOS pricing for B2B apps is untenable however. Same with Auth0. Is there any cost effective SaaS auth solution which allows multiple customer SSO integrations besides Microsoft Entra ID for External?
Agreed, Firebase is the worst. Google's impenetrable documentation, paired with frequent breaking changes, opaque pricing model (paired with asking for your card details but not letting you set a limit at which the app should turn off), trigger-happy product sunsetting, etc. etc. should be enough to turn anyone away.
And this isn't even getting started on how bad the DX is in general. I have found Pocketbase to be so much easier for basic auth (obviously it's too simplistic if you need major scale SSO solutions...)
Would also like to give a shoutout to Stytch. We've used them since day 0 to build our entire auth system, and have found the overall dev experience to be quite great
