Chat with LLM: JWT

Posted on In Word count in article: 3.8k Reading time ≈ 14 mins.

Introduction

“Chat with LLM” refers to learning knowledge by interacting with LLM chat tools (such as DeepSeek, ChatGPT). Learning through Q&A is more efficient. The content of these blog posts on “Chat with LLM” is mainly derived from my conversations with LLM chat tools.

This post explains the principles, workflow, advantages, and disadvantages of JWT.

Q1. JWT Principles

Q:

Introduce the principles of JWT.

A:

JSON Web Token (JWT) is an open standard (RFC 7519) used for securely transmitting information between networked applications. Its core principle is to ensure the integrity and trustworthiness of the information via digital signatures or encryption, and it is commonly used for authentication and authorization. Below is a detailed explanation of JWT’s principles and workflow:

1. JWT Structure
JWT consists of three parts, separated by dots (.), in the form: Header.Payload.Signature. Example: xxxxx.yyyyy.zzzzz

1.1 Header

  • Purpose: Declares the token type (JWT) and the signature algorithm (e.g., HMAC SHA256 or RSA).
  • Format: A JSON object that is Base64Url encoded.
  • Example:
    1
    2
    3
    4
    {
      "alg": "HS256",  // signature algorithm
      "typ": "JWT"     // token type
    }

1.2 Payload

  • Purpose: Carries the actual data to be transmitted (known as “claims”).
  • Format: A JSON object that is Base64Url encoded.
  • Types of claims:
    • Registered Claims: Standard fields, such as iss (issuer), exp (expiration time), sub (subject), etc.
    • Public Claims: Customizable claims, but must avoid collisions.
    • Private Claims: Fields agreed upon between the parties.
  • Example:
    1
    2
    3
    4
    5
    {
      "sub": "user123",
      "name": "Alice",
      "exp": 1620000000  // expiration timestamp
    }

1.3 Signature

  • Purpose: Verifies that the message has not been tampered with and ensures the authenticity of the sender.
  • Generation: Concatenate the Base64Url encoded Header and Payload with ., and then generate the signature using the algorithm specified in the Header and a secret key.
  • Example (using the HS256 algorithm):
    1
    2
    3
    4
    HMACSHA256(
      base64UrlEncode(header) + "." + base64UrlEncode(payload),
      secretKey
    )

2. JWT Workflow

  1. User Login: The client submits credentials (e.g., username and password) to the server.

  2. JWT Generation: After verifying the credentials, the server generates a JWT:

    • Constructs the Header and Payload.
    • Generates the signature using a secret key, combining all three parts to form a complete JWT.

  3. Returning the JWT to the Client: The client stores the JWT locally (e.g., in LocalStorage or Cookie).

  4. Client Requests with JWT: Subsequent requests carry the JWT in the Authorization header in the Bearer format:

    1
    Authorization: Bearer <JWT>

  5. Server JWT Verification

    • Decodes the Header and Payload, and checks if the signature is valid (to prevent tampering).
    • Verifies the claims (e.g., whether exp has expired or if iss is valid).
    • If verification passes, returns the requested resource.

3. JWT Security

  • Information Exposure: The Header and Payload are only Base64 encoded and are not encrypted, so sensitive information (e.g., passwords) should not be included.
  • Transmission Security: Must be transmitted via HTTPS to prevent man-in-the-middle attacks.
  • Key Management:
    • For symmetric algorithms (e.g., HS256): The key must be strictly protected.
    • For asymmetric algorithms (e.g., RS256): The private key signs, and the public key verifies, which is more secure.
  • Tamper Resistance: The signature ensures data integrity, but care must be taken to prevent key leakage.

4. Advantages and Disadvantages of JWT

Advantages

  • Stateless: The server does not need to store session information, making it suitable for distributed systems.
  • Cross-Domain Support: Easily used in cross-domain scenarios (e.g., microservices, single sign-on).
  • Flexibility: The Payload can be customized to include additional data.

Disadvantages

  • Revocation Challenge: Once issued, a JWT cannot be forcibly invalidated before its expiration (requires token blacklisting or short expiration times).
  • Storage Risk: Client-side storage may be susceptible to XSS attacks (using HttpOnly Cookie is recommended).

5. Typical Use Cases

  1. User authentication (e.g., OAuth 2.0 Bearer Token).
  2. API authentication between services (microservices architecture).
  3. Single sign-on (SSO).

Through the principles above, JWT achieves secure information transmission in a compact and self-contained manner, becoming a widely used authentication solution in modern web development.

Q2. Which Parts Are Plaintext?

Q:

Which parts among the three are effectively plaintext to the user?

A:

In the three parts of a JWT (Header, Payload, Signature), the Header and Payload are plaintext for the user, while the Signature is an encrypted signature that cannot be directly interpreted. Here is a detailed explanation:

1. Header and Payload are Plaintext

  • Reason: The Header and Payload are only Base64Url encoded (a URL-safe encoding method) and are not encrypted.

  • Characteristics:

    • Reversible: Anyone can decode them using a Base64Url decoding tool (such as jwt.io) to obtain the original JSON data.
    • Transparency: The decoded content can be directly viewed, for example:
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      // Decoded Header:
      {
        "alg": "HS256",
        "typ": "JWT"
      }

      // Decoded Payload:
      {
        "sub": "user123",
        "name": "Alice",
        "exp": 1620000000
      }

  • Risks:

    • Sensitive Information Leakage: If sensitive data (such as user ID, email, permissions) are stored in the Payload, an attacker can easily read them.
    • Tampering Risk: Although they can be decoded and modified, it is not possible to forge a valid signature without the key.

2. Signature is Ciphertext

  • Reason: The Signature is the encrypted signature of the Header and Payload, generated using a secret key and a specified algorithm (e.g., HS256, RS256).
  • Characteristics:
    • Non-reversible: It cannot be decoded directly to retrieve the original information; it is essentially a hash or an encrypted binary data.
    • Tamper-Proof: The server verifies the Signature to ensure that the Header and Payload have not been altered.

3. Example from a User’s Perspective

Assume a JWT as follows:

1
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwiZXhwIjoxNjIwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

  • Header：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . Decoded:

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

  • Payload：eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwiZXhwIjoxNjIwMDAwMDAwfQ . Decoded:

    1
    { "sub": "user123", "name": "Alice", "exp": 1620000000 }

  • Signature：SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c .This cannot be directly decoded and requires a key to verify.

4. Security Recommendations

  1. Avoid Sensitive Data: Do not store passwords, keys, or other sensitive information in the Header or Payload.
  2. Use HTTPS: Prevent JWT theft during transmission.
  3. Short Expiration: Set a reasonable expiration time using the exp field to reduce the risk if compromised.
  4. Encrypt Sensitive Fields: If sensitive data must be stored, consider additional encryption for the Payload (e.g., using JWE).

Summary

  • Plaintext Parts: Header and Payload (Base64Url encoded and reversible).
  • Ciphertext Part: Signature (encrypted signature, irreversible).
  • Core Security Mechanism: Relies on the Signature to prevent tampering, not on hiding the data itself.

Q3. Hashing vs. Encryption

Q:

So does the Signature first hash the Header + Payload and then encrypt the hash? When the server receives the Signature, does it first decrypt it and then verify whether the hash is correct?

A:

Your question touches on the core mechanism behind JWT signature generation and verification, but it is important to distinguish between hashing and encryption. Different signature algorithms (such as HS256 and RS256) implement this process in distinct ways. The specific procedures are as follows:

1. JWT Signature Generation Process

(1) HMAC Algorithm (e.g., HS256)

  • Core Mechanism: Based on a keyed hash (no encryption involved).
  • Steps:
    1. Encode the Header and Payload in Base64Url and concatenate them with a dot (resulting in header_b64.payload_b64).
    2. Compute the hash: Use HMAC combined with a hash function (such as SHA256) and a secret key to generate a Message Authentication Code (MAC).
    3. Generate the Signature: Base64Url encode the hash result to obtain the Signature.
  • Formula:
    1
    Signature = Base64UrlEncode(HMAC_SHA256(header_b64.payload_b64, secret_key))

(2) RSA Algorithm (e.g., RS256)

  • Core Mechanism: Based on asymmetric encryption signatures (involving encryption).
  • Steps:
    1. Encode and concatenate the Header and Payload in Base64Url (forming header_b64.payload_b64).
    2. Compute the hash: Use a hash function (e.g., SHA256) to generate a hash of the concatenated string.
    3. Encrypt the hash: Encrypt the hash using the private key (i.e., create a digital signature).
    4. Generate the Signature: Base64Url encode the encrypted result to obtain the Signature.
  • Formula:
    1
    Signature = Base64UrlEncode(RSA_Encrypt(SHA256(header_b64.payload_b64), private_key))

2. Server Verification Process

When the server receives a JWT, it verifies the signature as follows:

(1) HMAC Algorithm (HS256)

  • No Decryption Needed: Since HMAC is a keyed hash, not encryption.
  • Verification Steps:
    1. Recompute the HMAC hash of header_b64.payload_b64 using the same secret key.
    2. Compare the computed result with the decoded Signature from the JWT.
    3. If they match, the data has not been tampered with.

(2) RSA Algorithm (RS256)

  • “Decryption” Required: Here, the “decryption” is actually the signature verification process.
  • Verification Steps:
    1. Use the public key to decrypt the decoded Signature, obtaining the original hash.
    2. Recompute the hash of header_b64.payload_b64 (e.g., using SHA256).
    3. Compare the decrypted hash with the recomputed hash.
    4. If they match, the data has not been tampered with.

3. Key Differences Summary

Algorithm Type Keyed Hash (HMAC) Asymmetric Encryption (RSA)
Signature Generation Based on a keyed hash, no encryption Private key encrypts the hash value
Signature Verification Recompute and compare hash Public key decrypts signature, then compare hash
Key Management Symmetric key (kept on the server) Asymmetric keys (private key for signing, public key for verification)
Security Relies on the secrecy of the key Relies on the security of the private key

4. Answering Your Questions

  • Question 1: “Does the Signature first hash the Header + Payload and then encrypt the hash?”

    • Answer:
      • For HMAC (e.g., HS256): It only hashes (using a secret key), without encryption.
      • For RSA (e.g., RS256): It first hashes, then encrypts the hash value using the private key.

  • Question 2: “When the server receives the Signature, does it first decrypt it and then verify whether the hash is correct?”

    • Answer:
      • For HMAC: There is no decryption; it simply recomputes the hash and compares.
      • For RSA: It needs to “decrypt” (verify the signature using the public key) to retrieve the hash, then compare it with the recomputed hash.

5. Clearing Up Misconceptions

  • Hashing ≠ Encryption:
    • Hashing is a one-way, irreversible process (e.g., SHA256) used to ensure data integrity.
    • Encryption is a reversible process (e.g., RSA) used to protect data confidentiality.
  • The Essence of JWT Signatures:
    • HMAC is a keyed hash (providing integrity and authentication).
    • RSA encrypts the hash value (providing integrity and non-repudiation).

6. Practical Code Examples (Pseudocode)

HS256 Signature Verification

1
2
3
4
5
def verify_hmac(jwt, secret_key):
    header_b64, payload_b64, signature_b64 = jwt.split('.')
    data = header_b64 + "." + payload_b64
    expected_signature = HMAC_SHA256(data, secret_key)
    return expected_signature == base64url_decode(signature_b64)

RS256 Signature Verification

1
2
3
4
5
6
7
def verify_rsa(jwt, public_key):
    header_b64, payload_b64, signature_b64 = jwt.split('.')
    data = header_b64 + "." + payload_b64
    decoded_signature = base64url_decode(signature_b64)
    decrypted_hash = RSA_Decrypt(decoded_signature, public_key)  # 用公钥“解密”
    actual_hash = SHA256(data)
    return decrypted_hash == actual_hash

Summary

  • The signature mechanism of JWT varies depending on the algorithm:
    • HMAC: Relies on key-based hashing, verifies by directly comparing hash values.
    • RSA: Encrypts the hash value with a private key, verifies by decrypting with the public key and comparing.
  • Core Objective: Ensures that the Header and Payload have not been tampered with, rather than encrypting the data itself.
  • Security Recommendation: Choose the algorithm based on the scenario (HS256 is simple and efficient, RS256 is more suitable for distributed systems).

Q4. Forward Secrecy

Q:

According to what you said, regardless of HMAC or RSA, JWT does not support forward secrecy.

A:

Yes, your understanding is correct. JWT (whether using HMAC or RSA signature algorithms) does not support Forward Secrecy (FS). Here is a detailed explanation:

1. Core Concept of Forward Secrecy

Forward secrecy is a security feature that ensures that even if a long-term key (such as the server’s private key or the shared key for HMAC) is compromised in the future, an attacker cannot decrypt past communications or forge historical sessions.

Key to achieving forward secrecy: Each session uses a temporarily generated key (as in TLS with ECDHE key exchange), and the key is destroyed after the session ends, rather than relying on a long-term key.

2. Why JWT’s Signature Mechanism Does Not Support Forward Secrecy

(1) HMAC (Symmetric Signature Algorithms like HS256)

  • Relies on a Long-Term Key: HMAC uses the same shared secret key (secret_key) for both signing and verification, and this key is usually long-lived.
  • Risk: Once the secret_key is compromised, an attacker can forge any historical or future JWT.
  • No Temporary Key Mechanism: The HMAC key does not change per session, so forward secrecy cannot be achieved.

(2) RSA (Asymmetric Signature Algorithms like RS256)

  • Relies on a Long-Term Private Key: The signing is done using a fixed private key, while the public key is used for verification.
  • Risk: If the private key is compromised, an attacker can forge historical or future JWTs.
  • Fixed Key Nature: The RSA private key is generally static, and the signature process does not involve temporary keys.

3. Why JWT Does Not Natively Support Forward Secrecy

  • Different Design Goals: JWT is designed to be a stateless, self-contained token mechanism, rather than managing dynamic sessions.
  • Static Token Characteristics: Once a JWT is issued, its validity is solely based on its signature and claims (such as exp), and the key cannot be dynamically updated.
  • Limited Use Case: JWT is typically used for authentication and authorization rather than end-to-end encrypted communications, so it does not incorporate complex key negotiation mechanisms.

4. Mitigation Strategies for the Lack of Forward Secrecy in JWT

Although JWT itself does not support forward secrecy, the following strategies can help mitigate the risk:

(1) Short-Lived Tokens

  • Set a short exp (expiration) time, such as 15 minutes to 1 hour, to reduce the attack window if the key is compromised.
  • Combine with a refresh token mechanism to dynamically update access tokens.

(2) Key Rotation

  • Regularly change the shared secret for HMAC or the private key for RSA.
  • Invalidate issued JWTs after key rotation (e.g., using a blacklist or short expiration).

(3) Leverage TLS Forward Secrecy

  • Use TLS 1.3 and enable cipher suites that support forward secrecy (e.g., ECDHE-ECDSA-AES128-GCM-SHA256).
  • Ensure that JWTs are transmitted over secure channels (HTTPS) to prevent eavesdropping and man-in-the-middle attacks.

(4) Use Stateless Short-Lived Tokens

  • For example, OAuth 2.0 access tokens (often JWTs) are designed to be short-lived and can be combined with server-side state management (e.g., database record of token status).

(5) Encrypt Sensitive Data

  • Encrypt sensitive fields in the JWT Payload (e.g., using JWE).
  • Use a hybrid approach: the JWT signature ensures integrity while encryption ensures confidentiality.

5. Alternative Token Mechanisms That Support Forward Secrecy

If forward secrecy is a strict requirement for your application, consider other approaches:

  • Dynamic Session Keys: Generate temporary keys on the server for each session, then sign and transmit them to the client (though this contradicts the stateless nature of JWT).
  • Stateful Session Tokens: Use session cookies with server-side stored temporary keys (sacrificing statelessness for forward secrecy).
  • End-to-End Encryption Protocols: Implement application-layer protocols (such as the Signal Protocol) that provide forward secrecy, though with increased complexity.

6. Summary

  • JWT Does Not Support Forward Secrecy: It relies on long-term keys (either the HMAC shared secret or the RSA private key).
  • Mitigation Measures: Use short-lived tokens, key rotation, TLS with forward secrecy, and additional encryption where necessary.
  • Design Trade-off: JWT’s simplicity and statelessness are balanced against security needs based on your specific use case.

If your application demands strong forward secrecy, it is recommended to implement it at the transport layer (via TLS) or within the application protocol (such as using short-lived OAuth 2.0 tokens), rather than relying solely on JWT’s mechanism.

Q5. Another Perspective on JWT

Q:

In a login scenario, can I understand JWT technology as follows: the server does not use sessions at all, and only stores some user-related information in a cookie, and at the same time, the cookie cannot be tampered with by the user.

A:

In a login scenario, your understanding is basically correct.

Q6. The Purpose of JWT Header

Q:

Why do we need to declare the token type (JWT) and the signature algorithm (e.g., HMAC SHA256 or RSA) in the Header?

Verifying whether the payload has been tampered with is entirely the server’s job, right? If so, why transmit this information between the client and the server?

Is this to allow the server to be compatible with multiple verification methods?

A:

1. Reasons for Declaring the Token Type and Algorithm in the Header

The Header of a JWT must include the alg (signature algorithm) and typ (token type) fields, as explicitly required by the JWT standard (RFC 7519). Their necessity is reflected in the following points:

(1) The Server May Need to Dynamically Choose the Verification Method

  • Scenario: The server might support multiple signature algorithms (e.g., both HS256 and RS256).
  • Problem: Without declaring the algorithm in the Header, the server would not know which algorithm and key to use to verify the signature.
  • Example:
    1
    2
    3
    4
    5
    // Header
    {
      "alg": "RS256",  // The server, upon seeing this, selects public key verification for RSA signature.
      "typ": "JWT"
    }

(2) Preventing Algorithm Confusion Attacks

  • Background: An attacker might tamper with the alg field in the Header to trick the server into using the wrong algorithm for signature verification (for example, changing RS256 to HS256).
  • Mitigation:
    • The server should strictly validate that the alg field is an expected value (e.g., only allowing RS256).
    • Never rely solely on the algorithm declared by the client, but rather enforce the server’s pre-configured allowed algorithms.

(3) Clearly Identifying the Token Type

  • Purpose: The typ: "JWT" indicates that this is a standard JWT token, avoiding confusion with other types of tokens (such as encrypted JWE).
  • Extensibility: If new token types (e.g., JWT+XML) are introduced in the future, this field helps distinguish between them.

2. Why Transmit the Header to the Client?

  • Core Logic: JWT is a self-contained token; the server does not need to store additional information to verify it.
    • For Signature Verification: The server needs the alg field from the Header to know how to verify the signature.
    • For Decoding the Payload: The Header might include declarations (such as cty for custom content types) necessary for correctly parsing the Payload.
  • Stateless Design: If the Header did not include algorithm information, the server would have to store metadata for every token, defeating the stateless nature of JWT.

3. Is Verifying Tampering Solely the Server’s Job?

  • Correct: Yes, the client cannot verify the legitimacy of a JWT. It is the server’s responsibility.
  • Client’s Role:
    • Simply store and transmit the JWT (e.g., via a Cookie).
    • Even if the client decodes the Header and Payload, it cannot ensure the signature’s validity.

4. Why Must the Header Information be Transmitted?

(1) Technical Necessity

  • Signature Verification Depends on the Header: The signature is generated based on the entire Header and Payload, so the server must have access to the original Header and Payload to recompute the signature.

(2) Addressing Security Concerns and Misconceptions

  • Misconception: “Transmitting the algorithm information in the Header poses a security risk.”
    • Fact: An attacker cannot bypass verification by tampering with the alg field as long as the server strictly checks that the signature matches the expected algorithm.
    • Security Practice: The server should configure a whitelist of allowed algorithms (e.g., only RS256), ignoring any unauthorized algorithm declarations from the client.

5. Is It to Support Multiple Verification Methods?

  • Partially Correct: The alg field in the Header allows the server to support multiple algorithms, but this is not the main purpose.
  • Core Purposes:
    1. Stateless Verification: The server does not need prior knowledge of the token’s signing method.
    2. Algorithm Declaration: Ensures consistency in the signature generation and verification process.
    3. Prevention of Algorithm Confusion: Clearly defines the signature mechanism to prevent ambiguity.

6. Practical Scenarios

(1) Multi-Tenant Systems

  • Different tenants may use different signature algorithms (e.g., Tenant A uses HS256, Tenant B uses RS256).
  • The server dynamically selects the appropriate verification method based on the alg field in the Header.

(2) Algorithm Upgrades

  • A legacy system might use HS256 while a new system upgrades to RS256.
  • The server can handle both old and new tokens via the alg field in the Header, gradually phasing out the old algorithm.

Summary

  • The alg and typ in the Header are essential: The server requires this information to correctly verify the signature and parse the token.
  • Security Responsibility Lies with the Server: It must strictly validate the algorithm, signature, and claims rather than relying solely on the client-provided information.
  • Transmitting the Header Poses No Extra Risk: As long as the server implements proper verification, an attacker cannot bypass security by tampering with the Header.

Q7. Can the JWT Header be Removed?

Q:

If the server only supports JWT with a single encryption algorithm, can we omit the header (disregarding the JWT specification)?

A:

Step-by-Step Analysis and Recommendation

1. Technical Feasibility Analysis

If the server only supports one fixed algorithm (e.g., HS256) and does not adhere to the JWT specification, it is theoretically possible to remove the Header field. However, you would need to redesign the token structure. Below is a comparison of two approaches:

Approach Standard JWT (with Header) Custom Token without Header
Structure Header.Payload.Signature Payload.Signature
Signature Generation Method HMAC(Header_b64.Payload_b64) HMAC(Payload_b64)
Server Verification Reads algorithm from the Header for dynamic verification Fixed algorithm (e.g., HS256) for direct verification
Compatibility Compatible with JWT ecosystem tools (libraries, debuggers) Requires a fully custom implementation

2. Potential Risks and Limitations

Risk/ Limitation Description
Inconsistent Signing Scope Without the Header, if additional metadata (e.g., token version) needs to be extended in the future, the signing logic must be redesigned, which may lead to compatibility issues.
Difficulty in Algorithm Upgrades Hardcoding the algorithm means that if you need to switch algorithms (e.g., migrating to RS256), all clients must be forced to upgrade, preventing a smooth transition.
Ecosystem Incompatibility Standard JWT libraries (e.g., jsonwebtoken) cannot be used, so you must implement encoding, decoding, and signature verification yourself, increasing development effort.
Complexity in Security Auditing A custom solution requires an independent security assessment, whereas the security of standard JWT has been widely verified.

Summary

  • Omitting the Header is Technically Feasible: In a scenario where the server strictly uses a fixed algorithm, it is possible.
  • Trade-offs: This sacrifices standardization, flexibility, and compatibility with existing tools, and you must bear the additional security risks.
  • Recommended Scenario: Only consider this for closed, small-scale systems where you are committed to maintaining a custom implementation over the long term.

Other

Two common solutions to the session-sharing problem when deploying web servers in a cluster:

  • One solution is to persist session data by writing it into a database or other persistent storage. Various services would then request the data from the persistent layer upon receiving a request. The advantage of this approach is a clear architecture, but the downside is increased engineering effort. Moreover, if the persistent layer fails, it becomes a single point of failure.
  • Another solution is for the server not to save session data at all, with all data stored on the client and sent back to the server with every request. JWT is a representative of this approach.

References