Add tokenGenerator to Email provider config

[firede]

Please stick to one distinct feature request per issue where possible and raise additional feature quests as separate issues. Try to avoid adding feature requests to existing issues in the comments of issues raised by other users.

Summary of proposed feature

Add tokenGenerator to Email provider config. example:

function randomMemorableToken(): string { /* ... */ }
// => "bacca-cavort-west-volley"

providers: [
  Providers.Email({
    tokenGenerator: randomMemorableToken
    server: {
      // ...
    },
  }),
],

Purpose of proposed feature

Customize notion style email:

Detail about proposed feature

next-auth/src/server/lib/signin/email.js

Lines 12 to 13 in c6d6d9c

	// Generate token
	const token = randomBytes(32).toString('hex')

const token = provider.tokenGenerator ? provider.tokenGenerator() : randomBytes(32).toString('hex') 

Potential problems
Usually need to be used with sendVerificationRequest.

Describe any alternatives you've considered
A clear and concise description of any alternative options you've considered.

Additional context
Any other context, screenshots, etc.

Please indicate if you are willing and able to help implement the proposed feature.
Yes! if the idea is accepted.

[iaincollins]

@firede Thanks for the submission. This is a great idea!

I don't know what we should call the function - maybe something like verificationToken() or generateVerificationToken() or createVerificationToken() - but I would be very happy to support and test this and to collaborate on the implementation.

I can see how, if we implemented this, it would be easy to extend later (e.g. to support things like 2FA input, SMS, etc) which is something a few folks have asked about.

In the immediate term, this really nicely solves the problem of people signing in to a browser on a device that does not configured to receive email at the email address they are using (e.g. by checking their phone and typing in the code in the browser on whatever device they are using).

Regarding implementation, the verification URLs already have the Provider ID in the URL (e.g. in the provider=email query string below is actually the provider.id value:
https://next-auth-example.now.sh/api/auth/verify-request?provider=email&type=email

With that in mind it would be very easy to update the verification page to handle displaying an input box if an option (e.g. provider.showVerificationTokenInput: true) is set on the provider. We could do something similar in the email provider template that also changes how it appears depending on if the option to display the verification token is enabled or not.

I'm very happy to help with aspect as needed.

[firede]

@iaincollins Thanks for the comments.

maybe something like verificationToken() or generateVerificationToken() or createVerificationToken()

I voted for generateVerificationToken, the style is consistent with sendVerificationRequest.

With that in mind it would be very easy to update the verification page to handle displaying an input box if an option (e.g. provider.showVerificationTokenInput: true) is set on the provider.

Another option I recommend to use showVerificationToken, which makes sense in both the verification email and the verification page.

I will try to create a PR for this.

[stale]

Hi there! It looks like this issue hasn't had any activity for a while. It will be closed if no further activity occurs. If you think your issue is still relevant, feel free to comment on it to keep ot open. Thanks!

[stale]

Hi there! It looks like this issue hasn't had any activity for a while. To keep things tidy, I am going to close this issue for now. If you think your issue is still relevant, just leave a comment and I will reopen it. (Read more at #912) Thanks!