These days most people already do use fresh/refresh pattern JWTs. Which is a good thing. I completely agree that long lived JWTs is a very bad idea. The whole part about JWT is supposed to cut down on database lookup time doesn't really work all the time either. I mean the JWT will probably return a user id upon decryption, don't you have to check if that's a correct user id through the db anyway?
You do not need to check if it's the correct user ID from the db since, if the signature checks out, then you can assume that it's the backend that created the JWT (since only the backend should have the JWT private key). In this case, we can be sure that the userId in the JWT was not tampered with since the signature is partly created based on this userId (implying that if the userId was changed on the frontend, the signature would not check out).
So if the signature checks out, we can be sure that the userId in the JWT is also something that your backend had set, which means it must be in the db.
That being said, if your JWT secret key is compromised, then the attacker can set the userId to any random string in which case all bets are off.
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.
These days most people already do use fresh/refresh pattern JWTs. Which is a good thing. I completely agree that long lived JWTs is a very bad idea. The whole part about JWT is supposed to cut down on database lookup time doesn't really work all the time either. I mean the JWT will probably return a user id upon decryption, don't you have to check if that's a correct user id through the db anyway?
You do not need to check if it's the correct user ID from the db since, if the signature checks out, then you can assume that it's the backend that created the JWT (since only the backend should have the JWT private key). In this case, we can be sure that the userId in the JWT was not tampered with since the signature is partly created based on this userId (implying that if the userId was changed on the frontend, the signature would not check out).
So if the signature checks out, we can be sure that the userId in the JWT is also something that your backend had set, which means it must be in the db.
That being said, if your JWT secret key is compromised, then the attacker can set the userId to any random string in which case all bets are off.