JWT Email Validation Protocol

Question

I had an idea about the email validation step inside an account creation process on a web application. This is the first time I build something like that, so I just want to be sure that this protocol is secure.

As I don't really want to store anything on my database for a 'non verified' user, I had the idea to use a JWT in order to verify the user's email address. This is my idea:

1. The user visits the /register endpoint on the website and enters his email (only his email, no username or password for the moment).
2. I verify the email format using regex on the backend server and check the MX DNS records associated with the domain name.
3. I create a JWT containing the user's email address that he provided as only data. After that I send an email to that address containing a link to a new endpoint: /create?token=<generated jwt>. (This token is cryptographically signed preventing generation of registration links already bound to an email address).
4. If this email belongs to the user, he just clicks on the link and I would now know that this address valid.
5. The user can complete his registration on this new /create endpoint where he will be asked to provide a username and a password.

I think that this method would be more user-friendly because the user don't have to enter his username and password twice (1: registration, 2: login after clicking on the emailed link) and more efficient for my database as I don't keep track of the unverified users at all.
On top of that the expiration time set on the JWT would be very convenient as I could set it to 24 hours (after its creation) and the link would instantly become unusable.

I would just need to display the email address on the /create endpoint to ensure that someone did not send a link bound to his email address to someone else to register (which would give this person the ability to reset the victim's password later). This is pretty easily prevented by displaying a non-editable field containing the email address next to the username and password prompt.

question from:https://stackoverflow.com/questions/65894184/jwt-email-validation-protocol

Answer 1

You should probably use (and check) the iss and aud fields in the jwt to indicate which of your websites issued the token for which one (probably itself). While you only use this on one website, it doesn't matter much, but with multiple websites it gets more complicated, it's always a good idea to include in messages who sent it to whom.

Consider the max length that will fit in an url, a jwt base64-encoded (I guess) can get long (but I think the above scenario would work, so with this data I don't think it's too long already).

Also this allows a known-plaintext attack on the jwt secret as you will issue a new jwt and send it to any email address. Probably you could have some kind of rate limiting on the /register endpoint to mitigate this. This might also have a denial of service aspect as signing jwts and sending emails can be fairly resource heavy.

And finally, the threat you mentioned in the last paragraph (a user sending his own link to somebody else so they register with the attacker's email address) is an excellent one. Only displaying the email address might not be enough mitigation, it totally depends on your scenario, even the visuals how it would be displayed or acknowledged by the user I guess. This is certainly one way to attack your users, one stronger mitigation is if they need to enter their email address again and you compare it to the one in the jwt - but that is in exchange for worse ux, the tradeoff is for you to decide. You could for example also explicitly have the user just confirm the email address if you think that's enough for your application, it very well can be.