Should resource servers check the token issuer?

[andrewbonney]

Posting this here so I don't forget as I still need to go back and read the RFCs again.

In a network with a single authorization server, the 'iss' in the token will always be the same and everything should be happy. If however you run more than one authorization server which happen to share keys, the value of 'iss' may vary. The spec needs to clearly indicate whether you should or should not check the value of 'iss' at the resource server end, and whether or not this value needs to be coordinated between distributed authorization server instances.

[prince-chrismc]

I recall this being mentioned in one of the documents.

The Issuer Identifier for the authorization server (which is typically obtained during discovery) MUST exactly match the value of the "iss" claim.

from https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/?include_text=1

Reviewing the mentions of iss its certainly not clear in IS-10.

https://tools.ietf.org/html/rfc8725#section-3.8 says to follow the jkws_uri such that you always look at the correct Auth server. Does not limit querying different issuers

[andrewbonney]

Ok. So clearly the resource server needs to check that the 'iss' value matches the location that the public key is sourced from. The spec perhaps needs updating to indicate that:

• The 'iss' MUST be the absolute URI which the OAuth metadata can be found from (as per https://tools.ietf.org/html/rfc8725#section-3.8)

For the case where multiple authorisation servers exist in a cluster, the spec could state that the 'iss' must be the same for them all, which would require them to share a common (aliased) hostname, but that rather breaks the 'priority' mechanism. An alternative would be that when resource servers validate tokens they should check if the 'iss' matches any of the hostnames currently listed via '_nmos-auth._tcp'. The challenge there is that if mDNS is being used (or a complex subdomain based unicast DNS setup) then the issuing auth server may not be visible either.

[prince-chrismc]

From https://tools.ietf.org/html/rfc7523#section-3, we are allowed to have application specific match of the iss.

An alternative would be that when resource servers validate tokens they should check if the 'iss' matches any of the hostnames currently listed via '_nmos-auth._tcp'

This would help cover the scenario when a new Auth Server of higher priority comes on. Two resource servers with different auth servers would be able to validate each others token.

The challenge there is that if mDNS is being used (or a complex subdomain based unicast DNS setup) then the issuing auth
server may not be visible either.

I think mDNS will be hard to fit under "MUST be an absolute URI" unless we specify it's the IP address to match the issuer. I would not expect to connect to the server over its .local

The DNS should match the aud, if the token is being used in a different subdomain it MUST be rejected. I don't think it would need to be visible.

[andrewbonney]

Having gone back over this I think my greatest concern is around large (potentially multi-site) deployments. If you had two sites, you may wish for the control system in site A to be able to adjust a subset of systems in site B. You could have one Auth Server serving both sites, but this wouldn't be very resilient to WAN link failures. In the case that each site had its own Auth Server they could use their own individual private keys, but both servers could be configured to distribute each other's public keys.

If a Resource Server in site A receives a token from the Auth Server in site B, it can verify the token signature using the public keys it already has, but the iss won't match that of its local Auth Server, and it won't be able to see the remote Auth Server in its local DNS-SD advertisements.

If we assume that iss is always a URI and that all Auth Servers use the same api_* TXT records for their discovery, the Resource Server could request the Auth Server metadata from the remote site and compare with the issuer attribute. It could then proceed to obtain the jwks_uri too if desired. I'm just not sure what additional benefit this provides which the act of signing the token doesn't already. It also places requirements on all Resource Servers being able to communicate with all Authorization Servers.

[garethsb]

Couple of questions...

Is it safe to assume we can require Auth Servers to use URL for iss?

Why would Resource Server in site A be able to request the Auth Server metadata from the remote site via its DNS name, but not be able to see its DNS-SD records?

[andrewbonney]

Is it safe to assume we can require Auth Servers to use URL for iss?

No, not unless we require it in the spec.

Why would Resource Server in site A be able to request the Auth Server metadata from the remote site via its DNS name, but not be able to see its DNS-SD records?

Good question. I was envisaging two subdomains which prevent the DNS-SD records leaking, but of course that prevents the A records leaking too. I guess the Auth Servers' A records could be in a third (global) subdomain.

If the scenario seems a bit far fetched then that's fair enough, I'd just like to make sure we've considered how this may impact potential deployments.

[garethsb]

No, not unless we require it in the spec.

I was really asking whether it was reasonable for NMOS spec to limit this, when the actual deployed service may be a general-purpose Auth server. If this is something that is always configurable then OK :-)