0

What would the proper issuer be for implementing an oidc micro-service that will provide authorization for multiple clients differentiated by different domains?

The spec says:

REQUIRED. Issuer Identifier for the Issuer of the response. The iss value is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.

It does not state whether or not this identifier has to match the request domain or even be a real url at all. Making this a static url that merely identifies this service would make validation in some other micro-services easier.

Does making it a static url break the spec in any way or have any other pitfalls that may not be immediately obvious?

user1652802
  • 1
  • 1
  • 2

1 Answers1

1

OpenID Connect Discovery 1.0 incorporating errata set 1 states:

issuer

REQUIRED. URL using the https scheme with no query or fragment component that the OP asserts as its Issuer Identifier. If Issuer discovery is supported (see Section 2), this value MUST be identical to the issuer value returned by WebFinger. This also MUST be identical to the iss Claim value in ID Tokens issued from this Issuer.

The "OpenID Connect Core 1.0 incorporating errata set 1" specification states:

16.15. Issuer Identifier OpenID Connect supports multiple Issuers per Host and Port combination. The issuer returned by discovery MUST exactly match the value of iss in the ID Token.

OpenID Connect treats the path component of any Issuer URI as being part of the Issuer Identifier. For instance, the subject "1234" with an Issuer Identifier of "https://example.com" is not equivalent to the subject "1234" with an Issuer Identifier of "https://example.com/sales".

It is RECOMMENDED that only a single Issuer per host be used. However, if a host supports multiple tenants, multiple Issuers for that host may be needed.

There is no reason to expect the client (which makes the Authorization Request) and Authorization server to be within the same DNS Domain. Or to expect the client to be in the same NDS Domain as the Resource Server.

The specifications do not define these Relationships so any relationships must be done using other Internet Specifications. The only one I know of is the certificate "trust" relationships.

Be sure to read the OAuth 2.0 Security Best Current Practice

Community
  • 1
  • 1
jwilleke
  • 10,467
  • 1
  • 30
  • 51
  • Thank you for your answer. I have read those documents and my interpretation was that issuer should match the host that the call to authorization / token was made on. I have received some push back from other parts of the company saying that using a single issuer across multiple hosts would make it easier to validate tokens. I believe that this would break spec and is not recommended but I have been having trouble finding a simple sentence in the spec that would make this clear. – user1652802 May 10 '20 at 20:27