Stream: smart
Topic: Expected scopes on a "refreshed" access token
Cooper Thompson (Mar 08 2022 at 22:49):
In the section about refresh access tokens, the spec has this blurb in the Response sub-section:
scope - Scope of access authorized. Note that this will be the same as the scope of the original access token,
and it can be different from the scopes requested by the app.
Of specific interest is the bit about the scope being the same as the original access token. For the FHIR resource scopes, there isn't anything unexpected. My question is about openid and fhirUser scopes. Was the intent that the scope of a refresh access token include scopes like openid and fhirUser? And if the scopes are provided, then presumably the associated claims should be too. id_token is explicitly mentioned in the response object for the initial access token, but is omitted in the object for the refresh access token. Was the intentional or not?
Related question: do we think sending an id_token in the refresh access token response object is useful? Would that be interpreted as re-asserting user identity? Since there isn't user interaction, a re-assertion of identity is really more of an inference than an assertion.
Josh Mandel (Mar 08 2022 at 22:54):
My question is about openid and fhirUser scopes.
I think the intent was your access to FHIR data should be the same; the authentication context wouldn't necessarily be.
Josh Mandel (Mar 08 2022 at 22:54):
(We don't have conformance language around this, FWIW ;-))
Josh Mandel (Mar 08 2022 at 22:54):
do we think sending an id_token in the refresh access token response object is useful?
No, if you haven't re-authenticated the patient (and there's no place in the refresh token workflow to do that) it doesn't even make sense to me at first glance. Surely the OIDC spec has something to say about this...
Josh Mandel (Mar 08 2022 at 22:55):
https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokenResponse
Josh Mandel (Mar 08 2022 at 22:55):
Upon successful validation of the Refresh Token, the response body is the Token Response of Section 3.1.3.3 except that it might not contain an id_token.
Josh Mandel (Mar 08 2022 at 22:56):
So, from the OIDC spec perspective, including an id_token in a refresh token response is allowed and could be useful, but it's also OK to omit.
Robert Scanlon (Mar 10 2022 at 21:36):
Does the SMART App Launch Guide (or OAuth 2.0) provide any guarantees to the client about the scope of the refreshed access token, in relation to the original access token? The Inferno team had interpreted the line "..this will be the same as the scope of the original access token' to literally mean that scope parameter provided on the token refresh response will include the same scopes as were provided along with the original access token.
Robert Scanlon (Mar 10 2022 at 21:44):
You may have already answered that question by stating that the authorization context may not necessarily be the same, but I just want to be clear that you are also referring to the content of the scope parameter and not just the inclusion of the id_token parameter.
Josh Mandel (Mar 11 2022 at 00:31):
The fhirUser and openid scopes might well be excluded; but any patient/ or user/ scopes (FHIR data access scopes) from the original token scopes should be there
Last updated: Apr 12 2022 at 19:14 UTC
