Stream: smart
Topic: SMART Scopes to authorise a client, a user or both?
Adam Hatherly (Jun 14 2019 at 15:05):
Apologies if this is a daft question, but I'd always assumed that a SMART on FHIR OAuth2 authorisation request was essentially requesting authorisation for a client (system) to access data for a user (e.g. a healthcare professional), and that the OAuth2 server should take account of both the client (system) and the user (roles, etc) in deciding which scopes to authorise. I've come across other OAuth2 discussions which suggest it should only be used to authorise scopes for a client, and any user permissions should be handled in the API rather than the OAuth2 endpoint - e.g. this thread: https://stackoverflow.com/questions/50267663/how-to-return-different-scopes-for-different-roles-in-identityserver-4/50270143
Do you have a view on this?
John Moehrke (Jun 14 2019 at 15:18):
could be either.. this level is a 'systems design' decision made between the team working on the authorization server and the resource server. Typically the decision is the combined app rights and user rights. But there is no reason why it can't be only app rights. Note that there is a third vector of patient-consent which could also be included, or left to the resource server. The more decisions one includes in OAuth, the better separation of duties (authZ vs Resource-Server); but the more decisions made the harder to encode the permissions and residual obligations in the token/scope. So it is ultimately a systems design complexity tradeoff.
Adam Hatherly (Jun 14 2019 at 15:20):
ok, that makes sense. To I think the blanket statement in that stackoverflow post that OAuth2 scopes are only for client AuthZ and should not be used for user rights is incorrect - which is what I thought!
Grahame Grieve (Jun 14 2019 at 21:17):
well, you might want to read this: http://www.healthintersections.com.au/?p=2967
I don't think you can't use them for user rights... in fact, I do, in test.fhir.org. But I can only do that because my server is not a real clinical system
Jenni Syed (Jun 17 2019 at 14:12):
I think the primary requirement is that, once the API is called, both the user and the app rights are enforced. The spec leaves it to the implementer to determine how that is done.
Adam Hatherly (Jun 18 2019 at 15:27):
Thanks all. I agree with the scope questions on the page you posted @Grahame Grieve - they are things I've grappled with in the past also. I'll have a think and maybe make some suggestions on the scopes thread if I come up with any ideas.
Last updated: Apr 12 2022 at 19:14 UTC
