JWTs aren't inherently unsafe. I like that JWTs are signed by a server side secret, and I like the flow that creates during auth. Depending on how secure the app needs to be, I've even stored user agent and remote address info in a JWT, signing it with a user specific secret. I had the JWT checked for all of that as accurate against headers and then refreshed the sign/verify secret if the JWT had data that was bad in it.
Most apps can get away with an expiry on a JWT and increase performance, this decreasing energy usage, this decreasing environmental impact of your code.
The CIA of information (Confidentiality, Integrity, Availability) is held strong. OP only focuses on Confidentiality for some reason.
JWT is inherently unsafe for the sole purpose it cannot be immediately invalidated. The only way to force invalidation is to change a signing key. If you’re blacklisting JWT’s, then you’re using it wrong. Blacklisting requires preserving a state and checking against it. If you’re saving them, then you’re using them wrong (there’s no a plus in scalability over sessions). If you’re using refresh tokens, then again, you have a state. Plus, it leads to number of bad practices, such as storing them in local storage which can be exposed to XSS attacks, use of long lived JWT’s, or storing sensitive informations in their payload. What would be the correct way to use them? Probably by having a dedicated authentication server like Keycloak which can use short lived JWT’s in combination with refresh tokens and key rotation. But, do you really need such a complicated architecture in the end of the day?
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.
JWTs aren't inherently unsafe. I like that JWTs are signed by a server side secret, and I like the flow that creates during auth. Depending on how secure the app needs to be, I've even stored user agent and remote address info in a JWT, signing it with a user specific secret. I had the JWT checked for all of that as accurate against headers and then refreshed the sign/verify secret if the JWT had data that was bad in it.
Most apps can get away with an expiry on a JWT and increase performance, this decreasing energy usage, this decreasing environmental impact of your code.
The CIA of information (Confidentiality, Integrity, Availability) is held strong. OP only focuses on Confidentiality for some reason.
JWT is inherently unsafe for the sole purpose it cannot be immediately invalidated. The only way to force invalidation is to change a signing key. If you’re blacklisting JWT’s, then you’re using it wrong. Blacklisting requires preserving a state and checking against it. If you’re saving them, then you’re using them wrong (there’s no a plus in scalability over sessions). If you’re using refresh tokens, then again, you have a state. Plus, it leads to number of bad practices, such as storing them in local storage which can be exposed to XSS attacks, use of long lived JWT’s, or storing sensitive informations in their payload. What would be the correct way to use them? Probably by having a dedicated authentication server like Keycloak which can use short lived JWT’s in combination with refresh tokens and key rotation. But, do you really need such a complicated architecture in the end of the day?