Show HN: Clerk – all of user management as-a-service, not just authentication

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

First off, full disclosure: I don't work for Clerk; I work for a competitor which offers overlapping functionality, FusionAuth: https://fusionauth.io

I think a sibling comment laid it out well. It's a tradeoff. You are giving up some control over how your users are stored for significant acceleration of functionality. We've had customers say we saved them 1-2 person months of time in initial build, never mind ongoing maintenance.

Would you build an app using a database managed by someone else? Isn't data a crucial asset? Some call it the new oil, I've heard. Yet lots of people choose to use an outsourced database provider. Auth is more user facing than a database, but if you can get the data out, what's the difference?

That said, you should pick your own comfort level. Other options include self hosting (there are commercial and OSS solutions which you can run on your own hardware).

You should also have a frank conversation with any providers about their security posture (sounds like the Clerk folks are going to add some docs to their site about this, which is great.)

Another consideration: you want the ability to export your users should you want to move services. People who aren't self hosting with FusionAuth can get a database export from us, for example, if they want to migrate.