For me it is also a red flag to include third party CDN JS (especially without SRI) on security critical applications (like the login for the dashboard and customer logins do with jsdelivr).
And agreed on the CDN JS. We'll move these assets to the customer's domain.
edit: added reference and context for completion.
In the same vein, it seems like a lot of people aren't too aware of the "identity" space so there's a whole lot of re-inventing the wheel with external sources not realizing something already exists.
Why anyone would use third party js for anything other than dev work is beyond me. Are people really building websites that can serve html, images, and css, but not js?
That no longer works, see https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca... and https://developers.google.com/web/updates/2020/10/http-cache...
I was talking about using 3rd party file hosting services like cdnjs.com and unpkg.com
It's gotten so bizarre that highly popular libs (even Facebook's React!!! )will recommend you hotlink these third party sites rather than give you a zip file to download and host yourself.
That said, maybe the HN community can answer something I've wondered about... Why isn't there an Open Source, standardized, self-hosted, version of this kind of service? Or, why hasn't one, or two, options emerged that everyone uses and I would have heard of by now?
User management, authentication, and authorization, are all problems that have been solved in many apps, and there are plenty of best practices. So, just like you shouldn't roll your own hashing algorithm, I'd think we'd want to do the same with this. It would make sense for one of the open source companies or organizations like Canonical, RedHat, Apache or Mozilla to have at least tried to do this.
The closest I can think of to an attempt is Persona...
Anyway, just been wondering about this for a while, and thought I'd take the opportunity to ask.
it can get a bit complex, but to be fair the whole oauth/oauth2.0/openid/openid-connect/saml is quite messy in general.
In particular, I am trying to solve the problem of how I can share client secrets (so they can generate access token using it) with the respective clients.
I don't want to share them over email/ password protected doc.
I tried making one client for each realm and adding one user to it. When I login via user account using GUI, I am unable to see any info related to clients.
What am I doing wrong here?
What are the good practices around this?
Thanks kind folks
Fast self contained binaries, easy to interface with Kubernetes.
Adding some UI around them and managing them via api is nice enough.
The only incognita is whether they're going to handle scaling (I hope I'll have this problem one day).
Hydra is for OpenId though, I'd point to Kratos + Oathkeeper.
In general, if more sites grew proper OpenID auth vs justa subset of providers, we'd see more people run their own OpenID servers to authenticate against external services.
Basically, for an open source/free software service to succeed in this area, it needs to allow both federated and SaaS model because that's how free software people are :) And federated is hard because nobody accepts pure OpenID anymore (and it's funny: you'll trust an email address but not a URL as a unique identifier). But it's probably how hard it was to get working that's the issue.
Because it is a lot of hard, strict and continuous work. Specially if you want - and you kinda need to, if you want anyone to use you - to provide customization for: styling, different databases, languages (both programming and natural), login methods (SSO, email, etc), email delivery systems, user fields, etc.
So people building open source generally will just solve their own problem and might share that, not solve a problem space one up with all of these combination complexity mess. The most "standard" open source I know is Passport.js, but it only solves the problem of login methods.
You can roll any subsystem of it and use off-the-shelf providers for other subsystems (we pay a service to host the server, but we run our own dashboard server to poke into it, others run their own database and use just the API server, etc), but I suppose it's easiest if you run the whole parse backend as a whole.
So, there are options, some I now remember hearing of before.
I'm still interested in more of you thoughts on why they don't have a wider adoption rate.
It's great to see a service focus on taking away all the pain related to user management, not just login.
It's been quite a journey to reach this point, with over a year of iteration on the developer experience before we found something developers love. Using Clerk will enable you to spend more time on your application, and less time worrying about the ever-growing list of user management concerns.
Our team is listening in this thread and we're happy to answer any questions.
Compared to say Auth0, which would be $114 for 5000 MAU.
The only difference is profile, and Auth0 mostly covers it by allowing you to easily store metadata.
I am not sure I understand what makes Clark worth 2x Auth0?
Thanks for your questions! It's good feedback that there's no security documentation up yet. We have a lot more content coming live in the next few weeks - but let me try to hit some of the most important points:
* Session management is handled with secure, httpOnly cookies. We have you set a CNAME in production so we can set cookies in a first-party context (SameSite=Lax).
* Cookies are scoped only to domains that require authentication data. If your backend is on api.example.com and you're running hosted Wordpress blog on blog.example.com, Wordpress won't receive your session cookies.
* Passwords are bcrypted
* All frontend-facing endpoints have CSRF protection enabled
Please let us know if there is anything specific we can help clarify. We've gotten into the nitty gritty so there's a lot to document, and it would be great to understand what areas to surface most prominently.
For web browsers, cookie-based auth solves a ton of browser-specific problems that history has spent a long time building up answers for.
Also note that the cookies should be http only and with the secure flag
Here's a good reference: https://trust.okta.com
Do I trust a new service or continue with one of the most trusted service from AWS?
I think that honestly, the biggest sell for a lot of newcomers is gonna be "you don't need to know AWS!" -- in my (very limited!) experience, if you want to do X with AWS, you're gonna need to learn how to do W, Y, Z, and maybe A and B with AWS too.
AWS moves so quickly I think it would be a disadvantage to rely on a smaller, unknown 3rd party that tries to replace itself as AWS.
It’s nice to see that there’s an MFA option, and login notifications coming soon. I build this into my small projects too - even if unconventional - because I like to be warned about unusual activity on my accounts. Last thing you’d want is someone taking over a super user or staff account without anyone noticing.
Just a small note: would be nice to have a page describing your security practices.
Congrats on the launch!
Are you offering any security benefits?
What security is there against malicious insider threat? (Eg can you / people at Clerk impersonate any of my customers on demand? Is there auditing/accountability for such activity?
Is this something that sites with crappy roll-your-own user management would be advised to migrate towards, and if so why?
Is your main added value that you are not Facebook/Google?
I'd be _very_ hesitant to use this without some very strong guarantees that legal won't come breathing down my neck because I can't point them to a contractual guarantee that we will be complying with those (and similar rules from other jurisdictions).
I lose enough sleep worrying about PII that I store in databases I manage. Farming that responsibility out to a 3rd party does not fill me with joy, it raises instead lovecraftian levels of horror about what I'd tell a judge about how I ensured an EU citizen's rights to have their data expunged from my auth/userprofle system...
Where I cone from (.au) even an ip address is considered PII under our Privacy Act if it's linkable to another identifier - an ip address on it's own is not PII, but an ip address and an email address makes the ip address into PII as well as the email address. (It's unclear, but this likely includes storing a "last login date" in your email-containing database table that "could" be correlated to a login api call with an ip address in your log files, even if you are not actively doing that.)
- Can user information be exported for clients who may want to build out their own solution later? If so, what does that story look like?
- Can account management pages be customized/styled to match the clients' branding?
- What parts, if any, of Clerk are open source? Do you have a github?
- Do free tier users have a grace period to upgrade/migrate if they exceed 5000 MAU, or is user access cut off until they upgrade?
- Where are you located, and are you targeting certain regions/countries for new hires?
Also, the tier pricing is a bit opaque.
The "professional" tier pricing appears to start at $49/month (for <= 1000 MAU) and scale to $4999 (for 100,000 MAU). The "enterprise" tier mentions a volume discount (which would suggest less than $0.05/MAU), but presumably the overall price increases? If that's not the case, why not allow clients to remain on the professional tier if they don't need features exclusive to the enterprise tier?
- Where are you located, and under what jurisdiction do you fall?
Can customers extend your UI components? Do they store that data with you? One of the nice parts about authentication only is that it's relatively well-defined and not a place where customers frequently have variable needs (outside of just data sources to auth against).
Cool idea either way though, and I like seeing more innovation in the space.
On your backend, Clerk gives you a stable User ID for each user. You're free to use it as a foreign key in your database as you normally would. (clerk.dev runs on clerk, and that's how we do it internally)
We only have a Node SDK so far - here's a guide on retrieving the User ID from your backend:
Soon we will launch a way to add custom attributes to the user object, as well as management of those attributes in the UI if desired. Things can get a bit murkier there, but those features will always only be opt-in.
It's nothing about Clerk specifically, it's just a problem with these kinds of products. I just worry that as your customers grow and scale, they naturally need to leave your platform (or downgrade to an auth-only solution). I'll definitely be curious to see how the product grows, though!
It's not documented yet, but our frontend components leverage an API that was built with the expectation that some developers won't like our designs, or will need something custom we can't accommodate.
In those cases, using the API directly should offer the flexibility you need.
On the other hand, looking at node.js it's really a dumpster fire. Even when using passport, you are still back to writing the code to compare passwords at which point so much can go wrong. So there's a lot of scope for hosted services. This of course compounds the problem because those service providers are GREAT at SEO and content marketing, so now a lot of Google hits on nodejs auth end up recommending Auth0 &friends.
I'm not sure I agree. This isn't really an infrastructure cost, it's a direct COGS (cost of goods sold) cost, and hits the service's margin. For a SaaS business charging $10-1000 per month per user it's fine.
For a retail business though I think this could be prohibitively expensive. Let's say you have a 10% conversion rate and $100 a year spend for customers, that's actually only $0.83 a month per active user. This is a 6% margin hit.
Sure, maybe in retail you often don't need non-customers to log in, but maybe you do. Or maybe your active users correlate much more strongly with your paying users, but maybe they don't. Content-led, email newsletter style business could struggle with this pricing.
Allauth itself is opinionated, and some things were built based on expectations that are not reflective of today’s web apps.
It can be done but the lift is much bigger than one might think.
I also think one of the most important parts of django is user/auth.
Seeing FastAPI and modern frontends continually advance, and now this user management service, I’d suggest that Django is getting unbundled.
The missing part to me seems to be a stand alone ORM and something to replace traditional view/templates so existing django devs could onboard easier. Maybe these already exist or are in development?
I really like Django, but I do feel like there has been too much emphasis on stability and not enough experimentation to integrate API and modern frontend work into core.
I think some of this has to do with how unstable django was in its earlier days. Sort of a ptsd from that.
However, what has been forgotten is that it also allowed the project to handle changing developer needs and take market share from Drupal and others.
The best example I have seen of this problem is in the ecommerce package, Solear.
If you listen to the project founders in the the 4/2019 Python podcast, “Building Scalable Ecommerxe Sites on Saleor” you can hear the use case of the project falling away as modern frontend is coming into focus. 
The challenge is that was two years ago.
I actually see this as a problem for Python even beyond Django.
I would love to see allauth extended with some sort of React toolkit so we could do SPA logins without refresh. That seems like a much smaller lift..
And what if you want to drop this vendor?
Sorry but the greatest user management experience in the world is not going to make me use this. Maybe, if there is some kind of mirroring back of all user data to some database I control, I might consider it.
Nope, sorry not touching this with a 100foot pole. And I will go further and not use any company that uses this for their user management needs.
Subscription management will follow sometime after, and will probably look like a Stripe integration that automatically creates Stripe Customer objects for your Users and Organizations. Is this along the lines you're thinking?
If I'm building a photo-hosting app, it would be a bummer to pay for/build out a big "Organization Subscriptions" feature; if I'm building an enterprise-oriented chat application, I wouldn't want to spend many hours or dollars on individual "User Subscriptions".
But that said, I recognize splitting out those two features is more of a cherry on top; the main value here is just having them available to me in the first place. Either way, definitely keeping my eye on Clerk! Good luck folks!
I can only imagine using this "for real" if I could actually store the users in a database I manage. The last thing I want is to introduce a new 3rd party single-point-of-failure.
"8. Disclosure of Data
We may disclose personal information that we collect, or you provide:
Other cases. We may disclose your information also:
to our subsidiaries and affiliates;
to contractors, service providers, and other third parties we use to support our business;
for any other purpose disclosed by us when you provide the information;"
Who are these "subsidiaries" or "affiliate" companies? Data brokers?
From a company perspective it might be worth it to shave the 2-3 months to develop and perfect your own system. But from a user perspective, you are selling them out. Most people may not notice, but do you really want to risk the legal exposure or PR nightmare if their affiliate companies abuse this user data, or perhaps a subsidiary company leaves the data unencrypted in some db instance.
Why would anyone trust a third party with what is the most important asset, their users?
Thank you in advance.
As ever, there are trade offs and you take the good with the bad.
Best case scenario, there's healthy competition in the space, providing more alternatives and allowing you to end your contract with them if the service sucks. Worst case scenario I guess is that the company implodes taking all its data with it, affecting untold amounts of businesses. A GDPR-like regulation stipulating the ability to export that data (so, user databases) would go a long way towards mitigating prolonged outages in that worst case, and in the best case of the worst case, their competitors are able to import the exports. And/or tools that can spin up a $database instance in $cloud.
Also, if your issue is that owning your user passwords is difficult, then I'm sorry that's just the nature of the problem. It doesn't get any easier by offloading the problem to a third party. Bcrypting passwords is not rocket science anyway. MFA libraries exist for pretty much any server library you use.
Sure a company dedicated to doing user management will definitely do a better job than you, but only if your needs align with those of the majority of its users. The minute you want something custom,and trust me you will you're back to doing user management yourself. Only now you have a giant opaque blackbox to deal with.
Also, tomorrow if Google buys the company,I'll have 20 hours of notice to integrate my own user management before they shut it down. If Facebook buys it, they'll use my user data for targeting their advertising. Either way, I'm in deep trouble (If I care about my users, which I think most people will).
Even ignoring these, the simple fact is that by the very nature of the company, it is a much bigger target for people trying to break into and steal user information,than my little saas could ever be. I'd wager for most people using such services they'd be more likely to get hacked as collateral damage rather than being targeted.
If JaneService manages ten thousand credentials and has a breach, it could put JaneService out of business, but it won't affect MonicaSoft.
Now, trusting this particular third-party? Definitely a big question mark! It's on them to earn your trust. But I think to say that third parties in general can't be trusted with your users is to be a little ignorant of the modern web engineering landscape. We trust a lot of people with a lot of things, and not in an unreasonable manner.
I really can't think of any good reason to hand crucial control of a site over to any third party, much less user authentication where one breach will potentially cost you millions and land you in jail.
The whole business model seems to revolve around being a crutch for people not capable or competent of running their own services.
Because Auth0 and other providers have security experts specializing in prevent hacking attempts and there is no way you can do a better job than them unless you make it your full time job.
you don't have to use your real email for everything, even google has forwarding addresses.
and apple has private/forwarding emails as well, so this is a moot point.
I've even used G Mail's forwarding email for 6 years and I've never been hacked.
If you're concerned about this just use a fake email.
But you claimed that the email can be hacked, I used an email forwarding service provided by google or apple.
So are you saying I can be hacked through this way, please provide evidence of this happening in a real world passwordless scenario.
> An individual can mitigate them, but they still exist
Again, I would be more convinced of real world evidence and statistics rather than theorising.
I'm not arguing than an intelligent user can't get rid of security issues. I'm saying a product that uses passwordless login still has security issues. Not every user is going to do that and theyre gonna blame you when they get hacked.
> Again, I would be more convinced of real world evidence and statistics rather than theorising.
You first. You made the initial claim that passwordless login has no security issues. Systems should be assumed insecure unless proven otherwise.
Like what? you keep saying "still has security issues", but you don't give any real world examples. Just saying "still has security issues" is not a good argument.
> You first.
Lots of companies use this method in the real world, Slack, Medium, Freetrade, Substack, Monzo (a bank) and many more.
If a bank and a stock trading app is comfortable using this method, I am sure they are comfortable with the security of this method.
In addition, I already have given examples in this thread which you willingly choose to ignore.
Your turn, start with this:
> Forwarding email increases risk of being hacked. They only have to get one of the emails to get into my account.
The point is that doing auth properly is hard. Sending an email might be easy, but creating and managing the session in a secure fashion is hard, even if you’re “just doing passwordless email auth”.
> The point is that doing auth properly is hard...
it works just like password reset no?
there's not much state with passwordless email auth as opposed to passwords.
I don't think I understand exactly what your argument is.
> Sure, because “do passwordless emails” is just a snap of the finger away, right?
And I showed it literally is.
The choice is yours to reimplement this authentication system, but in terms of "a snap of the finger away", You can do that, That is all.
I've done these type of systems before at scale and it took minutes to do (works just like a password reset mechanism) and it is very trivial.
In your original comment above, I think you are projecting this a bit too much.
Next Comment: Because they are better at security
Your comment: Or you can do passwordless yourself and have no security problems
Next comment: You can't just do passwordless with a snap of the finger
Your comment: Yeah just use a 3rd party
You're incorrect about the thread
> The choice is yours to reimplement this authentication system, but in terms of "a snap of the finger away", You can do that, That is all.
It doesn't matter if it's a 3rd party, it is still an option that exists "a snap of the finger away", which was my response to that comment, this type of system can be done in an hour, 3rd party or library.
But if you want to speed things up, then there's your solution.
That was the point, but go ahead and try and reduce and spin this to your own interpretation.
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.
It's not even worth evaluating at the free tier without this. I asked in their slack and they said they intend to support this, which is promising (though sounds like it's not implemented yet)
There's also an argument to be made that companies like this could (certainly not guaranteed) employ security experts and have better implementations (through libraries) as a result. Those implementations could (if updated appropriately), yield a more secure auth solution. In that regard, going with a third party, who has expertise, could be "better".
Also, unless you're going to host your database that stores user data on prem, you're likely trusting a cloud with it.
If I missed the point of your question I'm sorry. Did my best to answer. I have no relation to any of these services, other than I've used some at times throughout my career.
Furthermore, with the economies of scale, there can be more investment done on security & protection of users by a common element. Think of it as a collection of companies pooling their resources on a single engineering team which is responsible for building a rock solid authentication system with many useful features. This helps little guys build on top of something which has the same efficacy as auth services that large companies can afford to build.
At the end of the day, it's a trade off.
A similar question that was asked only a few (10?) years ago, was "why would I trust a third party with my credit card data?" And now it's something that people don't think twice about, because of all the regulatory challenges around storing credit cards, and how bad a breach is.
We see auth, and more generically, basic user data, as a corollary to that. With User Data regulations popping up in different countries (GDPR/CCPA), in the next 5-10yrs, we think it will become pretty common place to use a service to offload some of these gnarly responsibilities.
The other concern is what happens if you shut down or decide to change your plan to be prohibitively expensive? (I'm not implying that's the case for you, but it's a consideration that has to be made). There have been vendors in the past that have abruptly shut down without warning, leaving their customers scrambling to build or find alternatives. In all honesty, I'd rather build an authentication system from the beginning than having to take my service down at a critical time.
This is actually a really interesting product though, and i would definitely consider it on future projects.
Auth0 maybe. Firebase is created by an advertising agency, so no.
1) Pricing is free up to 5,000 MAU
2) But the next pricing grade starts at 1,000 MAU for $49/mo + $0.05/MAU additional
so if you have 5,001 MAU you take a big leap from $0 to $249/mo
Is there a reason for that huge bump? Why doesn't the first pay tier start at 5,000 MAU?
And how is MAU even calculated? Like, aren't all users in the system active users? Or are you able to have a bunch of unactive users in the system as well not counted?
That is, when you are billed based on MAU you don't pay for the number of users in your database, only for the ones that actually use your app/service/whatever.
> Our prices are based on your Monthly Active Users (MAUs) and not your entire userbase, so you only pay for logged in users who interact with your website during the course of the month.
Does this help clarify? Sorry for the confusion.
The free plan does not include 2-step verification, and that was the reason for the increase in the paid plan.
We'd love some feedback on how you'd like to see the free plan constructed. What would be most helpful for getting you started with Clerk?
Not offering MFA on the free tier tells me you're more interested in making money than in security.
There are plenty of other features that an enterprise will pay for.
It would be good to offer SMS MFA in the free tier, providing the dev plugs in valid Twilio credentials.
Especially in a security focused product.
Not the type of behavior you'd expect to see from the company you're handing all your user account data over to.
They do. There is a pool of money they make that they take from gains made on your money before you get the remainder as interest. That is what pays for that.
Here's how I would do the price tiers, since you asked:
* STARTER - Free up to 5,000 MAU, features as listed.
* STARTER PLUS - Add a credit card and just pay $29 plus $0.05 for each additional MAU over the first 5,000. Same features as listed for STARTER.
In this approach, MAU 0 - 5,000 is free, and MAU 5,001 is $29.05. In the Starter plus tier, 6000 MAU is $29 + $50 = $79 and 10,000 MAU is $29 + $250 = $279
* For the PRO tier, the jump is pretty dramatic between $29 and $249 for the same # of users, so I suggest a 2x rather than a 8x premium. This means that you should price pro at $49 plus $0.02 for all users. This makes 5001 users $49 + $100 = $149
In this arrangement you don't even need to have a 5000 starter cliff for Pro. You can start with pro at even 500 users if you wanted the MFA features and the cost would be just $49 + $10 = $59.
Just my 2 cents.
I've been meaning to evaluate keycloak.org and userbase.com, two radically different open source user management layers. Especially, userbase which has a relatively more attractive pricing for their hosted option.
Besides, user management is something I'd like to rid if I can, and instead rely on anonymous / decoupled (passwordless?) identity layers like human-id.org and gazepass.com
Cloudflare's OPAQUE is another enticing (zero-password) tangent in all of this, but they warn folks to not build identity systems using it, yet.
The professional pricing have "Two-step verification" and "No visible Clerk branding".
Not necessarily criticism, just my impression after a quick glance.
1. Why use this over AWS Cognito?
2. Any intention to manage authorization as well?
Somewhere someone convinced us all that "Authentication/Authorization" are hard problems that we should leave to third parties.
- Who is your customer type ? Individual developers ? IT of companies ?
- What do you bring in addition to Google G Suite ?
- Why is that important to have beautiful UI ?
- Why would I use your service to power auth of my service, as it would probably take more time to integrate your apis, and configure your frontend to my branding than do it from scratch ?
- Presumably, engineers building customer-facing applications
- Google G Suite can be a fine SSO solution for internal apps, but isn't the thing you're going to use for your customers
- I'm not sure how to answer this one. Surely it's quite obvious how a beautiful user experience is valuable? Your customers aren't comparing your experience against your competitors, they're comparing you to the best experience they have seen to date in any space. Companies who don't invest in their experience (and by extension, their visual design) will fall behind.
- At a surface level this may appear true, but in practice people often significantly underestimate the time involved in building a high quality and secure authentication system. If all you do is throw an email address and password in a table, then sure. But you're going to have sign up, log in, forgot password workflows (and emails) at the very least. Then, if you're actually trying to protect something, you're going to have password complexity requirements, brute force protection, 2FA (authenticator, sms, etc), security notifications, browser fingerprinting, etc - to name a few.
I'm still not sure how I feel on the outsourced authentication concept, but certainly not because building your own auth is free or cheap. Just because it's such a critical part of data that it might be worth eating the cost for (but I'm not sold necessarily).
We would love to make it so developers don't need to think about, or make it easy to think about, GDPR and CCPA, and any future regulations that come up.
Right now we're hosted on GCP in us-central. We will need to be more distributed as we start to tackle GDPR et al., making sure data is hosted in the correct location.
Am I alone on this? Let's be honest, how much of the SaaS code you write could be applicable in any SaaS application?
Seems most companies don't need new boilerplate as everyone is just adding code to the existing product.
I don't think this model works, as small indie devs trying to do SaaS won't pay well enough and drown you in support and anything more than a mid company trying to do SaaS will reimplement their own (badly but good enough) in a month.
Saasify with a few millions funding and a hundreds of sales could do ok, but investors are throwing money on other things these days.
Could you expand some more on the team behind this? As this service would be a critical part of any application relying on it for authentication I’m keen to know about the size of the team supporting it.
Do you offer an SLA and 24/7 support?
I can't see it yet but I'm expectant you'd have ancillary forgot password & user management (manual signup/migration, disable account) flows in the works?
A "one more thing" to have me hooked would be user/team billing management .
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
I have started using Keycloak for one of my side projects.
I am unable to get my head around it and was pondering there should be a Keycloak as a service.
Also, solving the trust part is one challenge which I hope you folks would handle.
1. What happens if you go down? Then our users can’t auth in right?
2. I saw in one of the screenshots the ability to connect OAuth providers - will your service also store refresh tokens for these api services?
What other frameworks would you like to see prioritized?
Since we're tackling both the APIs and the customer-facing UIs, we think we'll be able to add a lot of value here