One of the most sort of the word within the web developer community JWT, everyone has either implemented or is willing to implement this in their projects specifically on their API Layer. Here I will discuss the basics of JWT briefly that will allow the developer to understand “What, How, Where and Why” about these tokens.

Acronym JWT & RFC Standards

A technical jargon that everyone is talking about, if we go with the acronym JWT it stands for JSON Web Token. Its a JSON object that’s outlined in under the RFS standard as RFC 7519 as a secure way to represent a group of information between two parties.

Highlights of these standards are

• Compact.
• URL Safe means of representing claims.
• Can be transferred between two parties.
• Encoded as JSON Object

Tokens are consumed as payload of

• JSON Web Signature (JWS) structure

Or

• Plaintext of a JSON Web Encryption (JWE) structure

Purpose of this token is enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.

Construct of Java Web Token

The token constructed as a group of a header, a payload, and a signature component with below format
header.payload.signature

Structure Details

Header

The header element of the token contains information about how the signature should be computed.

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

In the above JSON,

“typ” key specifies that the object is a Java web token,

“alg” key specifies which hashing algorithm is being used to create the signature component, in above example the value specifies that HMAC-SHA256 algorithm is used. This algorithm is used to describe a secret key, to compute the signature.

PAYLOAD

The payload element of the token is that the records that‘s hold on within token (this records are additionally as the “claims”)

{
“Practice”: “Applo”,
“iat”: “1512649623”
}

In above example has the standard Issued At Time claim (iat) and a custom claim (Practice).

The following are the set of standard fields

Reference URL

Note: The size of the data can have an effect on the overall size of the token, this generally isn’t an issue but having excessively large token could negatively effect on performance and cause latency.

SIGNATURE

HMAC-SHA256(base64urlEncoding(header) + ‘.’ + base64urlEncoding(payload), secret)

Signature is calculated by concatenating the header and payload with a period as a separator after these two values are encoded using Base64url Encoding.

The concatenated string is then encrypted using the cryptographic algorithm specified in the header, in this case HMAC-SHA256.

JWT Components Together

The three parts are encoded separately using Base64url Encoding, and concatenated using periods to produce the JWT

Final Token is as follows

const token = base64urlEncoding(header) + ‘.’ + base64urlEncoding(payload) + ‘.’ +  base64urlEncoding(signature)

Protection of data?

It is necessary to know that the aim of using JWT isn’t to cover or obscure data in any approach. Tokens ensures that information sent was truly created by associate authentic source and targeted receiver.

1. Token Data is encoded and signed, not encrypted.
2. The encoding data is to transform the JWT data’s structure.
3. Authorized data allows the data receiver to verify the authenticity of the source of the data.

Hence encoded & authorized data does not secure the data.

Verifying

It is always recommended to use JWT that are signed by the relevant algorithm like (HS256) where only the authentication server and the application server know the secret key that is defined by user.

The application server get the secret key from the server when the application start up and its authentication process is being initiated.The application will then verify that the signature received from JWT’s hashing operation validate the signature on the JWT itself (i.e. it validated the JWT signature created by the authentication server).

If the signatures are found exactly the same then, it defines that JWT is valid and after that API call will happen from an authentic source Else, the signature differs with each other that means JWT is not valid, which means an indicator of a potential threat may attack on application.

Therefore verification of JWT always adds a trust layer between itself and the current user.

Advantages

Stateless: These tokens are truly stateless with compact and self-contained with minimal information. It includes authentication, expiry details, custom claims digitally encoded.

Portable: A single token is capable to be used with multiple application based on the claims defined, it can be used for complex implementation of SSO – Single Sign On and implementation of token providers as well.

Smart Device Friendly: The tokens makes an ideal candidate for applications build specifically for smart devices as these are generally stuffed in authentication headers with no extra orchestration required such as cookies.

Robust Performance: JWT has a capability to be stuffed in the http request header and cut off an additional network round trips. This allows JWT an edge over other authentication mechanism.

Author : Vijay Dhirubhai Patel