Stream: inferno
Topic: BDA-03 - Should Inferno fail servers ignoring invalid scopes
Cooper Thompson (Aug 02 2021 at 14:07):
For the BDA-03 test, Inferno (Program Edition) is flagging the test as failed if the server doesn't error when a client requests the user/*.read scope. This is based on language in backend auth guide. I think that check should just confirm that the server doesn't grant user scopes. Our server will ignore any invalid scopes presented, and will return the scopes registered to the client during client registration (which can only be system scopes for backend clients).
Cooper Thompson (Aug 02 2021 at 14:09):
Do folks agree in my interpretation? If so, I can write a github issue to update BDA-03 to validate the server-issued scopes instead of the HTTP response code when a client sends invalid scopes.
Josh Mandel (Aug 02 2021 at 14:43):
I agree that ignoring requested Scopes is fine, assuming you are in fact granting something and returning what you granted in the Scopes array of the generated access token response. If you're talking about issuing an access token with zero scopes because all of the requested Scopes were ignored and no default Scopes are configured... That seems like more dubious behavior.
Josh Mandel (Aug 02 2021 at 14:45):
(in any case, it's not illegal or nonsensical or an application to request some combination of system level Scopes and user level scopes, using some combination of the application's own authority and the authority of a relevant user -- though this would be in the context of an authorizations code Grant (i.e., an app launch) ... We are clarifying this as we merge the backend Services content into the core SMART specification. I would not want to see the test suite and force behavior that would limit these kinds of possibilities )
Yunwei Wang (Aug 02 2021 at 15:37):
BDA-03 tests using 'user/*.read' scope and expects a 4xx error. @Cooper Thompson What is the response from your server?
Cooper Thompson (Aug 02 2021 at 15:39):
200-OK, but we ignored the user scope and instead returned a token with the system scopes the client was registered for.
Yunwei Wang (Aug 02 2021 at 15:42):
Doesn't this violate https://tools.ietf.org/html/rfc6749#section-5.2?--
Yunwei Wang (Aug 02 2021 at 15:43):
The authorization server responds with an HTTP 400 (Bad Request)
status code (unless specified otherwise) and includes the following
parameters with the response:
invalid_scope
The requested scope is invalid, unknown, malformed, or
exceeds the scope granted by the resource owner.
Cooper Thompson (Aug 02 2021 at 16:55):
That is from the auth code grant section. The client credentials grant section (https://datatracker.ietf.org/doc/html/rfc6749#section-4.4.2) references section 3.3, which includes this blurb:
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.```
Josh Mandel (Aug 02 2021 at 17:23):
(Agreed with Cooper's reference -- and in the context of an authorization code grant, I wouldn't say that user/*.read or, say, system/*.read is "invalid". They might just not be authorized.)
Yunwei Wang (Aug 02 2021 at 18:38):
@Cooper Thompson Would you mind to create a github issue so we can track it?
Cooper Thompson (Aug 02 2021 at 18:45):
Done. https://github.com/onc-healthit/inferno-program/issues/331
Last updated: Apr 12 2022 at 19:14 UTC
