5 ms·
Implementing magic email sign in links is more straightforward and secure. You implement a login route which takes an email address. You symmetrically encrypt
by jeofken 5y ago
Implementing magic email sign in links is more straightforward and secure.
You implement a login route which takes an email address. You symmetrically encrypt the email with a secret key from an environment variable, and send a link to /login?secret=<email-ciphertext>. This route handler checks that the ciphertect decrypts into the email, and if true, save the ciphertext as a cookie and check that it decrypts to the right email every time you require auth
- lukevp 5y agoSo anyone who compromised the cookie can login as this user forever? There’s no expiration or revocation in this protocol. Once you layer on expiration, this is basically sending someone a link with a JWT in the get request. Or you can hit the DB to check a secret key that’s in the email, and if it has expired, but this is worse than JWT because it requires a DB to verify the identity, where JWTs can be verified without interaction with the issuing system .
- deleted 5y ago[deleted]
- hnick 5y agoThis basically happened to me on a site, sans cookie. It sent notifications when customers left reviews. The convenient user experience is, when someone leaves a review, to forward the email with the review to the customer and ask how we can help. After doing this a few times I realised it had small links in the footer to login and administrate without a password, using tokenised links. Support had no way to expire these. I needed to create and migrate a new account (which incidentally ended up emailing hundreds of people for reviews they left months and years ago).
- jeofken 5y agoOh yeah of course you must do all those things! Assumed it was obvious that this was only about the steps leading up to giving the JWT token. Wrote it with one hand on my phone :-)