Stream: smart
Topic: Patient vs User Scope
Benjamin Langley (Jan 15 2021 at 17:09):
Could someone please explain what the difference between patient and user scope is for a standalone launch? I'm on the Carin BlueButton track where we use SMART for a patient to authenticate to their payer to obtain EOBs etc. Would the user and patient scopes be the same here? Is it suffice to just support one (ie patient/*.read and not user/*.read)
Benjamin Langley (Jan 15 2021 at 17:12):
As a sort of follow up - is the patient scope just resources in the patient compartment? So if we wanted every user to be able to read all Organizations would that need to be user/Organization.read or would patient/Organization.read be suffice
Josh Mandel (Jan 15 2021 at 17:50):
-
patient/scopes are appropriate when your app needs to get access to a specific patient record (the user will select which patient as part of the approval process). -
user/scopes are appropriate when your app needs access to all the records the approving user is allowed to access
Josh Mandel (Jan 15 2021 at 17:51):
For patient access API requirements, often patient/ scopes are good enough
Josh Mandel (Jan 15 2021 at 17:52):
Scopes aren't strictly tied to the FHIR "CompartmentDefinition" because the compartment definition is quite rigid and authorization servers are free to define access and more flexible ways (e.g., including additional data that is linked to by resources in the patient compartment)
Benjamin Langley (Jan 15 2021 at 20:13):
Hi Josh, this was really helpful. One follow up - since its not required for servers to publish which scopes they support is it just expected the client will need to determine how to deal scope errors (i.e. if a client requests a scope and the auth server returns an error its up to the client to figure out how to deal with that). Is there any guidance for how a client could go about this (if the supported scopes aren't published)?
Josh Mandel (Jan 15 2021 at 20:18):
We recommend that servers publish in the .well-known/smart-configuration doc; in the real world, servers should publish in their documentation, fo humans to read too. And ultimately, apps need to be robust to unsupported scopes (like, come back and try again).
Benjamin Langley (Jan 15 2021 at 20:19):
Gotcha. Is there a reason its not a required field?
Josh Mandel (Jan 15 2021 at 20:20):
It can be hard for a server to express all scopes it can support, since they can grow combinatorially.
Josh Mandel (Jan 15 2021 at 20:21):
But for your specific use case, actually you can just check whether permission-patient or permission-user are listed in capabilities[].
Josh Mandel (Jan 15 2021 at 20:21):
So that's actually a much better answer, in this specific case.
Josh Mandel (Jan 15 2021 at 20:22):
Clear, unambiguous documentation, even ;-)
Jenni Syed (Jan 15 2021 at 20:25):
Also keep in mind a server could support a scope but the user could remove it (or the server could deny it). I wouldn't just keep retrying :)
Josh Mandel (Jan 15 2021 at 20:30):
You definitely don't want to auto-retry, or keep retrying repeatedly; but between authz responses and user input, there are cases where you'll want to re-try with different/down-selected scopes.
Sagar Shah (Jan 15 2021 at 23:00):
Josh Mandel said:
patient/scopes are appropriate when your app needs to get access to a specific patient record (the user will select which patient as part of the approval process).
user/scopes are appropriate when your app needs access to all the records the approving user is allowed to access
Need one clarification here. Does it mean the access token issued with patient scope with a specific patient (during approval) cannot be used for any FHIR API of another patient?
Michele Mottini (Jan 15 2021 at 23:54):
Correct
Sagar Shah (Jan 16 2021 at 14:10):
Thank you for clarification here. Also, if the app only has patient/ scopes, then how does the auth server know what patients to be shown in the picker? Is it up to the EHR/patient portal to determine user permissions here and accordingly display the list of patients?
Michele Mottini (Jan 17 2021 at 00:56):
Up to the EHR. Usually it has a list of patient each user can access - like their family members or the likes
Sagar Shah (Jan 17 2021 at 01:21):
Thanks @Michele Mottini for clarifying.
Dan Cinnamon (Feb 04 2021 at 14:49):
I'm getting a lot of questions about the patient scoping requirements- and making sure I'm following the right path. Right now my understanding from all of this discussion is that if I request a patient/ scope, and the user picks a patient at consent time. This token will be rejected by the resource server if an attempt is made to access a different patient than was selected. The piece I'm struggling with is- in the implementations where the access_token is opaque- how does the resource server know which patient a given token is bound to (and all downstream refreshed tokens as well)?
Michele Mottini (Feb 04 2021 at 15:23):
The access token is opaque for the client, but the server must know how to validate it and what does it grant
Dan Cinnamon (Feb 04 2021 at 16:25):
Gotcha- thank you @Michele Mottini , so for example in a case where the resource server and the authorization server are part of the same product suite- there must be some communication within the components so that if authz server mints opaque token "12345abcd" for patient 6789, the resource server portion of that can look up that fact somewhere while validating/introspecting (and if the requested patient is not 6789- reject). Additionally, any refreshed access tokens would also be bound to patient 6789 and that same communication/lookup will occur. Is that right?
Michele Mottini (Feb 04 2021 at 16:28):
Yes
Dan Cinnamon (Feb 04 2021 at 16:33):
Thank you! Much appreciated!
Brian Postlethwaite (Feb 07 2021 at 09:27):
Not sure of that should be a 401 reject, or a 404 not found. Security considerations I expect here might result in either of these?
Michele Mottini (Feb 07 2021 at 12:23):
403 or maybe 404, not 401
Last updated: Apr 12 2022 at 19:14 UTC
