Show HN: Comprehensive authentication library for TypeScript

72 pointsposted a year ago
by khanmitdoit
(github.com)

49 Comments

9dev

a year ago

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.

bekacru

a year ago

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

trescenzi

a year ago

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

maxbond

a year ago

(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.

pmdfgy

a year ago

You can rename the project to "The most comprehensive authentication library for node" then.

forty

a year ago

node:crypto seems to be supported by Deno's compatibly layer

Danjoe4

a year ago

Noone uses passkeys

willio58

a year ago

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.

mhuffman

a year ago

>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.

9dev

a year ago

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.

radicalriddler

a year ago

I mean, Cloudflare's done a lot of work in polyfilling a lot of node_compat stuff.

The only one is generally password hashing. At this point, I just run up a service binding to a rust worker and hash it over there.

jakubmazanec

a year ago

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?

bekacru

a year ago

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.

jakubmazanec

a year ago

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).

serial_dev

a year ago

If I Google SAW, I don’t get AWS as a result, I’ll reach out to them for you to change their name.

jakubmazanec

a year ago

Oh, did I make mistake by remembering the wrong generic name? If only it could have been prevented...

bilater

a year ago

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.

codr7

a year ago

Likely the most comprehensive library lacking JWT support.

I can't remember last time I used anything but JWT at work.

claytongulick

a year ago

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.

digger495

a year ago

The devs are clearly biased.

Look, i have Oauth2 trauma, and hate ForgeRock, but that doesn't mean they don't have a place

mnahkies

a year ago

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)

bekacru

a year ago

Thanks. Yeah that should be supported down the road.

melenaos

a year ago

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.

bbor

a year ago

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.

bekacru

a year ago

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.

politelemon

a year ago

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.

pdyc

a year ago

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.

zdragnar

a year ago

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.

user

a year ago

[deleted]

utkut

a year ago

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.

rishabhpoddar

a year ago

Do checkout supertokens.com - open source auth. We have tons of features and also full TS support.

blazing234

a year ago

Why would I use this when I can just use keycloak and call it a day?

splatterxl

a year ago

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...

neilv

a year ago

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.

mckirk

a year ago

Did you take a look at Lucia? If so, what were your thoughts on it?

neilv

a year ago

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.)

bschmidt3

a year ago

[flagged]

neilv

a year ago

">" is a convention for verbatim quotes. Please don't use it for paraphrasing.

Also, please try to avoid uncharitable interpretations, as well as ad hominem attacks. HN guidelines: https://news.ycombinator.com/newsguidelines.html

madeofpalk

a year ago

FWIW, it is a verbatim quote from their bio. Using one’s bio to dunk on them is an age old tradition.

Comment is still insufferable. Perfect caricature of SF HN tech bro.

neilv

a year ago

> FWIW, it is a verbatim quote from their bio. Using one’s bio to dunk on them is an age old tradition.

That's not what was paraphrased.

> Comment is still insufferable. Perfect caricature of SF HN tech bro.

I believe that a related idea, "Don't roll your own crypto[graphy]", is widely accepted good advice.

Authentication in Web systems overlaps with that, and has a bit of the same nature.

Though the nuances in Web systems aren't as hard as the nuances can get in cryptography math and protocols, and in computer implementation of same. Still, it's much harder than it looks, to get sufficiently right. Most people don't have time for that.

Personally, I take both seriously. I don't touch cryptography implementation myself directly. And lately (as I said in the original comment), I'm trying to use off-the-shelf Web authentication. Because, as I implied, it's hard get all the nuances right.

Aside: "Dunk on" of other commenters sounds to me like contemporary social media personal attack sport, which I'm trying to avoid on HN. When I stopped by HN on Saturday morning, to get a little startup business mindset/enthusiasm, before spending the day working on an indie Web project, I wasn't looking to have a reasonable assessment called "insufferable", by some random new account. (A new account of someone who seems to be having a bad day, and getting off on the wrong foot with HN, with every single of their 6 comments attacking other commenters.) And then, after I tried to respond reasonably constructively to them, some other person, who might've misread the situation, jumps in, to double-down for the new account. Maybe all 3 of us would like to start the day over, and not spread bad day contagion further?

user

a year ago

[deleted]

davedx

a year ago

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.

user

a year ago

[deleted]