I often receive the question of how OAuth token audience validation should work in environments where multiple OAuth clients are calling multiple resource services. Generally, the audience or
aud claim in OAuth represents the application to which the OAuth token was issued. This can be handy as an additional layer of token validation for certain types of applications (say you have a single, monolithic application architecture with no additional services). However, validating the audience claim quickly starts to increase in complexity when multiple clients and services enter the mix.
As the number of applications in a service ecosystem scale, requiring audience validation forces all applications to track and validate against all audiences, often individual clients, which have been introduced. As new OAuth clients (with their new audiences) are created, this rapidly becomes an unwieldy task. One erroneous approach to correct this issue is to try issuing multiple audiences in tokens.
There’s a better alternative, which is to simply rely on scope validation. Rather than requiring each application accepting OAuth tokens to maintain knowledge of all possible clients, you can validate
scope in a token instead. The
scope array of values within a token represent the resources to which the token has access. This effectively inverts the dependency - rather than resources having to know what will call them, the IdP pre-determines which resources are allowed.
In practice, this proves to be a much better model as new client applications and resource services are added. Additionally, the list of scopes allowed for each client provides a effective form of ‘documentation’ for determining the resources upon which a particular client depends.
One of the common sources of this confusion is Microsoft’s own JWT authorization libraries, both for ASP.NET and ASP.NET Core. Rather than providing scope validation by default, they provide audience validation. A separate piece of middleware is required to implement scope validation (but highly recommended!).
Interestingly, the OAuth 2 Authorization Framework RFC only mentions audience validation as a security mechanism for applications using less secure flows, such as implicit. All other references in the document use the term scope to describe the resource authorization property of an access token.Written on May 9th, 2020 by Joel Braun