How To Properly Use JSON Web Tokens
Networking
10/05/2021
In a previous blog post, I explained what JSON Web Tokens are. However, when developers are first introduced to JWTs, they incorrectly assume that it can replace the battle-tested session ID in every aspect. The reality: it's only suitable for very specific use cases.
When to use
Let's get straight to the point. 😜 You should only use JWTs for:
- One-time and/or short-lived (e.g. 15min) authorization, and
- Server-to-server communication
Regarding the 1st point, imagine that Server A issues a JWT that allows you to fetch some data from Server B for a limited time only. And as an example for the 2nd point, using JWTs for API authorization is quite common. Even Google does it!
Security issues
Security is practically THE reason JWTs will never replace a session ID.
Storage methods
Local storage is often the go-to method for JWTs, even though it shouldn't be. It exposes your token to a multitude of attacks as it can be accessed by anyone using JavaScript. If there's one thing you don't want to bet against, it's the creativity of a hacker.
For this reason alone you should use an httponly cookie as it prevents anyone from accessing it, even you! But of course, this introduces a host of new issues as you are no longer able to access it on the client side... 💩
Revoking authorization
If for some reason or another an account gets compromised by a hacker, how are you going to revoke that users' session? The short answer: you can't. You'll simply need to wait until the token expires. The longer answer: you can by logging out everyone in your application as a result of changing your secret key. However, that's not exactly a desired solution for obvious reasons.
Logged in users
Speaking of logging out, how do you know who's logged in in the first place? I think you already know the answer 😉 (P.S. You can't know).
Stale data
Similar to revoking a token, it's impossible to change the payload of your token until the current one expires. Naturally, this will lead to an outdated payload which will then give rise to a host of other problems. For instance, image you downgraded a user's role from "admin" to "regular". Sadly, this change won't be reflected in the token.
Exposed user data
Another flaw of a JWT is the lack of encryption of its payload. Literally anyone who has access to the token will be able to read its contents by base64url decoding it. Granted, you may apply another layer of security by encrypting the payload itself.
Bandwidth consumption
Another minor, though not insignificant downside of a JWT is its size. It will certainly exceed that of a cookie session. And over the long-run, this can make a difference in bandwidth consumption as it is sent with every request. So yeah, size does matter. 😆
Further readings
There is certainly more extensive content out there about the use cases of JWT. If you're interested in reading up more on this, I recommend part 1 and part 2 of joepie91's Ramblings about JWTs.
