JWT is the abbreviation of JSON Web Tokens. JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.
This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.
Authorization: This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. Single Sign On is a feature that widely uses JWT nowadays, because of its small overhead and its ability to be easily used across different domains.
So, Why should you use JWTs?
1. Stateless
JWTs support the stateless server REST principle. In this case, the server does not store the session info of different calls made from the same client, a JWT can be sent as an authorization header in each call, removing the need to track session information on the server.
2. Decoupled/Decentralized
JWTs don’t need a central system to validate each request. The tokens can be validated anywhere, even in libraries and util classes.
3. Supports Claims
We can put JSON data called “claims” inside the token. User details like id, username, roles and privileges can be bundled inside the token, therby reducing network calls required to fetch this info from the backend server.
4. Auto-expires
JWTs can be programmed to expire within a given expiry time. So, we don’t need to manage the lifecycle of the token in our backend database, in fact, it is not advisable to store JWTs in a persistent database. Expired JWT tokens, will throw gnarly exceptions if they are decoded.
JWTs are stateless, decentralized, they support claims inside the token and they auto expire.
But, there are some drawbacks too,
1. Bulky
JWT’s aren’t memory efficient. Especially, when you’re using custom claims inside the token, the size of the token may bloat to an extent where it cannot be stored in a cookie.
2. Transparent
The token claims cannot be tampered with but, the claims are just base64 encoded in the middle part of the token, so they can be decoded easily.
3. Stale data
Data inside the token can become stale and it might no longer reflect the latest version of the data in your database.
4. Stale tokens
You cannot invalidate individual JWTs because you are not supposed to store them in a persistent store. This means that you cannot be sure that the user is logged out of any system.
So, JWTs are stateless, decentralized, support claims inside the token and they auto expire. But, they are also bulky, transparent and have a propensity for going stale.
How do we mitigate the disadvantages?
- Reduce TTL, always create shortlived (30 mins) tokens.
- Refresh the token frequently.
- Refresh only if the user keeps interacting with you website.
- Store the resource identifiers and not the resource itself as claims inside the token.
- Do not keep sensitive data like the user’s login credentials in the token.Keep the token size to less than 4KB, duh!