Access Tokens & JWT (Structure, Signing, and Validation)

#The Anatomy of a Bearer Token#link

We've discussed how scopes limit what a token can do, but how is the token actually constructed? While OAuth allows any token format, JSON Web Tokens (JWT) have become the industry standard because they are self-contained.

JWT Structure: Header, Payload, and Signature

A JWT is composed of three Base64URL-encoded parts separated by dots. Because the payload is only encoded (not encrypted), anyone with the token can read the data inside.

// Part 1: Header
{ "alg": "HS256", "typ": "JWT" }

// Part 2: Payload (Claims)
{ 
  "sub": "1234567890", 
  "name": "John Doe", 
  "iat": 1516239022, 
  "exp": 1516242622, 
  "scope": "read:profile" 
}

// Part 3: Signature
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

The signature is the most important part. It allows the Resource Server to verify that the token was actually issued by the Authorization Server and has not been tampered with.

Symmetric vs. Asymmetric Signing

Token Validation Workflow

When a Resource Server receives a JWT, it must perform these checks in order: 1. Verify the signature, 2. Check the expiration (`exp`), 3. Verify the issuer (`iss`), and 4. Validate the audience (`aud`).

• ▪Verify signature using the public key
• ▪Ensure current time < exp
• ▪Check that the 'iss' matches the trusted Auth Server
• ▪Validate that the token was intended for this specific API (aud)