What is JWT or JSON Web Token?

JWT stands for JSON Web Token. They are often used for authentication and authorization purposes in web applications. 

It's a compact, URL-safe means of representing claims between two parties. They are digitally signed, providing a way to verify the integrity and authenticity of the information contained within the token.

The Idea of JWT:

Imagine you have a special key that you can give to someone to prove who you are without telling them your password. This key has three parts:

A Label: This says what kind of key it is. Let's call it a "JWT Key."

Some Information: This is like a note that says who you are and what you're allowed to do.

A Secret Lock: This is like a lock that can only be opened with a special secret code.

So, when you want to prove your identity to a website, you send them your special key (JWT token). They can read the information to see who you are and what you're allowed to do. But they can't change the information, because it's locked with the secret code.

This way, you don't have to share your password all the time. You just give out your special key, and the website can trust it because of the secret lock. This is how JWT tokens work to help keep things secure on the internet.

The concept of JWT:

Here's a breakdown of how JWTs work and their main components:

Header: 

The header typically consists of two parts: the type of the token (JWT) and the signing algorithm being used (e.g., HMAC SHA256 or RSA). This part of the token is used to describe how the signature should be computed.

Payload:

The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional metadata. JSON Web Tokens come in three different types, known as JWT claims: registered, public, and private claims.

• Registered Claims (Standard Claims): These are a set of predefined claims that are commonly used in JWTs. They are not mandatory, but they provide a standard way to include common pieces of information. Some of the most commonly used registered claims are: 

1. iss (Issuer): Identifies the entity that issued the JWT
2. sub (Subject): Identifies the subject of the JWT, usually the user
3. aud (Audience): Identifies the recipients for whom the JWT is intended
4. exp (Expiration Time): Specifies the expiration time after which the JWT is not valid
5. nbf (Not Before): Specifies the time before which the JWT is not valid
6. iat (Issued At): Specifies the time at which the JWT was issued
7. jti (JWT ID): Provides a unique identifier for the JWT
   
   

• Public Claims (Custom Claims): These are claims that are defined by you, the developer, for your specific use case. They are used to include additional information that is relevant to your application but not covered by the registered claims. For example, you might include the user's role or permissions as custom claims. For instance, you could add a custom claim like:
  { "role": "admin" } as josn.
  
  
• Private Claims: These are similar to public claims but are meant to be agreed upon between parties that use them. They are not meant to be defined in any public standard and can be used for any purpose agreed upon by the sender and the recipient.

Each JWT you create can include any combination of these three types of claims. The registered claims provide a standardized way to convey essential information, while the public and private claims allow developers to include application-specific details and customize the JWT to their needs.

Signature:

To create the signature part you have to take the encoded header, the encoded payload, a secret, and the algorithm specified in the header and sign that.

Components of a token-based authentication system:

Access and refresh tokens are the components used in a token-based authentication system, often in combination with JWTs.

Access Token:

An access token is a short-lived token that a user receives after successfully authenticating with a server. It contains information about the user's identity and permissions. Access tokens are used to gain access to protected resources, such as specific API endpoints or data, without requiring the user to re-enter their credentials for every request.

Access tokens are often implemented using JWTs. They are signed by the server, which means they can be verified for authenticity, but they usually have a relatively short expiration time to enhance security. This is because if an access token is compromised, the attacker would only have access for a limited time.

Refresh Token:

A refresh token is a longer-lived token that is used to obtain a new access token after the current one expires. It is usually stored securely on the client side, such as in an HTTP-only cookie. When the access token expires, the client can use the refresh token to request a new access token from the authentication server without requiring the user to log in again.

Refresh tokens are not meant to be used directly to access resources; they are used to obtain new access tokens. They are typically more secure because they are not exposed to the same risks as access tokens. If a refresh token is compromised, it is less critical because it has a longer expiration time, and its purpose is limited to obtaining new access tokens.

In summary, access tokens are short-lived tokens that allow users to access protected resources, while refresh tokens are longer-lived tokens used to obtain new access tokens after they expire. Both access and refresh tokens are crucial components of token-based authentication systems, and they work together to provide a secure and efficient user authentication and authorization process.

Uses of JWT tokens:

JWTs can be used in various scenarios, such as:

• Authentication: After a user logs in, the server generates a JWT token and sends it to the client. The client stores the token (usually in a cookie or local storage) and sends it with each subsequent request to prove its authenticity. The server can then validate the token and grant access to protected resources.

• Authorization: JWTs can include claims like roles or permissions. The server can use these claims to determine whether a user is allowed to perform certain actions.

• Single Sign-On (SSO): In a multi-application environment, a user logs in once and receives a JWT token. This token can be used to authenticate the user across different applications without requiring them to log in again.

• Information Exchange: JWTs can be used to securely transmit information between parties. Since they are signed, the receiver can trust that the data hasn't been tampered with.

Final note:

It's important to note that while JWTs are secure and widely used, they should be used carefully. For example, sensitive information should not be stored in the payload, as the payload can be decoded. Additionally, JWTs should be transmitted over HTTPS to ensure their security.

Overall, JWTs provide a flexible and powerful way to handle authentication and authorization in web applications, offering a stateless and secure approach.