iss (Issuer) Claim
The iss (issuer) claim is a registered JWT claim identifying the principal that issued the token, typically a URL or string like https://auth.example.com. Verifiers should validate that iss matches an expected issuer to prevent accepting tokens minted by untrusted authorization servers. iss is especially important in multi-tenant and federated setups where several issuers may be plausible. Implementations across Node.js, Python, Go, Ruby, and Java follow the same RFC standards, so concepts transfer directly between stacks. Security reviews should treat this as part of your full authentication threat model, not an isolated configuration detail. Document expected behavior for client teams so tokens are issued, stored, and validated consistently across services.
Why It Matters
Without iss validation, an attacker who obtains a valid token from a staging issuer could use it against production if signing keys overlap or validation is loose. Always pin expected iss values in verifier configuration alongside aud checks. Getting this wrong often surfaces only after an incident, when forged or replayed tokens expose gaps in validation or secret handling. Platform teams should encode these rules in libraries, linting, and deployment checklists so individual services cannot drift silently. Pair technical controls with monitoring: log verification failures, track unusual token lifetimes, and alert on spikes in 401 responses.
Code Example
{
"iss": "https://auth.example.com",
"sub": "user_42",
"exp": 1720454400
}Related Terms
Related Tools
Related Articles
Frequently Asked Questions
Is iss required?
Not strictly required by RFC 7519, but strongly recommended for production APIs and OpenID Connect compatibility. Consult your JWT library documentation for exact option names, defaults, and error types. When in doubt, prefer stricter validation and shorter token lifetimes over permissive shortcuts.
What format should iss use?
A case-sensitive string or URL uniquely identifying your authorization server, stable across rotations. Consult your JWT library documentation for exact option names, defaults, and error types. When in doubt, prefer stricter validation and shorter token lifetimes over permissive shortcuts. Test edge cases with expired, malformed, and wrong-algorithm tokens in CI before shipping auth changes.
Can iss change during key rotation?
The issuer identity should remain stable. Only signing keys and kid values change during rotation. Consult your JWT library documentation for exact option names, defaults, and error types. When in doubt, prefer stricter validation and shorter token lifetimes over permissive shortcuts.