What is JSON Web Token?

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object

In simple words,

“ A JSON Web Token (JWT) is a standardized format used to securely transfer information between two parties. ”

Structure of JWT

HEADER + PAYLOAD + SIGNATURE

This is the structure of JWT. A JWT contains a Header, Payload, and Signature separated by two dots.

Header: Shows the token type, which is JWT, and the signing algorithm being used, such as HMAC, HS256, or RSA.

Payload: Contains additional data, such as name, password, expiration date, city, etc.

Signature: Verify the message hasn’t changed along the way.

So as you have seen the structure of JWT, I will show you the actual JSON Web
tokeneyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiAiMTIzNDU2Nzg5MCIsIm5hbWUiOiAiQW51YmhhdiBTaW5naCIsImlhdCI6IDE1MTYyMzkwMjJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

So You are thinking about what type of Encoding or Encryption is used to produce this token

Decoded Token
{ “typ”: “JWT”, “alg”: “HS256” } . { “sub”: “1234567890”, “name”: “Anubhav Singh”, “iat”: 1516239022 }. SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

So if you see the first two parts, which are Header and Payload, they can be converted into clear text because these two parts are base64 URL encoded. So to get a clear text header simply do base64 URL decode :)

What is the difference between Base64 and Base64URL that I see above in JSON web tokens?

Both Base64 and Base64url are ways to encode binary data in string form. You can read about the theory of base64 here. The problem with Base64 is that it contains the characters +, /, and =, so sometimes this character does not work well when passed using GET parameters or HTTP headers. So base64url solves this by replacing some characters.

+ (plus ) is replaced by - (minus)
/ (slash) is replaced by _ (underscore)
= (Padding characters) are eliminated

So I think you have got the difference.

Example :

Base64 => WW91+IGFyZSBh/IGhhY2tlcg==

Base64 URL => WW91-IGFyZSBh_IGhhY2tlcg

How JWT Works?

Suppose we have a client who wants to retrieve some information from the Resource Server. So the first client has to authenticate to the server by giving login credentials, then the Authorization server talks with a Database in which the credentials are stored. Once the credentials are verified JWT token is generated, and the Authorization server replies back to the client with JWT Token.

So client gives this token to the Resource Server to access the resource that he wants from the Resource Server. When the resource server gets this JWT Token, it tries to verify if the JWT token is valid or not. The main work of the resource server is to verify the integrity of the token. So when the validation is done, the client will be given the resources he was requesting for.

From the Attackers Point of view :

To be able to successfully access those resources which are given back only with the valid JWT Token, the Attacker has 2 options

An attacker needs to have Login credentials So that he can request the Authorization Server for a valid JWT Token.
An attacker needs to have the signing key, which is used to create the JWT Token. So remember signing key can be available on the Authorization Server or the Resource server, so the attacker needs to compromise one of this server to get the signing key so he can create his own JWT Token and request those resources from the resource server.

Diving Deep in JWT

Here we are going deep in JSON web token. We will understand more about Header, payload, and Signature.

Header

typ: The type of token is JWT
alg: The algorithm used is HS256.

Because of the Header, the resource server gets to know what type of algorithm is used while validating the signature.

Payload

This part usually contains user identification information for authorization.

These are key-value pair formats. Once the signature part, followed by the payload part, is verified to be valid, this user anubhav will have access to the resources he is requesting.

As you can see here, user anubhav is not an admin user. So the main game in JWT is here only, we have to make changes in the payload to trick the server to get logged in as any other user or make a vertical privilege escalation.

Signature

In the below image, you can see HS256 Signature is used, but you may also see longer tokens that are created using the RS256 Algorithm.

In the signature part, it is crucial to ensure that the JWT token is not tampered with. The elements involved in creating a Signature are Header, payload, the key used with the Algorithm, and the type of Algorithm you want to use to create the Signature. Once the Signature is created, the Signature will be appended to the Header and payload.

When the created JSON web token is sent to the resource server, this Signature will be extracted, and the Signature is re-calculated on the resource server to make sure that the JWT payload does not tamper in any way.

HS256 and RS256 are commonly used algorithms.

HS256 :

HS256 Algorithm takes Header (base64url encoded) followed by a dot and the payload (base64url encoded). It appends a secret that is only known to an authorization server & the resource server, and then it performs SHA256 Hash of that. Once again, it will be encoded as base64url encode, and finally, it will be appended to the Header and payload. This how we get the HS256 Signature.

HS256 algorithm

Potential Security Issues with HS256:

Secret key is distributed to all the servers and if one server is compromised, the shared key can be stolen.
If the shared secret key is weak, then we can perform brute-forcing the key.

RS256 :

RS256 uses RSA and SHA256 algorithms.

SHA256 Hash of Header and Payload is generated.
This hash is signed using RSA Private key.
So, RS256 Signature is a signed SHA256 hash of Header, Payload.
This is appended to the Header and Payload as 3rd part of the JWT Token.

Once the Authorization server produces this JWT Token, this token is given back to the client. When the client presents this JWT to a resource server, the resource server requires RSA Public key to validate the Signature. The resource server ensures that the Signature present in the JWT is actually created using the private Key, which is with the authorization server.

Now, suppose the attacker wants to generate this JWToken using RS256. In that case, he needs to have access to the private key which is available only on the authorization server, and even the resource server cannot create JWToken. It can only validate the token created by the authorization server is valid or not.

So, One can reproduce this token only if he/she has the private key used to encrypt the hash.

None Signature :

This none type of Signature is not commonly seen when creating a JWToken. Still, some JWT frameworks provide support to this Signature. Because of this support provided by the framework, there could be some insecurity of JWT, leading to attacks like signature stripping.

None signature means there is no signature at all. So, an attacker can tamper with the data and send that tamper data to the server. The resource server will not know if the payload is modified because there is no signature associated with the token.

Author: Anubhav Singh.