[HN Gopher] Show HN: The most comprehensive authentication libra...
___________________________________________________________________
Show HN: The most comprehensive authentication library for
TypeScript
The most comprehensive authentication library for TypeScript
Author : khanmitdoit
Score : 56 points
Date : 2024-09-28 07:51 UTC (15 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| splatterxl wrote:
| 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...
| davedx wrote:
| 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.
| neilv wrote:
| 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 wrote:
| Did you take a look at Lucia? If so, what were your thoughts
| on it?
| neilv wrote:
| 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.)
| bbor wrote:
| 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 wrote:
| 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 wrote:
| 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.
| apsurd wrote:
| 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
| jakubmazanec wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| If I Google SAW, I don't get AWS as a result, I'll reach
| out to them for you to change their name.
| mnahkies wrote:
| 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 wrote:
| Thanks. Yeah that should be supported down the road.
| pdyc wrote:
| 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 wrote:
| 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.
| 9dev wrote:
| 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.
| dagmawibabi wrote:
| Better auth has passkeys
| bekacru wrote:
| 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 wrote:
| 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 wrote:
| (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 wrote:
| You can rename the project to "The most comprehensive
| authentication library for node" then.
| forty wrote:
| node:crypto seems to be supported by Deno's compatibly layer
| melenaos wrote:
| 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.
| bilater wrote:
| 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.
| forty wrote:
| 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
| codr7 wrote:
| Likely the most comprehensive library lacking JWT support.
|
| I can't remember last time I used anything but JWT at work.
| claytongulick wrote:
| 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 wrote:
| The devs are clearly biased.
|
| Look, i have Oauth2 trauma, and hate ForgeRock, but that
| doesn't mean they don't have a place
| vunderba wrote:
| 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
| blazing234 wrote:
| Why would I use this when I can just use keycloak and call it a
| day?
___________________________________________________________________
(page generated 2024-09-28 23:01 UTC)