JWT Tokens and What’s special about them?

If you are a web developer or a consumer of some REST API, chances are you have come across JWT tokens while authenticating. This article will help you understand what sets JWT Tokens apart and what that means to you as a developer.

Let’s start with discussing an authentication flow in a typical application. It looks something like:

• User inputs their credentials via the frontend interface and hits Submit. Those credentials are submitted to the server.
• The server verifies the credentials and if they are correct then it generates a session for the user and returns the session identifier to the application client. A session is a temporary mechanism to identify authenticated users on the backend. Imagine it being something like a pass that every authenticated user gets which they have to present when asking for resources from the server. The pass in the analogy is the session identifier.
• The client app stores that session identifier and submits it to the server along with any request it makes.

The session identifier (referred to as token from here on out) could be as simple as a randomly generated string or a salted hash of the user email or something along those lines. But, these kinds of approaches have a fundamental issue.

To facilitate the verification of the tokens and features like automatically expiring tokens, the server has to save a copy of the generated token to the database. And, every time a request is received it has to make a database query to verify that the presented token matches the issued token. This obviously, has a performance cost because of the extra query that has to run on every request. But that’s not all.

Because plain tokens do not contain any information about the user, if your application requires, say, the email or the name of the user, it will have to make an additional API or a database request which could’ve been prevented if the tokens contained that identifying information already.

These kinds of tokens are often described as Stateful Tokens, because the tokens themselves do not have enough information to prove their validity. Instead, the server needs to keep track of the token validity in its database.

JSON Web Tokens or JWT Tokens are Stateless Tokens. They are stateless because they contain enough information within them to cryptographically prove their validity. This means that a server doesn’t have to query a database to validate the token it receives. The server can simply perform a mathematical calculation and assert that the presented token was issued by it at some point in time. These tokens can also contain an arbitrary amount of JSON data, allowing you to put things like the user id, email in the token itself.

How do JWT Tokens Work?

To understand how JWT tokens work, you need to understand Cryptographically Secure Hashing (referred to as hashing from here on out).

Generally speaking, hashing is the process of converting an arbitrary amount of data (text, usually) into a fixed length data (a hexadecimal number, usually) called hash. Cryptographic hashing also requires that reversing a hash to obtain the original data be practically impossible. To put it simply, hash algorithms are one way functions that take a variable length string and returns a fixed length number. You can read more about them here.

For example,

SHA1 is a popular hashing algorithm, the SHA1 hash of the string “Hello World” is always 0a4d55a8d778e5022fab701977c5d840bbc486d0 (in hex number format). But, if you only had the hash of some data, it will take your a very very long time to find the original data leading to the hash by brute force.

JWT tokens use hashing algorithms to secure themselves. They do this by leveraging the irreversibility property of hashing algorithms. The process of generating a JWT token for a user is roughly outlined below:

1. Generate a secret key for the server. This secret should be kept private and should not change when the server is restarted. You can use a random string generator or some other tool like it to generate it.
2. Extract the id, email or some other unique property of the user that you want to identify the user with.
3. Append the server secret key to the the id string.
4. Hash the resulting string (the actual hashing algorithm does not matter in the context of this discussion).
5. Append the hash to the the id with a delimiter such as a colon.

The result obtained is a token that contains two components, the first component is the id of the user in plain text. The second component is the hash of the id and the server secret, also called the signature of the token. Hashing the id of the user with a secret makes the token tamper proof. If a malicious actor knew a user’s id, which in most cases is public information, and tried to generate a fake token for their account, they won’t be able to generate the signature, because of the unknown secret key. The irreversibility of hash algorithms means that the attackers cannot employ any practical means to extract the secret key from known signatures.

The process of verifying the token would look like:

1. Split the received token using the delimiter. You will end up with two components.
2. The first component is id, append the server secret to the id.
3. Hash the result.
4. Check if the hash matches the second component, if they do, you can be sure that the token was generated by you and was not tampered (given that your secret key is secure enough). The server can then give the user access to the respective resources.

Note that the described flow does not justify the J in JWT which stand for JSON. In a standard JWT implementation, the user id and other arbitrary data is stored as a Base64 encoded JSON string. The encoded string is then considered the payload and hashed with the secret key. This makes the token much more versatile and useful. Often times, you can store some sane amounts of user information in the token itself so the frontend can display some relevant some information without having to wait for a network request.

This ability to securely store arbitrary information also allows for features such as auto expiring tokens. You can simply put the time of expiry in the token itself and during the process of token validation, after the token has been proven to be untampered, extract the time of expiry from the token and check if is still valid.

Head on out to https://auth0.com/learn/json-web-tokens/ to learn more about the JWT Standard or to https://jwt.io/ to play around and generate your own tokens.