Open tclain-pillar opened 1 year ago
This sounds like a duplicate of https://github.com/nextauthjs/next-auth/discussions/4059 (If you agree, let's close this issue)
I've been thinking about this and I would like to support it in @auth/core
, although we'll need to document the caveat well, that the link in the e-mail will only work on the same device/browser the sign-in process was initiated from.
Description 📓
Currently the generateVerificationToken option in the email provider assumes that a completely random string should be generated.
This makes sense as the database adapter needs to persist a hash of the verification process
createVerificationToken
anduseVerificationToken
merthods.This assumption actually prevent advanced and more performant alternatives.
For instance a stateful approach put additional load on the database to persist, check and vacuum previous authentication verification codes.
I have had great success using self-contained, stateless encryption container such as iron-session.
An iron-session seal will contain the identifier of the user in itself as well as TTL. As such it does not need to be stored in database.
Ideally the generate verification method should pass the user identifier, so that stateless tokens can be used as follows:
Right now I can't use this method with the existing customization options as no arguments are passed to generateVerificationToken.
We'd simply need to replace https://github.com/nextauthjs/next-auth/blob/6132c3fa751b647dd8261ac9b30e24fb140a2f1a/packages/next-auth/src/core/lib/email/signin.ts#L15
with
Thoughts?
I'd be happy to help implement this feature.
How to reproduce ☕️
The email provider is as follow
generateVerificationToken expects no argument.
Contributing 🙌🏽
Yes, I am willing to help implement this feature in a PR