WorkOS has taken the alternative design of ONLY doing authentication and explicitly not user management. This is a subtle but I think super important distinction so figured it could be useful to share why in this thread, especially for developers looking at auth solutions and thinking about their app's architecture.
Essentially in the market right now there are a bunch of user-management-as-a-service solutions (Auth0, FusionAuth, now Clerk) and all of them have a similar design. They provide hosted auth UIs and they "run" your user database. This gives them control of the identity layer of your app, and they are the "source of truth" for users.
This has some benefits (e.g. centralized admin) but in talking with developers, we actually found there are huge drawbacks which are not initially obvious.
The user database sort of the data holy grail. It's arguably the most important and sensitive data your app has. From a UX perspective, the sign-in UI is the "front door" experience. It's the one feature that literally every user touches.
In OP's post, they write:
"Best of all, the components will automatically update as our team optimizes their design, develops new features, and adds support for the latest in account security."
We found this was the LAST thing developers want. There are plenty of open source sign-in components (Tailwind, etc) but with Auth0/Clerk/etc. you never get full control over the UI. It's run by a 3rd party which may introduce random new features at any time. It's giving up a huge amount of control, both UI/UX and strategic. Plus you're always in the "uncanny valley" of design, where your auth screens feel slightly different than the core app experience. IT admins have trained users to avoid these sites because they are typically phishing attacks. Not good.
Even with all this, perhaps the biggest downside for developers is a longer-term issue: you get locked-in. If down the line you end up wanting to run authentication through an unsupported provider, too bad, you're stuck. This is how Auth0 gets you. Developers integrate early, all the users are in Auth0, and then it's too difficult or dangerous to migrate out later. You're held hostage. And this is when they raise prices like an authentication racket. ("You've sure got nice app here. Would be a shame if something happened to it...” etc.)
Obviously biased as I've founded a company in this space, but I think we've solved a lot of these issues with WorkOS, allowing for maximum flexibility with powerful authentication APIs while ALSO enabling developers to fully control the user database. It's been a super hard thing to get right and I should really write a longer blog post in itself. But just a forewarning to app developers: be careful where you store your user data.
PS: A misc secret for the HN crowd, we're actually launching 2-Factor Auth APIs tomorrow. ;) Zoom link here for the stream: https://lu.ma/workos-winter-release
Also colinclerk are you Colin Sidoti? If so I was a few years ahead of you at MIT and I think we totally we met a few times around when I was graduating. Small world! :D
WorkOS has taken the alternative design of ONLY doing authentication and explicitly not user management. This is a subtle but I think super important distinction so figured it could be useful to share why in this thread, especially for developers looking at auth solutions and thinking about their app's architecture.
Essentially in the market right now there are a bunch of user-management-as-a-service solutions (Auth0, FusionAuth, now Clerk) and all of them have a similar design. They provide hosted auth UIs and they "run" your user database. This gives them control of the identity layer of your app, and they are the "source of truth" for users.
This has some benefits (e.g. centralized admin) but in talking with developers, we actually found there are huge drawbacks which are not initially obvious.
The user database sort of the data holy grail. It's arguably the most important and sensitive data your app has. From a UX perspective, the sign-in UI is the "front door" experience. It's the one feature that literally every user touches.
In OP's post, they write:
"Best of all, the components will automatically update as our team optimizes their design, develops new features, and adds support for the latest in account security."
We found this was the LAST thing developers want. There are plenty of open source sign-in components (Tailwind, etc) but with Auth0/Clerk/etc. you never get full control over the UI. It's run by a 3rd party which may introduce random new features at any time. It's giving up a huge amount of control, both UI/UX and strategic. Plus you're always in the "uncanny valley" of design, where your auth screens feel slightly different than the core app experience. IT admins have trained users to avoid these sites because they are typically phishing attacks. Not good.
Even with all this, perhaps the biggest downside for developers is a longer-term issue: you get locked-in. If down the line you end up wanting to run authentication through an unsupported provider, too bad, you're stuck. This is how Auth0 gets you. Developers integrate early, all the users are in Auth0, and then it's too difficult or dangerous to migrate out later. You're held hostage. And this is when they raise prices like an authentication racket. ("You've sure got nice app here. Would be a shame if something happened to it...” etc.)
Obviously biased as I've founded a company in this space, but I think we've solved a lot of these issues with WorkOS, allowing for maximum flexibility with powerful authentication APIs while ALSO enabling developers to fully control the user database. It's been a super hard thing to get right and I should really write a longer blog post in itself. But just a forewarning to app developers: be careful where you store your user data.
PS: A misc secret for the HN crowd, we're actually launching 2-Factor Auth APIs tomorrow. ;) Zoom link here for the stream: https://lu.ma/workos-winter-release