Json Web Token (JWT)

JSON Web Token (JWT) is an open standard and are just one piece of the puzzle in ensuring trust and security in our application. The reason why JWT are used is to prove that the sent data was actually created by an authentic source. (are not used to secure data)

A JSON Web Token consists of three parts: Header, Payload and Signature.

The header component of the JWT contains information about how the JWT signature should be computed. The header is a JSON object in the following format:
{
“typ”: “JWT”,
“alg”: “HS256”
}

In this JSON, the value of the “typ” key specifies that the object is a JWT, and the value of the “alg” key specifies which hashing algorithm is being used to create the JWT signature component.

The payload component of the JWT is the data that‘s stored inside the JWT (this data is also referred to as the “claims” of the JWT). We can put as many claims as you like in Payload. There are several different standard claims for the JWT payload, such as “iss” the issuer, “sub” the subject, and “exp” the expiration time. These fields can be useful when creating JWT, but they are optional.

Code Name Description
iss Issuer Identifies principal that issued the JWT.
sub Subject Identifies the subject of the JWT.
aud Audience Identifies the recipients that the JWT is intended for. Each principal intended to process the JWT must identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the aud claim when this claim is present, then the JWT must be rejected
exp Expiration time Identifies the expiration time on or after which the JWT must not be accepted for processing. The value should be in NumericDate format.
nbf Not before Identifies the time on which the JWT will start to be accepted for processing.
iat Issued at Identifies the time at which the JWT was issued.
jti JWT ID Case sensitive unique identifier of the token even among different issuers.
  • The signature is computed using the following pseudo code:

// signature algorithm

data = base64urlEncode( header ) + “.” + base64urlEncode( payload )

hashedData = hash( data, secret )

signature = base64urlEncode( hashedData )

The algorithm then joins the resulting encoded strings (header and payload) together with a period (.) in between them. In our pseudo code, this joined string is assigned to data. The data string is hashed with the secret key using the hashing algorithm specified in the JWT header. The resulting hashed data is assigned to hashedData. This hashed data is then base64url encoded to produce the JWT signature.

Now that we have created all three components, we can create the JWT. Remembering the header.payload.signature structure of the JWT, we simply need to combine the components, with periods (.) separating them.

JWT works best for single use tokens. Ideally, a new JWT must be generated for each use.

Acceptable use cases:

  • Server-to-server API calls, where the client can store a shared secret and generate a new JWT for each API call.
  • Give tokens an expiration : Technically, once a token is signed – it is valid forever – unless the signing key is changed or expiration explicitly set. Having an expiration in your JWT payload, a short one in particular, is important so that if old JWT ever get compromised, they will be considered invalid and can no longer be used.
  • As a way for one system to provide a logged in user limited access to another system.
  • No Database Table : This implies fewer DB queries, which implies faster response time.
  • Embrace HTTPS : Do not send tokens over non-HTTPS connections as those requests can be intercepted and tokens compromised. Having HTTPS helps prevents unauthorized users from stealing the sent JWT by making it so that the communication between the servers and the user cannot be intercepted.
  • Keep it secret. Keep it safe : The signing key should be treated like any other credentials and revealed only to services that absolutely need it.

To show how and why JWT are actually used, a simple 3 entity example (see the below diagram). The entities in this example are the user, the application server, and the authentication server. The authentication server will provide the JWT to the user. With the JWT, the user can then safely communicate with the application.

How an application uses JWT to verify the authenticity of a user.

JWT Authentication flow in Restful API:

We can implement below flow as well:

Leave a Reply

Your email address will not be published. Required fields are marked *