You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While this attack is not explicitly enabled by this specification, and is possible in a plain OAuth 2.0 deployment, it is made somewhat more likely by the use of dynamically-configured clients. As such, the use of audience-restricted access tokens and Resource Indicators [RFC8707] is RECOMMENDED when using the features in this specification.
However there is currently no way for the OAuth client to know (in the general case i.e. loose coupling between the different actors) that the audience restriction has been properly supported and applied by authorization server. For example, the authorization server might silently ignore the resource parameter of the authorization request.
Ideally, the authorization server should probably include the resource back in the authorization response similar to how this is done for the scope parameter (and in a sense for the authorization_details parameter). Such an option should probably have been included in RFC8707, however.
Alternatively (or in addition) some authorization server metadata could be used to indicate that it supports resource indication.
The text was updated successfully, but these errors were encountered:
I agree that the token response should include resource like it does scope to inform the client. However I don't think that is a mechanism that this spec can suggest or define, it probably should have been part of RFC8707. Same goes for the authorization server metadata to indicate support, that should have been part of 8707, and isn't something this spec can define.
The current draft contains the wording:
However there is currently no way for the OAuth client to know (in the general case i.e. loose coupling between the different actors) that the audience restriction has been properly supported and applied by authorization server. For example, the authorization server might silently ignore the
resource
parameter of the authorization request.Ideally, the authorization server should probably include the
resource
back in the authorization response similar to how this is done for thescope
parameter (and in a sense for theauthorization_details
parameter). Such an option should probably have been included in RFC8707, however.Alternatively (or in addition) some authorization server metadata could be used to indicate that it supports resource indication.
The text was updated successfully, but these errors were encountered: