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?
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
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.
- 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
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.
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?
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.
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.
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?
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?
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.
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.
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
This article is 18 months old. There are even more options now!
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.comBlog post author. I think AuthKit is the best solution today!
But you really need to implement email change for users. It's a joke that it's not offered, that's a standard feature for every SaaS v0.1
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.
on changing emails: https://news.ycombinator.com/item?id=41927216
Don't forget SSOReady!
I think Magic.link mostly threw away the web2 auth side of their produce and went all-in on blockchain? Haven't seen them in conversations for awhile.
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.
Knowing both the team behind SSOReady and their product, I can tell you that this couldn't be further from the truth.
What a shameful thing to say — of course you want your own product to look good, but badnaming your competitors is not the way to go.
(Disclaimer, as I mentioned elsewhere, I am building Stack Auth, which is also on your list.)
"You can think of us as an open source alternative to products like Auth0 or WorkOS." from SSOReady's README: https://github.com/ssoready
Single dev in contributors graph: https://github.com/ssoready/ssoready/graphs/contributors
Pre-pivot startup called Okapi (YC W24): https://news.ycombinator.com/item?id=39755927
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.
Adding to the list - Pangea AuthN
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 :)
https://pangea.cloud/services/authn/
I knew I forgot one! Just added.
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
Is it that bad?
Zitadel, Casdoor, Ory, Keycloak, Logto?
I was more thinking about the replies — but granted!
I see, that’s fair yeah
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?
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
Thanks a lot for stating this. I'm happy to invest in AuthKit and recommend it if I know it will eventually support email change!
Yes it will happen!
I wish a library exists (in rust or anything that is easy to embed) instead.
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.
Propel is great.
Summary of article:
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.
I work at WorkOS / AuthKit.
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.
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.
Appreciate that. We have many thousands of apps like yours on the platform, and I’m glad to hear the free plan is working for you.
Forgetting about your auth provider is indeed the dream!
Don't worry, I have paid apps too haha. I just have one free app that I haven't needed to upgrade.
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.
Cofounder of Clerk. I agree - our pricing has been significantly reduced since this was written (partially in response to this post)
We do intend to build more products, but if you're using us for pureplay auth we shouldn't cost 1% of revenue at scale.
(As far as I know, we don't cost 1% at any scale, except very early startup days pre-revenue who opt not to use our free plan.)
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?
naive q: why not just add a workaround that skips the auth process for local dev? also helps test automation.
Clerk really is awesome. This is a good write up.
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?
Cofounder of Clerk here - we dramatically lowered our prices starting December 2023: https://clerk.com/blog/new-pricing-plans
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.
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.
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?
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.
Any tips on what I should use instead?
Supabase Auth Anonymous Sign-ins
- https://supabase.com/blog/anonymous-sign-ins
- HN discussion: https://hw.leftium.com/#/item/40066560
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.
They also have amazing support.
Surprised Keycloak and Dex didn't make the list!
Personally feel like those are the two most standard options for something self-hostable.
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.
I'd like to throw Pocketbase into the mix. Has made my life so much easier. Worst auth experience: Firebase on NextJS. Never again.
I have tried it all. Just use Firebase or AWS cognito. Others are VC funded rug pull / info gathering ops.
Firebase has to be some of the worst DX I have encountered in the wild. Truly shocking. Also, trusting any Google product is probably unwise.
Cognito is dirt cheap. Its just clunky to use, but agree has everything you might need
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?
In defense of firebase, their tenant solution is the best I've ever seen (at least so far).
I am noting that this is a fairly dated article (Feb 15, 2023), but supabase does MFA to sign into their platform.
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.
Security features seem like the ONE thing you wouldn't want an LLM generating/hallucinating ...
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.
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.
Authentik is decent self hosted solution
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.
I'm using Firebase Auth with a Chrome extension.
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:
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.Example of this flow in an extension: https://chromewebstore.google.com/detail/turasapp/lpfijfdbgo...
[0] https://cloud.google.com/identity-platform/docs/reference/re...
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.
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.
We have a new major version of the chrome extension sdk with a docs overhaul on the verge of release over here at Clerk if that’s useful!
try propelauth, for example https://www.propelauth.com/post/chrome-extension-authenticat...
WorkOS now has AuthKit which we use happily.
No one should use Firebase today.
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...)
[dead]
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