What Is JSON Web Token And How It Works

JSON Web Token, or JWT (“jot”) for short, is a standard for safely passing claims in space-constrained environments. Compactness, Simplicity, and Usability are key features of its architecture. Although much more complex systems are still in use, JWTs have a broad range of applications. here we will cover the architecture of JWTs, including their binary representation and the algorithms used to construct them, while also taking a look at how they are commonly used in the industry.

A JSON Web Token looks like this :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.

TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQWhile

this looks very complex, it is a very compact and printable representation of a series of claims, along with a signature to verify its authenticity.

There are 3 parts of JWT Token.

• Header: It typically consists of two parts the first one is the type of the token, which is JWT, and the second one is the signing algorithms being used, such as HMAC SHA256 or RSA.

{

"alg":"HS256",

"typ":"JWT"

}

• Payload: The payload which contains the claims. Claims are statements about an entity by the user and additional data.

{

"sub":"1234567890",

"name":"John Doe",

"admin":true

}

• Signature: For the creation of the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

These claims are definitions or assertions made about a certain party or object. Some of these claims and their meanings are defined as part of the JWT spec. Others are user-defined. Behind JWTs the magic is that they standardize certain claims that are useful in the context of some common operations. For example, one of these common operations is establishing the identity of a certain party. Another key aspect of JWTs is the possibility of signing them, using JSON Web Signatures (JWS, RFC 75156), and/or encrypting them, using JSON Web Encryption (JWE, RFC 75167). Together with JWS and JWE, JWTs provide a powerful, secure solution to many different problems.

Use Of JWT's

• Authentication: If a user successfully logs in using their credentials, an ID TOKEN is returned. According to the OpenID, an ID Token is always a JWT.
• Authorization: Once a user is successfully logged in, an application may request to access routes, services, or resources on behalf of that user. JWT uses an Access Token, which may be in the form of a JWT. Each subsequent request includes the access token.
• Information Exchange: It is a good way of securely transmitting information between parties because they can be signed, which means you can be sure that the senders are who they say they are. Structure of a JWT allows you to verify that the content has not been tampered with.

                                            Figure 1: Use of JWT as access tokens in OAuth

Figure 2: Use of JWT for authorization grant in the OAuth framework

When should a JWT expire?

• As soon as possible, to prevent misuse for long periods.
• As late as possible, so that users don't have to reauthenticate all the time.
• Introduce a shortlived token used for authentication per request.
• Introduce a longlived token used to generate a new shortlived token when needed.

The longlived token is used in combination with a blacklist retracted tokens.

Should I accept all valid JWT's?

• No, because "none" is a valid algorithm.
• The key you use to check the signature should match the algorithm.