Issuer Claim

Issuer Claim

JWT RFC7519 defines the Issuer Claim iss, which identifies the principal that issued the JWT. The claim holds the unique identifier for the Authorization Server. When a service receives a JWT, it should verify that the JWT came from the expected Authorization Server. It does so using the iss claim.

IdentityServer inserts the iss claim value using the origin IdentityServer is hosted from by default. You can change this behavior by setting the IssuerUri property in IdentityServer Options.

Multi-Issuer

Duende IdentityServer can respond with different iss claim values depending on the domains it hosts.

Imagine a single IdentityServer instance is hosted over 3 different domains like auth.dailyreader.example, auth.streamwave.example, and auth.podvault.example. If that instance of IdentityServer was developed to allow users to sign-in across all three domains with the same credentials, the result token still only works for the APIs accepting tokens from the target issuer. For example, if the backend API only allows tokens with the issuer auth.dailyreader.example, a user’s token with iss claim auth.streamwave.example will not be accepted. Even though their credentials work across all three domains, the token is limited to the one issuer.

If you configure the IssuerUri property in IdentityServer Options, Multi-Issuer will not be enabled: the returned iss claim will always contain the configured IssuerUri value.

Caution

Multi-Issuer does not mean IdentityServer can self-host itself across different domains to separate data across different tenants. You must set up that infrastructure yourself.