Not without some degree of back-end persistence, which I assume is the main reason it's not how what the article does. You'd need to create some sort of short-lived state in the back-end that gets cleared by opening a link in the email. The login-window could then just do polling, or use some more sophisticated method for waiting for the server to grant it access.
The only state is in the browser. On the server you just need to verify the token, which could be sent by the browser in the authorization header as a bearer token or in the body or in the url as a parameter or search term. (Sending in URL is an unforced error. It exposes the token, so dont do this in practice.) You should also sign with RSA keys vs secret, so you can verify the origin.
Regarding exposing the token. The magic url, which i hope there's a better term for, can point to a url on the server that returns html where the token and any user data are passed via session storage. It doesnt matter about the nonce. Sincei its now dead.
You say the state is in the browser, but there's not just one browser, but two, and they have no way of directly communicating. Or are you talking about the way it's described in the article?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How do you go about implementing that last part? Where clicking the magic link on one device logs you in on another?
Not without some degree of back-end persistence, which I assume is the main reason it's not how what the article does. You'd need to create some sort of short-lived state in the back-end that gets cleared by opening a link in the email. The login-window could then just do polling, or use some more sophisticated method for waiting for the server to grant it access.
The only state is in the browser. On the server you just need to verify the token, which could be sent by the browser in the authorization header as a bearer token or in the body or in the url as a parameter or search term. (Sending in URL is an unforced error. It exposes the token, so dont do this in practice.) You should also sign with RSA keys vs secret, so you can verify the origin.
Regarding exposing the token. The magic url, which i hope there's a better term for, can point to a url on the server that returns html where the token and any user data are passed via session storage. It doesnt matter about the nonce. Sincei its now dead.
You say the state is in the browser, but there's not just one browser, but two, and they have no way of directly communicating. Or are you talking about the way it's described in the article?