Question 1

Registered Claims

Accepted Answer

are a set of predefined, standardized fields established by the IETF in RFC 7519. They are not mandatory, but they provide a universal language for token validation. The most critical registered claims include iss (Issuer, identifying the server that created the token), exp (Expiration Time, a crucial numeric timestamp defining exactly when the token becomes invalid), sub (Subject, typically the unique user ID), aud (Audience, identifying the intended recipient of the token), nbf (Not Before, a timestamp indicating when the token becomes active), and iat (Issued At, the timestamp of creation). All timestamps in JWTs are represented as NumericDate values, which are the number of seconds since the Unix Epoch (January 1, 1970, 00:00:00 UTC).

Question 2

Public Claims

Accepted Answer

are custom fields created by developers that are meant to be shared across different organizations. To prevent naming collisions (where two different companies use the same key for different purposes), public claims should be registered in the IANA JSON Web Token Claims Registry or formatted as collision-resistant URIs (e.g., https://example.com/claims/role). Private Claims are custom fields used exclusively within a closed system or single organization, such as {"employee_id": "8675309", "department": "engineering"}.

Question 3

Symmetric Algorithms (HS256, HS384, HS512)

Accepted Answer

utilize a single, shared secret key for both creating the signature and verifying it. HS256 (HMAC using SHA-256) is the most common symmetric algorithm. In this model, the server generating the JWT and the server verifying the JWT must both possess the exact same secret string. This method is incredibly fast and computationally inexpensive. However, it suffers from a major architectural limitation: key distribution. If you have an authentication server issuing tokens, and 50 different microservices verifying those tokens, you must securely distribute the master secret to all 50 microservices. If any single microservice is compromised, the attacker obtains the secret key and can forge perfectly valid JWTs for any user, completely destroying the integrity of your system. Therefore, symmetric algorithms are strictly reserved for closed, monolithic applications where the same server issues and verifies the token.

Question 4

Asymmetric Algorithms (RS256, ES256, PS256)

Accepted Answer

solve the key distribution problem by utilizing public-key cryptography. RS256 (RSA Signature with SHA-256) is the industry standard for enterprise applications. In this model, the authentication server generates a mathematically linked pair of keys: a Private Key and a Public Key. The server uses the strictly guarded Private Key to sign the JWT. The 50 microservices are given only the Public Key. The mathematical magic of RSA allows the microservices to use the Public Key to verify that the signature was definitively created by the Private Key, but it is mathematically impossible to use the Public Key to forge a new signature. If a microservice is compromised, the attacker only gets the Public Key, which is useless for forging tokens. ES256 (ECDSA using P-256 and SHA-256) is a modern variation of asymmetric cryptography that uses Elliptic Curve mathematics. ES256 provides the exact same security level as RS256 but generates significantly smaller signature strings, making it highly desirable for bandwidth-constrained environments like mobile applications or IoT devices.

Question 5

JWT vs. SAML (Security Assertion Markup Language)

Accepted Answer

is a comparison of eras. SAML is an older, XML-based standard heavily used in enterprise Single Sign-On (SSO) environments (like corporate Active Directory integrations). SAML assertions function similarly to JWTs—they are signed packages of user data. However, SAML XML payloads are massive, complex, and computationally heavy to parse. A SAML assertion might be 10 kilobytes of dense XML, whereas the equivalent JWT is 600 bytes of JSON. JWTs have largely replaced SAML in modern web and mobile development due to JSON's native compatibility with JavaScript and the lightweight nature of the tokens, though SAML remains entrenched in legacy enterprise systems.

Question 6

Can I decode a JWT without knowing the secret key?

Accepted Answer

Yes, absolutely. The secret key is only required to verify the signature (the third part of the token). The header and payload (the first two parts) are merely encoded using Base64Url, not encrypted. Anyone who possesses the token string can instantly decode it and read all the JSON data inside. This is why you must never store passwords, social security numbers, or sensitive personal data inside a standard JWT payload.

Question 7

If anyone can decode the token, what prevents a user from changing their user ID or role?

Accepted Answer

While anyone can decode and modify the payload, they cannot generate a valid signature for their modified payload without the server's secret key. When the server receives the token, it takes the header and payload, runs them through the hashing algorithm using its closely guarded secret key, and compares the result to the signature attached to the token. If an attacker changed "role":"user" to "role":"admin", the server's mathematical hash will not match the attacker's token signature, and the token will be immediately rejected as tampered.

Question 8

What is the difference between an Access Token and an ID Token?

Accepted Answer

An Access Token is used to authorize a user to access an API or resource; it is meant to be read by the API server, and its payload format is often specific to that API. An ID Token, defined by the OpenID Connect (OIDC) standard, is strictly meant to be read by the client application (like a web browser or mobile app). The ID Token contains standard claims about the user's identity (like name, email, and profile picture) so the frontend application can display "Welcome, John!" without needing to make an additional API call.

Question 9

Why does my JWT decoding library throw an error about "Clock Skew"?

Accepted Answer

Clock skew occurs when the server that generated the token and the server verifying the token have slightly different system times. If Server A creates a token at 12:00:05 and sends it to Server B, but Server B's clock thinks it is currently 12:00:00, Server B will look at the iat (Issued At) claim and think the token was generated 5 seconds in the future. Most robust decoding libraries will reject "future" tokens. You fix this by configuring a "leeway" tolerance of 30-60 seconds in your verification library.

Question 10

How do I invalidate or log out a JWT before it expires?

Accepted Answer

Because JWTs are stateless, you cannot "delete" them from a central database. The most common solution is to maintain a denylist (blacklist) of revoked token IDs (jti claim) in a fast, in-memory store like Redis. When a user logs out, their token's jti is added to Redis until its natural expiration time passes. Every API request must quickly check Redis to ensure the token hasn't been revoked. Alternatively, you can keep token expiration times extremely short (e.g., 5 minutes) so that revoked access naturally expires very quickly.

Question 11

Is it safe to store a JWT in LocalStorage?

Accepted Answer

No, storing JWTs in the browser's localStorage or sessionStorage is strongly discouraged by security professionals. Any JavaScript executing on your website has full access to localStorage. If your site has a Cross-Site Scripting (XSS) vulnerability, a malicious script can instantly copy the JWT and send it to an attacker, granting them full access to the user's account. The recommended best practice is to store the JWT in an HttpOnly, Secure cookie, which is completely inaccessible to client-side JavaScript.

JWT Debugger & Decoder

Command Palette