Closed geoff-va closed 4 years ago
I just noticed the validate_requested
scopes comment specifically states it's only handling this for password and client_credentials, so this seems intentional. Is there somewhere in the spec or a reason we wouldn't apply this to all code flows?
I created a test client with the following authorized scopes:
openid testing
using
authorization_code
flow.Then I followed the instructions here to get an access code, but requested the following scopes:
openid other special
instead of the ones in the Client's scope (these were custom scopes I've added).
I then proceeded to fetch the access token using my supplied code and was returned claims that were part of the
special
scope.In addition, when I view the token and authorization code in the admin, they are scoped for the requested scopes (
openid other special
) instead of the intersection between the requested scopes and the Client's authorized scopes.So, unless I'm misunderstanding something, you can request and obtain access to any scopes despite what may exist in the clients authorized scopes.
Can someone else validate this?
Update
After a further investigation, it appears that the
create_response_dict
method is what is responsible for creating the access token and properly scoping it (delegating actual creation to a method based ongrant_type
)It looks like only the
password
andclient_credentials
grant types are callingvalidate_requested_scopes
. Would there be any reason to treatauthorization_code
flow differently in this case? It would seem regardless of thegrant_type
would should only be allowing access to approved scopes.