Developer tools · JWT decoder
Audience and Issuer Checks: Stopping a JWT From Being Replayed Elsewhere
· Why it matters
jwt authentication security
A token issued for one service can be presented to another that shares the same issuer. This post explains how aud and iss checks stop that, and how to read both claims in a token.
Service B accepts a token meant for service A — the cross-service replay that a valid signature does not prevent
A signature can be valid for a token that was issued to a different service. If several APIs trust the same identity platform but ignore recipient context, a credential intended for service A may be replayed at service B. Cryptographic integrity alone does not answer who should consume it.
ToolAcre can reveal `iss` and `aud` so a developer can spot an obvious mismatch. Those strings remain unverified until the signature succeeds, and the browser tool never performs that check. The actual resource server must enforce both its issuer relationship and intended audience.
iss — binding a token to the issuer your service trusts, and why a string match is not enough without key binding
`iss` identifies the entity the payload claims issued the token. A verifier needs an exact expected issuer under its own configuration and must bind that identity to the correct key-discovery relationship. Comparing text without the cryptographic binding leaves room for an attacker to copy the expected string.
The decoder describes `iss` as “who created the token,” but that is the registered meaning, not a finding about a pasted value. Readable issuer text is useful evidence for debugging configuration. It cannot select an arbitrary key source or authenticate itself.
aud — a string or an array naming the intended recipients, and the rule that a verifier must find itself in it
`aud` names intended recipients and may appear as one string or a collection. The resource server’s policy must find itself in the authenticated value using the exact comparison rules required by its profile. It should not accept a token merely because some other familiar service is listed.
ToolAcre carries arrays as JSON text in its claims table, preserving their visible structure for inspection. It does not know the current API’s identifier and cannot decide a match. That deliberate absence prevents a generic decoder from inventing authorization context it does not possess.
azp and scope — the OpenID Connect and OAuth claims that refine who may use the token and for what
`azp` and `scope` can add context about an authorized party and requested permissions in profiles that define them. They do not replace audience, issuer or signature checks. A scope name is an assertion, not a permission grant until the resource server maps an authenticated value to its own policy.
The current decoder treats these as application-specific claims because its registered-description table covers seven core names. It displays their values but supplies no OpenID Connect or OAuth semantics. Consult the applicable profile and provider contract before using them in a decision.
The confused-deputy pattern — how a legitimate token becomes an attack when audiences are not checked
A confused deputy uses legitimate authority in an unintended context. A token accepted by the wrong service can trigger exactly that pattern even when nobody forged the signature. Audience checks limit where authenticated claims may be applied, while issuer checks limit whose assertions the service considers.
This is why a general “signature valid” flag would still be insufficient. Authorization depends on recipient and operation. ToolAcre avoids that ambiguity entirely by reporting no verification result, leaving the consuming service to combine cryptography with contextual policy.
Worked example — reading iss and aud from two tokens in the ToolAcre JWT decoder and deciding which service should accept each
Create two harmless tokens whose decoded payloads differ only in `aud`: one names `service-a`, the other `service-b`; both claim the same issuer. ToolAcre makes the difference visible. A service-A verifier should accept neither merely from this display and should reject the authenticated service-B audience.
Then reverse the exercise with two issuer strings. The expected text alone is not enough unless verification used keys trusted for that issuer. These examples separate inspection from acceptance and show why copying the right-looking claims into a fabricated token changes no trusted policy.
What this does not cover — signature verification, which the decoder never performs; aud and iss checks only matter after the signature holds
Audience and issuer checks matter only after cryptographic verification establishes that the protected bytes correspond to trusted key material. ToolAcre performs none of that verification. Its output cannot establish that a claim survived intact or that a known issuer authored it.
It also does not fetch metadata, choose keys or compare configured recipients. Use backend tests and logs to prove rejection for wrong issuer and wrong audience. A visual match in a decoder is a debugging clue, never sufficient authorization evidence.
Takeaway: check who it is for, not just who signed it — the ToolAcre JWT decoder shows the aud and iss claims you need to compare
Check who the token is for, not merely the name it says signed it. The robust flow authenticates protected bytes under an independently trusted issuer relationship, then requires an acceptable audience and applies service-specific authorization rules.
Use ToolAcre to read safe test values and formulate the next server-side check. Do not choose verification keys from untrusted header or claim data, and do not turn displayed `iss`, `aud`, `azp` or `scope` into a grant without the full trusted flow.