What is a JWT (JSON Web Token)?

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. These claims can be user data or other relevant information encrypted for security purposes. JWTs are used in authentication and authorization protocols, including OAuth 2.0 and OpenID Connect, but can also be used in any context where claims about a subject need to be conveyed and integrity protected possibly also ensuring confidentiality.

---

JWTs consist of three parts: a header, a payload, and a signature.

• Header: This part typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.
• Payload: This contains the claims. Claims are statements about the user and other metadata. There are three types of claims: registered, public, and private claims.
• Signature: To create the signature, you have to take the encoded header, the encoded payload, a secret, and the algorithm specified in the header and sign that.

The combination of these three parts provides a robust framework for the transmission of data with validation.

JWTs offer several advantages over traditional cookies and sessions. They are:

• Stateless: The server doesn't need to store session data. Every single request contains all the information the server needs to validate the user and provide the response.
• Scalability: Since there's no session-related data storage involved, applications that use JWT scale more effectively.
• Decentralized: Information is stored within the token, and it doesn't rely on a centralized authentication server.

However, like all technologies, JWTs have their challenges. One needs to ensure the token's security and manage token expiration appropriately to prevent unauthorized access.

Traditionally, sessions and cookies were used for user authentication. When a user logs in, the server creates a session for the user, and the session ID is stored in a cookie on the user's browser. For subsequent requests, this session ID is used to fetch the session data and validate the user. JWTs, on the other hand, eliminate the need for sessions and cookies since the token itself contains all the necessary information about the user. This makes JWT a preferred choice for single-page applications and API-based architectures, where stateless authentication mechanisms are more suitable.

JWT claims are pieces of information asserted about a subject within a JSON Web Token. Claims are presented as name/value pairs within the JWT payload. These claims include both standard claims, which are predefined in the JWT specification, and custom claims, which are additional user-defined attributes relevant to the specific application.

Standard claims are predefined in the JWT specification and are intended to facilitate interoperability between different systems. Common standard claims include:

• JWT jti (JWT ID): The jti claim in a JWT is a unique identifier for the token. It is used to prevent the JWT from being replayed, ensuring that a token can be used only once, adding an extra layer of security.
• JWT aud (Audience): The aud claim identifies the recipients that the JWT is intended for. It helps ensure that the JWT is sent to and can be processed by the intended parties, preventing misuse in unintended contexts.
• JWT kid (Key ID): The kid (Key ID) claim in a JWT header is used to identify the key used to sign the token. This is particularly useful in scenarios where multiple keys are used and the recipient needs to know which key should be used to verify the signature.
• JWT Issuer (iss): The iss claim identifies the issuer of the JWT. This claim is used to verify that the JWT was issued by a known and trusted issuer, adding a layer of trust to the token's authentication process.
• JWT sub (Subject): The sub claim in a JWT identifies the subject of the token, typically the user. This claim is used by the receiving party to determine the principal about which the token asserts information, such as the authenticated user's identifier.
• JWT nbf (Not Before): The nbf claim defines a time before which the JWT must not be accepted for processing. This allows the token issuer to define a future start time for the token's validity, preventing its use before a certain moment.

Custom claims are additional claims that are not registered or predefined by the JWT standard. These can be used to convey information specific to your application, such as user roles or other attributes. Custom claims should be namespaced to avoid collisions with standard claims and other custom claims.

---

JWT is a token format, while a cookie is a storage mechanism. JWT can be stored in a cookie, but unlike session cookies, JWT can contain more user-specific data and doesn't rely on server-side session management.

JWTs are primarily used for authentication and secure data exchange. They are commonly used in single-page applications, mobile applications, and API-based architectures for stateless, server-side authentication.

JWT itself is just a data format, so its security depends on its usage. If implemented correctly, with proper signature validation and using HTTPS, JWT can be as secure as sessions. However, JWTs can be vulnerable if not properly handled, especially if the token is leaked or not encrypted when storing sensitive information.

Standard tokens in JWT refer to predefined claims specified in the JWT standard, which are intended to ensure interoperability between different systems. Examples include iss (issuer), exp (expiration time), and sub (subject), which provide essential data about the token's context and usage.

Custom tokens in JWT are user-defined claims that allow you to include additional information specific to your application needs, such as user roles or operational permissions. These are not registered or predefined and should be carefully namespaced to avoid collisions with standard claims.