Should OAuth2 Access Token support multiple audiences?

Question

I am considering a usecase where an OAuth2 client obtains an access token to access multiple resource servers.

Based on spec, to protect against token redirect attack:

to deal with token redirect, it is important for the authorization
server to include the identity of the intended recipients (the
audience), typically a single resource server (or a list of resource
servers), in the token.

This means that in our usecase, the access token can have a list of audience URIs and then each resource server would then verify the token has access to its resource.

However, according to the draft spec of the Resource Indicators for OAuth2, the authors state:

I continue to question the value of allowing multiple resources vs the functional and security complexity that comes with doing so. Writing the preceding paragraph just underscores that concern. So just noting it here.

I have also noticed that identity management providers such as Auth0, only support single audience field values and instead point to using a combination of scope and audience for multiple resource servers.

Other providers support multiple audiences.

So... is there a security problem with having multiple audience values?

It seems to me scope and audience have different intentions and so mixing them up is not necessarily the right approach. According to:

Scope, from Section 3.3 of OAuth 2.0 [RFC6749], sometimes is overloaded to convey the location or identity of the resource server, however, doing so isn't always feasible or desirable. Scope is typically about what access is being requested rather than where that access will be redeemed (e.g. email, user:follow, user_photos, and channels:read are a small sample of scope values in use).

Any thoughts on this would be appreciated. Thank you!

Note:

Token redirect: An attacker uses a token generated for consumption by one resource server to gain access to a different resource server that mistakenly believes the token to be for it.

Answer 1

Under some authorization models, when you first receive an access token, only you (and the authorization service) know a secret that provides access to the token's audience.

When you present the token to a service in order to authorize yourself, that service also knows a secret that provides access to the token's audience.

If the audience is within a single trust boundary, even if composed of different services, then this does not increase the privileges of the receiving service.

However, if the token can be used by the receiving service to access another service to which it would not otherwise have access, then there is the possibility that it is a bad actor who will abuse this increased privilege.

Hence, an access token should typically have an audience that is within a single trust boundary.

I read the Auth0 link as suggesting that multiple API's within a single trust boundary can rely on a single access token, but use scope to control which API's the user can access, which is consistent with your other quotes.