JWT

What is JWT?

JWT is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.

JWTs are commonly used for authorization and information exchange. They can encode user credentials and are often used in token-based authentication systems.

JWTs are secure because they can be digitally signed. However, they should be transmitted securely and stored safely. Since JWTs can contain sensitive information, they should not be exposed to untrusted environments.

Usage Example

Now, suppose the user wants to access a restricted area of the website that requires an authentication token.

• Login Process: Upon successful login, instead of or in addition to creating a session, the server creates a JWT containing user information and digitally signs it.
• Token Structure: The JWT typically consists of three parts - header, payload, and signature. The payload might include user identification info.
• Sending the Token: This token is sent to the user's browser.
• Browser's Role: The browser stores this token (often in local storage) and sends it in the HTTP Authorization header with requests to access protected resources.
• Server Verification: The server verifies the token's signature to ensure it's valid and hasn't been tampered with and then grants or denies access based on the token.

Difference under the hood

• Storage Location: Can be stored in the browser (often in local storage) or sent in each HTTP request's headers.
• Data Storage: Encodes data as a token, which includes information and a signature. The token can contain claims (data) about the user.
• Management: Created and signed by the server. The browser simply stores and transmits the token.
• Use Case: Ideal for scenarios where stateless authentication is needed, especially in distributed systems or APIs.
• Security: Secure as they are digitally signed. Vulnerable to theft, so it's crucial not to store sensitive information directly in the token and to transmit securely.

JWT structure

Header: The header 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.

Example:

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

This JSON is Base64Url encoded to form the first part of the JWT.

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 data. There are three types of claims: registered, public, and private claims.

Example:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

This JSON is also Base64Url encoded to form the second part of the JWT.

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

For example, if you're using the HMAC SHA256 algorithm, the signature will be created in the following way:

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

The signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed along the way.

Where to Use Public and Private Keys

• Private Key:

  • Location: Stored securely on the server that generates and signs the JWTs.
  • Usage: Used to sign the JWT before sending it to the client.

• Public Key:

  • Location: Can be distributed to any server or service that needs to verify the JWT. It can be public because it cannot be used to generate valid tokens, only to verify them.
  • Usage: Used to verify the JWT's signature when a client presents the token for authentication.

Example Flow with Public/Private Key:

• Server A (Authentication Service) generates a JWT after a user logs in and signs it with its private key.
• Server B (Resource Server) receives a request with the JWT and uses the public key to verify the token. If valid, Server B allows access to the requested resource.