Next-auth: Add Email and Password authentication example

[OmkarKirpan]

Please add email and password based authentication example.
I am trying to authenticate using API in signIn() method and returning user object but it is not getting stored in local storage.
OAuth is working great.

[iaincollins]

Hi there. This should work - if you have a repo you can share I would be happy to take a look.

[onomatopoetry]

Hello, I am trying to conduct a very simple test of the custom signIn() function to log in with a username and password. I've downloaded the example from github, run npm install in the 'example' directory, then npm run dev. Without modifying anything else in the example, I've uncommented the signIn() function in next-auth.functions.js, and altered it like so:

signIn: ({form, req}) => {
  return new Promise((resolve, reject) => {
    // Should validate credentials (e.g. hash password, compare 2FA token
    // etc) and return a valid user object from a database.
    /*
      return usersCollection.findOne({
      email: form.email
    }, (err, user) => {
      if (err) return reject(err)
      if (!user) return resolve(null)

      // Check credentials - e.g. compare bcrypt password hashes
      if (form.password === "test1234") {
        // If valid, return user object - e.g. { id, name, email }
        return resolve(user)
      } else {
        // If invalid, return null
        return resolve(null)
      }
    })
    */
    resolve({id:1234, name: 'Test', email: '[email protected]'})
  })
}

Now when I visit http://localhost:3000/auth/credentials and input anything into the "Email Address" and "Password" fields, I appear to login successfully. I see in the network tab that /auth/signin is being visited, followed by the callback.js page. I'm then returned to the index page _but i am not signed in._ The session object does not include a user object, and the "Manage Account" and "Sign out" links are not appearing.

What am I doing wrong?

[onomatopoetry]

After tearing my hair out for hours and hours I finally found where I went wrong - in next-auth.functions.js, the deserialize method must bet modified so that it _also_ returns a promise which resolves to {id:1234, name: 'Test', email: '[email protected]'}. This will ensure that the req.user object is always populated correctly with the dummy user by passport after a log in!

But here's a more sensible test. First, uncomment the signIn function in next-auth.functions.js. Then, under the line reading const nextAuthOptions = await nextAuthConfig() in the index.js file at the root level of the example, just add the following two lines:

const insert = nextAuthOptions.functions.insert
insert({name: 'Test', email: '[email protected]'})

Finally, at http://localhost:3000/auth/credentials, simply log in with the email '[email protected]' and the password 'test1234' (this password is alredy hardcoded in the example in next-auth.functions.js)

[ericvrp]

Do we have authentication with password (/should I create a feature request)?
I could not find it. Logging in with just an email address is nice but I think my users expect a username(email) and password login.

[LoriKarikari]

@ericvrp it's already on the roadmap.

[tiivik]

Is authentication with password planned to include password reset flow as well or should I create a feature request?

[iaincollins]

Is authentication with password planned to include password reset flow as well or should I create a feature request?

Support for arbitrary credentials (e.g. username, password, two factor authentication token, etc) is planned for version 2 (but not for launch) and the implementation is currently under consideration.

I did a write up about it somewhere in one of the pull requests or other issues, but I forgot where I put it - I need to turn it into an issue.

My gut feeling is that probably won't included a password reset feature and I am inclined to think I would ultimately reject feature request as I don't want to encourage people to store user passwords because it invariably leads to less security for users (even if we do support the feature for those that need it).

However, I think would be reasonable and helpful would be for us to have example code in the documentation people could use use to add a route to handle password resetting if they really wanted to do that.

Other considerations are that any page we do we also want to make it possible to customise, and every extra page we add means extra work to support that and to keep the documentation updated (and currently we are missing some custom page documentation and examples as it is).

I am not absolute about this and open to having my mind changed on it, but that is where I sit on the issue right now. I don't find it an easy decision.

I think it's too early for pull request - I still haven't gotten around to the existing one @jamespfarrell raised, but do want to address this.

Please feel free to actually make a feature request for this, as at least we can discuss it there and people can voice their thoughts on it.

[antoniomarcosferreira]

I am also in need of this feature, unfortunately the users of the application (Brazil) are not used to authenticating only via email. I can help with something too.

[iaincollins]

Thanks for the offer!

We are not looking for help implementation right now; I'd actually prefer it if people didn't submit implementations for this feature as they tend to only consider their own use cases and not wider use cases, such as how it might work with 2FA, FIDO U2F, certificates, password constraints and other authentication journeys (especially edge cases).

The challenge is providing an API that supports positive authentication patterns (like 2FA, U2F) in a way that doesn't create a foot gun whereby developers enable username and password support without thinking about the implications and considering the tradeoffs (and the risks they are exposing people to by making that decision).

[iaincollins]

I'm closing this issue as it relates to v1.

There will be a specific issue for this when we come to look at it in v2.