Duplicate requests causing verification token to be invalidated

[michaelhays]

A user is attempting to log in via email (passwordless), and the login email is successfully delivered to them. When they click the login link in that email, I'm seeing two separate requests to /api/auth/callback/email?callbackUrl=...&token=...&email=... coming from two different IP addresses (in different US states), a couple of seconds apart.

The first request succeeds, which logs the user in. But that request uses the verification token from the email, which invalidates it, and so the second request to the same URL fails. The user ends up being redirected back to the login page, with ?error=Verification in the URL.

Any ideas for a workaround here? My temporary fix is to allow the verification token to be used an unlimited amount of times before its expiry, though that's not the most secure solution.

Separately, any ideas for why these duplicate requests are happening? I'm guessing it has to do with VPN routing.

---

Edit: If you want to allow the verification token to be reused, you can override useVerificationToken from your adapter, to prevent the token from being deleted after use.

For example, for the Prisma adapter, write this in your NextAuth.js options:

import { PrismaAdapter } from '@next-auth/prisma-adapter'
import type { NextAuthOptions } from 'next-auth'
import remeda from 'remeda'
import prisma from '~/prisma/client.ts'

const nextAuthOptions: NextAuthOptions = {
  adapter: {
    ...PrismaAdapter(prisma),
    async useVerificationToken({ identifier, token }) {
      const verificationToken = await prisma.verificationToken.findFirst({
        where: { identifier, token },
      })

      if (!verificationToken) {
        return null
      }

      return remeda.omit(verificationToken, ['id'])
    },
  },
  ...
}

[ejeatstofu]

I am seeing something similar here as well

[ejeatstofu]

@michaelhays could you share how you enabled the verification token to be used more than once?

[michaelhays]

You can override useVerificationToken from your adapter, to prevent the token from being deleted after use.

For example, for the Prisma adapter, write this in your NextAuth.js options:

import { PrismaAdapter } from '@next-auth/prisma-adapter'
import type { NextAuthOptions } from 'next-auth'
import remeda from 'remeda'
import prisma from '~/prisma/client.ts'

const nextAuthOptions: NextAuthOptions = {
  adapter: {
    ...PrismaAdapter(prisma),
    async useVerificationToken({ identifier, token }) {
      const verificationToken = await prisma.verificationToken.findFirst({
        where: { identifier, token },
      })

      if (!verificationToken) {
        return null
      }

      return remeda.omit(verificationToken, ['id'])
    },
  },
  ...
} 

[aaly00]

We are sending the user to a page that redirects the user to the magic link after a settimeout. This mitigates the need to create a token with no expiration date. This option should probably be built into next-auth.

You create a page like the one we have /auth/magiclink?redirect= with the redirect param set to the actual magic link. Then in your page you decide what logic you want to use. You can force the user to click a button, do an auto redirection after a set timeout, or both. You probably also want to check to make sure you're not creating an open redirect vulnerability in your redirection page.

 EmailProvider({
    async sendVerificationRequest(params) {
        const {
            identifier,
            url: callbackUrl,
            provider,
            theme
        } = params;
        const {
            host
        } = new URL(callbackUrl);
        // Create a url which redirects to host
        const NEXTAUTH_URL = new URL(env.NEXTAUTH_URL);
        const url = new URL(
            `${NEXTAUTH_URL.origin}/auth/magiclink?redirect=${encodeURIComponent(callbackUrl)}`
        ).href;
        // NOTE: You are not required to use `nodemailer`, use whatever you want.
        const transport = createTransport(provider.server);
        const result = await transport.sendMail({
            to: identifier,
            from: provider.from,
            subject: `Sign in to ${host}`,
            text: magicLinkEmailText({
                url,
                host
            }),
            html: magicLinkEmailHtml({
                url,
                host,
                theme
            }),
        });
        const failed = result.rejected
            .concat(result.pending)
            .filter(Boolean);
        if (failed.length) {
            throw new Error(
                `Email(s) (${failed.join(", ")}) could not be sent`
            );
        }
    },
    server: {
        host: env.EMAIL_SERVER_HOST,
        port: env.EMAIL_SERVER_PORT,
        auth: {
            user: env.EMAIL_SERVER_USER,
            pass: env.EMAIL_SERVER_PASSWORD,
        },
    },
    from: env.EMAIL_FROM,
}),

[michaelhays]

This is a great solution! Thanks for sharing @aaly00

[albertsikkema]

Thanks, that really helped!

[hatemelseidy]

Sharing a DynamoDB version for the useVerificationToken solution presented above. Note that sk and pk are hardcoded. You can set expires TTL parameter in DynamoDB such that tokens get removed after a TTL.

  adapter: {
    ...DynamoDBAdapter(
      client,
      {
        tableName: process.env.NEXT_AUTH_AWS_DDB_TABLE_NAME
      }
    ),
    async useVerificationToken({ identifier, token }) {
      const TableName = process.env.NEXT_AUTH_AWS_DDB_TABLE_NAME ?? "next-auth";
      const data = await client.get({
        TableName,
        Key: {
          ["pk"]: `VT#${identifier}`,
          ["sk"]: `VT#${token}`,
        }
      })
      return format.from<VerificationToken>(data.Item)
    },
  },