Validating scopes after user approval in the AuthCode Flow?

[wilsonge]

I've been working on the AuthCode flow and I feel like something doesn't quite make sense to me in terms of validating scopes on a per user or per client basis. I'm well aware that the finalizeScopes method exists but it's placement seems wrong to me

When you are building a system to approve users you end up in the flow:

• Request Approval
• User logs in
• User entity created
• User approves scopes
• Redirect back with auth code

Then we trade the auth code for a token:

• User requests access token with auth code
• finalizeScopes called as part of payload validation
• user gets access token

However logically to me something doesn't quite add up as the user has approved grants that may not actually be granted (because they then get removed in finalizeScopes) or worse they approve scopes and then a new scope gets added which the user hasn't approved (although I guess we can check the grant type and ensure that no new scopes are added as a 'worst case' option)

I'm convinced that as a result the finalizeScopes probably should be called twice as a result - once before the user approves scopes and then once again when getting the access token as a final sanity check to ensure the payload hasn't been manipulated maliciously.

The problem is that even if I wanted to do this it's not straightforward. Getting access to the scopes repository object isn't easy from within what is the /authorize method in your documentation (as this finalizeScopes call would need to take place after the user entity has been created).

Hope this issue is clear and thanks in advance for any thoughts!

[Sephster]

Hi @wilsonge - RFC 6749 states the following:

The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. If the issued access token scope is different from the one requested by the client, the authorization server MUST include the "scope" response parameter to inform the client of the actual scope granted.

As such, if the server is changing the scopes that are requested, we should be returning these scopes to the client. If they don't change, it is optional as to whether we return the scopes or not.

There has been some discussion on how to implement this optional setting and it will likely break backwards compatibility but should be implemented in a future version.

I don't think that we need to call finalizeScopes twice but I do think we need to adjust the implementation to adhere to this part of the RFC.

I would welcome your thoughts on this approach. Thanks