The API looks basically the same as any auth library and i have no idea how you approach this differently than other solutions?
I checked out the docs and it looks great and you seem to have all the bases covered but I think having a Why in the intro is helpful and comparisons to other solutions like next-auth, supabase auth etc.
The only place where "node" is necessary is for password hashing, and as there’s no cryptographically secure way to hash passwords on CF Workers or other edge runtimes it's not really an option. At this stage of the project, supporting Deno isn't a priority but for those not using email and password auth, CF Workers and other edge/serverless runtimes should work just fine
None of the hashes available in webcrypto's digest() are suitable for storing passwords (eg it doesn't support argon2, scrypt, bcrypt, or PBKDF2). They are all SHA family hashes.
You can use PBKDF2 through the deriveKey() function. So you could use that to store passwords. However, this is the least preferred of the acceptable algorithms, and is only recommended for use in scenarios where you must follow a standard that mandates the use of PBKDF2.
As someone who literally jumps on any passkey I see given to me as an option - I hope people are using them because I just want to use them more.
Passwords are dumb for most use cases. They’re okay if you follow best practices, the thing is 99% of people don’t. So most people re-use passwords, and if asked to create new ones they append a character or something ineffective.
No thanks, just do a LiDar scan of my face and get me into Netflix please.
>Passwords are dumb for most use cases. They’re okay if you follow best practices, the thing is 99% of people don’t. So most people re-use passwords, and if asked to create new ones they append a character or something ineffective.
This may be dependent on your social. Everyone I know uses password managers, even at work. So they have different passwords for every account and browser/phone extensions or apps to fill them in.
That only solves half of the problem though. Since many people do not use password managers (and thus potentially reuse their passwords, there's still an incentive to obtain stored password hashes. With passkeys, the public keys stored in any given provider's database are useless—so any provider switching to Passkeys rids themselves of a big attack vector. Just think about a possible feature without rainbow tables, large credential leaks, and so on. That's what Passkeys enable.
The problem with those packages that are "all inclusive" is that you end up depending on a very large number of third party packages, even if your use case probably doesn't require it
The project explicitly states it as a non-goal, which seems odd to me as I haven't dealt with a REST api that was session based in a decade. Pretty much everything is JWT based.
Honestly, I can't think of any commercial software I've been involved with or API interfaced with that has been written in the past ten years or so that hasn't used JWTs.
I cannot comment on the quality of the library, but please change the name to something else than "Better auth" - such generic names are difficult to search for. You do want your users to find stuff relating to the library without false positives, right?
Thanks for the suggestion. Surprisingly, it’s actually quite easy to search for. There aren't much false positives. It’s already the first result that comes up on Google.
I seriously doubt that. If I google Best auth, or "Best auth", or best-auth, or "best-auth", I'm getting generic results (eg. a Reddit thread about best auth library).
Looks pretty interesting, I see it supports social logins but doesn't look like generic oauth oidc / saml is supported yet - I think that'd be the killer feature, as rolling your own user/pass login isn't all that hard but generic SSO is where things get tricky.
If you added that, I've started working on a SCIM client implementation in typescript that could be a nice complement (or just jumpstart) in future (https://github.com/mnahkies/node-scim)
This looks promising! I agree with the need for more practical examples in the README. Authentication can be tricky, and clear code samples would definitely help to highlight how this library stands out. I’ll keep an eye on this—always looking for better TypeScript solutions.
i dislike auth libraries directly messing up with db forcing particular table schema on apps but i keep seeing it in most auth libraries in typescript/js ecosystem.
It isn't uncommon to keep auth in a separate DB from the rest of your application. Your application shouldn't care about the schema of anything auth related, other than how you match an authenticated session to an application identity.
Can you share your reasoning behind the tagline? It seems like a hard sell, which doesn't necessarily help the otherwise gorgeous looking website and solid-seeming API choices. Like;
JWT-Based Authentication: We won’t support JWT-based auth unless provided by a third-party plugin.
Right there you've missed something that, say, next-auth covers natively + extensively. What kind of "comprehensiveness" are you targeting?
EDIT: Wow, just want to double down on the "gorgeous website" comment after clicking through your docs. Well done, inspiring work! Clear, concise, and eminently navigable.
Thanks for the kind words! I don’t think a single library should support two fundamentally different session methods—it adds unnecessary complexity, especially with the plugin ecosystem. That said, I could see it being added as a plugin if there’s a real need.
In that case I'd agree with the GP comment - it's not comprehensive, it's opinionated. Opinionated is not a bad thing, the 'comprehensive' bit feels misleading though as auth is a vast subject. The two topics I wondered about immediately when I saw that word simply weren't there.
I've rolled my own before (including implementing several distinct F500 SSO variants atop it). I'm sympathetic to the benefits of that, but I think most Web developers would get the nuances of it wrong, to the point of increasing both system downtime and security vulnerabilities.
That said, I recently went to add off-the-shelf JS/TS authn to a new SvelteKit app, looking at a few different packages, and was surprised how rough it was to do any method other than sell out your users to adtech companies just a little bit more. (The last off-the-shelf auth framework I used, for Python Flask, was more straightforward to add, and for a rich feature set.) So there seems to be an opportunity to do better.
I think I'll probably use Lucia for my second attempt, though initially Auth.js looked like it would work more rapidly out of the box.
(I threw out the first attempt, and decided that my most urgent needs, for standing up the beta site and then showing previews for prospective partners, only needed a mix of Nginx HTTP Basic Auth and then simply non-public URLs. Which I could do in minutes, and would also have lower friction for partners to look at. Once authn for normal users percolates back up the project management urgency-sorted backlog, I'll take another quick look at off-the-shelf options, in case there's changes, and then expect I'll probably go with Lucia. Or maybe this Better Auth will be looking like what I want.)
Yup, come to the same conclusion. I browsed the source of this project, in particular the password hashing and encryption, it seems overcomplicated compared to a KISS bcrypt implementation. I’ve also spent way too much time integrating Auth0 on previous projects, and I now think the cost/benefits of using third party auth is very debatable.
Looks interesting but the README desperately needs a few practical code samples to demonstrate usage.
Sidenote: HN generally frowns on creating sock puppet accounts to post identical Show HN under different user names:
https://news.ycombinator.com/submitted?id=khanmitdoit
https://news.ycombinator.com/submitted?id=bekacru
The API looks basically the same as any auth library and i have no idea how you approach this differently than other solutions?
I checked out the docs and it looks great and you seem to have all the bases covered but I think having a Why in the intro is helpful and comparisons to other solutions like next-auth, supabase auth etc.
With direct dependencies on Node.js modules, you outright prevent using other runtimes like Cloudflare workers, Deno, etc.
Node has decent support for WebCrypto, for example, which renders all usages of node:crypto obsolete.
At this point, I’d also argue that anything not promoting PassKeys as the default method is on the wrong track.
The only place where "node" is necessary is for password hashing, and as there’s no cryptographically secure way to hash passwords on CF Workers or other edge runtimes it's not really an option. At this stage of the project, supporting Deno isn't a priority but for those not using email and password auth, CF Workers and other edge/serverless runtimes should work just fine
Is there a reason the web crypto api doesn’t work?
CF workers support it: https://developers.cloudflare.com/workers/runtime-apis/web-c...
Most browsers support it: https://developer.mozilla.org/en-US/docs/Web/API/Crypto
(I am not a cryptographer.)
None of the hashes available in webcrypto's digest() are suitable for storing passwords (eg it doesn't support argon2, scrypt, bcrypt, or PBKDF2). They are all SHA family hashes.
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
You can use PBKDF2 through the deriveKey() function. So you could use that to store passwords. However, this is the least preferred of the acceptable algorithms, and is only recommended for use in scenarios where you must follow a standard that mandates the use of PBKDF2.
You can rename the project to "The most comprehensive authentication library for node" then.
Noone uses passkeys
As someone who literally jumps on any passkey I see given to me as an option - I hope people are using them because I just want to use them more.
Passwords are dumb for most use cases. They’re okay if you follow best practices, the thing is 99% of people don’t. So most people re-use passwords, and if asked to create new ones they append a character or something ineffective.
No thanks, just do a LiDar scan of my face and get me into Netflix please.
>Passwords are dumb for most use cases. They’re okay if you follow best practices, the thing is 99% of people don’t. So most people re-use passwords, and if asked to create new ones they append a character or something ineffective.
This may be dependent on your social. Everyone I know uses password managers, even at work. So they have different passwords for every account and browser/phone extensions or apps to fill them in.
That only solves half of the problem though. Since many people do not use password managers (and thus potentially reuse their passwords, there's still an incentive to obtain stored password hashes. With passkeys, the public keys stored in any given provider's database are useless—so any provider switching to Passkeys rids themselves of a big attack vector. Just think about a possible feature without rainbow tables, large credential leaks, and so on. That's what Passkeys enable.
node:crypto seems to be supported by Deno's compatibly layer
Better auth has passkeys
The problem with those packages that are "all inclusive" is that you end up depending on a very large number of third party packages, even if your use case probably doesn't require it
https://npm.anvaka.com/#/view/2d/better-auth
Likely the most comprehensive library lacking JWT support.
I can't remember last time I used anything but JWT at work.
I was wondering about this too.
The project explicitly states it as a non-goal, which seems odd to me as I haven't dealt with a REST api that was session based in a decade. Pretty much everything is JWT based.
Honestly, I can't think of any commercial software I've been involved with or API interfaced with that has been written in the past ten years or so that hasn't used JWTs.
The devs are clearly biased.
Look, i have Oauth2 trauma, and hate ForgeRock, but that doesn't mean they don't have a place
I cannot comment on the quality of the library, but please change the name to something else than "Better auth" - such generic names are difficult to search for. You do want your users to find stuff relating to the library without false positives, right?
Thanks for the suggestion. Surprisingly, it’s actually quite easy to search for. There aren't much false positives. It’s already the first result that comes up on Google.
I seriously doubt that. If I google Best auth, or "Best auth", or best-auth, or "best-auth", I'm getting generic results (eg. a Reddit thread about best auth library).
If I Google SAW, I don’t get AWS as a result, I’ll reach out to them for you to change their name.
Oh, did I make mistake by remembering the wrong generic name? If only it could have been prevented...
Looks pretty interesting, I see it supports social logins but doesn't look like generic oauth oidc / saml is supported yet - I think that'd be the killer feature, as rolling your own user/pass login isn't all that hard but generic SSO is where things get tricky.
If you added that, I've started working on a SCIM client implementation in typescript that could be a nice complement (or just jumpstart) in future (https://github.com/mnahkies/node-scim)
Thanks. Yeah that should be supported down the road.
This looks promising! I agree with the need for more practical examples in the README. Authentication can be tricky, and clear code samples would definitely help to highlight how this library stands out. I’ll keep an eye on this—always looking for better TypeScript solutions.
i dislike auth libraries directly messing up with db forcing particular table schema on apps but i keep seeing it in most auth libraries in typescript/js ecosystem.
It isn't uncommon to keep auth in a separate DB from the rest of your application. Your application shouldn't care about the schema of anything auth related, other than how you match an authenticated session to an application identity.
It might be better auth, but it really needs better docs!
Is this for node.js projects? I thought it would be something for a client side project.
Do checkout supertokens.com - open source auth. We have tons of features and also full TS support.
Why would I use this when I can just use keycloak and call it a day?
Can you share your reasoning behind the tagline? It seems like a hard sell, which doesn't necessarily help the otherwise gorgeous looking website and solid-seeming API choices. Like;
Right there you've missed something that, say, next-auth covers natively + extensively. What kind of "comprehensiveness" are you targeting?EDIT: Wow, just want to double down on the "gorgeous website" comment after clicking through your docs. Well done, inspiring work! Clear, concise, and eminently navigable.
Thanks for the kind words! I don’t think a single library should support two fundamentally different session methods—it adds unnecessary complexity, especially with the plugin ecosystem. That said, I could see it being added as a plugin if there’s a real need.
In that case I'd agree with the GP comment - it's not comprehensive, it's opinionated. Opinionated is not a bad thing, the 'comprehensive' bit feels misleading though as auth is a vast subject. The two topics I wondered about immediately when I saw that word simply weren't there.
The website is beautifully done.
Here it is: https://fumadocs.vercel.app/
edit: wow, i'm having fun and getting motivated by the creator. glad i went down this Saturday morning rabbit hole.
https://fuma-nama.vercel.app/blog
I'm not a big fan. I think the advantages of rolling your own fully custom auth outweigh the simplicity of a plug-and-play framework like this.
Sure, there might be some use-cases and I can see why people might opt for it, but not me...
I've rolled my own before (including implementing several distinct F500 SSO variants atop it). I'm sympathetic to the benefits of that, but I think most Web developers would get the nuances of it wrong, to the point of increasing both system downtime and security vulnerabilities.
That said, I recently went to add off-the-shelf JS/TS authn to a new SvelteKit app, looking at a few different packages, and was surprised how rough it was to do any method other than sell out your users to adtech companies just a little bit more. (The last off-the-shelf auth framework I used, for Python Flask, was more straightforward to add, and for a rich feature set.) So there seems to be an opportunity to do better.
Did you take a look at Lucia? If so, what were your thoughts on it?
I think I'll probably use Lucia for my second attempt, though initially Auth.js looked like it would work more rapidly out of the box.
(I threw out the first attempt, and decided that my most urgent needs, for standing up the beta site and then showing previews for prospective partners, only needed a mix of Nginx HTTP Basic Auth and then simply non-public URLs. Which I could do in minutes, and would also have lower friction for partners to look at. Once authn for normal users percolates back up the project management urgency-sorted backlog, I'll take another quick look at off-the-shelf options, in case there's changes, and then expect I'll probably go with Lucia. Or maybe this Better Auth will be looking like what I want.)
Yup, come to the same conclusion. I browsed the source of this project, in particular the password hashing and encryption, it seems overcomplicated compared to a KISS bcrypt implementation. I’ve also spent way too much time integrating Auth0 on previous projects, and I now think the cost/benefits of using third party auth is very debatable.