Posted by stevekrouse 17 hours ago
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.
We should be able to demand users remembering their passwords, I dont like to cater towards users who simply dont want to put in the work to use my product.
Will I lose potential users over this? Yes. Does it feel bad knowing I am in control and wont have to offload to 3rd party vendors? Hell no.
fwiw, we also have entire staff dealing with SSO issues among our employees and users, despite relying on external services to handle auth.
A problem domain as complex as authentication is bound to habe issues of some sort. But I am not sure if I would be so fond of „outsourcing“ something as integral to my services as the access to these services
Sometimes that's just an opportunity
Technically true, because Google's core product is ads. Also fundamentally wrong, because Gmail serves as a massive source of ad targeting information, in addition to being a high-engagement canvas to display those ads.
Ad display I'll still grant you of course.
All you need is Apple and Google Oauth.
At least to me it sounded very much like they were talking about mobile.
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
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.
Oh you still have to build the auth system yourself? Well maybe a realtor does sound good now.
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.
For starters, if I'm a "house builder" by trade, then yeah, I am going to build the house myself. Otherwise, why should the client pay me, and not the guy I'm subcontracting?
Secondly, there is no such thing as a "house builder" profession. It consists of a lot of different trades people, some of them having legal power to sign off your house build (for example an electrician). Now, we could try to push for something similar in software engineering, and say require you to have an "authentication engineering certificate" in order to handle code related to auth, and only a person holding the certificate can allow such code for production use. But I'm pretty sure all the vibe coders and tech bros will cry how unfair and bureaucratic the system is.
But of course the entire SWE profession is based on grifting, and extracting as much money as possible from the customers while cutting the costs. If you are so afraid to save passwords to a database, then at least don't call yourself a software engineer.
Of course, we're not talking about email/password with "remember me" checkbox kind of auth.
People not knowing what salt and pepper is... Vulnerabilities almost as if on purpose...
Perhaps it is actually not THAT hard but just like error handling, people don't want to do the unsexy parts and want to delegate those tasks to someone else perhaps. There must be a behavioral pattern there...
> There must be a behavioral pattern there...
The pattern is that your comment is very far from reality.
And this someone's name begins with "Cla" and ends with "ude".
So we're going to have a lot more vulnerabilities in the auth code going forward.
Whether it's painful to put in later or not is sadly nothing that the managers and executives concern themselves with.
It’s not just the table, it’s also the auth and many other things that you know you will need but you would prefer to focus on other stuff.
Almost always you start by saying that you will replace that when the time comes and you have proved you have a product and now it’s time to actually build the real thing.
Some teams do that and some other, never migrate away and that’s how the GTM of companies like Clerk works.
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.
Given, I feel if you run supabase at a big company you are either lazy and probably have too much budget to spend on useless costs.
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.
Wrote an article about that here: https://fusionauth.io/articles/authentication/fedcm (hosted at my employer's website)
Knowing every single line of code involved allowed me to add some location-based functionality for one client, provide tailored logging to meet the needs of another client, and my favorite was winning a deal against much bigger competitors by being able to integrate with an absolutely ancient legacy system.
Just like “Goto considered harmful”, DRY, YAGNI, etc - they’re great at making you slow down and think. But they’re not inviolable.
I am with you on this.
Even if done for fun/learning, it can teach how the details of auth work to better appreciate and understand how other systems work and what to look out for.
I prefer to use existing things if possible, but if it was getting unreasonable to get it how it was needed, it wouldn't be off the table.
It is hard for serious use-cases. That does not mean you should not do it, but know what tradeoff you are doing in the build-vs-buy equation. Know that this part of your system probably requires more testing, review and expertise than your core product.
And the cookies are not difficult on a technical level, you just have to spend time understanding the threat models and mapping those models correctly onto your own app.
Then customers come and ask for SSO, SAML, OIDC, their niche auth protocol, 2FA, Pass phrases, etc...
And now your auth is a mess and a dedicated job to maintain and evolve.
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.
Using a passwordless login from scratch (magic link + Google OAuth2, sessions stored in Postgres without an external auth vendor) gets us around that altogether. The fears about why one would avoid it are generally not justified. Deliverability is the only true problem. Address that, with a proper provider for transactions, and we’re in boring territory – which is the most delightful kind.
To move from Clerk to Better Auth is logical if the choice is between sovereignty and convenience. It’s the core problem that any group doesn’t want to confront right away: “How much of this am I truly willing to own?”
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.
just beautiful. nothing to add, clap clap