Understanding JWT

One of many ways of implementing Authentication & Authorization into your applications is the JWT (JSON Web Token)

A JWT is a string of random characters that is an encoded form of information.

Its a methodology of transmitting information between two parties securely in JSON format. The information can be trusted since it is digitally signed using a secret/key not disclosed to the user. In other words, only the party that has signed it has access to the secret/key, hence maintaining integrity.

---

Examples of where JWT is used

• Authentication | Authorization
• Transferring of sensitive data between parties (as mentioned above)

Perhaps the most common usage of JWT is for scenarios of Authentication. The procedure followed is as follows:

1. Once a user logs in, a JWT is issued to the user from the server.
2. The user sends this token with each subsequent request to the server via the Authorization header.
3. The server verifies this token to ensure that the user is who they claim to be and sends back the requested route/service if it was verified.

Note Although the JWT is signed and protected from fraud, this does not mean that it is encrypted - it is base64 encoded, which means that you could use a base64 decoder to get the JSON information. Therefore, avoid storing secret information in the JWT unless that information is by itself encrypted.

---

JWT Structure

The JWT consists of 3 main components, each separated by a single dot (.)

• Header
• Payload
• Signature

A JWT would therefore be in the form of:
hhhhhh.pppppppp.ssssss

Where the "h" characters represent the header, the "p" characters the payload, and the "s" characters the signature.

Let us shed some light on what each of these components represents.

---

The Header

The header usually gives information about the token itself: the type (in this case, JWT) and the algorithm used to sign it (Ex: SHA256).

An example Header is as follows:

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

---

The Payload

Perhaps the most important part of the JWT. This is where the "Claims" (user information and any additional data) are stored. "Additional data" could be the iat (issued at), sub (subject) and aud (audience).

An example Payload is as follows:

  {
    "sub": "1234567890",
    "iat": 1516239022,
    "name": "John Doe"
  }

The Payload and Header are Base64Url encoded.

---

Fun fact for the curious minds: Authorization can be implemented by having a "role" attribute in your JWT. For example:

  {
    "sub": "1234567890",
    "iat": 1516239022,
    "name": "John Doe",
    "role": "Admin"
  }

This "role" attribute can be validated in the backend to provide certain permissions for the calling user. For example, the server could check if the token has an Admin role, and if so, let the user access that specific resource.

---

The Signature

The Signature is a signed combination of the Base64Url encoded Payload & Header, the algorithm defined in the Header and a specified secret.

For example, say we are using the SHA256 Algorithm, then the secret would be as follows:

  HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    your-256-bit-secret
  )

The signature is to make sure that the data has not been altered. Also, to verify whether the user is who they claim to be - in cases where a private key was used for the signing process.

---

A Final Example

jwt.io

---

All in all, JWT can be intimidating if all we do is read about it and not apply it anywhere. However, once you implement Authentication using JWT, you will fully understand the entire concept - it might even become second nature.

Keep growing!