JWT Authentication Security

# CHAPTER 6

JWT Authentication Security #

1. Introduction #

2. Learning Objectives #

• Understand the three-part structure of a JSON Web Token.

• Explain the difference between Base64 encoding (readable) and Hashing (secure).

• Identify and mitigate critical JWT vulnerabilities (e.g., algorithm switching).

• Understand the necessity of Token Expiration and Refresh Tokens.

• Implement secure JWT generation and validation in PHP.

3. Beginner-Friendly Explanation #

• When you first arrive, you show your ID (Email/Password) at the gate.

• The gate attendant gives you a glowing wristband (The JWT).

• The wristband has information printed on it: "John Doe, VIP, Expires at Midnight."

• As you walk around the festival, you show the wristband to enter different VIP tents. The tent guards don't need to call the front gate to check your ID; they just look at the wristband.

The crucial part: How do the tent guards know you didn't just print the wristband yourself? The wristband contains a cryptographic signature—a special glowing stamp that only the festival organizers (the Server) have the ink for. If a hacker alters the text on the wristband from "General Admission" to "VIP", the glowing stamp breaks, and the guard immediately rejects it.

4. Real-World Attack Scenarios #

• The "None" Algorithm Attack: Early JWT libraries had a flaw. A hacker could take a valid token, change their user ID to 1 (Admin), and change the token's encryption algorithm to "none". The server would see "none", decide it didn't need to verify the signature, and grant the hacker Admin access.

• Secret Key Brute Forcing: If a developer uses a weak secret key (like secret123) to sign the JWT, a hacker can easily guess the key offline, and then forge unlimited valid tokens for any user.

5. JWT Structure (Anatomy of a Token) #

1. 1. Header (aaaaa): Contains metadata, usually the type (JWT) and the hashing algorithm used (e.g., HS256).

1. 2. Payload (bbbbb): The actual data (claims) you are transmitting (e.g., {"user_id": 123, "role": "admin"}).

1. 3. Signature (ccccc): The mathematical hash of the Header + Payload + Your Server's Secret Key.

*CRITICAL WARNING:* The Header and Payload are merely Base64 encoded, NOT encrypted. Anyone who intercepts the token can decode it and read the JSON payload. Never put passwords or credit card numbers in a JWT payload!

6. Vulnerable vs Secure Code Examples #

Vulnerable PHP (Trusting the payload without verifying the signature):

<?php
$token = $_SERVER[&#039;HTTP_AUTHORIZATION'];
$parts = explode(&#039;.', $token);
// DANGER: Decoding the payload and trusting it without verifying the signature!
$payload = json_decode(base64_decode($parts[1])); 

if ($payload->role === &#039;admin') {
    grant_admin_access(); // Hacker just gave themselves admin access.
}
?>

Secure PHP (Using a vetted library like firebase/php-jwt):

<?php
use Firebase\JWT\JWT;
use Firebase\JWT\Key;

$token = str_replace(&#039;Bearer ', '', $_SERVER['HTTP_AUTHORIZATION']);
$secret_key = $_ENV[&#039;JWT_SECRET']; // A strong, 64-character random string

try {
    // This library automatically checks the signature and the expiration date!
    $decoded = JWT::decode($token, new Key($secret_key, &#039;HS256'));
    
    if ($decoded->role === &#039;admin') {
        grant_admin_access();
    }
} catch (Exception $e) {
    http_response_code(401);
    echo json_encode(["error" => "Invalid or expired token."]);
}
?>

7. JSON Examples (The Payload) #

{
  "iss": "https://api.mybank.com", // Issuer
  "sub": "1234567890",             // Subject (User ID)
  "exp": 1716336000,               // Expiration Time (Unix Timestamp)
  "role": "user"                   // Custom claim
}

8. Token Expiration and Refresh Tokens #

• Rule: Access Tokens must have a short lifespan (e.g., 15 minutes to 1 hour).

• Refresh Tokens: When the short-lived Access Token expires, the client sends a long-lived "Refresh Token" to a special /refresh endpoint to get a new Access Token. Unlike JWTs, Refresh Tokens are saved in the database, allowing the server to revoke them instantly if a user's account is compromised.

9. Best Practices #

• Use a Vetted Library: Never write your own JWT verification code. The cryptographic math is complex and highly prone to timing attacks. Use industry-standard libraries like firebase/php-jwt.

• Strong Secrets: Generate your JWT Secret Key using a CSPRNG (like we did in Chapter 5) and store it securely in your .env file.

• Validate the Algorithm: Ensure your verification code explicitly demands a specific algorithm (e.g., HS256). Do not let the token itself dictate the algorithm.

10. Common Mistakes #

• Storing Sensitive Data: Putting personal identifiable information (PII) like home addresses or social security numbers in the JWT payload. Anyone who gets the token can read it.

• Infinite Lifespans: Creating a JWT that does not contain an exp (expiration) claim, or setting the expiration to 10 years in the future.

11. Mini Exercises #

1. 1. Copy a JWT from your own testing or use jwt.io to generate one. Paste it into the debugger at jwt.io and look at the decoded payload.

1. 2. Why is it dangerous to trust the data in the Payload without verifying the Signature?

12. Practice Challenges #

13. MCQs with Answers #

14. Interview Questions #

• Q: What is the "None Algorithm" attack against JWTs, and how do you prevent it?

• Q: Why shouldn't you store sensitive data (like a credit card number) in a standard JWT payload?

• Q: Explain the architecture of using short-lived Access Tokens coupled with long-lived Refresh Tokens. Why not just use one long-lived Access Token?

15. FAQs #

16. Summary #

17. Next Chapter Recommendation #