Passwords

[broberson]

Description 📓

I understand that the developers of this library agree that password authentication is generally less secure and more error prone than password-less methods. And I agree with that.

However, developers who want to use password authentication are going to do it anyway. Many of us have no say in the matter; we implement the features we're told to implement.

The developers of next-auth are correct, password authentication is less secure. However, a password auth solution developed as a first-class citizen as part of this library would be far more secure than the various kludgy workarounds that developers are hammering the Credential Provider into, mangling JWT handling to trick the system into saving sessions to a database.

Discouraging the use of passwords in this way is like discouraging people from speeding by eliminating seat-belts and airbags from your vehicle design. This is not making web-applications more secure, and should be reconsidered.

Thanks for taking the time to read this.

How to reproduce ☕️

This behavior is by design, unfortunately.

Contributing 🙌🏽

No, I am afraid I cannot help regarding this

[Pab450]

It's not an issue, you're polluting, open a discussion, if it gets a lot of up they might reconsider the credentials provider.

[broberson]

It wasn't submitted as an issue. It was submitted as a feature request.

[luxaritas]

Worth cross-linking to #6177.

To be clear up front: I greatly respect the maintainers here, and their reasoning for taking their stance is understandable. However, I have concrete concerns about the current situation, which I'll share below.

Use Cases

There are multiple perfectly valid use cases for using normal credentials:

• DB seeding (Remove the shackles from CredentialsProvider #6177)
• Ease of local development or simple applications. If I'm developing an app, or if I'm building an app just for myself or select others, I don't want to bother setting up OAuth with third party providers, and I may not have a (reliable ) SMTP server for magic links.
• Security. Yes, passwords have problems. However, it may not be desirable to rely on/trust a third-party for authentication. Additionally, magic links also have issues (vulnerability to phishing, reliance on the security of transport to and storage on the email server, the email account being compromised, etc). Further, most likely, all of these will be authenticated with a username and password anyways, making many of the benefits moot.
• Privacy. Some users may not want to create an account with a third party provider, and some websites may even allow the opportunity to not even provide an email if the user prefers to even keep that private.
• For sites that allow multiple, completely-separate accounts, it creates significantly more friction if registering via username is not an option.
• User expectations. Unfortunately, whether we like it or not, and as much as our understanding of the security implications may be better, we still have to cater to users. Many users are liable to have expectations of being able to just provide their username/email and a password, and adding additional friction could lead to lost conversions or be a non-starter for stakeholders.

Why the current setup is insufficient

@balazsorban44 noted in #6177 (comment)

IMO the current primitive for this (authorize callback) gives you full flexibility.

This is, unfortunately, insufficient. As was mentioned in the OP of that issue, people are still going to do it but worse. JWT has security downsides compared to generated session tokens, but AuthJS users will either just use it because that's what's included out of the box, or they'll implement their own session token handling, effectively rolling their own auth when this library already handles it but not in a way that is able to be accessed by consumers. The existing setup would only be sufficient if, eg, AuthJS's built-in non-jwt session handling was able to be used when configuring CredentialsProvider. Additionally, if AuthJS also handled the credentials from end to end, including things like configuring the password hash to be used, that would further ensure anyone using it would be using a well-configured implementation.

As-is, the individuals who you're trying to discourage using it because they don't know the implications have a decent chance of doing it anyway but wrong, and those who know better but still need it are stuck between an inferior implementation or having to roll their own. IMO, it's better to have a few people do something that may not be ideal but in a validated manner vs having fewer people using it but having their implementations be much more liable to have serious security issues.

[luxaritas]

Also this seems like a bit of a weird hill to take this strong of a stance on when practically every other environment I can think of (auth solutions like Auth0, Keycloak, and Authentik, frameworks and CMSs like Django, Laravel, and Drupal, and high-profile apps like GitHub, Google, etc) support passwords. Additionally, strict security standards (FIPS, ASVS Level 3, etc) all allow for passwords - and their recommendations for stronger security are multi-factor authentication and authenticator protocols like WebAuthN - neither of which AuthJS supports. If passwords were problematic enough that they should be made hard to implement correctly (I'd be ok with complicated to implement period if the work between there and doing it right was trivial!), most of these should presumably not support or at least advise against passwords in favor of the alternatives you recommend (social login, for example, is unlikely to be preferred by ASVS where passwords are advised against).

[LFCavalcanti]

I've been struggling with this... I understand providing the whole backend for password support is a challenge... Hashing, Salting, Password reset, then email verification.
All that would be manageable if Next Auth would at least support Database strategy for session storage instead of forcing only JWT. This creates a whole new layer of problems with augmenting the session type in projects using Typescript, using a call back to extract information from the Token, like the "sub" property for the user ID.
The answer shouldn't be "use Auth0 or Clerk", those are third party services and if Next Auth aims to be used in enterpise applications, well, it has to be easier to work along side credential based backends.

[broberson]

Hacking on the code, it seems like it wouldn't be that horrible to implement a new provider that's basically a combination of the Email provider and the Credentials provider, specializing in authentication with a username/email and password.

There are a lot of places in the library where little changes would be needed to support another built-in provider, but it seems kind of do-able. The annoying part is doing it twice, in the "next-auth" package and all over again in the "@auth/core" package, while tracking all of the subtle little changes between the way they do things.

Also, I have no idea how one would trigger re-sending a verification email if the one sent when the account was created didn't get through. Just sending a new one every time someone tries to log in without verifying their email address seems like a bad idea. Might have to make "verify your email address" a separate thing that can be done regardless of how the user account was created and then leverage it to work with password authentication. There are probably other potholes like this to trip over as well, and I just haven't stuck my foot in them yet.

What I'm saying is that it wouldn't be impossible, even for someone new to the codebase, to implement this over the course of a couple of weeks. Someone who knows what they're doing, someone who's been maintaining and improving this for a year or more, could probably make this happen in two or three days and do a much better job of it.

[ncls-alien]

We don't really need all the special logic that Credential Provider asks for directly built-in. Would be nice but I am happy with how the Credentials Provider works at the moment minus the part that it can not be used with database sessions. That alone would make me the happierst person alive and Auth,js the most superior auth library in my eyes now that it also supports server-side rendering in app dir of Next.js.

[ncls-alien]

The thing is that by limiting Credentials Provider to JWT, they actually make it less secure since. If a dev wants to really have Credentials login then they will either go woith the hassle create a work around themselves and maybe they will even do it correctly (but some will also not), or they will just use JWT. As a user of a service that uses JWTs, you have no control over people logged into your account. You can't really invalidate JWTs and passwords are stored in the database either way.