github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-08-22 16:42:53 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

Magic link tokens are not invalidated when new tokens are requested #2080

New Issue
Closed
opened 2026-03-13 09:25:22 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-03-13 09:25:22 -05:00
Owner
Copy Link
Copy Source

Originally created by @josepchetrit12 on GitHub (Oct 6, 2025).

Is this suited for github?

  • Yes, this is suited for github

Is your feature request related to a problem? Please describe.

When a user requests multiple magic links in succession, all previously issued tokens remain valid until they naturally expire. This creates a issue where an attacker who gains access to an old email/link can still authenticate successfully, even after the user has requested a new magic link.

Describe the solution you'd like

When a new magic link is requested, all previous tokens for that email should be invalidated, ensuring only the most recent link is valid.

Describe alternatives you've considered

magicLink({
            sendMagicLink: async ({ email, token, url }, request) => {
                // Delete all previous magic link tokens for this email, keeping only the most recent one
                await invalidateOldMagicLinkTokens(email);
                
                // Send the new magic link email
                await sendMagicLinkEmail({ email, token, url })
            }
}),

Additional context

No response

Originally created by @josepchetrit12 on GitHub (Oct 6, 2025). ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. When a user requests multiple magic links in succession, all previously issued tokens remain valid until they naturally expire. This creates a issue where an attacker who gains access to an old email/link can still authenticate successfully, even after the user has requested a new magic link. ### Describe the solution you'd like When a new magic link is requested, all previous tokens for that email should be invalidated, ensuring only the most recent link is valid. ### Describe alternatives you've considered ```ts magicLink({ sendMagicLink: async ({ email, token, url }, request) => { // Delete all previous magic link tokens for this email, keeping only the most recent one await invalidateOldMagicLinkTokens(email); // Send the new magic link email await sendMagicLinkEmail({ email, token, url }) } }), ``` ### Additional context _No response_
GiteaMirror added the security label 2026-03-13 09:25:22 -05:00
GiteaMirror commented 2026-03-13 09:25:24 -05:00
Author
Owner
Copy Link
Copy Source

@Bekacru commented on GitHub (Oct 6, 2025):

This is intentional as there are valid use cases like when a user generates a magic link from different devices/browsers, where they should still be able to log in. It’s a short-lived token, so it should be fine

@Bekacru commented on GitHub (Oct 6, 2025): This is intentional as there are valid use cases like when a user generates a magic link from different devices/browsers, where they should still be able to log in. It’s a short-lived token, so it should be fine
GiteaMirror commented 2026-03-13 09:25:24 -05:00
Author
Owner
Copy Link
Copy Source

@Blackmamoth commented on GitHub (Oct 7, 2025):

@Bekacru saw this was closed. I have an implementation approach for this as an opt-in feature (invalidateOldTokens: false by default). When true, it would invalidate previous tokens for that email before generating a new one. If you're open to it as a config option, I can put together a PR. Let me know

@Blackmamoth commented on GitHub (Oct 7, 2025): @Bekacru saw this was closed. I have an implementation approach for this as an opt-in feature (invalidateOldTokens: false by default). When true, it would invalidate previous tokens for that email before generating a new one. If you're open to it as a config option, I can put together a PR. Let me know
GiteaMirror commented 2026-03-13 09:25:25 -05:00
Author
Owner
Copy Link
Copy Source

@sypion commented on GitHub (Feb 23, 2026):

@Bekacru saw this was closed. I have an implementation approach for this as an opt-in feature (invalidateOldTokens: false by default). When true, it would invalidate previous tokens for that email before generating a new one. If you're open to it as a config option, I can put together a PR. Let me know

I like this idea! I understand there's a case when, for example, slow email clients, but I have set up an onboarding experience where, in some specific cases, previous magic links should no longer be working if a new one is generated and sent.

@sypion commented on GitHub (Feb 23, 2026): > [@Bekacru](https://github.com/Bekacru) saw this was closed. I have an implementation approach for this as an opt-in feature (invalidateOldTokens: false by default). When true, it would invalidate previous tokens for that email before generating a new one. If you're open to it as a config option, I can put together a PR. Let me know I like this idea! I understand there's a case when, for example, slow email clients, but I have set up an onboarding experience where, in some specific cases, previous magic links should no longer be working if a new one is generated and sent.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No labels security
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#2080