openidmulti-tenantopenid-connectidentityserver4authority

OIDC: Multiple authorities share same issuer, concern?


We have a multitenant identityserver open id connect solution with each tenant/customer currently having their own specific authorize url and metadata information. We use the same keys to sign jwts for all tenants. Example authority url for one tenant: https://auth.ourdomain.com/tenant123. (reason being historical and not very easy to change)

While we do need different authorize url for each tenant we would really prefer as much simplicity as possible when it comes to validating the signed jwts while building internal apis and for third parties. Currently the issuer uri is also tenant specific but we are thinking about changing this so that all tenants share the same issuer uri and thus jwt validation can be performed against a fixed authority uri.

Apart from the dependency that all authorities must share the same signing jwks are there any concerns about multiple authorities sharing same issuer uri when it comes security, specification or simply recommended best practise?


Solution

  • In general I'd not recommend using the same issuer since that increases the risk of tokens being reused across tenants, i.e. a user from one tenant impersonating another user at a different tenant.

    One can decrease that risk by making sure that an "audience" is sent in the token that identifiers the intended recipient/tenant and making sure that recipients actually verify that audience value but you'd depend - even more - on a correct implementation at the recipient, which is hard to ensure.

    Another measure that would decrease the risk is making sure that user identifiers are unique across all tenants but that is also hard to ensure.

    FWIW: the same argument holds for re-using keys: it makes it harder to protect against "cross play".

    Note: in principle key reuse also makes it harder to rollover keys (and avoid a big bang approach across all tenants), but in OIDC's keys you probably use a jwks_uri for that anyway, which automates things based on TLS server certificate validation.