Nowadays JWTs are widely used as an authorization standard and allows for secure information transmission. There are a lot of features that make JWT the first choice to implement.So let’s dive into the blog post to uncover the basic terminologies of JWT, learn to build JWT from scratch and know about its working.

What is JWT??

It stands for JSON Web Tokens. JWTs are open, industry-standard (RFC 7519) for representing trusts between the 2 parties. By trust, it is implied that there establishes a secure transfer of information between the 2 communicating parties. The information sent is digitally signed that keeps its integrity preserved. Lets learn more about its features that makes it popular.

Features of JWT

Compact : The compact size of the jwt enables it to be sent via URL, POST request, HTTP header. The compactness also leverages high-speed transmission. Because of less overheads, Single sign-on widely uses jwt.

Self- Contained: JWT contains information about the user (will be discussed later in the post). So once a valid user is identified, the token is used to any further identification therefore removing the need to query the database again and again.

Structure of JSON Web Tokens

JWT is composed of 3 parts:
Header
Payload
Signature

So this is what a token looks like

Still Confused? Lets break down!

Header

Header forms the first part of the token that contains the algorithm used for signing. HMAC SHA256 and RSA are some of the popularly used algorithms. Also, it holds the type of the token type. It is structured in json that is further base64 encoded.

JWT can be distinguished as a JWS[ JSON Web Signature] or JWE[JSON Web Encryption]. If the value of alg (in the header) represents a signature algorithm, the JWT is a JWS; if it represents an encryption algorithm, the JWT is a JWE.

If you are wondering whats the difference btw JWS and JWE, lets make it clearer.

Signing is used in the token so that no one can tamper the data being communicated. Although the dilemma is, sensitive information can be sent if the token is just signed (as the base64 can be easily decoded). 
So if sensitive information is transferred as a part of token, a layer of security can be added by encrypting the token. That makes a JWE.

Hope you got is clear now! 

Heading towards the format, let’s see how it looks like:

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

Payload

It builds up the next part of the token. The payload contains the user information. They are called as claims.

The claims are of 3 types: Registered, public and private claims.

Payload Format

{
 "user": "testuser"
 "admin":"true"
}

The payload is then base64 encoded.

Note: As the header and payload are readable, it is strongly advised to not to stuff in any sensitive information unless the jwt is encrypted. 

Signature

Signatures verifies the identity of the sender and also endures that the sent data is not tempered with.This part basically takes in base64 encode header, base64 encoded payload, a secret, and the signing algo as the part of the header. All the 4 elements are combined to create a signature.

Format

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

Note: It is optional to create a signature, but its recommended. If you omit the signature, there jwt will contain only 2 parts (header and payload) and will be of the form (xxxxxxxxxx.yyyyyyyyyyyyy), that can be easily malformed over the transit.

On Combining the 3 components, here’s what we get

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoidGVzdHVzZXIiLCJhZG1pbiI6InRydWUifQ._e5Mro6PcJnrte1dJAFeuKEUoxPuy0e501Qg90LivD0

You can play around with these components on https://jwt.io

Also, when you are given the auth token as a part of request/response header, you can decode the part to get some useful information.

Working of JWTs

When the user authenticates with the server with his credentials, JSON Web token is generated by the server is returned back as the response.

Now when the user again requests for any protected route with JWT in its authorization header, as a first step, the server checks the JWT, verifies it and allows/disallows the user access based upon his authorization rights.

This authentication mechanism does not save the state of the user therefore on each request made, token verification has to be done.

Thats all for the blog post. In the upcoming post, I’ll be covering how JWTs can be exploited!!
Until then, keep exploring!!