Thanks for the write-up. I work for FusionAuth and we're taking steps to make our config less 'maze-y' and to be more friendly for JavaScript devs. For example, a react SDK: https://github.com/FusionAuth/fusionauth-react-sdk/
But I really appreciated the unvarnished feedback. Looking forward to reading the Ory post.
Easily the best writeup comparing the popular offerings out there, prompting a considered response from a few of the package devs. Not too shabby for a first writing effort. More please…
I’d like to address the points you mention about SuperTokens:
We've reduced bundle sizes by 70% and reduced the number of cookies. Access token size will also be reduced with another update
In terms of the implementation details in the app code - this is for things like SSR, session verification etc and these are the functions for those
We are not specific to React but yes we provide a prebuilt UI only for React at the moment. We plan to add Angular / Vue UI components but otherwise many Angular and Vue users use SuperTokens with their own sign up page designs.
this is a great write up. Some responses to your red flags:
*No setting for session lifetime* - as you point out, there is a setting called "JWT expiry limit". I'll mention this to the Auth team and see if they want to consider changing the name of the setting
*Client-side unencrypted tokens* - we give developers options. Serverside auth is definitely more secure, but that's not always an option (eg, on React). If you have a serverside requirement, you can check out our Auth Helpers [0] which give you several patterns for serverside auth.
*No 2FA on their own platform* - we just released this to the Auth server in December[1]. It's on it's way for the platform.
This comment caught my eye: "It also creates the ultimate vendor lock-in".
That's surprising! You can pg_dump all your entire database, including your users. I can assure you that's easier than other Auth platforms.
With that said, I want to let you know that this is all fair feedback. We definitely care about Auth - it's one of our most important products. We have a dedicated Auth team who are fixing issues based on user feedback, as fast as possible. We receive a flood of feedback across a lot of channels, and we do our best to keep up. From an product perspective, we aim to deliver products that makes sense in a Postgres context - you can see that we think deeply about how this service fits with Row Level Security in our MFA post below.
Your article has a lot of actionable insights, which I'll go through with the team to continue this improvement.
https://www.osohq.com/ - in app authorization. Next to the SaaS offering, there is also an OSS lib. I wouldn't use the SaaS, but the lib might be interesting to investigate
So far, I found Auth0 to be the best commercial offering out there. Their MAU is calculated on monthly active users. So you only get charged from those who are using your App.
On the other note, if your offering is price sensitive take a look at the offerings from the Hyperscalers, like AWS Kognito, Azure Active Directory B2C etc. Not as good as Auth0, but cheaper.
There's also some alternatives to supabase that have auth. Such as appwrite which is another big startup, or pocketbase which is mostly maintained by 1 guy
Thanks for that article, I enjoyed reading and love how you compare the solutions in a honest way with all the pros and cons.
Disclaimer: I am one of the Co-Founders of ZITADEL
I can totally understand that you had some troubles figuring out all the ressources and settings. This is a part we want to improve in the future. We already started making our documentation better, but we also want to make it more clear in the Console itself.
Since you published your blog post there are some note worthy new features that could have made your life easier.
1. Adding Identity Provider Templates - It was to complicated to adding all the providers based on an oidc configuration where you had to figure out the whole configuration by yourself. We now added templates, so you can choose Google add your app id and secret and you are ready to go.
2. In a first part we only implemented a hosted login UI. But we listened to our community and are currently building an API, so you are able to implement your own customized login page. Its in a Alpha state currently, and every feedback is appreciated:
We are aware that our examples, sdks and guides need some improvement in, this is something we want to focus on in the near future. In the meantime, we try to help where ever we can in our chat or the github issues/discussion. Also every feedback helps us to find out what is needed the most.
Comparing Auth from Supabase, Firebase, Auth.js, Ory, Clerk and others
Thanks for the write-up. I work for FusionAuth and we're taking steps to make our config less 'maze-y' and to be more friendly for JavaScript devs. For example, a react SDK: https://github.com/FusionAuth/fusionauth-react-sdk/
But I really appreciated the unvarnished feedback. Looking forward to reading the Ory post.
Easily the best writeup comparing the popular offerings out there, prompting a considered response from a few of the package devs. Not too shabby for a first writing effort. More please…
Thank you for the detailed writeup!
I am one of the cofounders of SuperTokens.
I’d like to address the points you mention about SuperTokens:
We've reduced bundle sizes by 70% and reduced the number of cookies. Access token size will also be reduced with another update
In terms of the implementation details in the app code - this is for things like SSR, session verification etc and these are the functions for those
We are not specific to React but yes we provide a prebuilt UI only for React at the moment. We plan to add Angular / Vue UI components but otherwise many Angular and Vue users use SuperTokens with their own sign up page designs.
(supabase ceo)
this is a great write up. Some responses to your red flags:
*No setting for session lifetime* - as you point out, there is a setting called "JWT expiry limit". I'll mention this to the Auth team and see if they want to consider changing the name of the setting
*Client-side unencrypted tokens* - we give developers options. Serverside auth is definitely more secure, but that's not always an option (eg, on React). If you have a serverside requirement, you can check out our Auth Helpers [0] which give you several patterns for serverside auth.
*No 2FA on their own platform* - we just released this to the Auth server in December[1]. It's on it's way for the platform.
This comment caught my eye: "It also creates the ultimate vendor lock-in".
That's surprising! You can pg_dump all your entire database, including your users. I can assure you that's easier than other Auth platforms.
With that said, I want to let you know that this is all fair feedback. We definitely care about Auth - it's one of our most important products. We have a dedicated Auth team who are fixing issues based on user feedback, as fast as possible. We receive a flood of feedback across a lot of channels, and we do our best to keep up. From an product perspective, we aim to deliver products that makes sense in a Postgres context - you can see that we think deeply about how this service fits with Row Level Security in our MFA post below.
Your article has a lot of actionable insights, which I'll go through with the team to continue this improvement.
[0] Auth Helpers: https://supabase.com/docs/guides/auth/auth-helpers
[1] MFA: https://supabase.com/blog/mfa-auth-via-rls
Take a look at https://goauthentik.io/
https://www.osohq.com/ - in app authorization. Next to the SaaS offering, there is also an OSS lib. I wouldn't use the SaaS, but the lib might be interesting to investigate
So far, I found Auth0 to be the best commercial offering out there. Their MAU is calculated on monthly active users. So you only get charged from those who are using your App.
On the other note, if your offering is price sensitive take a look at the offerings from the Hyperscalers, like AWS Kognito, Azure Active Directory B2C etc. Not as good as Auth0, but cheaper.
There's also some alternatives to supabase that have auth. Such as appwrite which is another big startup, or pocketbase which is mostly maintained by 1 guy
So helpful! I went through this same journey myself and was surprised there wasn’t a clear winner. Thanks for writing this.
Found your analysis super helpful whilst trying to navigate the Auth space!!
Awesome practical analysis, thanks for sharing!
Thanks for that article, I enjoyed reading and love how you compare the solutions in a honest way with all the pros and cons.
Disclaimer: I am one of the Co-Founders of ZITADEL
I can totally understand that you had some troubles figuring out all the ressources and settings. This is a part we want to improve in the future. We already started making our documentation better, but we also want to make it more clear in the Console itself.
Since you published your blog post there are some note worthy new features that could have made your life easier.
1. Adding Identity Provider Templates - It was to complicated to adding all the providers based on an oidc configuration where you had to figure out the whole configuration by yourself. We now added templates, so you can choose Google add your app id and secret and you are ready to go.
2. In a first part we only implemented a hosted login UI. But we listened to our community and are currently building an API, so you are able to implement your own customized login page. Its in a Alpha state currently, and every feedback is appreciated:
API: https://github.com/zitadel/zitadel/discussions/5875
Customisable UI: https://github.com/zitadel/zitadel/discussions/5922
We are aware that our examples, sdks and guides need some improvement in, this is something we want to focus on in the near future. In the meantime, we try to help where ever we can in our chat or the github issues/discussion. Also every feedback helps us to find out what is needed the most.
Thanks the thorough analysis, I'm just starting with Ory so I'm very keen to read your guide - any idea when it will be available ??
Very nice writeup. I'm still waiting for the next part :D