`hashed_token` of `email_change_new` link properties is outdated

[felixgabler]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

In contrast to the correctly working email_change_current, when I call this:

client.auth.admin.generateLink({
    type: 'email_change_new',
    email: user.email!,
    newEmail,
    options: { redirectTo: `${frontendOrigin}/app` },
})

I get an object like this:

{ action_link:
   'http://127.0.0.1:54321/auth/v1/verify?token=7353528fed7a27ef989b96a85480251849791f1031950c0b50293ba9&type=email_change&redirect_to=http://localhost:3000/app',
  email_otp: '026207',
  hashed_token: 'a7ebb4cce397f5c582c297d3b83597176edff96a8a2b1a2792c13183',
  redirect_to: 'http://localhost:3000/app',
  verification_type: 'email_change_new' }

where the hashed_token is not the same as the one in action_link and it gives me a outdated otp error when I try to validate it.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Use snippet above and compare tokens

Expected behavior

The tokens should be the same.

Screenshots

If applicable, add screenshots to help explain your problem.

System information

• OS: macOS
• Browser (if applies): Chrome
• Version of supabase-js: 2.47.10
• Version of Node.js: v22.11.0

Additional context

Very weird that it works with email_change_current

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 6 months.
It will be closed in 30 days if no further activity occurs.

If this is still relevant, please comment to keep it open.

[mandarini]

Hi @felixgabler, thank you for opening this issue!

This is a real bug, but it lives in the auth server (GoTrue), not in supabase-js or auth-js, so I'm transferring it to the supabase/auth repo where it can be fixed.

Quick reason: the SDK just passes through whatever /admin/generate_link returns. On the server, the hashed_token field in the response is computed from the user's current email + OTP, while for email_change_new the token actually embedded in the action_link (and stored in the DB) is computed from the new email + OTP. Different inputs, different hashes, hence the mismatch.

In the meantime, you can either pull the token query param straight out of the action_link URL, or recompute it yourself as sha224(newEmail + otp) hex-encoded.

[dhruvxvaishnav]

Hi @mandarini, I’d like to work on this if it’s still available.
I checked the current master implementation, and the mismatch still appears present: adminGenerateLink initializes hashedToken from params.Email, while email_change_new stores and uses GenerateTokenHash(params.NewEmail, otp) for the action link, but the response returns the former value.
My plan is to add a focused regression test asserting that, for email_change_new, the returned hashed_token matches the token used in the generated action_link, then update the response to return the token used for that verification type while preserving existing behavior for the other link types.
Would this approach be acceptable? If so, could you assign the issue to me?

[mandarini]

@dhruvxvaishnav let's reach out to the auth team cc @fadymak

[bnjmnt4n]

For reference, there is another issue which is a duplicate of this one: #2538.

There are also the following existing PRs which attempt to solve this issue: #2537 (my PR), #2550, #2716.

It would be great if the team could confirm the issue and review the fixes.