Token Expired

A user rang in. They’d forgotten their password, requested a reset, got the email, clicked the link, changed their password. Straightforward. All good.

Then they said: “I need to change the password on my mobile phone as well.”

So they went back to the email on their phone, clicked the same link.

Token expired.

“Why can’t I change the password on my phone?”

What Actually Happened

Password reset links are single-use. The moment you use one to set a new password, the token is invalidated. Intentionally. It’s a security measure, not a bug. If that link kept working, anyone who intercepted the email later could use it to reset the password again.

So from the system’s perspective, everything worked exactly as designed.

From the user’s perspective, something was broken.

The Mental Model Gap

The user’s mental model made complete sense from where they were standing. They’d “changed their password on the computer,” and now they needed to “change it on the phone.” Two devices, two tasks.

What they didn’t realise was that the password isn’t stored on the device. It lives in the system. Change it once, it’s changed everywhere. The phone doesn’t need a reset link, it just needs you to log in with the new password.

“Token expired” did nothing to explain this. It’s an error message written for developers, not people.

A better message might have been: “This link has already been used. Your password was changed successfully. Just log in with your new password on any device.”

One sentence. Would have saved the support call entirely.

The Fix

I walked them through logging into their phone with the new password. It worked immediately. The whole call took about two minutes, most of which was explaining why a link that worked five minutes ago suddenly didn’t.

They weren’t confused because they were doing anything wrong. They were confused because the system told them something went wrong when nothing had.

The password reset worked. The error message failed.