Get the top HN stories in your inbox every day.
tornikeo
SkyPuncher
It’s just a few fields until it’s not.
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.
sreekanth850
I don’t know when we became this lazy. Auth is hard, sure, but putting your users table and sessions behind a vendor API is not something cool. Tell me one feature that is not supported by libraries like OpenIddict (You can build around) or Keycloak?
hylaride
If you're a SaaS vendor, you want to make onboarding and logging in as easy as possible and being able to do things like add a "login with google/apple" button or other third party SAML/SSO tooling is one way to do that. Supporting that workflow sucks as it can involve very finicky integrations involving certificate trusts, etc.
sevenzero
I think the main argument usually is time savings. Personally I just always do E-Mail and password auth, yea its old and not the shiny new thing, but it doesn't require me to integrate 200 different ways of doing auth.
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.
selfmodruntime
Well the disadvantage is that you're responsible for your companies keycloak.
jarym
"home built auth system" is bound to have "random SSO issues". You fix them, that's how things mature.
tomrod
Supabase's auth is MIT licensed and OSS, is it not?
SkyPuncher
Yep, it’s just a drag. It’s not our core product value so any effort we put into it is a drag.
rubogubo
I'm guessing they simply didnt want to spend the time and money doing that
moooo99
> 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.
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
Gareth321
There is a trust component for sure, but a business requires assessing the value of time against revenue. I can say for our org that using an off the shelf solution like Clerk saves us time and money and we believe the risk is very small relative to the savings. Maybe the cost for you is not large right now, but when you've got 20 enterprise customers all asking for specific OIDC integrations configured with Private Link, custom domains, and private clusters, an auth solution starts looking mighty fine.
amluto
Is this perhaps a reason to have a Users table that is separate from the table of data on how you authenticate that user?
sebmellen
Just use Ory Kratos and self host it.
EtienneK
That’s when you install Keycloak.
faangguyindia
is it just me? who just uses magic links delivered via email or telegram as backup?
vinckr
Personally I hate magic links via email with a passion and will actively avoid products that have this as the only authentication method
impulser_
Majority of apps are B2C apps, they don't need any of this.
All you need is Apple and Google Oauth.
sandeepkd
If you are just starting out its probably a good idea. Think about the use case when google bans either your app or bans your app user?
mooreds
It depends on your use case.
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
therealpygon
Why pay someone to build a house? I’m sure you could do it yourself…but that doesn’t mean that is the best use of your time in all cases. The analogy is basic but apt; not everyone needs or wants to run (or create) every mechanism. I don’t do all of my own hosting either and it’s not because I couldn’t, it’s that it isn’t worthwhile in my cases.
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.
the__alchemist
I see Postgres etc as the builder. Supabase is more like the realtor; a middle man extracting profits and complicating the situation.
Orygin
Does Postgres talk OpenID connect directly? Does it integrate SAML easily?
Oh you still have to build the auth system yourself? Well maybe a realtor does sound good now.
pietz
This comment is more ridiculous than ever in 2026.
gessha
If you’re implying that people should __always__ roll their own services and never vendor out non-core parts, the security industry would love to learn where you work.
arikrahman
Yes the analogy doesn't work here because that is much more cost prohibitive and labor intensive.
ajdegol
Because of AI or because hackers are hyper targeting infra clusters?
dnnddidiej
Emperor, meet clothes.
notatoad
>that doesn’t mean it’s the best use of your time in all cases
Okay, so… what are those cases? I’m also curious.
elevation
> 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.
fnoef
This is such an absurd take.
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.
square_usual
> For starters, if I'm a "house builder" by trade
You're not a house builder, you're a widget maker who needs a house to live in. Auth is almost never your startup's core competency or offering. Spending one of your very valuable five engineers on the auth tarpit while you lose deals because SSO is hard could be life and death for you.
egorfine
Because auth is a productivity tarpit. Anything plan on doing with auth looks simple but almost never is. Homegrown auth can easily sunk half of your dev and support teams.
Of course, we're not talking about email/password with "remember me" checkbox kind of auth.
aatd86
I wonder if it is not people being notoriously lazy or clueless at an astonishing degree. How often do you hear that password were saved in plaintext? Surprisingly high in this day and age.
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...
selfmodruntime
Your comment has a bit of an inexperienced smell. Business auth infinitely more complex than saving a user and salting/hashing his password.
> There must be a behavioral pattern there...
The pattern is that your comment is very far from reality.
egorfine
> want to delegate those tasks to someone else perhaps
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.
eddythompson80
Don't you wanna level up your career to become an architect? You can draw a box, call it "User Management" and slap "Clerk" or some other SaaS on it, and assume it's managed for you. This allows you to shove whatever requirements you want in that magic blackbox as you feel "it doesn't bring value" for you to implement.
jarek83
I must as intelligent as you because I also never understood why things like supabase even exist. I believe this shows how much front-end dev world is detached from how things can simple and secure by default.
dnnddidiej
Do you say the same about AWS RDS. Are you saying VMs is all you need and it is a doddle for anyone with FE only experience to set up, maintain and scale.
kevmo314
Yes many people do say the same about AWS RDS.
f3408fh
Yeah you’re a bit confused. Supabase has nothing to do with frontend other than providing SDKs and some frontend components to integrate with their backend.
the__alchemist
I am just as confused as you. My 2c: For a broad range of requirements, running your DB directly and managing auth with Django or similar is easier. Perhaps at enterprise scale, this changes.
jonas21
That's what they did. They migrated to Better Auth, which stores everything in your DB. It's the equivalent of Django auth for the Typescript ecosystem.
throwaway613746
[dead]
oompydoompy74
BetterAuth is users in your own database. So you don’t have to!
il
People are very scared of messing up authentication and getting hacked. They would rather offload that responsibility to a third party and not think about it.
sandeepkd
Unfortunately this is a common premise and on surface its a good idea too to let a expert in particular domain handle it. Where it gets muddy is when this third party are themselves learners and just see this as a good business opportunity
bekacru
Hey, Bereket from Better Auth here. I started Better Auth to solve this exact issue for myself, and it later turned into a company. It always give me joy to just see others getting the same value from it :) There is a lot to work on, would love to know what we can improve
rbbydotdev
Do you think the complexity of auth in the browser, is because browsers don't do enough?
bekacru
I think auth is complicated outside of browsers too. But browsers do make some things uniquely confusing, especially cookies and general security primitives are full of footguns
pc86
Not who you're replying to but browsers do way too much. Load the code you're given and don't do anything else.
mooreds
FedCM might be of interest to you. It's one effort to make browsers do more around authentication.
Wrote an article about that here: https://fusionauth.io/articles/authentication/fedcm (hosted at my employer's website)
JSR_FDED
So let me be the one to invite ridicule and scorn by admitting I wrote my own auth code. It was fiddly and boring at the same time. It also wasn’t rocket science, and it works well. I’ll be the first to admit that there are cases where this is a bad idea, I’m just responding to the chants of never roll your own auth.
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.
dvt
Kind of funny how something that used to be routinely self-written has been outsourced to libraries. I must’ve written auth like a few dozen times back in the PHP days, not particularly hard or complicated. There’s a million tutorials on how to salt and store passwords. I’ve had my sites attacked many times, but never breached. (JWT, OAuth, etc. has added a ton of surface area, however. So these days it’s inevitably harder to do.)
brabel
Username and password as the only option to authenticate is really getting obsolete. You need to support social login, passkey, email links, maybe SMS or some other less secure methods depending on your target market… and more often also new standards like verifiable credentials with wallets managing credentials, including logins. Good luck writing your own implementations.
princevegeta89
I recently worked at a stupid startup where the entire logic of the app was basically delegated to several third-party services out there. It felt like an absolute piece of shit overall. Following the flow of things end-to-end was a nightmare. It was so stupid because the so-called co-founder PM at that company thought it would be cool to keep doing that.
I am with you on this.
Urahandystar
Thats because the goal of the start-up is to prove they have a viable business not build fancy tech.
princevegeta89
At the same time, it also made things three times more complicated when it came to debugging. They found themselves swimming in the shit
j45
It's not that crazy. It can take time to do and get right, and is time away from other things.
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.
ipnon
It’s not that crazy! Or hard. If you can store a hashed password in your users table, and keep the salt secret, you have working auth.
SahAssar
I'm not discouraging anyone from writing your own auth, but if you have even a little bit higher requirements it becomes more complex. For example I have audited codebases where the TOTP code was enough to get a valid token (without a password, due to a bug), where there was no rate limits on password attempts and one where the password lockout system meant that you could DDoS all admin access trivially, etc, etc. That's even before you need to integrate with a third party via something like OIDC or SAML or SCIM which are probably needed for a product used by businesses these days.
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.
Capricorn2481
> and one where the password lockout system meant that you could DDoS all admin access trivially
What happened there?
skrtskrt
Cookie management and CSRF stuff harder to get right, hashing passwords is completely trivial with and library.
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.
gkoz
If you believe salt has to be kept secret, yeah, don't write your own auth.
LVB
And then the client asks for SAML & OIDC support, and codes via SMS, and god knows what else.
Orygin
Indeed. Password auth was always easy to do, and it seems half the commenters here think that's all you need in modern times.
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.
benatkin
I'm actually surprised val.town outsources it. So what you're doing makes sense to me.
wxw
I enjoyed the Supabase migration article from a while ago (https://blog.val.town/blog/migrating-from-supabase) as well. There's a shortage of good, honest writing on long-term engineering decisions, please keep up the blog!
BoppreH
> A hard lesson you learn building a complex system is that its reliability is the minimum of the combined reliability of its critical parts.
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.
gordonhart
Learned this one the hard way during the last major CloudFlare outage. I don't use them, but their outage bricked my app for hours anyway because the Auth0 public keys used to verify JWTs were served behind CloudFlare, breaking the entire auth chain. Fun!
snide
This is why I'm so thankful I went with Lucia early. They sort of sunset their library and replaced it with documentation (and some small utilities) for how to manage and host authentication for yourself. It's always presented as some big, scary thing you can't manage yourself, but I found that taking the week to learn how security and basic salting works, I was able to feel more confident about how everything worked.
lioeters
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.
_heimdall
I'm surprised to see so many top comments here promoting building your own auth. For years I've only heard "never roll your own auth."
DimmieMan
I think it's a correction, There's multiple levels of interpretation:
1. Don't roll your own crypto
2. Don't roll your own auth strategy
3. Don't Roll your own auth code
4. Don't host your own auth infrastructure.
For the last few years level 4 has been aggressively pushed with a lot of advertising spend to push people towards prohibitively expensive hosted providers. Donning a tinfoil hat for a moment, auth as a service companies have made everything seem substantially more difficult than it is too for simple needs.
Now we're seeing a correction back to 2 and 3 as people way up the risks of SaaS vs just using a easier to manage local library and discovering it's not as scary as it's been made out to be if you follow now fairly well established patterns.
the providers aren't going anywhere, people still need them for a variety of reasons but their time as the default is ending and whether this is good is to be determined.
jpalomaki
It’s likely because the quick thought is that auth is just user table with hashed password.
Then when you really start thinking about it, the list of requirements grows.
Of course it’s still totally doable for an average developer, but takes time and mistakes can be catastrophic. And maybe the time is better spent developing stuff that differentiates you from others.
small_scombrus
There are few hard and fast rules, but "never use something that could change as a primary key" and "never roll your own Auth" will always be true
nkmnz
For me, the real issue of switching auth providers hasn’t been touched: do thy all use the same hashing functions or how did they move the password hash column across providers? Running them in parallel and rehashing on first login?
arian_
The auth migration cycle is the startup version of moving apartments. You swear each time will be the last, you lose stuff in the transition, and somehow the new place has the exact same problems as the old one but in different rooms.
kreidema
Been using BetterAuth for half a year/one year now. It's exactly what I always wanted when using Clerk (and its free as a side effect). I was never a fan of the "we'll manage your user Table", always set up the Web hooks to sync everything to my own user table, but still loved the development experience clerk provided (most of it).
I will never go back. Lets see if in 3 years I have a different opinion, but I can't imagine so.
luodaint
Notable that in each step, there’s an added abstraction; specifically, an authentication abstraction is the hardest one to reverse.
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?”
WilcoKruijer
You could almost call the comparison between Clerk and Better Auth unfair. One is a service and one is a library, apples to oranges. Any third-party service integrated into a stack is a liability, libraries as well, but to a lesser degree. It’s about time for more services to be replaced by libraries. Better Auth really shows how to do that imo, it’s a library that integrates on the frontend, backend, and database. This is why it’s so good.
Get the top HN stories in your inbox every day.
Can someone more intelligent then me tell me why should I offload my postgres users table to some 3rd party provider? Like what is so hard about keeping that table in my VM on hetzner that I have to give it off to someone else? It's not payments, it's just a few fields of data