I think it is not a good idea to add a JWT token to a denylist as it is encoded in base64... You can add "==" to the end of your token to bypass the denylist check and login.
That's if the user somehow gets access to the token and sends it with a request, which is very hard expect they're some hacker or something. And adding extra characters to the end of the token will make sure it's invalid and the verify token middleware checks for that.
The token is in the header "Authorization" right ? Any user can update the Authorization token in the request. Maybe it's not easy for everyone but it is possible.
JWT is encoded in base64, but in base64 you can add padding with "=" without changing the encoded message. "Hi dev.to !" in base64 is "SGkgZGV2LnRvICE=" but also "SGkgZGV2LnRvICE==" or "SGkgZGV2LnRvICE===".
So if you check the encoded token in the denylist you can just add "=" at the end of the token to bypass the denylist and use the token without changing the decoded value.
Here is the RFC for the base64: tools.ietf.org/html/rfc4648
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
This is why our design revoked tokens via their jti field, which is not changeable provided the tokens are correctly signed (with an RSA or elliptic curve key pair). it does require all tokens to be parsed, but we can delegate that to a trusted library that should be resistant to attack...
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.
I think it is not a good idea to add a JWT token to a denylist as it is encoded in base64... You can add "==" to the end of your token to bypass the denylist check and login.
That's if the user somehow gets access to the token and sends it with a request, which is very hard expect they're some hacker or something. And adding extra characters to the end of the token will make sure it's invalid and the verify token middleware checks for that.
If I didn't get you right, please explain.
The token is in the header "Authorization" right ? Any user can update the Authorization token in the request. Maybe it's not easy for everyone but it is possible.
JWT is encoded in base64, but in base64 you can add padding with "=" without changing the encoded message. "Hi dev.to !" in base64 is "SGkgZGV2LnRvICE=" but also "SGkgZGV2LnRvICE==" or "SGkgZGV2LnRvICE===".
So if you check the encoded token in the denylist you can just add "=" at the end of the token to bypass the denylist and use the token without changing the decoded value.
Here is the RFC for the base64: tools.ietf.org/html/rfc4648
Oh wow, didn't realize this. Thank you for sharing. Will check it out.
This is why our design revoked tokens via their
jtifield, which is not changeable provided the tokens are correctly signed (with an RSA or elliptic curve key pair). it does require all tokens to be parsed, but we can delegate that to a trusted library that should be resistant to attack...