Magic Passcode

[iamthesiz]

Your question
I'm curious if there's currently a way to have the same behavior as the magic link, but instead send a 4-6 digit code to their email that the user can then enter in themselves on the site.

Also kind of like this but with email code instead of SMS code.

What are you trying to do
I'm working on a PWA and a magic link will take you directly to the mobile browser (ex: iOS Safari) instead of directly to the PWA. This is a way to get around that.

Feedback

• Found the documentation helpful
• Found documentation but was incomplete
• Could not find relevant documentation
• Found the example project helpful
• Did not find the example project helpful

[glenarama]

Also experience the same user experience issue - another way to solve this would be to handle email auth the same way https://magic.link/ or Vercel do. Rather than opening a new session, the link authenticates the original session.

[iamthesiz]

@glenames I thought about this. I guess I should take a deeper look into that.

[glenarama]

@alex-cory Its not possible with the current email auth implementation - its a suggested alternate feature request I guess. I think it's a fair bit trickier to implement because it would require a subscription to the database from the client requesting access.

[iamthesiz]

@glenames @iaincollins How does this flow look?

Also, what is the recommended way of adding the jwt or session token or csrf token to the frontend. I'm not quite sure how next-auth is setting these on the frontend so when calling useSession it will have the correct values to fetch the current session.

• /login frontend
  • type in email, click login/signup - POST { email, isAddedToHomescreen } to /api/auth/magic-link
  • if isAddedToHomescreen, subscribe to channel private-magic-link-me@gmail.com
    • on trigger event from channel private-magic-link-me@gmail.com - set JWT from socket body
• /api/auth/magic-link POST
  • create/get user with post body.email
  • create JWT with userId, email, isAddedToHomescreen and whatever else should go into the JWT
  • email user with link /magic-link?jwt=<the-jwt>
• /magic-link?jwt=<the-jwt> SSR page
  • in getServerSideProps
    • deserialize JWT to get email, trigger socket with JWT from query params as the socket body, send to channel private-magic-link-me@gmail.com
  • frontend
    • if isAddedToHomescreen display message saying "you have been logged in, now go back to your app added to your homescreen"
    • else client side redirect to home page

I'd be interested in helping put a PR together 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 it open. (Read more at #912) Thanks!

[iamthesiz]

keep alive

[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 it open. (Read more at #912) Thanks!

[iamthesiz]

keep alive

[iaincollins]

Thanks for bumping! Actually yes this is possible, but I don't think was ever documented.

1. A generateVerificationToken() callback can be used with email Providers. That will generate a unique token - and hash it in the database, so it is not stored in clear text. You can use this in conjunction with a custom sendVerificationRequest() callback to send either a custom email or trigger an SMS message.

   By default if generateVerificationToken() is not set, then it will generate some random bytes for the token:
   https://github.com/nextauthjs/next-auth/blob/main/src/server/lib/signin/email.js

   An implementation would look something like this:

 Providers.Email({
    generateVerificationToken: () => { return "ABC123" },
    sendVerificationRequest: ({ identifier: email, url, token, site, provider }) => { /* your function */ }
 })

A caveat is that, unlike all other callbacks, generateVerificationToken is assumed to be synchronous - i.e. it does not use await when it is called, which is a mistake and we should change that. (Maintainer edit. It IS called with await since 3.6.0)

2. Finally, you would also want to create a custom page for the /api/auth/verify-request route, as documented here:
   https://next-auth.js.org/configuration/pages

   Note you can actually have multiple providers that work this way (e.g. both Email and a custom one that does SMS) and handle them with pages that render differently, as the 'provider ID' is passed to the verification page, you would just need to set a custom id property on each provider instance.

For more information on customising the email provider, please see:
https://next-auth.js.org/providers/email

Additionally, there is also this guide to using SMS for sign in with Everify:
https://everify.dev/blog/two-factor-authentication-for-nextjs

This approach uses the credentials callback, which is perfect if you want stateless sign in without a user database - or if you want to use an existing user database in your own way.

---

I want to have built-in support for sending email codes like this, and potentially even make that the default behaviour for the email provider, as it makes it much easier to support cross-device sign in (e.g. start sign in on desktop, get email on phone, enter code on email and you are done).

I would also still support signing in by just clicking the button in the email; the messaging would just need to be right to not confuse users (as once the button was clicked the token would "used up" so you wouldn't want them clicking it on their phone by mistake).

We would need the built-in verify-request page to look a little different to accommodate short tokens like this (i.e. it would need to have form input elements for the code).

The final consideration is that shorter tokens really ought to have a shorter expiry time. This functionality is currently baked in to each database adapter (in the createVerificationRequest(), getVerificationRequest() and deleteVerificationRequest() methods).

Ideally I would like to see this abstracted out so that it is possible to use the Email provider without a database adapter, if you have these methods defined on the provider, although this is already possible with the existing callbacks (which can be very powerful) as shown in the example blog post.