For decades cookies have been used to authenticate a user and hold session data. But a simple session cookie has certain limitations and too many attributes to worry about.
How about we talk about a token that not only helps to authenticate but also provide authorization. The token that we shall be discussing is called JWT or JSON Web Token.

JSON web tokens are a type of access tokens that are widely used web applications. A JWT is based on JSON(JavaScript Object) format.

Unlike a cookie which can easily be forged, neglecting some exceptions, what makes a JWT hard to alter is the fact that it has a signature, that either uses a secret key/private key to ensure integrity.

Typically, a JWT token is signed by the server using a key, ensuring that the information included within the JWT token is safe and cannot be altered by the attacker in order to manipulate his identity. Attempts to edit the information in the token will be detected by the server, and the token will not be accepted by the server as a result of the attempted modification.

In most cases, the token is used for the purpose of authentication, and it is assigned to the user as a cookie, but it is more commonly found in a header, and it is checked by the server every time a request is handled by it.

Structure of a JWT.

• A Header
• A Payload
• A Signature

Please keep in mind that they are all base64url encoded and separated by a dot (.).

This makes it easier to distinguish between the header, payload, and signature.

A JWT begins with a header, that is base64 encoded and when we decoded it tells us some of the information about the algorithm that is being used such as HS256 or HS512

Example:

{ “alg” : “HS256”, “type” : “JWT” }

When base64url encoded, this provides the following decoded string: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

The algorithm used here is HS256. But it is up to the developer to use the algorithm that best suits him and the company’s policies.

The payload is followed by a header, which is then followed by more content. Given that JWTs are employed in access control mechanisms, the payload must be relevant to the mechanism in order for it to function properly.

It can store information such as a username, a timestamp, a user role, and so on and so forth

When used in the example below, the goal of our token is to identify the role of the user. Here’s what the JWT token string looks like with the payloads encoded in base64 format:

eyJhY2Nlc3NfdHlwZSI6ImFkbWluIn0

When we decode the above string it shows an output like this

{access_type:”admin”,username:”securitylit”}

As you can see, it contains a number of attributes such as access type, username, and other information, which allows the server to distinguish between the types of resources to which they have access and the users who are attempting to access them.

So, if the header and the payload are basee64url encoded can’t they be easily changed?

Yes, they can be, and this is one of the reasons why they are insecure to use. However, it is because of the third element that JWT is reliable and secure to utilise.

The signature of a JWT is the third and final component of the token.

If you recall, the header section tells what algorithm to use. The header and the payload are first base64url encoded and then encrypted using a secret key. The format of the signature is provided below.

signature = HMAC-SHA256(base64urlEncode(header) + ‘.’ + base64urlEncode(payload), secret_key)

Just for the sake of this example, I’ve used the secret key as learnjwt.

The signature becomes: DnV2av0k-4PxoDRVLORqAA8cju8sZ8xAgq8tcV9oG7Q

For an application using JWT, you might see something as,

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhY2Nlc3NfdHlwZSI6ImFkbWluIn0.DnV2av0k-4PxoDRVLORqAA8cju8sZ8xAgq8tcV9oG7Q

The part in red, before the first dot, is the header, followed by the payload and then the signature.

Since the header and the payload are simply base64url encoded, you can decode them and look at their contents. But if you try to alter them to, either to impersonate your victim or change your role, you will get an error (provided that the JWT is properly configured).

This is because, the header and the payload can be faked but not the signature, until you access to the secret key.

Though JWT appears to be the one stop solutions to facilitate authentication and authorization, yet it can prove to be troublesome if not properly implemented.

Here are some of the ways that you can try to bypass JWT.

1. Change the Algorithm Type.

If the backend allows to alter the algorithm (alg), you can try to set it as None (ie “alg”:”None”).

Now that the algorithm has been set as None, you can tamper with the payload. The backed will not check the signature as it has been set to None.

2. Provide a invalid Signature.

It is also possible that the application never checks for the signature, therefore leading to JWT bypass.

3. Brute-force the secret key

Though not recommended, you can try to brute-force the secret key. In case the key is small and easy to guess, you can forge a valid signature after tampering with the payload.

JWT is an open standard used to share security information between two parties, i.e. a client and a server. It is compact, yet reliable to use. However, if not properly implemented, it can prove to be a nightmare for any web developer and for the company as well.

Some of the impacts of JWT misconfigurations and its limitations are:

Token Side jacking

Attackers use this method to obtain access to the system by impersonating a targeted user identity after intercepting or stealing a token from a user or system administrator.

No Built-In Token Revocation by the User

Once a JWT token has been issued, it cannot be revoked; it will only expire. Once the token has been compromised, there is no way for us to revoke the token until it expires.