What Is a JWT and How to Inspect Its Security Claims

JSON Web Tokens (JWTs) are everywhere — API authentication, single sign-on, session management. But most developers never look inside them. That is a mistake. A misconfigured JWT can give an attacker full access to any account, bypass signature verification entirely, or escalate privileges with a single header change.

This guide explains what a JWT is, how to decode it, and what security claims to inspect. You will learn to spot the misconfigurations that matter — using the JWT Decoder from SecuriTool, all client-side.

What Is a JWT?

A JWT is a compact, URL-safe token format defined in RFC 7519. It carries claims (statements) about an entity — typically a user — and is signed so the recipient can verify it was issued by a trusted source.

A JWT looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Three Base64-encoded parts separated by dots:

Part	Contains	Example Content
Header	Algorithm and token type	{"alg":"HS256","typ":"JWT"}
Payload	Claims (user data, permissions, timestamps)	{"sub":"1234567890","admin":true}
Signature	Cryptographic verification	HMAC-SHA256(header + payload, secret)

Why Inspect JWT Security Claims?

JWTs are only as secure as their configuration. The most common vulnerabilities come from the header and payload claims — not from broken cryptography. Security researchers look for:

Claim	Risk if Misconfigured	Impact
alg	none bypasses signature verification entirely	Full authentication bypass
kid	Path injection or SQL injection via key ID	Code execution, data leak
jwk / jku	Attacker supplies their own signing key	Token forgery
exp	Missing expiration = token valid forever	Permanent session hijack
iss / aud	Missing validation = cross-tenant token reuse	Account takeover across tenants
role / admin	Server trusts client-provided privilege claims	Privilege escalation

Step-by-Step: Decode a JWT

1. Copy any JWT from an Authorization: Bearer header, cookie, or URL parameter.
2. Paste it into the JWT Decoder at securitool.js.org.
3. Read the decoded header and payload instantly.
4. Check the critical claims listed above.

Everything happens client-side. No token data leaves your browser.

Header Claims: What to Check

The alg claim

The algorithm claim tells the server how to verify the token. This is the most attacked JWT field.

{
  "alg": "HS256",
  "typ": "JWT"
}

Red flags:

• alg: "none" — Signature verification completely disabled. The server accepts any token without checking the signature. This is the most critical JWT vulnerability.
• alg: "HS256" with a public key in jwk — Algorithm confusion. The server expects RSA but the attacker signs with HMAC using the public key as the secret.
• alg switches between RSA and HMAC across different endpoints — inconsistent verification.

The kid claim

Key ID tells the server which key to use for verification. It is often used as a file path or database lookup.

{
  "alg": "RS256",
  "kid": "key-2024"
}

Red flags:

• Path traversal: "kid": "../../dev/null" — trick the server into using /dev/null (empty key) for verification.
• SQL injection: "kid": "key' OR '1'='1" — manipulate the key lookup query.
• Command injection: "kid": "|ls -la" — if the server passes kid to a shell command.

The jwk and jku claims

These claims tell the server where to find the signing key. An attacker can point them to their own key server.

{
  "alg": "RS256",
  "jku": "https://attacker.com/keys.json"
}

Attack: The server fetches the attacker's public key and uses it to verify the attacker's token — which was signed with the attacker's private key.

Payload Claims: What to Check

Missing expiration (exp)

{
  "sub": "user123",
  "iat": 1516239022
}

If there is no exp claim, the token never expires. An attacker who steals it has permanent access.

Missing issuer/audience validation

{
  "sub": "user123",
  "name": "John Doe"
}

Without iss (issuer) and aud (audience), a token issued by Service A can be used to access Service B. This is critical in microservice architectures.

Privilege claims

{
  "sub": "user123",
  "admin": true,
  "role": "superadmin"
}

If the server trusts these client-provided claims without checking its own database, an attacker can modify the payload and escalate privileges.

Real-World Example

Decode this token:

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.

Header: {"alg":"none","typ":"JWT"} — the none algorithm means no signature verification.

Payload: {"sub":"1234567890","name":"John Doe","admin":true} — admin flag set to true.

Signature: Empty string after the second dot.

Verdict: This token bypasses all authentication. Any server that does not explicitly reject alg: none will accept it as valid.

What the Tool Cannot Do

• Cannot verify signatures — the decoder shows the decoded content but does not validate whether the signature is correct. You need the server's public key or secret for that.
• Cannot detect server-side misconfigurations — if the server accepts alg: none, you can only find out by testing against the actual API.
• Cannot decrypt encrypted JWTs (JWE) — JWE tokens are encrypted, not just signed. The decoder will show the encrypted envelope.

Conclusion

JWT security is not about broken cryptography — it is about misconfigured claims. A single missing exp or a permissive alg: none can compromise an entire authentication system.

By decoding every JWT you encounter and checking the critical claims, you can spot vulnerabilities that most developers miss.

Try it with your own tokens:

---

Published May 31, 2026 · Practical Guide · SecuriTool