You might be interested in some of the presentations at KeyConf[0]. You can also get some real world stories from the Reddit[1].
I was at KubeCon EU this year (representing my employer, FusionAuth) and there were lots of folks who were running Keycloak who came and chatted with us.
It's a different set of tradeoffs than Auth0 or other SaaS services. More control, but more responsibility too.
Is that the new library that came out in rails 8? Saw someone present on that at RailsConf 2025 and it seemed like a great solution for all rails apps. Hope it leads that ecosystem to get rid of devise (which I always found confusing).
We ended up caching the credentials and the JWT refresh token from Clerk, and then manually requesting the access token using the Clerk's sparsely documented frontend API. Except that to do this with Clerk, we needed to fake the cache API and then pluck the token out of the undocumented "__clerk_client_jwt" key.
This is supported by Better Auth out-of-the box. It doesn't hide these kinds of stuff from you.
Disclaimer: I work for a Clerk competitor, FusionAuth.
Can you share your evaluation process? I'm always curious how folks evaluate auth providers.
Did you do a spike? Full POC across a couple of solutions? Rely on a recommendation from a friend? Run through a quickstart and decide it worked and you had bigger problems to solve? Something else?
Nice website! I like your docs too. Small tip though, the couple obviously AI-written articles (ostensibly for SEO purposes) in your footer are a little of a code smell.
Also design wise, the main logo item (vortex looking thingy) is a tad bit complex, maybe think about a redesign focused on making it more simple/recognizable. The rotating dashes on the landing page hero are a good motif though, so I'd lean into that.
Also noticed that on this page: https://fusionauth.io/tech-papers/winter-2026-g2-fusionauth-... the form under "To get this tech paper complete the form below." doesn't load on Firefox with Enhanced Tracking Protection enabled. Disabling it causes the form to load though.
> Outsourcing auth does not make much sense IMO. The less you can split your state over multiple services the fewer problems you will have.
I agree with the general principle. Fewer moving pieces make for more stable applications ("choose boring technology"[0]).
However, I was wondering what you do when you have more than one application that the same userbase wants to access. I can see 3 options:
1. make them register/have credentials for each application (not a great user experience)
2. use a standalone auth server and deal with the increased complexity
3. pick one of your applications to 'own auth' and have the other applications delegate to it. congrats, you've just invented a standalone auth server that is coupled to one of your apps
I think depending on how much integration you want, either option 1 or treating the multiple applications as a single application that can do multiple things could be good options. Also, option 2 could still avoid having to worry about your auth service going down or rate limiting you. And you could avoid JWT headaches.
Perhaps there is also an option 4, which is option 1 plus a shared user information database for things like Stripe account, profile picture, etc. That is more complex obviously, but it would still solve the issues I had with WorkOS. In particular, I think it would mostly solve "syncing external auth provider state with your user state is a bug center." In particular, the awkwardness around sequencing of account creation and deletion would largely go away because that would be managed as in 1, and the extra shared information would be just that. (But maybe you would want to delete it if the user deletes all their accounts?) And you wouldn't be forced to use webhooks to get updates to shared user state. You could put it in a shared Convex database, for instance, or use some other solution of your choosing.
The tl;dr of the article is that there are auth specific features that are not differentiated but that users expect. Just like you might outsource pieces of functionality like data storage and message sending to specialized servers/libraries/applications, you can do the same with authentication.
The article could use some improvements, tbh, it is 2.5 years old.
So the argument is that the brand will understand the problem domain well enough to define it so an outsourced software factory can build it. That factory will also run it and maintain it.
I've seen this in the consulting world with long term relationships between a brand and a consulting company, where the consulting company is the technology partner.
I don't think there's anything to stop that from happening with agents; it's just a different means of producing software.
I was at KubeCon EU this year (representing my employer, FusionAuth) and there were lots of folks who were running Keycloak who came and chatted with us.
It's a different set of tradeoffs than Auth0 or other SaaS services. More control, but more responsibility too.
0: https://events.linuxfoundation.org/kubecon-cloudnativecon-eu...
1: https://www.reddit.com/r/KeyCloak/
reply