Stream: smart
Topic: The custom claims of SMART App Launch
Ingvar Sørlien (Oct 21 2020 at 11:59):
I have a couple of question to the handling of the custom scopes of SMART App Lauch as defined in the standard:
- The SMART App Launch scopes and launch context defines that the launch context should arrive with the access token, but from my understanding, it must be part OF the access token - the launch context, e.g. patient must be a custsom claim in the access token iteslf. This is at least how I have got it to work with different FHIR-servers. Is that understanding right? Or should it be both, in such way that the launch context must be provided in the token response, and also in the access token itself?
If so:
- The SMART App Launch scopes and launch context defines the name of the scopes for the launch context as e.g. "patient", "encounter". If this should be part of the access token, the JWT specification is highly recommending that claims should be either "registered claim names" or "Public claim names" registered in the JWT Public Claim Name registry. Is there any plans for registering the "patient" and "encounter" as public clame names?
My challenge is that the Identity provider we are currently working with are not supporting private claim names, since this is discouraged in the JWT Specification.
Jenni Syed (Oct 21 2020 at 13:42):
1) The spec only states that the application gets it with the token response, as separate claims. It is not required to be part of the access_token, and in fact applications MUST treat the access token as an opaque string per OAuth (so they cannot retrieve the patient context from within the token). If a system (OAuth/Resource servers) decide to put the claim in the token so that a FHIR service can enforce something... it's free to do so, but token format/contract between the OAuth server and Resource server is left outside of the specifications and may change in a breaking way over time
Jenni Syed (Oct 21 2020 at 13:43):
2) The spec is defining the names of the parameters that are returned as separate claims with the token response. Here is an example token response: http://www.hl7.org/fhir/smart-app-launch/scopes-and-launch-context/#launch-context-arrives-with-your-access_token
Jenni Syed (Oct 21 2020 at 13:43):
{
access_token: "secret-xyz",
patient: "123",
...
}
Jenni Syed (Oct 21 2020 at 13:44):
Note that the access token is a separate field, encounter would be below patient in the response as a separate field as well if included (and I think the secret-... is intended to hint that the token is an opaque string not to be processed by applications)
Josh Mandel (Oct 21 2020 at 17:28):
it must be part OF the access token
The confusion here is between "the access token response" (the JSON payload an app gets from calling /token) and "the access token" (a specific property of that JSON payload). In SMART, we make no restrictions on the access token itself (as a review, @Ingvar Sørlien you may want to check out video from 2 week ago)
Ingvar Sørlien (Oct 22 2020 at 05:41):
Thank you so much for the clarifications @Jenni Syed and @Josh Mandel! So, the contents of the access token and the access control itself is not covered at all in the SMART Spec. That makes sense, but means that we actually have no standard defining interoperability between FHIR-servers and Authorization servers. I see why the implementers of FHIR-servers are supporting "patient" as custom claim in the access token to actually be able to use it for access control, even if this is not part of the SMART spec.
Josh Mandel (Oct 22 2020 at 15:07):
we actually have no standard defining interoperability between FHIR-servers and Authorization servers
Token Introspection is the piece that helps here; we only briefly refer to it in the SMART 1.0 guide but will be providing more guidance in the 2.0 guide , and you can see the draft guidance at https://github.com/HL7/smart-app-launch/blob/master/fsh/ig-data/input/pages/token-introspection.md
Brian Postlethwaite (Oct 28 2020 at 06:20):
I'm currently implementing this specific part, and kinda confused on where to put things...
The context I'm looking to share is:
Clinical - patient and optionally encounter
User - practitioner, practitionerrole, organization
Brian Postlethwaite (Oct 28 2020 at 06:23):
http://hl7.org/fhir/smart-app-launch/scopes-and-launch-context/index.html#scopes-for-requesting-identity-data
I get where patient and encounter can go, that's pretty clear, and I assume can also be extended to include things like episodeofcare too.
But the fhirUserlooks like a custom claim in the id token that has the full url to the practitioner in it. But what about all the other parts?
Brian Postlethwaite (Oct 28 2020 at 06:23):
If I just added them all in as context variables, would that matter?
Brian Postlethwaite (Oct 28 2020 at 06:24):
would it make more sense in the idtoken to have each of these things as custom claims?
Robert Scanlon (Oct 28 2020 at 15:24):
So you are looking for a way to communicate the practitionerrole(s) and organization(s) of the authenticated user to the client, right? Another option might be for the client to query /PractitionerRole?practitioner=[practitioner_id] based on the Practitioner provided in the fhirUser claim. I do not know if this is a better option than the ones you provided though.
Brian Postlethwaite (Oct 28 2020 at 19:04):
Which wouldn't tell you which of the roles the practitioner is in the context of.
Brian Postlethwaite (Oct 28 2020 at 19:07):
unless the fhir user could be a practitionerrole reference too
Michele Mottini (Oct 28 2020 at 19:26):
Like the same person being able to login under different roles? Nothing that is currently supported I am afraid (do many server even support such a thing?)
Brian Postlethwaite (Oct 28 2020 at 20:13):
3 of the systems that I work on, and some others from partners definitely do it (most of these were in primary care)
Brian Postlethwaite (Oct 28 2020 at 20:15):
Common with multiple sites, when they log into the site, the UI defaults to filter things down specific to that site - appointments/rates/templates etc
Isaac Vetter (Oct 28 2020 at 21:57):
Brian, we commonly extend the contextual information passed alongside the access_token, including with not only additional clinical information but also user information.
In my experience many application architectures have a centralized IAM system that consumes user identity assertions (like OIDC) and only then passes control to the "app". If you place this user content in the OIDC id_token JWT, it's more likely to get used for authnz, if alongside the access_token, for business logic (e.g. defaulting UI filtering).
Brian Postlethwaite (Oct 29 2020 at 03:23):
So where I have put it at the moment alongside the access_token and not inside the id_token is consistent with what you're suggesting then.
However that would then not permit you to be able to tell them apart, if you had a smart app that worked on a selected practitioner eg for a performance review form...
I'd kinda like to be able to split the difference between user context, and UI focus context (selected item).
Last updated: Apr 12 2022 at 19:14 UTC
