What is a JWT token

#jwt #web #security

If you on this page, chances are that you have been seeing JWT tokens for a while and you are curious to find out what they really are and how they actually work! Why did they get so mainstream anyway?! 🤔

It's just a string with a well-defined format

JWT stands for JSON Web Token and a JWT token is a string composed by 3 parts: a header, a body (sometimes also referred to as payload) and a signature. Just to look at a more concrete example, a JWT token looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJoZWxsbyI6ImZyb20gSldUIn0.XoByFQCJvii_iOTO4xlz23zXmb4yuzC3gqrWNt3EHrg

Parts are separated by a . (dot) character, so we can identify the three parts as follows:

header: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
body: eyJoZWxsbyI6ImZyb20gSldUIn0
signature: XoByFQCJvii_iOTO4xlz23zXmb4yuzC3gqrWNt3EHrg

Header and Body are JSON strings encoded using the Base64Url algorithm (a URL-safe variation of the standard Base64 encoding algorithm).

If we decode them this is what we get:

header: { "alg": "HS256", "typ": "JWT" }
body: { "hello": "from JWT" }

The signature part contains bytes which represent a cryptographic signature of header and body (also encoded using Base64Url) and can be used to verify the authenticity of a token.

When JWT tokens are used

JWT tokens are mostly used as a mechanism for "stateless" authentication and authorization. Let's try to discuss what this means with a simple example:

In this picture, John is authenticating against an auth server. The auth server recognizes his credentials and gives him back a token. John can now use the token to connect to specific services.

Every time John makes a request to a service, he will need to attach his token to the request. The service can look at the token to understand if the request can be authorized. The service can read the information embedded within the token to understand that the request is coming from John and can verify that the signature was applied by the Auth server.

This process is "stateless" because this validation can be done without having to make an explicit request to the Auth server. This is a great property for distributed systems or, in general, systems that deal with a high load of requests.

Now you can be nosy

Now that you know how a JWT token is made you can start to be nosy and look into the JWT tokens you bump into.

You can copy-paste tokens into jwt.io or use a command-line tool like jwtinfo to read the content of the header and the body in plain text.

Trust me, if you do that you will be surprised by how many interesting information you can find there!

Conclusion

JWT tokens are an interesting approach to authentication and they are particularly convenient in distributed systems when we want to minimise the communication and the amount of load to the authentication provider. Once a token is created, it can be validated without the need to call the authentication provider again.

If you are curious to understand more about how JWT works (and even how you could crack tokens using Node.js 😼) check out this talk I gave a couple of years ago at BuzzJS 2018 in the beautiful New York City:

While you watch that, you can have the slides too! 🤗

If you found this article interesting please follow me here, on Twitter and check out my personal website/blog for other web related articles.

Also, if you like Node.js please have a look at my book, Node.js Design Patterns third edition, which can help you to learn how to design and implement production-grade Node.js applications using proven patterns and techniques.

Thank you! 👋

Top comments (4)

Vitaliy • Oct 1 '20

In practice "stateless" is virtual though.
As soon as your system needs to be able to withdraw previously granted access / invalidate token (say, any messenger that has "log out other devices" feature) you become dependent on some way of communication with auth service again.

Luciano Mammino • Oct 1 '20 • Edited

This is a very valid point, thanks @xazzzi

In reality, this does not happen all the time. Most system to system interactions won't probably need this feature.

When this feature is needed it does become complex to handle this requirement efficiently. I have seen one implementation of this requirement in the past that was particularly clever and effective. It did use Redis with local client cache. It did work very well and had very little overhead because every revoked token was kept in Redis only until the token itself reached its own invalidity time (in that case was 1 week). Also, in this particular setup, the cardinality of the revoked keys was very low (in the order of less than a hundred at a given time). Therefore it was very feasible to keep a local copy of the list of currently revoked keys and use Redis pub/sub to keep those local copies in sync. Not really stateless but it did minimise the number of requests to the auth server significantly!