VerificationToken is getting used before email link is clicked (production build)

[danberk4]

Question 💬

I'm having an issue where after our app has been deployed to run on our server (Ubuntu / Apache2) the verificationToken will immediately get utilized after the user submits their email to login on the sign-in page. The prevents them from login using the link sent to the user in their email because the token has already been used and deleted from the database. We are using the Email provider only.

I noticed in the debug logs that [next-auth][debug][adapter_useVerificationToken] is being called instantly after the user logs in. This never occurred on any builds deployed locally.

Any thoughts on why this is happening? Log below

[next-auth][debug][adapter_createVerificationToken] { args: [ { identifier: '[email protected]', token: '59ce8a420596af22c7d4a98650654a917547f313a6ae7e6658520abbfd0683e2', expires: 2022-05-19T19:14:14.725Z } ] }

[next-auth][debug][adapter_useVerificationToken] { args: [ { identifier: '[email protected]', token: '59ce8a420596af22c7d4a98650654a917547f313a6ae7e6658520abbfd0683e2' } ] }

[next-auth][debug][adapter_getUserByEmail] { args: [ '[email protected] ] } { email: '[email protected]' } [next-auth][debug][adapter_getUserByEmail] { args: [ '[email protected]' ] } [next-auth][debug][adapter_createUser] { args: [ { email: '[email protected]', emailVerified: 2022-05-18T19:14:18.372Z } ] }

How to reproduce ☕️

Sign In using the "Email" provider

Contributing 🙌🏽

Yes, I am willing to help answer this question in a PR

[danberk4]

After reading through the access logs for HTTP request from application I noticed that the link containing the verification token showed a GET request from a "Barracuda" network IP address before the login email hit my inbox.
It looks like some type of email filter is clicking the link while doing some kind of security scan.

See this discussion Do mail servers follow links in emails as part of a security scan before inbox delivery?

Are there any suggestion on how to get around this?
Altering the verification page to check for a human prior to using the token, maybe through a captcha of sorts?
Is there a proper way to preprocess the request when the magic link is clicked to look at where the request came from?

[Hikoya]

Hello, currently facing this issue too, is there any suggestions to this problem?

[joelhooks]

Is there any convenient way to make the VerificationToken allow for multiple uses within a certain window (or generally)?

It's less secure, but in outlet case that isn't a concern.

This issue is very aggravating.

[mikeebee]

I see a similar issue when clicking a link in Gmail (Inside Shift.app which could be a factor), the original URL has more added. From what I can see, Google is performing a malicious link check - https://support.google.com/mail/answer/10173182?hl=en

So for example, this link:

http://localhost:3000/api/auth/callback/email?callbackUrl=http%3A%2F%2Flocalhost%3A3000%2Fauth%2Fuser&token=83f08988d10e2c020e71efdc6d8bfaec5e4e14b815becd269c092c7b403d2ce4&email=mike%40threedivers.com

Becomes this when it hits the browser:

https://www.google.com/url?q=http://localhost:3000/api/auth/callback/email?callbackUrl%3Dhttp%253A%252F%252Flocalhost%253A3000%252Fauth%252Fuser%26token%3D83f08988d10e2c020e71efdc6d8bfaec5e4e14b815becd269c092c7b403d2ce4%26email%3Dmike%2540threedivers.com&source=gmail&ust=1674521721577000&usg=AOvVaw01dw8D0nbrvXrqGB-U3q17

So as mentioned above, (From what I can gather) the link is being followed by Google when I click it, and the verification token is being deleted before the real user can use it after the redirect.

The difference to the original poster is that I can see the verification token in the database before clicking the link.

If I copy and paste the link from the email, it works fine every time.

[mikeebee]

As a temporary solution, I have created a wrapper for the main adapter and overridden the useVerificationToken adapter method and replaced the delete function that was used with a get, so the entries aren't deleted. This means I will need to do some manual cleanup work on the database which isn't ideal but it has fixed my issue.

Bear in mind the tokens still have an expiry date so become useless after that time.

This is for DynamoDB but I think the concept would be similar for the other adapters as useVerificationToken is a required method across the board. i.e. you'll need to replace the delete query with a get query from whichever service you are using in /packages/adapter-[service-name].

/**
 * This file overrides the DynamoDB useVerificationToken adapter method for NextAuth.js
 * @next-auth/dynamodb-adapter v1.0.6
 *
 * We no longer delete the verification token after it's used in
 * useVerificationToken because we were having issues with
 * certain email clients hitting the link prior to the user
 * so when the user gets there the token is no longer valid
 *
 * Monitor discussion here:
 * https://github.com/nextauthjs/next-auth/discussions/4585
 */

import { DynamoDBAdapter } from '@next-auth/dynamodb-adapter';
import { format } from '@next-auth/dynamodb-adapter/dist/utils';
import type { Adapter, VerificationToken } from 'next-auth/adapters';
import type { DynamoDBDocument } from '@aws-sdk/lib-dynamodb';

export interface DynamoDBAdapterOptions {
  tableName?: string;
  partitionKey?: string;
  sortKey?: string;
  indexName?: string;
  indexPartitionKey?: string;
  indexSortKey?: string;
}

function customDynamoDBAdapter(client: DynamoDBDocument, options?: DynamoDBAdapterOptions): Adapter {
  const TableName = options?.tableName ?? 'next-auth';
  const pk = options?.partitionKey ?? 'pk';
  const sk = options?.sortKey ?? 'sk';

  const adapter = DynamoDBAdapter(client, { tableName: TableName, ...options });

  // Override useVerificationToken method
  adapter.useVerificationToken = async ({ identifier, token }) => {
    const data = await client.get({
      TableName,
      Key: {
        [pk]: `VT#${identifier}`,
        [sk]: `VT#${token}`,
      },
    });

    return format.from<VerificationToken>(data.Item);

    // Old method left here for posterities sake
    // const data = await client.delete({
    //   TableName,
    //   Key: {
    //     [pk]: `VT#${identifier}`,
    //     [sk]: `VT#${token}`,
    //   },
    //   ReturnValues: "ALL_OLD",
    // })

    // return format.from<VerificationToken>(data.Attributes)
  };

  return adapter;
}

export { customDynamoDBAdapter };

[emrysgraefe]

Very helpful. My org has a lot of clients who use a spam filter that sniffs all the links. We found that none of them were able to log in due to this.

This solution worked out for us, making the changes from the prisma adapter.

[bsplosion]

As a temporary solution, I have created a wrapper for the main adapter and overridden the useVerificationToken adapter method and replaced the delete function that was used with a get, so the entries aren't deleted. This means I will need to do some manual cleanup work on the database which isn't ideal but it has fixed my issue.

We ended up having to do a similar thing, though against the PrismaAdapter. We've had numerous issues with links getting consumed well in advance of users actually getting a chance to click, whether it's due to security in the user's email environment, firewalls prefetching/preflighting content with actual GETs, link checkers running within the browser itself, or certain browser versions not respecting Next.js link prefetch logic.

Ultimately, we chose to redirect the user to a hosted confirmation page which requires a final button click to confirm verification, where the button then sends the actual GET against the NextAuth API.

Then we implemented a custom Adapter which just uses most of the default PrismaAdapter properties but overrides createVerificationToken and useVerificationToken (though createVerificationToken is arguably also able to stay as the default if you structure the table correctly).

We had to add a pair of columns to the VerificationToken table to support link reuse up to some limit. The first column is a use_count and tracks how many times the token has been consumed, and a window_expires column is set to a few minutes in the future.

When useVerificationToken gets called, we await a delete every verification token which has an expires in the past, a window_expires in the past, or a use_count which is greater than or equal to the max uses we allow.

We can then await an update for the verification token provided, incrementing use_count by 1 and updating the window_expires to the end of that buffer period. If the update found a record, it updates and returns it (meaning the verification token wasn't culled as invalid in the prior step). If there was no record found, it means the verification token either doesn't exist or was invalid until the cull, in which case you just return null.

This combination has fixed even the most egregious issues with corporate link checkers and extensions which check navigation safety, with the drawback that we create sessions for each of those systems as well (though that was happening already). Technically this could also facilitate some link sharing, though that's a pretty minimal issue IMO if you structure the expiry and uses appropriately.

It'd be absolutely amazing for this approach to be an optional feature out of the box. We had far too many poor customer experiences before coming to a full solution which would work across the most aggressive of environments.

[lukevella]

Update: 2024-10-04

People have reported that the method suggested in the docs below does not prevent all link checkers from consuming the token.

Update: 2024-03-16

Ignore everything else I said. The correct answer is in the docs: https://next-auth.js.org/tutorials/avoid-corporate-link-checking-email-provider

---

Update: 2023-10-25

I decided to take a different approach. Instead I'm changing the link sent to users to a page where the user can click a button that uses the magic link generated by next-auth. I prefer this solution over modifying the behavior of the adapter.

So the link inside the email looks something like /auth/login?magicLink=<magicLink> which takes them to a page like this:

Clicking Continue sends a request to <magicLink> and redirects them to the app.

---

Original

Spent a couple hours trying to figure out why some users couldn't login. Glad I found this.

I'm working around this by customizing the PrismaAdapter such that the verification token is not deleted when it is used. Instead I delete all existing verification tokens for an identifier when the verification token is created.

See: lukevella/rallly#909

I know this probably isn't ideal but at least it doesn't require a database migration. Looking forward to a proper solution for this.

[lukevella]

@baptisteArno have you been able to confirm that redirecting in a useEffect works? I may have been overly cautious in thinking that a corporate link checker might be able to follow a client side redirect but I wasn't able to confirm it myself.

[baptisteArno]

For now I am actually pushing just the HEAD method detection work around, are you all saying that this is not enough? I have a client that have that issue and I will see if that fixed it

[bsplosion]

@baptisteArno I can attest that there are at least 2 link checkers we’ve encountered which do full page loads, including JS.

You guys are free to try the client redirect approach of course, and maybe your client base doesn’t use one of those checker variants which do JS loads, but it definitely isn’t a complete solution. We started with client redirects (and handling HEAD per the documentation), but that failed for several of our companies. YMMV, I just wanted to maybe save you all some tricky-to-triage client issues.

[baptisteArno]

Arg... Thanks for the info @bsplosion. I wish we could just do OTP easily with nextauth without any links

[sihamouda]

In my case outlook sends a GET request, I fixed it by checking a specific cookie, @baptisteArno