Tag Archives: OpenID Connect

JWT (JSON Web Tokens)

While working on one of the security-related aspects of the platform i’m building, i came across JWT specification which i find very interesting and thought will share with you the notes i made while reading:


  1. JWT acronym stands for “JSON Web Tokens”.
  2. Definition of a security token:
    • encrypted data structure (in this case of JSON format) which contains:
      • information about the issuer and subject (claims)
      • proof of authenticity (digital signature)
      • expiration (validity) time
  1. Suggested pronunciation of JWT is the same as the English word “jot”.
  2. Basic facts:
  1. Why JSON-based standard?
    • XML-based SAML data format, exchanged over SOAP protocol offered a ton of encryption and signature options but was percieved as a “heavy” technology and of not much use by mobile appliance (initially not that strong in terms of computing power). JSON messages on the other hand don’t require a fairly advanced technology stack (like SAX, StAX, etc.) to produce and parse data structures and can be exchanged over HTTP (also, each browser nowadays is supporting JavaScript).
  1. Characteristics:
    • Plaintext JWTs: support use cases where the JWT content is secured by means other than a signature and/or encryption contained within the JWT. A plaintext JWT has the header “alg” parameter value set to “none”.
    • Encrypted JWTs: use JSON Web Signature (JWS) and JSON Web Encryption (JWE) to sign and/or encrypt the contents of the JWT using JSON Web Algorithms (JWA)
    • symmetric (HMACSHA256-384) and asymmetric (ECDSA, RSA) signatures
    • symmetric and asymmetric encryption (RSA, AES/CGM)
  1. Structure:
    • JWT Header
      • metadata
      • algorithms & keys used
    • JWT Claims
      • Reserved Claim Names:
        • “iss” (Issuer)
        • “sub” (Subject)
        • “aud” (Audience)
        • “exp” (Expiration)
        • “nbf” (Not Before)
        • “iat” (Issued At)
        • “jti” (JWT ID)
        • “typ” (Type)
      • Public Claim Names
      • Private Claim Names
  1. Example:
// header object

// claims object

    // additional public claims
    "scope":["read", "search"],
    "client":"system A"

In the example above, the JWT Header implies that the encoded object is a Plaintext JWT. Additional public claims, may be useful for example in oAuth protocol (to know which system (A in this case) requested the token and what operations (read, search) will it be authorized to perform using this token).

  1. Sample encoding:
    • Base64url encoded representation of the JWT Header:
      • eyJhbGciOiJub25lIn0
    • Base64url encoded representation of the JWT Claims Set:
      • eyJleHAiOjEzNzM2NDI3NzYsInN1YiI6Ik1hcml1c3oiLCJuYmYiOjEzNzM2NDIxNzYsI


Complete JWT is a result of concatenating encoded representations of the header and the claims set with a period (‘.’) character between the parts:

  • eyJhbGciOiJub25lIn0.eyJleHAiOjEzNzM2NDI3NzYsInN1YiI6Ik1hcml1c3oiLCJuYm


Finally, the above string representation of a JWT security token is what gets transmitted over the wire as a message header or url query parameter.