Have you ever used a JWT? You have probably done this if you have ever performed functional testing of software that contains the logic of authentication and authorization in its structure.

The “JWT” term can be pronounced as “jot” and is defined as a JSON Web Token. All JWTs are developed by Aut0 company, whose purpose is to enable software products to determine if users have correct rights to access a certain website.

Why can JWTs be useful? [highlight dark=”no”]They help to simplify the application’s task of verifying the user’s authorization data, not transmitting a login, a password, and cookie files during this procedure.[/highlight]

There is the possibility to intercept various requests but a JWT doesn’t contain any personal data and is completely protected, therefore, this catching won’t be useful.

We’ll talk further about the process of developing JWTs and correct testing of them.

A structure of a JWT

So every JSON Web Token consists of three basic parts, that are structured from a certain sequence of digits and letters, separated by dots.

One of the most efficient ways to study and learn a JWT is to constantly practice, using an official JWT debugger, that can be found here: http://jwt.io/

The name of every JWT consists of a special algorithm, used for encrypting a JWT, and also a type of token.

The data contain a group of user’s assertions.

There are three types of assertions:

• Registered assertions — classical assertions that have been established by software code of a JWT assertion (iss — a creator of a statement; iat — a token’s release date in unix-variable; exp — a token assertion’s expire date; and — a token’s receiver; sub — information for a user);
• Public assertions are the second type of classical assertions that are added to a JWT register. For example, a name, an email, and a time zone of token’s coverage;
• Private assertions are the third type of assertions that are defined by a developer of an application and are specific for one local group of usage. For example, a company can use a unique userID for all its users and this will be included in an assertion’s body.

An example from a debugger:

{
«Sub»: «1234567890»
«Name»: «Name Surname»
«iat»: 1516239022
}

The object here is 1234567890, the user’s name that has personal access to this object is Name Surname and the token has been created in 1516239022, according to Unix time.

If junior testers don’t completely understand this type of timing, they can use the services of the special converter that will help them to perform complete encrypting.

The link: https://www.epochconverter.com/

Now let’s move to a signature.

It’s taken from the first two sections and encodes them in Base64. Afterwards, a unique secret key can be added to these encoded sections — a very long line of values and digits. And finally, a signature encrypts everything with the help of the HMAC SHA256 algorithm.

Every JWT has the following structure: an encoded name, some encoded data, and an encoded signature of a user. To properly differentiate all three sections, you can ask a debugger to highlight them in different colors.

If you, as a QA specialist, frequently meet a JWT inside the software you are testing, you can try to take any token and read its structure through the JWT debugger. The decoded information can help you understand the functionality of the software you are testing.

But if there is no JWT on your project, you can create it yourself. You need to put information inside a debugger’s Payload section and analyze the way of editing an encrypted JWT:

{
«sub» : «user»
«userName» : «test»
«iss» : 1516239022
«exp» : 1586606340
}

During the decoding of a current JWT, a signature won’t be decoded due to a secret. But taking into account the fact that the first two parts of a JWT have been encoded, not encrypted, they can be easily decoded.

Usage and details of JWT tests

A JWT can be used in different ways but the most popular one is to transmit it inside the API request’s body by using a bearer token. For example, this is displayed in Postman in such a way:

After analyzing the structure and the purpose of JWTs, we can describe the correct way of testing them:

1. Try to send a request without a JWT, to verify that data can return;
2. Edit or delete one of the values from a JWT and check that data won’t return during using such a token inside a request;
3. Perform decoding of a correct JWT inside a debugger, edit the data inside it and check if it can function inside a request;
4. Check when a JWT will expire and try to send a request with an expired token, to check that the sent data won’t return;
5. Deploy a new JWT, whose expiration date will start in the future and check that data won’t return;
6.  Try to decode a JWT and check that the user’s personal data (such as the number and expiry date of a credit card) are not saved inside its structure.