JWT Claims Risk Checker

JWT Claim Risk Brief

{{ riskLabel }} Fail {{ statusCounts.Fail }} Warn {{ statusCounts.Warn }} Pass {{ statusCounts.Pass }} Claims {{ claimInventoryRows.length }}

Token label:

Use a short label that matches the API, client, or incident you are reviewing.

Token use profile:

Choose the closest relying-party context before reviewing expiry, audience, issuer, subject, and replay claims.

Allowed algorithms:

Use the algorithms your verifier is configured to accept, for example RS256, ES256, or EdDSA.

Expected issuer:

Leave blank only when you are doing a first-pass decode without relying-party context.

Expected audience:

Enter the API resource, client ID, or audience URI that should receive this token.

Maximum lifetime:

Short access tokens reduce replay exposure; adjust this to your production policy.

minutes

JWT or payload JSON:

Decoding happens locally in the browser. Signature verification still belongs in the relying-party verifier.

JWT parsing notes

{{ warning }}

Clock skew allowance:

Default 60 seconds catches meaningful time-claim drift without hiding clock noise.

seconds

Reference time override:

Use this for deterministic ticket evidence or replaying a past incident timestamp.

Require replay ID:

Flag missing jti

Use this when your issuer and resource server maintain revocation, replay, or incident correlation by token ID.

Sensitive claim terms:

These terms extend the built-in secret, credential, and personal-data checks.

{{ header }}	Copy
{{ cell }} {{ cell }}
{{ emptyTableMessage(tab.key) }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A JSON Web Token can decode cleanly and still be unsafe for the service that receives it. The payload is usually readable Base64URL-encoded JSON, not a sealed envelope, so a token review has to look beyond parsing. The issuer, audience, lifetime, algorithm, replay controls, authorization hints, and exposed claim values all have to match the relying party's policy for the exact flow being checked.

JWT claims are statements about a subject. Registered names such as iss, sub, aud, exp, nbf, iat, and jti give token systems a shared vocabulary, but the names do not create trust by themselves. Trust starts only when the receiving application verifies the signature or approved protection mode, binds the token to the expected issuer and audience, and applies authorization rules that match the token's purpose.

iss: The issuer that created the token. A relying party should bind accepted keys and policy to this value.
aud: The intended recipient. A token for one API or client should not be accepted by another.
exp and iat: NumericDate timestamps that define when a token stops being accepted and when its age begins.
scope or roles: Authorization hints. Broad values such as admin, wildcard, delete, manage, or owner need extra scrutiny.

The same claim can have different weight in different flows. An OpenID Connect ID token may need a nonce because it binds the authentication response to a client request. An API access token usually needs a narrow aud value because it decides which resource server should accept a bearer token. A client assertion should usually have a very short lifetime and a replay identifier. A browser session token may last longer, but that only works safely with revocation, rotation, and server-side checks.

Bearer tokens also have a replay problem. Anyone who obtains a still-valid bearer token may be able to present it until it expires, is revoked, or is rejected by a replay or sender-constraining control. Short lifetimes reduce the window, but they do not solve audience confusion, overly broad scopes, weak key selection, or readable sensitive data in the payload.

A wrong aud value can let a token intended for one service work at another service.
A missing or unexpected iss value weakens the link between the token, the signing keys, and the environment that should trust it.
A broad scope, role, or permission claim can turn a stolen bearer token into an authorization shortcut.
Header values such as alg=none, remote key URLs, or suspicious kid strings point to verifier-hardening work.
Readable secrets, tokens, emails, phone numbers, or account attributes can leak through logs, browser storage, referrers, screenshots, and support tickets.

Claim risk review is a triage discipline. It can identify values that deserve rejection, redaction, or a policy change, but it cannot prove that a relying party verifies signatures correctly or enforces authorization after token acceptance. Trust still rests on cryptographic verification, issuer key control, audience checks, revocation strategy, replay protection, and the application code that turns claims into permissions.

How to Use This Tool:

Start by describing the token context, then paste one token or one decoded claims object. The review compares the decoded header and claims with the profile and policy values you provide.

Enter a Token label that matches the API, client, environment, incident ticket, or flow under review.
Choose Token use profile. The profile changes expected claims and default lifetime for API access tokens, OpenID Connect ID tokens, refresh-like JWTs, client assertions, and browser session JWTs.
Set Allowed algorithms to the algorithms your verifier should accept, such as RS256, ES256, or EdDSA.
Enter the Expected issuer and Expected audience. Leave them blank only for a first-pass decode, because blank values prevent exact local matching.
Adjust Maximum lifetime to your policy. The default API access-token profile uses 15 minutes, while the client-assertion profile uses 5 minutes.
Paste a compact JWT, an Authorization: Bearer line, decoded payload JSON, or a JSON object with header and payload. If several lines are pasted, only the first non-empty token line is assessed.
Open Advanced for deterministic evidence. Clock skew allowance adjusts time-claim leeway, Reference time override replays a past timestamp, Require replay ID flags missing jti, and Sensitive claim terms extends the exposure check.

Use the Claim Risk Scorecard first, then the JWT Remediation Queue for fixes, the Claim Inventory Ledger for decoded values, the JWT Risk Profile chart for category concentration, and the JSON output for a structured record.

Interpreting Results:

The numeric score is a local risk score, not an accept or reject decision. Critical claim risk appears when a critical control fails or the score falls below 55. High claim risk appears when any control fails or the score falls below 75. Review claim risk appears when any warning exists or the score falls below 92. Low claim risk means the decoded token matched the configured local checks with no Fail or Warn rows and a score of at least 92.

A clean-looking scorecard can still be unsafe if the relying party uses a different algorithm allow-list, accepts a different issuer, ignores audience, fails to verify the signature, or grants authorization from another source. Treat each Fail row as a direct fix or rejection candidate. Treat each Warn row as a policy question that needs confirmation before the token is trusted.

JWT claims risk result interpretation
Output	What it gives you	What to verify elsewhere
`Claim Risk Scorecard`	Control status, severity, observed value, evidence, and recommended action.	The actual verifier behavior for the same token class.
`JWT Remediation Queue`	Fail and Warn rows sorted into work items.	Whether the issuer, client, and resource server can apply the change safely.
`Claim Inventory Ledger`	Decoded header and payload values with types and time interpretations.	Whether readable claims comply with privacy, data-minimization, and logging policy.
`JWT Risk Profile`	Risk points grouped by review category.	The exact scorecard row before changing a token policy.
`JSON`	A structured copy of the review, decoded values, scorecard, remediation rows, and category risk.	Whether the token itself should be redacted before sharing the report.

A single critical problem can outweigh many passing controls. Examples include alg=none, a missing signature segment for a signed algorithm, an expired token, an issuer mismatch, an audience mismatch, or a secret-like claim in the readable payload.

Technical Details:

A compact signed JWT normally has three period-separated parts: a JOSE header, a claims payload, and a signature segment. The header describes how the token was protected, including values such as alg, kid, and crit. The payload carries the claims that applications read after the token has been validated.

JWT time claims use NumericDate seconds from 1970-01-01T00:00:00Z UTC. exp sets the instant on or after which the token must not be accepted. nbf sets the earliest acceptable instant. iat records issue time and lets a verifier calculate token age. Small clock skew can be allowed, but a broad lifetime still increases replay exposure.

Rule Core:

The review is rule based. It decodes the submitted source, checks the visible header and payload fields, then assigns Pass, Warn, Fail, or Info rows by comparing the token to the selected profile and local policy values.

JWT claim and header rules used by the checker
Review area	Main checks	Risk signal
Structure	Compact JWT parts, decoded payload JSON, header/payload JSON, and compact JWE detection.	Invalid input fails. A five-part compact JWE is marked encrypted because claims cannot be inspected without decryption.
Header	`alg` allow-list, `alg=none`, `jku`, `x5u`, suspicious `kid`, missing `kid` for asymmetric rotation, and `crit`.	Unsecured or unexpected algorithms fail. Dynamic key URLs and critical extension headers warn.
Signature boundary	Signature-segment presence and unsigned-token conditions.	A present segment is informational here. Missing signatures and `alg=none` can fail because cryptographic verification is outside this review.
Time claims	`exp`, `nbf`, `iat`, clock skew, reference time override, and `exp - iat` lifetime.	Missing, non-numeric, expired, future, or overly long time windows produce Fail or Warn rows depending on the claim and boundary.
Issuer and audience	Exact issuer matching, accepted audience list, subject presence, and profile-required claims.	Missing or mismatched `iss` and `aud` values are high-signal because they decide who should trust the token.
Subject and replay	`sub`, `jti`, and `nonce` expectations for the selected profile.	Missing replay identifiers warn for profiles that need them. Missing nonce warns for the ID-token profile.
Authorization claims	`scope`, `scp`, `roles`, `permissions`, and `authorities`.	Wildcard, admin, root, superuser, all, write, delete, manage, owner, and similar grants warn as broad authorization.
Payload exposure	Configured sensitive terms, secret-like values, personal-data claim names, claim count, byte size, and nested objects.	Secret-like claims fail. Personal-data names, bulky payloads, and deeply nested claims warn because signed JWT payloads remain readable.

Formula Core:

Risk points are assigned from each scorecard row. A Fail row subtracts the full severity weight. A Warn row subtracts 60 percent of the severity weight, rounded to the nearest whole point. Pass and Info rows subtract zero.

score = clamp (100 - \sum_{checks} points, 0, 100)

JWT risk score weights and labels
Severity	Fail points	Warn points	Label effect
Critical	28	17	Any Critical Fail makes `Critical claim risk`.
High	18	11	Any Fail makes `High claim risk` unless Critical applies.
Medium	10	6	Any Warn can make `Review claim risk`.
Low	4	2	Scores below 92 remain review-level even without failed controls.

A token with one High Fail and one Medium Warn subtracts 18 plus 6 points, so the score is 76. The Fail row still makes the label High claim risk even though the numeric score is above 75.

Profile Defaults:

Token use profile defaults
Token use profile	Maximum lifetime	Expected checks
API access token	15 min	`iss`, `sub`, `aud`, `exp`, and `iat`; scope-like authorization context is expected.
OpenID Connect ID token	60 min	`iss`, `sub`, `aud`, `exp`, and `iat`; `nonce` is expected for this profile.
Refresh-like JWT	10080 min	`iss`, `sub`, `aud`, `exp`, `iat`, and `jti`; replay tracking is expected.
Client assertion	5 min	`iss`, `sub`, `aud`, `exp`, `iat`, and `jti`; short lifetime and replay resistance matter most.
Browser session JWT	480 min	`iss`, `sub`, `aud`, `exp`, and `iat`; `jti` is optional unless required manually.

Encrypted compact JWE values need decryption in an approved environment before claim inspection. Signed compact JWT values need signature and key validation in the relying party before any decoded claim is trusted.

Security and Privacy Notes:

The claim review runs locally in the browser for the pasted value, and it does not perform server-side signature validation. That privacy boundary reduces unnecessary handling, but it does not make live bearer tokens safe to paste into shared machines, screenshots, chat logs, issue trackers, or exported reports.

Do not rely on decoded claims until the receiving application verifies the signature, accepted algorithm, issuer key ownership, issuer, audience, and token type.
Use short-lived test tokens or redacted samples when documenting an issue. A copied bearer token may be enough to call an API until it expires or is revoked.
Keep passwords, API keys, refresh tokens, private keys, personal identifiers, and bulky profile data out of readable JWT payloads.
Use encrypted JWTs or opaque reference tokens when claim confidentiality matters more than client-side readability.

Worked Examples:

An access token for orders-api with aud set to billing-api should fail audience matching even if the token is current and signed. The token may be valid for another recipient, but this relying party should reject it because the audience does not include the current API.

An ID token with normal issuer, subject, audience, issued-at, and expiration claims can still warn when nonce is missing for an OIDC browser flow that requested one. The warning does not prove an attack, but it points to a binding check that should be confirmed against the original authorization request.

A payload containing email, phone, or address may only warn, while a payload containing names such as password, api_key, access_token, or refresh_token can fail the sensitive-claim exposure check. In both cases, remember that signing protects integrity, not payload secrecy.

FAQ:

Does a low-risk score mean the JWT is valid?

No. A low-risk score means the decoded claims matched the configured local checks. The relying party still needs to verify the signature, accepted algorithm, issuer keys, audience, revocation state, replay controls, and authorization behavior.

Why does the checker warn when issuer or audience is blank?

Issuer and audience are context checks. Without the expected values, the review can decode what the token says, but it cannot prove that the token belongs to the current API, client, or environment.

Can it inspect encrypted JWTs?

A compact JWE can be detected, but its claims cannot be inspected here because the payload is encrypted. Decrypt it in an approved environment, then review the resulting claims.

Why can a signed token expose sensitive data?

A signed JWT usually protects integrity, not confidentiality. The payload can be decoded by anyone who has the token unless the token is encrypted or replaced by an opaque reference.

Glossary:

JWT: JSON Web Token, a compact token format that carries claims in a JSON object protected by signing, encryption, or both.
Claim: A name/value statement in the token payload, such as issuer, subject, audience, expiry, or scope.
JWS: A signed JSON Web Signature structure. Claims are readable unless separately encrypted.
JWE: An encrypted JSON Web Encryption structure. Claims need decryption before inspection.
Relying party: The API, client, service, or application that receives the token and decides whether to trust it.
NumericDate: A JWT timestamp represented as seconds from 1970-01-01T00:00:00Z UTC.