What exactly is a JWT?
By: Benjamin Mitchell
Tags: Web Development, Backend Development, API, Json Web Token, Web Security

What exactly is a JWT? A JSON Web Token (JWT) is an open standard (RFC 7519) that specifies a compact and self-contained method for securely sending information as a JSON object between parties.

A JWT is a way of expressing claims that are going to be transferred between two people. A JWT’s claims are encoded as a JSON object that is signed using JSON Web Signature (JWS) and/or encrypted with JSON Web Encryption (JWE).

Because it is digitally signed, this information can be checked and trusted. A secret key (using the HMAC method) or a public/private key combination (using RSA or ECDSA) can be used to sign JSON Web Tokens.

Session vs. JWT

The most frequent method of authorization is to use a session. JWTs and sessions are distinguished by the fact that JWTs are self-contained, but sessions are not.

A JSON Web Token comprises the following information:

Payload: Keeps track of the user’s information and permissions.

Signature: Checks that the token is valid.

As a result, when a server receives a JWT, it may immediately access all of the information from the token, making it self-contained. A SessionID, on the other hand, is just a lengthy, random string. It has no information on its own. When you send a request to a server with your SessionID, the server has to perform extra work to figure out who you are.

Structure of JWT

JSON Web Tokens have three components, each separated by a dot (.):

Header: The header usually has two parts: the kind of token (JWT) and the signature algorithm (HMAC SHA256 or RSA)

Header JWT

Payload: Which contains the claims, is the second component of the token. Claims are assertions and extra data about an object (usually the user). JWT claims can be divided into two categories:

a. Reserved: Claims established by the JWT standard to enable compatibility with external, third-party applications. Reserved claims are OIDC standard claims. Here are a few examples of typical assertions that we can make:

· Subject (sub): Subject of the JWT (the user)

· Issuer (iss): Issuer of the JWT

· Audience (aud): Recipient for which the JWT is intended

· Expiration time (exp): Time after which the JWT expires

· Issued at (iat): The time at which the JWT was issued; can be used to determine the age of the JWT

c. Custom: Claims that you define yourself. To avoid collisions with reserved claims or other custom claims, name these claims wisely. Dealing with two claims with the same name but different facts may be difficult.

Claims of JWT

Signature:

The most essential component of the JWT is the signature. The signature is created by concatenating the header and payload using Base64url Encoding and a period separator. The crypto algorithm is then given it.

JWT Signature

When Should JWT Be Used?

JSON Web Tokens are useful in the following situations:

Authorization

Is the most typical circumstance in which JWT is used. Each subsequent request will contain the JWT once the user has signed in, allowing the user to access routes, services, and resources that are authorized with that token.

Information Exchange

JSON Web Tokens are a useful way to send information securely between parties. You can be sure the senders are who they say they are because JWTs may be signed — for example, using public/private key pairs.

Flow of JWT

Let’s have a look at JTW’s flow to get a clearer idea of what’s going on:

1. The user signs in with his “Username” and “Password.”

2. The server double-checks the validity of your credentials (Username & Password).

3. The server generates a JSON object if the credentials are valid.

4. The server then serializes the JSON data and generates a token before sending it to the browser.

5. The token is received by the browser and saved in the cookies.

6. The JWT is provided along in the request HTTP header the next time the user submits a request to a protected endpoint.

When Using JWT, Follow These Best Practices

If JWT is retained on the cookie, create a HttpOnly cookie to prevent third-party JavaScript from accessing the JWT token.

If a JWT token hasn’t expired and falls into the wrong hands, exploits may occur. Creating a token revocation list on your server to invalidate tokens when users leave your site might assist improve security, and to protect authorization headers, always use HTTPS.