JWT & Authorization Testing

Traffic Jam collects every credential observed in imported captures into the API workspace Auth tab, decodes and audits JWTs offline in a dedicated workbench, and replays one request across multiple observed identities for BOLA/IDOR investigation. All of it runs locally against captures you already have; use it only on systems you are authorized to test.

Extract auth material from captures

Open the API workspace and switch to the Auth tab. Traffic Jam scans every visible session and groups credential-bearing signals by name:

Each group card shows total uses, the number of distinct values, and endpoint count. Expand a group to see every value variant with the endpoints it was seen on and Sample buttons that jump to a request carrying it. Values are masked by default; enable the workspace reveal toggle to see exact values and unlock the Copy and Audit actions. Authorization: Bearer eyJ… values are decoded inline, with a payload summary (iss, sub, aud, exp, iat, nbf, jti, scope, client_id; timestamps rendered as ISO dates).

[!NOTE] Extraction is passive: it only reads imported captures. Nothing is sent to a server until you explicitly run a replay.

Audit a JWT

With secrets revealed, click Audit on any decoded JWT variant to open the JWT security workbench. The workbench decodes header and payload, reports the algorithm, and renders expiry status as a badge: valid, expired, not-yet-valid, or no-expiry.

The analysis raises warnings for the conditions that matter in an engagement:

• alg: none — the token is unsigned.
• Any HS* algorithm — HMAC secrets are crackable offline, and if the service also accepts RS256, an alg-confusion attack may apply.
• No alg declared in the header.
• No exp claim — the token never expires by itself.
• Lifetime over 24 hours (exp - iat) — reported as a long-lived token in hours.
• exp not after iat — non-positive lifetime.
• Empty signature segment.
• Sensitive payload claims: password, passwd, secret, ssn, credit_card, creditcard, card_number, private_key.

Offline HMAC dictionary check

In the workbench’s HMAC dictionary check section, paste candidates one per line and click Test candidates. The check works only for HS256, HS384, and HS512 tokens: each candidate is HMAC-signatured over header.payload with WebCrypto inside the renderer, and a candidate that reproduces the captured signature is reported as the recovered secret. Nothing leaves the renderer; progress is reported every 50 candidates. The dialog ships with a small starter list (secret, password, password123, changeme, JWT_SECRET) — replace it with a wordlist appropriate to the target.

Generate alg=none and RS-to-HS test tokens

The workbench builds two classic algorithm-confusion probes. Both are copy-only: the dialog never sends anything, so you decide where a probe lands (for example, pasting it into the replay workbench — see /docs/en/replay/workbench/).

1. alg=none variant — click Copy alg=none variant. The header is rewritten to alg: "none" and the signature segment is emptied (header.payload.). Send it to see whether the verifier accepts an unsigned token.
2. RS256 → HS256 confusion — paste the server’s RSA public key (PEM) into the RS256 → HS256 confusion variant field and click Generate & copy. The token header is rewritten to HS256 and re-signed with HMAC using the public key text as the key material. If the server verifies an HS256 token against its RSA public key, the forged signature validates.

[!WARNING] These probes mutate authentication material and can invalidate sessions or trip fraud controls. Send them only against targets you have written authorization to test.

Credential A/B replay (BOLA/IDOR)

When a group has two or more distinct values (for example, two users’ session cookies captured in different sessions), expand it and click Test variants for BOLA/IDOR. The Credential variant A/B test dialog replays one representative request once per observed credential value and lines the responses up side by side.

1. The dialog picks a representative request from the group’s observed requests, preferring GET/HEAD. The source URL and body are never changed — only the credential is swapped.
2. Click Run A/B test. Each variant is replayed sequentially (up to 20 variants, 30 s timeout per request) through the same batch endpoint that powers bulk replay, which enforces a 50-item server-side cap.
3. Results are labelled A, B, C… with the masked value, live status and duration, and a captured-vs-live comparison verdict. Similar successful bodies across different identities suggest the endpoint does not bind the resource to the caller — a BOLA/IDOR candidate.

For cookie groups, only the target cookie name is replaced; the rest of the captured Cookie header is preserved. If the representative method is state-changing (anything except GET, HEAD, OPTIONS, TRACE), the Confirm state-changing replay checkbox must be ticked before the run is allowed.

[!TIP] Query-parameter groups cannot be A/B tested from this dialog — the override mechanism swaps headers, not URLs. Replay such requests manually from /docs/en/replay/workbench/.

Reconstruct authentication flows

The API workspace Security tab includes a Credential lifecycles section built from Set-Cookie issuance and subsequent request use across all sessions. Each flow links a credential (masked) to the response that issued it and up to 20 requests that replayed it, sorted with the most-reused first. Flows where a credential is sent before it is ever issued in the capture are flagged used before issue — worth a closer look for pre-authentication or fixation-style anomalies. Only credentials that are both issued and used in the capture are listed.

The same reconstruction classifies auth endpoints by path pattern, so login, logout, token refresh, password reset, signup, OAuth authorize/token, MFA, and magic-link requests are enumerated in time order — a map of the target’s authentication surface for planning further authorized tests. Cross-reference credential-bearing requests quickly with global search (/docs/en/analysis/search/).