• Open standard (RFC 7519) used to securely transmit information between parties as JSON object
• Primarily used for stateless authentication and authorization
  • Allows a server to verify a user’s identity without storing session state in a database
• Structure
  • Single string made of three parts separated by dots
    • Header
      • Contains metadata about the token
        • Type of Token (JWT)
        • Cryptographic algorithm used to sign it (e.g HS256)
    • Payload
      • Contains the claim (the actual data being transmitted)
        • User ID
        • Permissions
        • Token’s expiration timestamp
    • Signature
      • Created by encrypting the encoded header, encoded payload, and a secret key
      • Ensures that the token has not been tampered with in transit
  • The header and payload are simply Base64-URL encoded, not encrypted, meaning anyone can decode and read them
    • Never store sensitive data (like passwords) inside a JWT payload
• How authentication works
  • Login
    • User sends their credentials (username and password) to the server
  • Issuance
    • Server validates the credentials, creates a JWT containing the user’s info, and signs it with a secret key
  • Storage
    • Client receives the token and stores it (usually in HttpOnly cookies or secure browser storage)
  • Verification
    • For subsequent API requests, the client includes the token in the HTTP Authorization header
    • Server decodes the token, checks the signature, and if valid grants access to the requested resource
• Advantages and limitations
  • Pros
    • Statless
    • Highly scalable
    • Speeds up requests since the server doesn’t need to query a database to check session data
  • Cons
    • Because server doesn’t maintain sessions, it is difficult to instantly invalidate or revoke a JWT before its designated expiration time