Scopes not validated against Client's scopes
geoff-va opened this issue · 2 comments
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 on grant_type)
It looks like only the password and client_credentials grant types are calling validate_requested_scopes. Would there be any reason to treat authorization_code flow differently in this case? It would seem regardless of the grant_type would should only be allowing access to approved scopes.
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?