The structure of JWT

I talked about JWT last week and we get the basic idea of what is JWT, how it works etc. Today I will talk about the structure of JWT and its pros and cons.

If you haven’t read about JWT, you can read it here. So lets get started.

A JWT contains 3 parts separated by a “.” sign. These are header, payload and signature.

You can also take a look and can play debugging of these three parts at the official website of JWT called jwt.io

Header

Header contains the type of token and algorithm used for signing and encoding. Algorithms can be HMAC, SHA256, RSA, HS256 or RS256.

{ 
  "typ": "JWT",    
  "alg": "HS256"
}

Payload

Payload contains the data we are exchange through client and server. Here is the sample payload.

{
  "uid": "1234567890",
  "name": "yuuma",
  "iat": 1231313123
}

We can also add expiration payload to add expiration date of that token. We have to be careful about sensitive informations since, JWT can be decoded easily.

Signature

Signatures are the most important part of JWT. It is calculated by encoding the header and payload using the Base64url encoding and concatenating them with a dot sign. This is then passed to the encryption algorithm. If he header or payload changes, signature has to calculated again.

//sample from jwt.io
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  your-256-bit-secret
) secret base64 encoded

Tips

We have to be careful about these facts if we are using JWT token in your authorization mechanism

• Use HTTPS to protect the Authorization header.
• Better to prepare with blocklist tokens as the attacker might get JWT token before it’s expiration date.
• If the JWT is cookie-persistent, you need to create an HttpOnlyCookie. This restricts third-party JavaScript from reading the JWT token from the cookie.
• For XSS, the server side should always sanitize user-generated data.
• For CSRF, have to mitigate CSRF by using the source of the request and special request headers.