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.
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.