Jwt Decoder Calculator

A JSON Web Token is three Base64url-encoded segments joined by periods: header, payload, and signature. The header is a small JSON object naming the signing algorithm in its alg field and normally the token type in typ. The payload is a JSON object of claims. Registered claim names defined by the specification include iss for issuer, sub for subject, aud for audience, exp for expiration time, nbf for not-before, iat for issued-at, and jti for a unique token identifier. The three time claims are NumericDate values, counted in seconds since the Unix epoch of 1 January 1970 UTC, which is why they appear as raw integers such as 1516239022 rather than as dates. Base64url differs from standard Base64 in substituting minus for plus and underscore for slash and in omitting padding, so a token survives placement in a URL or an HTTP header without further escaping. That encoding is not encryption. Anyone holding the token can read every claim inside it, so a JWT must never carry passwords, payment details, or other confidential data unless it is wrapped in JSON Web Encryption. The critical limitation of any decoder, this one included, is that reading a token is not the same as trusting it. Verification means recomputing the signature with the issuer shared secret for HMAC algorithms such as HS256, or with the issuer public key for RS256 and ES256, and separately checking exp, nbf, iss, and aud. Access tokens are typically issued with lifetimes of 5 to 60 minutes, with longer-lived refresh tokens handling renewal.

JWT emerged from the identity federation work of the late 2000s, when SAML assertions built on XML and XML Signature proved heavy for mobile clients and browser-based applications. Work on a compact JSON alternative began around 2010 and moved into the IETF, where the JSON Object Signing and Encryption working group was chartered in 2011 to define the underlying cryptographic formats. The result was a family of specifications published in May 2015: RFC 7515 for JSON Web Signature, RFC 7516 for JSON Web Encryption, RFC 7517 for JSON Web Key, RFC 7518 for JSON Web Algorithms, and RFC 7519 for JSON Web Token itself. Michael B. Jones of Microsoft, John Bradley of Ping Identity, and Nat Sakimura of Nomura Research Institute are the principal authors of RFC 7519. The OpenID Connect 1.0 specification, finalized in February 2014, had already adopted the draft format for its ID tokens, which drove rapid industry uptake ahead of formal publication. Security practice tightened after early implementation failures. In 2015 Tim McLean documented libraries that honored an alg value of none, and others that could be tricked into verifying an RS256 token as HMAC by using the public key as the shared secret. Those disclosures established the now-standard rule that a verifier must specify the algorithm it expects rather than trusting the one declared inside the token.