Oauth 3-legged client scope

banto_78
Participant III

Hi,

in the Oauth 3-legged flow at page http://d3grn7b5c5cnw5.cloudfront.net/sites/docs/files/oauth-auth-code-flow%20%281%29.png there is a step where the client invoke the endpoint /oauth/token and amongst other params it also passes the "scope". My point here : is that really correct and safe? An user has already given a consent where the scope has been defined in an earlier step. So what if now the client issue such request with larger scope? does it overwrite user approved scope? And i also think this is not what OAuth specify.

Any hint?

thanks lot.

1 5 743
5 REPLIES 5

banto_78
Participant III

Maybe that diagram is not correct. You're correct: the Authorization code is stored inside Apigee Edge with the appropriate scope. The client app passes the code, and receives a token with the approved scope.

I can think of a one reason the designer of such an exchange would want the client to send the scope at that point: to verify that the requested scope from the client matches the approved scope from the user.

In the event that the user has not approved all scopes as originally requested by the client, at that point the generation of the access_token could fail, and the client_app could relay the appropriate message to the user.

But I don't know the origin of that diagram. So I am guessing.

@bantobanto - that is a good point. I believe the presence of the scopes parameter in the oauth/token endpoint is dependent on the OAuth grant type.

In your comment above, you referred to https://tools.ietf.org/html/rfc6749#section-4.3.2 - this is the Resource Owner Password Credentials grant type, it does not use an authorization code flow and thus needs the scopes parameter in the /oauth/token endpoint.

When you look at the Authorization grant type https://tools.ietf.org/html/rfc6749#section-4.1.3 it does not include the scopes in the token endpoint, because this was already passed in the authorization code endpoint.

I think you are right about the picture.