SSO, SAML, SCIM, OIDC, OAuth, 2FA, passwordless auth, verification tokens, etc etc, And, variations of each for wildly popular systems you’ll be expected to integrate with but don’t support the exact spec.
For a while at my company, half our support engineers time went to handling random SSO issues that came up in our home built auth system.
All you need is Apple and Google Oauth.
If you are a B2C app, you are probably more concerned about:
- social providers (Apple and Google being the big ones, but others could play a role--FB or Tiktok for example)
- easy registration (but not too easy, you want to avoid bot spam)
- self-service account management (updating profile fields, consents [CCPA, GDPR, others], resetting passwords
- single sign-on between your apps (if you have multiple)
- language support (for your backend, and mobile/web front end)
- cost
- possibly MFA, possibly passkeys
It allowed us to do SSO for small one-off marketing / campaign focused sites. I could give a specific login URL and it would always log you in if you were already logged on.
To expand a bit more: if a business is faced with a choice to save some money by increasing risk, having people who’s job it isn’t managing and supposedly securing that information, or to have a third-party who job is literally to handle and worry about those things, who carries independent insurance, and who is on the hook if they lose customer data, and in exchange the business is simply taking the risk of associating with business that could do a poor job — which of those options sounds more appealing from a business sense? It’s a lot easier to blame someone else than earn back trust for your own major mistakes because you tried to write your own software to save a little money.
That’s the SaaS value proposition.
Okay, so… what are those cases? I’m also curious.
If you're willing to make a third party SaaS's uptime the ceiling for your own org, you can delegate auth. Github might not be a good choice for SSO.
If you're not threatened by per-user-per-month fees, you can delegate auth.
If your threat model is compatible with a third party having visibility into your user's network location and the frequency and duration of their activities across your org, you can delegate auth. (Okta will probably not inform your competitor that your main sales guy is in North Carolina this week and has logged in from the conference room wifi of your competitor's main client.)
If you can trust the third party to not allow an interloper to bypass your requirements, you can delegate auth.
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.
Whether it's painful to put in later or not is sadly nothing that the managers and executives concern themselves with.
Wrote an article about that here: https://fusionauth.io/articles/authentication/fedcm (hosted at my employer's website)
It's worse than that, the combined availability is the product of all components in the critical path. If your software, the authentication layer, and the cloud provider each have 99% availability, and any one of them can bring your service down, then your final availability is just 97%. With eleven components like that you have zero nines of availability.
That's why reducing components and going for reliable solutions is so important. I'm happy that the team took this path.
I remember when they deprecated the library and instead made it a learning resource on implementing auth from scratch. Brilliant decision, much respect to the author.
Would think twice before using it in the future.
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?
thankfully i'm familiar with better auth from a side project, but migrating SSO/SCIM sounds like it might be a bit of a pain
- Syncing external auth provider state with your user state is a bug center. It helps to keep as little state as possible in the auth provider, but there is still some. - Refreshing JWT access tokens every few minutes is another bug center and honestly there is no need to do this if you control your own auth. - WorkOS does not have a complete API. It is built on the assumption that you have one product per billing account and a fixed number of environments (staging, production, and they can give you another one if you ask support). You have to whitelist redirect and other URLs in the dashboard, and there doesn't seem to be an easy way for agents to do it.
Outsourcing auth does not make much sense IMO. The less you can split your state over multiple services the fewer problems you will have. Sometimes it is inevitable, like for payments, or if you need specialized databases for performance reasons. But for auth there is really no good reason if good libraries are available. To people who say that using a service will help you get started faster, none of the problems I hit with auth services had to do with having high scale -- most of them hit before I even launched.
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
What am I missing?
Anyone remember Auth0 and passportjs?
The churn of auth services is never ending, but I suppose so are the standards.
Heya, Auth0 is still around! They got bought by Okta in 2021 but still have a free tier and we see them in a lot of bake-offs.
And even more users who are looking to escape. Clerk is just a mess. They are trying to cram EVERYTHING into their libraries: Web3 crap, Stripe, etc. Clerk's JS blob is now triggering the browser inspectors for being slow to load.
Every time when we upgraded React, Clerk libraries were the biggest pain with their transitive dependencies. We had issues with Stripe libraries with conflicting versions, etc.
And forget about debugging it. The libraries are obfuscated, and the TS code is impenetrable mess of abstractions to support "isomorphic" code that can run transparently on the frontend and backend.
And their platform itself is lacking important functionality, like freaking audit logs and versioning. Somebody (probably) accidentally changed a setting in their console, and we couldn't trace back when it happened or who did it.
Edit: oh yeah, and don't forget their unreliability. I had to wake up on Sunday to deal with Clerk failing the API calls for token refreshes last week.
Uhm, companies like Replit and several other large startups are actually adopting Clerk. I guess if your world mainly revolves around X (formerly Twitter), it can seem like everyone is moving away from Clerk.
Also, Better Auth’s X presence is pretty much centered around criticizing every auth provider out there, so the discourse there tends to skew heavily negative.
This from an account created 2 hours ago, with a username that’s a negation of the BetterAuth founder…
If you’re Clerk stakeholder why not just come out as yourself and engage openly!
It's only when you start getting into the details that you begin to suffer. For example, there's _still_ no way to do offline auth on mobile. So that your application could be opened if there's no connectivity at the moment. But hey, you can do the Metamask Web3 blockchain thingie!
I have never used Twitter/X, and I don't even have an account there. I'm purely talking about my personal experience and the experience of other companies that I know personally.
> Also, Better Auth’s X presence is pretty much centered around criticizing every auth provider out there, so the discourse there tends to skew heavily negative.
They are actually not wrong. Auth is not such a hard task, it's just a lot of drudgery that detracts you from the actual goal of your company. But it's critical functionality that MUST ALWAYS WORK, before all else. And Clerk just fails this test.
I'm switching my company to Logto (it's lightweight and when something breaks, I know how to pick up the pieces), so I don't even have an opinion on Better Auth.
Does Better Auth offer this? Or any other auth libraries or solutions? I haven't heard of any, but haven't done an intensive look either.
I suppose you could do something with a cached JWT or cached password hash (though sending a password hash to a mobile client spooks me).
I'm in the space and interested in learning more.
This is supported by Better Auth out-of-the box. It doesn't hide these kinds of stuff from you.
no need for 3rd party provider.
- https://github.com/agoodway/introspex (generate Ecto Schemas from postgres tables)
- https://github.com/agoodway/pgrest (Supabase/PostgREST compatible query engine)
I also found this helpful in the migration: https://github.com/supabase-community/supabase-ex
Nothing for auth, I basically did a one-off script for that. Phoenix auth stuff that comes out of the box is great.
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...
Easy to use and high reliability. Some of these other providers are not the best at reliability.
Maybe you can help me out: I still have no idea what val.town is. I guess it's an alternative to Cloudflare Workers?
So yes, like Cloudflare Workers in some ways. Or like CodePen but fullstack. Or Replit. The val town "founding poem" was:
> If GitHub Gists could run,
> And AWS Lambda were fun