JSON Web Token (JWT) as URL to activate email

Question

How safe is it to do JWT as an activation email address?

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

Answer 1

Frequently asked questions you refer to are :

Use cases for the JWT token in the URL:

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

Both of them are good candidates for one-time tokens (which expire after they are pressed).

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

Answer 2

Using a stateless attribute, such as JWT, is safe if the secret you use to sign the token is a way to verify its security. But there are some additional aspects that you should consider before using JWT as an authenticator in your password - reset URI ...

Since you cannot invalidate a specific JWT (without saving the state again), and expiration is not enough (in this particular case), what you basically want to have is your JWT, which is usually known as a one-time or one-time token. The reason for this is because you probably don't want the single password-reset -link to be used more than once to reset the password, as this would allow potential attackers to completely block the user (by constantly changing passwords).

I described how this can work here: Disposable tokens with JWT - basically you will need to turn some kind of state in you on your server side (in your case, for example, a password hash of users) into an HMAC key and use this to sign your user-specific token. This will cause the token verification to fail after changing the password ...