Stream: smart
Topic: userinfo/fhirUser/profile
Sean McIlvenna (May 26 2020 at 23:08):
I'm using https://launch.smarthealthit.org/ to test my smart-on-fhir (client) implementation. I'm requesting scopes for "launch,openid,profile" and successfully getting an access token... However, my access token does not include any claims related to the user's profile. I would expect that to be the case based on Smart's spec saying:
Claims: The EHR SHALL support the inclusion of SMART’s fhirUser claim within the id_token issued for any requests that grant the openid and fhirUser scopes. Some EHRs may use the profile claim as an alias for fhirUser, and to preserve compatibility, these EHRs should continue to support this claim during a deprecation phase.
Any idea why the access token being returned does not include the claims related to the user's info like described above?
In fact... I'm getting very few claims in the access token:
{
"need_patient_banner": false,
"smart_style_url": "https://launch.smarthealthit.org/smart-style.json",
"token_type": "bearer",
"scope": "openid launch,openid,profile",
"client_id": "",
"expires_in": 3600,
"iat": 1590534137,
"exp": 1590537737
}
Vladimir Ignatov (May 26 2020 at 23:27):
You should use spaces to separate scopes in your requests. Otherwise the server sees it as one single scope "launch,openid,profile" and not three different ones. Since it is a demo server, it will grant you any scope you request. In other words, it doesn't know what "launch,openid,profile" is, but it assumes it is some unknown scope and you get it back as is.
Sean McIlvenna (May 26 2020 at 23:38):
@Vladimir Ignatov see my thread on "scope delimination"
Sean McIlvenna (May 26 2020 at 23:38):
I agree with your assessment, generally.. but the behavior seems wrong when I ask for space-delimited scopes
Last updated: Apr 12 2022 at 19:14 UTC
