Email

[zeemo25]

Provider type

Email

Environment

System:
OS: macOS 12.3.1
CPU: (8) x64 Apple M1
Memory: 21.21 MB / 16.00 GB
Shell: 5.8 - /bin/zsh
Binaries:
Node: 18.14.0 - /usr/local/opt/node@18/bin/node
Yarn: 1.22.19 - /usr/local/bin/yarn
npm: 9.3.1 - /usr/local/opt/node@18/bin/npm
Browsers:
Chrome: 110.0.5481.177
Firefox: 101.0
Safari: 15.4

Reproduction URL

NA

Describe the issue

Note: This is closer to a feature request than a bug. Might turn into a bug.

For email providers we store session data (email/sign in date) in the DB. And on client useSession calls the server checks the DB to validate the email parsed from the jwt in the payload is the same as the one in the DB.

Wondering why we need to compare the email in the DB to the email from the jwt payload server-side. It adds an additional lookup to the DB + makes us need to persist email data in the DB which increases costs for users. We already know the jwt (and the email in it) is valid because it's signed with a secret

How to reproduce

NA

Expected behavior

NA

[balazsorban44]

Could you clarify by an example what you mean?

Our Email provider currently only works with a database so the verification token (email+hashed random token) can be stored across requests/browsers.

When signing in, we hash the sign-in URL's token, and use the email+hashed token by checking if it's stored in the db, after which it is deleted (login links are one-time).

This is unrelated to using the JWT session though, which can be used even if you use a database. You can do so by setting strategy: "jwt" in the session config option: https://next-auth.js.org/configuration/options#session

(The default is to use a DB session, when an adapter is set)

Do I understand correctly that you have confusion aronud this? If you can give a concrete example, I might be able to help more

[zeemo25]

Example:

When using strategy: jwt along with an email provider and the default mongodb adapter we store the following:

1. Verification token (which is removed once the user clicks email magic link)
   
2. User entry (which is never removed)
   

Makes sense to store the verification token so we can verify the user email. But assuming we're using strategy: jwt along with an email provider I do not believe it makes sense to store the user entry after email verification. After the user clicks the magic link (and we have strategy: jwt) we should never need to query the user entry in the DB to verify user sessions.

[balazsorban44]

When using an adapter, a user is created (regardless the session strategy), in case it's being connected via an OAuth Provider. I guess if you don't expect adding one, then storing a user in the DB might be unnecessary. So yes, this is rather a feature request than a bug so I'm conveting it to a discussion/Idea.