JWT iss (Issuer) Claim

The iss (issuer) claim identifies the entity that created and signed the JWT. It is a case-sensitive string, typically a URL pointing to the authorization server. Validating the iss claim is a fundamental security check that ensures a token was issued by a trusted authority rather than forged by an attacker or generated by an untrusted service.

Format and conventions:

{
  "iss": "https://auth.example.com",
  "sub": "user123",
  "aud": "api.example.com",
  "exp": 1700003600
}

The OpenID Connect specification requires iss to be an HTTPS URL. OAuth 2.0 Authorization Server Metadata (RFC 8414) uses the iss value to locate the server's discovery document at {iss}/.well-known/openid-configuration. This allows clients to dynamically discover signing keys, token endpoints, and supported algorithms.

Why issuer validation matters:

Without issuer validation, an attacker could take a valid token from one service and replay it against another. For example, if Service A and Service B both accept JWTs but do not check iss, an attacker with a valid Service A token could access Service B. By checking that iss matches the expected authorization server, each service rejects tokens intended for other systems.

Multi-provider architectures:

Modern applications often accept tokens from multiple issuers: a corporate identity provider for employees, a social login provider for customers, and a machine-to-machine token service for internal services. The server maintains a list of trusted issuers, each with its own set of signing keys. When a token arrives, the server reads iss, looks up the corresponding key set, and validates the signature. If iss is not in the trusted list, the token is rejected immediately.

Implementation best practices:

Always validate iss against an explicit allowlist of trusted issuers. Never accept any token from any issuer. Use exact string comparison, not substring matching, to prevent attacks like https://auth.example.com.evil.com matching a pattern. In JWKS-based setups, map each issuer to its specific JWKS endpoint and cache the keys appropriately.