Hi team, We're seeing a recurring issue with our i...
# ask-a-descoper
a
Hi team, We're seeing a recurring issue with our invite flow. Users receive magic link invite emails, but when they click the link they get:
[E062504] Token expired: Failed to load magic link token, check if token expired or already used (for instance, an email scanner may have clicked the link)
This is NOT a token expiration time issue — we have a long expiration configured, and the failures happen within minutes of the invite being sent. It looks like something is consuming the token before the user actually clicks the link. Our immediate suspect was email scanners, but we have the isEmailScanner check enabled in our flow and it doesn't seem to prevent the issue. Here are some example cases that have failed in the past week. Case 1 — US project
P30p22ThcIydaxCprNgrJ2ZYriGI
(March 31): Invite creation cf-ray: - 9e4fa6ca8b68c998-IAD Failed magic link attempts by user: - 9e4faa2a0bc179ad-IAD - 9e4faa5778a779ad-IAD - 9e4fabc16ff979ad-IAD Case 2 — EU project
Peuc12rtvwjSr4gXbIvmOHyv8UyFi29b
(March 30): Invite creation cf-ray: - 9e46f28ccb525d74-FRA Failed magic link attempts by user: - 9e471e66effdd592-AMS - 9e47711249d4f5c9-AMS Can you help us debug what's going on? We'd appreciate any insight into what's consuming the tokens before our users get to them. Thanks!
✅ 1
d
Hi, I'm Descope's AI assistant. I've put together an initial response below based on your question. A member of the support team will take over and follow up shortly. Issue Summary We're experiencing a recurring issue with our invite flow where users receive magic link invite emails, but encounter an error when clicking the link:
Copy code
[E062504] Token expired: Failed to load magic link token, check if token expired or already used (for instance, an email scanner may have clicked the link)
This issue is not related to token expiration time, as we have a long expiration configured, and failures occur within minutes of the invite being sent. It seems that something is consuming the token before the user clicks the link. Suspected Causes Our immediate suspect was email scanners. However, we have the
isEmailScanner
check enabled in our flow, and it does not seem to prevent the issue. Example Cases Here are some example cases that have failed in the past week: • Case 1 — US project
P30p22ThcIydaxCprNgrJ2ZYriGI
(March 31): ◦ Invite creation cf-ray: 9e4fa6ca8b68c998-IAD ◦ Failed magic link attempts by user: ▪︎ 9e4faa2a0bc179ad-IAD ▪︎ 9e4faa5778a779ad-IAD ▪︎ 9e4fabc16ff979ad-IAD • Case 2 — EU project
Peuc12rtvwjSr4gXbIvmOHyv8UyFi29b
(March 30): ◦ Invite creation cf-ray: 9e46f28ccb525d74-FRA ◦ Failed magic link attempts by user: ▪︎ 9e471e66effdd592-AMS ▪︎ 9e47711249d4f5c9-AMS Request for Insight We would appreciate any insight into what's consuming the tokens before our users get to them.
m
@Bhagwanta Yeole can you help here
🙏 1
👀 1
b
Hi @Asaf Rosentswaig, I'm looking into this, for reproducing this issue. Will update you in sometime.
a
thanks!
b
@Asaf Rosentswaig Does this issue occur for a specific user, or is it affecting all users?
If it's related to specific user, Please check the audit page and check for the user id and email
m
@Asaf Rosentswaig for case 2, is the user id relevant
U3BfEvzFUJypakLls5QgTMP8tX1p
?
a
hey folks, sorry for the delay. yes in the second case its this user. after on they enabled sso + scim in the tenant so the user merged with the sso user this is why its active.
m
so for that user I see : 14:59 - magic link sent - 9e46f28ccb525d74-FRA - IP 35.157.81.179 15:17 - he verified the link + got JWT created - IP - 62.195.130.242 (CF-RAY 9e470d16f972aee9-AMS) 15:29 - failed magic link, on token expired - 9e471e66effdd592-AMS - IP 62.195.130.242
so seems the the 15:17 flow execution, consumed the token, so following attempts failed sees by user agent is was a Mac , Using Chrome browser You should be able to see that in your audit events page
i suggest you search audit page by user id / user email
a
thats exacly what ive seen as well before opening this message. thing is the client claims he didnt do the attempt at 15:17.
m
the IP and User agent match (from successful attempt in 15:17 and 15:29) so unlikely its NOT him BUT, it is possible he has some security tool that clicked the link in automated way, and evaded the scanner detection to solve this, add a condition for this specific user (or tenant) to force him to go via bot validation step, like this
and ask him to try again