[OPENAM-12498] Authorization Grant response returns scope(s) in the URL Created: 23/Feb/18  Updated: 28/Jun/19  Resolved: 06/Dec/18

Status: Resolved
Project: OpenAM
Component/s: oauth2
Affects Version/s: 13.0.0, 13.5.1, 14.1.1, 14.5.1
Fix Version/s: 13.5.3, 14.1.2, 6.5.0.1, 6.5.1, 6.0.1, 5.5.2, 7.0.0

Type: Bug Priority: Major
Reporter: Aaron Haskins Assignee: Lawrence Yarham
Resolution: Fixed Votes: 0
Labels: EDISON
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by OPENAM-14087 TestScopes test failures Closed
Regression
caused OPENAM-13929 Authorise endpoint against agent prof... Resolved
Target Version/s:
Sprint: AM Sustaining Sprint 54, AM Sustaining Sprint 55, AM Sustaining Sprint 56, AM Sustaining Sprint 57, AM Sustaining Sprint 58
Story Points: 5
Needs backport:
No
Support Ticket IDs:
Verified Version/s:
Needs QA verification:
No
Functional tests:
Yes
Are the reproduction steps defined?:
Yes and I used the same an in the description

 Description   

Bug description

Authorization Grant response returns scope in the URL. RFC 6749 suggests only the code and state (if defined in the request) should be returned. 

How to reproduce the issue

  1. Create OAuth2 Provider service
  2. Register an OAuth2 client profile
  3. Request authorization code using /authorize endpoint
  4. If authentication is successful, and the user allows access, an authorization code is returned, along with the scope(s).
Expected behaviour
Authorization Code is returned 
Current behaviour
Authorization Code and scope(s) are returned


 Comments   
Comment by Phill Cunnington [ 07/Mar/18 ]

An AS can change (i.e. add or remove) scopes that a Client has requested so in fact MUST respond back to the Client which scopes where granted. The only case were the AS MAY not respond with the scopes is if all the requested scopes where granted with no additions.

Comment by Andrew Vinall [ 12/Mar/18 ]

Bug Triage: We abide by the spec (section 4.1.2) and are not aware of any negative impact with sending the scope.

Comment by Dubois Olivier [ 15/Mar/18 ]

negative impact is that with a large number of scopes, the URL grows to large to be accepted by browsers.

Comment by Aaron Haskins [ 20/Mar/18 ]

Re-opening for consideration of the most recent comment. Also, 4.1.2 Authorization Response doesn't define the scope parameter to be returned in the response containing the authorization code. However, 3.3 Access Token Scope mentions:

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.

So if the scope(s) requested by the client are not what is granted, should the AS be returning the scope(s) in the Access Token Response (4.1.4) instead?

Comment by Lawrence Yarham [ 27/Sep/18 ]

First paragraph of https://tools.ietf.org/html/rfc6749?#section-3.3

The authorization and token endpoints allow the client to specify the
 scope of the access request using the "scope" request parameter. In
 turn, the authorization server uses the "scope" response parameter to
 inform the client of the scope of the access token issued.

Please say if I'm interpreting this incorrectly - this looks to indicate that the current behaviour is expected, i.e. the scope is always returned as a response parameter for the authorization endpoint.  While this doesn't indicate that the scope response parameter may be included, the second sentence in the second to last para (excerpt in comment above) indicates that the scope response parameter must ** be included if the issued scope is different from that requested.

Taking these two parts of section 3.3. together, it could be implied that the scope response parameter could be omitted if the authorized scope is the same as that requested)?  What other implications are there though of doing this?

Andrew Vinall, Phill Cunnington?  Or others?

Comment by Phill Cunnington [ 01/Oct/18 ]

Yes Lawrence Yarham your interpretation sounds correct. The AS only has to return the scopes if they do not match what the client has requested. Otherwise the AS can choose to do so if it wishes. (and in our case we always do so for simplicity)

 

The issue at question here is that the authz code response will include the scopes in the URL where the access token response usually returns the scopes in the body.

Comment by Lawrence Yarham [ 01/Oct/18 ]

Thanks Phill Cunnington

Just to confirm or otherwise on the response including the scopes being included in the URL, section 3.3 (see excerpt in my comment above), indicates: In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued. Can this be implied to be either body of the response or params on the URL?  I was reading it as a response parameter on the URL, i.e. current behaviour.

Comment by Phill Cunnington [ 02/Oct/18 ]

Lawrence Yarham The spec doesn't state anything about returning the `scope` parameter in the authorization code response (https://tools.ietf.org/html/rfc6749?#section-4.1.2) but it does state the AM can return the `scope` parameter in the token response and MUST if the scope is different to the requested scope (https://tools.ietf.org/html/rfc6749?#section-5.1).

This ticket is describing AM to be returning the `scope` parameter in the authorization code response (and the token response?) where we don't (shouldnt?)

Comment by Ľubomír Mlích [ 10/Jan/19 ]

Verified by tests in 6.5.0.1

Generated at Sat Nov 28 13:32:53 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.