In OIDC, it is unclear to me what purpose it serves to have the client specify an audience in its authorization request unless you can restrict what audiences a specific client is allowed to obtain a token for.
Is it possible to restrict what audiences a given registered client can request a token for? And if not, what purpose does it serve for the client to specify an audience in the authorization request if it can request any audience that is registered?
For client credentials grant where the client application performs client authentication as a requirement of the grant you can configure which clients can request which audiences and which scopes through the Dashboard itself by going to each API and configuring the desired grants for each client application.
In end-user based flows there’s a few things to consider that increase the complexity of the overall situation. First, in these flows not all client applications will perform client authentication so the authorization server cannot strictly identify the client; second, in these cases it’s much more likely that the policy decision is made taking the end-user in consideration rather than the actual client application.
The implication of the above is that at this time the method for a developer to specify a policy that may vary significantly depending on use case is through the use of rules. By implementing a rule you can either completely fail the authorization request or reduce the scope of the issued access token in accordance to the actors involved in that transaction (the end-user and even the client application, although have in mind that if there is no client authentication you can’t really be sure of the client application part).
To modify the scope of the issued access token you can check this very simplistic rule template. Have in mind that since you can run pretty much any logic (including calls to external systems) before setting the final scope. This approach gives you a lot of flexibility, but does come at a slight cost of implementation. Due to this we are considering supporting additional ways to define such policies that may not require actual code while still targeting the most common use cases for authorization policies.