Getting started with JSON Web Tokens - A Complete beginners guide

Nowadays, JSON web token is becoming more popular to make secure rest API, so today here we will learn what is exactly JWT and how it works.

So, let's get started...

What is JSON Web Token

  A JSON Web Token (JWT) is a JSON object that is defined in RFC 7519 as a safe way of transmitting information between two parties. Information in the JWT is digitally-signed so that it can be verified and trusted.  

How token is made

Basically, the token is the sum of Header + Payload + Signature which are seprated by dots(.), this information you can get when you decode it.

Therefore, a JWT typically looks like the following.

xxxxx.yyyyy.zzzzz

Let’s break it down.

Header

The JWT Header consists of 2 parts:

• The type of the token, which is JWT,

• The hashing algorithm is used to sign the token such as HMAC, SHA256 or RSA.

For example:

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

Payload

The Payload, also known as the JWT claim, contains all of the information we want to transmit.

For example:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Signature

The secret is the Signature held by the server in order to verify tokens and sign new ones.

Final Result:

After putting all above three things together, it becomes  three Base64 strings separated by dots, as shown below:

WHEN SHOULD YOU USE JSON WEB TOKENS?

These are some scenarios where JSON Web Tokens are useful:

A) Authentication:

 This is the typical scenario for using JWT, once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. Single Sign On is a feature that widely uses JWT nowadays, because of its small overhead and its ability to be easily used among systems of different domains..

B) Information Exchange:

JWTs are a good way of securely transmitting information between parties, because as they can be signed, for example using a public/private key pair, you can be sure that the sender is who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn’t changed.

HOW JSON WEB TOKENS WORK?

In authentication, when the user successfully logs in using their credentials, a JSON Web Token will be returned. Since tokens are credentials, great care must be taken to prevent security issues. In general, you should not keep tokens longer than required.

You also should not store sensitive session data in browser storage due to a lack of security.

Whenever the user wants to access a protected route, it should send the JWT, typically in the Authorization header using the Bearer schema. Therefore the content of the header should look like the following.

Authorization: Bearer <token>

This is a stateless authentication mechanism as the user state is never saved in the server memory. The server’s protected routes will check for a valid JWT in the Authorization header, and if there is, the user will be allowed. As JWTs are self-contained, all the necessary information is there, reducing the need of going back and forward to the database.

This allows to fully rely on data APIs that are stateless and even make requests to downstream services. It doesn’t matter which domains are serving your APIs, as Cross-Origin Resource Sharing (CORS) won’t be an issue as it doesn’t use cookies.

Is the token should be stored on DB or not?

When should Token be sent on the register?

• If the user is going to logged in direct after they have register you can send token
• If the user is going to redirect to login page, then just send a success message

Ideal ways to send token

Send Token in Cookie,httponly (Can only accessed by backend), if you just send normal cookie it can access anyone sends in the header

where to send the token in case of Web or Mobile?

Things to remember:

• JWT does not hide information; it just encodes information using the digitally-signed signature and verifies that the information has not been altered over the network. So, do not add any sensitive information to the JWT claim.

• You should treat the token as your car key, so that means everyone who has the token can access your key and drive your car without your permission.

• The token should always Expire, after some time like two days,7 days.
• Never pass the password in Payload as it can be decided, you can send email or some id if needed in payload information