JWT is the abbreviation of JSON Web Tokens. JSON Web Token (JWT) is an open standard ( ) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. RFC 7519 This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the algorithm) or a public/private key pair using or . HMAC RSA ECDSA : 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. Authorization 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!
![A Quick Guide to JSON Web Token [JWT]](https://hackernoon.imgix.net/images/hQ098u52DzPm2Y4UITQcQXtLRAk2-029a35hv.png?auto=format&fit=max&w=3840)
