Top
Best
New

Posted by sync 3 hours ago

Better Auth is joining Vercel(better-auth.com)
82 points | 56 commentspage 2
agrippanux 2 hours ago|
Uggggg I just implemented Better Auth for our new product - time to start looking for backup plans. I used to be a huge Vercel fanboy but everything they have done in the last few years turns into a complicated mess.
__s 2 hours ago|
Silent execution of tremor was a pain in the ass trying to upgrade to nextjs 15 / react 19: https://github.com/tremorlabs/tremor/issues/148
RichardChu 2 hours ago||
Better Auth is great, I use it for all my projects. Congrats to the team!
slig 2 hours ago||
Love better-auth, and congrats to the team!
ebeirne 2 hours ago||
This is amazing although I would really like for them to explore filling the backend gaps. An acquisition of Trigger.dev or Inngest would be the obvious move and nobody would be surprised. Thoughts?
fnoef 2 hours ago||
Ah, here we go again.

Glad I decided to roll my own auth rather then using some library. I had a feeling that eventually they will join Vercel.

notatoad 2 hours ago|
Yeah, we rolled our own auth as well. Everybody says you shouldn’t, it’s a risk, etc etc.

but to me that’s less risk than our auth getting bought by somebody whose business goals don’t necessarily align with mine.

slig 1 hour ago|||
The data lives in your server, everything is yours, if that happens, you just fork or write your own. Not sure what writing yourself first buys here.
pzo 2 hours ago|||
why not instead fork repo just in case but still use better auth until proven wrong? In case they go evil you just build from you forked one. At that point you would still have to either maintain your own auth or better auth fork.

With current AI your agents probably still will be better with maintaining a fork. Auth libs have pretty limited API surfaces comparing to e.g. ui frameworks.

fnoef 2 hours ago||
I prefer to maintain my code, tailored for my need, than maintaining a massive library that has support for every authentication method there is, while trying to be as generic as possible and fit every business.
Raed667 2 hours ago||
I was wondering when that would happen, it was meant to be since the beginning
mrcwinn 2 hours ago||
I nearly considered using them recently. So glad I dodged the bullet!
ftchd 2 hours ago||
Ain't nobody buying Jose, yet
electriclove 2 hours ago||
Umm.. so what did you end up using?
mrcwinn 1 hour ago||
Keycloak is excellent.
whalesalad 2 hours ago||
Auth is not hard to roll yourself. Crypto: don't do it. Auth? Easy peasy.
mooreds 2 hours ago||
Oh man, it really depends(tm). If you are building a small internal app, sure, but you'd often still be better off leveraging a social provider or employee directory.

I work in the auth space (for FusionAuth) and we run into plenty of folks that started out rolling auth themselves. Just username and password right? A bit of hashing, salting and leveraging a built-in crypto library.

But then you need to add account recovery. And then MFA. And then registration. And then progressive registration. And then webhook integration. And then passkeys. And then SAML integration. And the delegated SAML setup. And then and then and then.

You're distracted from your core application by feature requests for your login system.

You have lots of options nowadays. Use a library provided by your framework (Rails, Spring, and Django have them), use a tool like Better Auth, use a third party system like FusionAuth or Auth0. But don't build undifferentiated functionality that impacts your user experience.

PS Of course, where I stand depends on where I sit, but I firmly believe that you should not build an auth system the same way you should not build a database.

whalesalad 1 hour ago||
This is kinda like the ORM vs no-ORM argument. I think that off-the-shelf auth will accelerate your development for sure (like an ORM) but eventually, you are going to feel constrained by the framework/tool you are using. You will need to work around it. You will find that using it 'correctly' results in poor performance, and so you deviate here and there. Pretty soon you tell yourself, "man I should have just used SQL" or "man, I should have just rolled my own auth". At least ~20 years of software dev has taught me this.

For an MVP or a prototype, I think it's okay to use an off-the-shelf tool. For something serious that will have long-term legs, I would do it myself. I hear all of your concerns and arguments and agree there are a lot of footguns. But again, having spent the better part of my adult life using and interfacing with these tools, I have an innate understanding of how to model auth correctly (separate it from the user, separate users from an 'org' or 'team' entity, etc).

You said it though, 'it depends' is really the right answer here.

mooreds 1 hour ago|||
That's a great analogy. My only addition would be the nuance of that data modelling is way more flexible than authentication (and this is said as someone who is continually surprised by the business requirements, standards, and complexities of auth). Data modelling, after all, needs to handle the entirety of reality (at least what can be mapped to a computer). So you're more likely to outgrow it.

I've heard plenty of stories of folks moving from homegrown auth to a off-the-shelf solution, but that's because I'm in the off-the-shelf auth space.

It'd be super interesting to hear stories of folks who went the other way, and outgrew their service provider's auth.

sbkis 1 hour ago|||
Can you explain what you mean by “separate users from an ‘org’ or ‘team’ entity)?
whalesalad 1 hour ago||
You are building your app with a single user in mind. They can create <thing> (blog posts, photo albums, code repositories, you name it). Eventually you realize, sometimes people are working in teams or groups. Multiple people need to have access to <thing>. So instead of architecting from the get-go that a <thing> is owned by a user (usually with some kind of FK, like an owner_id, or user_id) you want to start by having an abstraction there right out the gate. Things are owned by a team or org, and a user belongs to an org.

This is why a lot of SaaS you use these days will come with a "default project" or "default team" that might just be 1:1 with your own person. But injecting that abstraction layer makes it super easy down to the road to allow other individuals to join or participate in the management of those entities.

sandeepkd 2 hours ago|||
Unfortunately its a common misconception, it feels easy, however auth is a lot more harder to do it right, specially when it comes to recovery. A simple example, protocol like TOTP (time based OTP) uses the concept of shared secret and almost every implementation stores the secret as it is in their databases
whalesalad 1 hour ago||
I gotta say, this is not a very strong argument for not doing auth yourself.
nicce 2 hours ago|||
Rolling auth by yourself is very messy. Storing tokens correctly, rotating and using correct tokens, with correct parameters and so on. Endless footguns.
lackoftactics 2 hours ago||
also the conseqeunces of implementing it badly from scratch don't make sense if you can use battle-tested solution
djfobbz 2 hours ago|||
Correct! As a Ruby dev, I started using rodauth and never looked back! https://rodauth.jeremyevans.net/
esafak 1 hour ago||
Authentication or authorization? Why do people keep conflating them?
whalesalad 1 hour ago||
I think it is pretty obvious why they often get conflated. There is substantial overlap between the two. "Who you are" and "what can you access" are tightly related. Of course they do not need to be, but it's not a surprise that in the majority of situations they are.
zuzululu 2 hours ago|
im amused that people are still relying on third party for handling auth when you can roll your own now with LLMs
slig 1 hour ago||
It's not third party, it's a library you use and you store the data. Got tired of it? Write your own, the data is there.
lackoftactics 2 hours ago||
It's one of those things you shouldn't trust LLMs to such an extent; that part should be very solid because the consequences of bad practices are getting to front page of hacker news :)
zuzululu 1 hour ago||
depends what LLM you are using but most frontier models have seen almost every github/doc/best practices its very hard to get something like supabase/lovable type of mess unless you purposely prompt it to be bad without much inner knowledge but even then it is rectifiable with the right prompts
RideOnTime22 14 minutes ago||
Everything is "rectifiable with the right prompts" if you handwave the hallucinations it makes (which yes, even frontier models do. Or I guess all companies that had major outages within the past months were using fossil models).

And it's funny this same argument can be said since Sonnet 3.7. But the issues still pop up.