4 ms·

Both of these cases can be handled by having the email link validate the original session rather than the "current" session/browser. If it happens to be on the

Both of these cases can be handled by having the email link validate the original session rather than the "current" session/browser. If it happens to be on the same browser that requested the login, it will be the same session anyway, and will work as you'd expect. If it's a different device/browser, then (using your example) the user will see a message on their phone like "Login validated, please check the original device where you initiated login" and their desktop session will now be validated. Ideally the site uses polling or a push mechanism to proactively show the right page, but the lazy way is just to show a message like "Refresh this page after clicking the login link from your email".

anderspitman 7y ago
I think I'm missing something. How is this different than the way emauth is currently doing it?
- gregmac 7y ago
  This is actually independent of emauth's implementation, it depends on how you implement the validation workflow (what you do when you receive the token). The naive implementation is to just say "Hey, a valid token... Ok, you're now logged in", but this suffers from the issue mentioned in a parent comment: >>> Links can be opened by the controller of the email even if they didn't make the original request. Links can also be opened by something scanning the email before the user sees them. Neither of these potentially malicious use-cases are covered by emauth.io. >> We store the user’s session ID at the time they request the email be sent, and then validate it’s still the same session ID when the token (which is a parameter on the URL) is consumed. > This breaks the use-case where the user is on a desktop computer but checks mail on their phone. So what I'm saying is: * Store the sessionId with the token * When you handle the validation request, mark the stored sessionId as "logged in" This handles the "click on validation from a different device" use case, while also preventing someone who's able to intercept your email from being able to log in themselves.

anderspitman 7y ago

I think I'm missing something. How is this different than the way emauth is currently doing it?

gregmac 7y ago
This is actually independent of emauth's implementation, it depends on how you implement the validation workflow (what you do when you receive the token). The naive implementation is to just say "Hey, a valid token... Ok, you're now logged in", but this suffers from the issue mentioned in a parent comment: >>> Links can be opened by the controller of the email even if they didn't make the original request. Links can also be opened by something scanning the email before the user sees them. Neither of these potentially malicious use-cases are covered by emauth.io. >> We store the user’s session ID at the time they request the email be sent, and then validate it’s still the same session ID when the token (which is a parameter on the URL) is consumed. > This breaks the use-case where the user is on a desktop computer but checks mail on their phone. So what I'm saying is: * Store the sessionId with the token * When you handle the validation request, mark the stored sessionId as "logged in" This handles the "click on validation from a different device" use case, while also preventing someone who's able to intercept your email from being able to log in themselves.