Passwordless - new request auto expires pending requests

[davidmw]

Passwordless - new request auto expires pending requests

Description

If a user requests passwordless login, gets impatient and requests again, the first is expired by the second request.

This is problematic with kids, in particular, or in situations where there is delay in email arrival to the client. After the 2nd or 3rd request, the 1st email arrives, which is now invalid. This could lead to more requests, invalidating the most recent that is in route

Related issues:

• Passwordless Code don't change upon every request till expired #1045

[davidmw]

It might be tempting to change Fusion to throttle the request spacing for a single account, for example one every 2-3 minutes. This doesn't seem like an ideal solution since it would bake in more delays when we are looking for a fast login process.

[mooreds]

Yes, I ran into this when writing the passwordless guide.

Curious about your thoughts on desired behavior. I can think of two options to ameliorate this issue:

• have more than one token be valid at a time, which has security implications (as well as implementation complications)
• present a message to the user that a request is in-flight and they should expect an email "any minute now" when there's an open passwordless request (which also has security implications)

Would love to hear your thoughts.

[robotdan]

To add to @mooreds this is working as designed. We are always open to improving the user experience, so perhaps there is some room to improve this without sacrificing security.

[davidmw]

On the security concerns: The repeated requests for passwordless link might come from different IPs / devices but even then - the request is silently ignored if the account doesn’t exist and links are only sent to the requester.

Having multiple short lived tokens active and in route, or having the same token on multiple emails without extending the lifespan of the original occurrence, don’t really seem to create a significant security issue.

[davidmw]

I suppose that any passwordless link email could be forwarded to a different email address and if there are multiple tokens active there could be forwards to multiple accounts.

I've previously been told that FusionAuth isn't designed to prevent multiple login sessions on a single user account. The multiple active passwordless token concept isn't much different, possibly allowing multiple simultaneous sessions for one known user.

Regardless of how the first batch of tokens is handled, if the user requests magic link and logs in, opens another tab and repeats the request magic link process - they could create a new session maybe for a different browser or device. Maybe the first successful use of a token invalidates all pending tokens for that user but is there a real security advantage to doing this?

[mooreds]

OK, so it sounds like you're advocating for having more than one passwordless token be valid at a time. Each passwordless token would live for the configured lifetime and if there were three in flight (aka requested by an energetic child) any of the three would work.

I suppose once any one of the three were used, we'd want to invalidate any of the others.

Is that basically the feature as you imagine it?

[davidmw]

That would create the desired result. Or if the implementation is easier to resend the same user token if it is still valid - then clicking the link from any of the emails would complete the login based that one token.

[narayanpromax]

Any update on this?

[mooreds]

@narayandreamer , nope, this has not been planned out. Still on our radar, but no definite timeline. Lots of cool features to build and we have to prioritize, unfortunately.

If you'd like to get an estimate on professional services to get this done on a specific timeline, please feel free to contact us and we can discuss.