JSON Web Token (JWT) as a url for email activation

Question

How secure it is to make JWT as the activation url in email?

For example: Click link to activate your account http://127.0.0.1:8000/account/activate/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ0b3B0YWwuY29tIiwiZXhwIjoxNDI2NDIwODAwLCJodHRwOi8vdG9wdGFsLmNvbS9qd3RfY2xhaW1zL2lzX2FkbWluIjp0cnVlLCJjb21wYW55IjoiVG9wdGFsIiwiYXdlc29tZSI6dHJ1ZX0.yRQYnWzskCZUxPwaQupWkiUzKELZ49eM7oWxAQK_ZXw

Answer 1

The FAQ you link to says:

Use-cases for a JWT token in a url are:

• account verification - when you email a person a link after they register on your site. https://yoursite.co/account/verify?token=jwt.goes.here
• password re-set - ensures that the person re-setting the password has access to the email belonging to the account. https://yoursite.co/account/reset-password?token=jwt.goes.here

Both of these are good candidates for single-use tokens (which expire after they have been clicked).

So, yes. Just make sure that each email can be activated only once (and don't use the terrible "secret" key from your example, if the signature can be faked, then your verification can be bypassed).

Answer 2

Using stateless token like JWT is secure as long as the secret you use to sign the token and the way you verify it are secure. But there are certain additional aspects you should consider before using JWTs as auth-token in your password-reset URI...

As you can't invalidate a specific JWT (without keeping state again) and expiry is not enough (in this specific case), what you basically want to have is your JWT to be what is commonly know a One-time- or Single-Use-Token. The reason for that is that you probably don't want a single password-reset-link to be used more that once to reset a password as it would allow potentially attackers to completely lock-out a user (by continuously changing passwords).

I described how this can work here: Single-Use Tokens w/ JWT - basically you would need to turn some kind of state you have on your server-side (in your case e.g. the hash of the users password) into an HMAC key and use that to sign your user-specific token. This would lead to failing token verification after the password was changed...