Stream: smart
Topic: Granular scopes
Josh Mandel (May 28 2020 at 17:45):
In yesterday's Argo2020 call, we talked about a few different syntaxes for representing granular scopes. @Jenni Syed you shared comments about scope size; do you have specific targets or limits you'd like us to consider, to help us pin down an objective consideration of trade-offs? (And do even our current resource-level scopes meet those targets, or are we already failing?)
Jenni Syed (May 28 2020 at 18:00):
The URL length limit comes into play during the authorization request. This varies by browser, and your proxies etc between you and the final target. One I've seen is 2048 (at a tomcat and I think IE use to have this) total for the full URL
Michele Mottini (May 28 2020 at 18:05):
Current scope string for our app connecting to Cerner is 280 characters (because no * - so list every resource individually)
Jenni Syed (May 28 2020 at 18:05):
For the token size, if a server is embedding scopes into the token vs requiring constant call backs to a central service, the size limit again varies. And it varies a lot :) eg: a popular gateway may put a general 25k limit on header size. But apparently apache defaults to 8k... and I thought nginx had some even lower defaults (it's been a while, I'll see if I can find updates) https://stackoverflow.com/questions/686217/maximum-on-http-header-values
Jenni Syed (May 28 2020 at 18:05):
But that header size has to include everything in that token, not just scopes
Jenni Syed (May 28 2020 at 18:07):
@Michele Mottini yeah, and I think we need to revisit wildcards during our SMART scope discussion :) We haven't implemented it because the spec says it means everything now and in the future that may be available, which is really hard to describe to a patient that is authorizing access. If we went back to "it's just a shortcut to the scopes I'm authorized for" that's different :) But a bit out of scope of this thread right now
Jenni Syed (May 28 2020 at 18:08):
However, even if the URL req could use wildcards, I wouldn't want to require them, and it won't solve the token header size limit since you would need to know what was actually authorized by the patient
Jenni Syed (May 28 2020 at 18:12):
There are approaches an auth server can do to reduce size (but still not require resource servers to call back to a central location like introspection), so that is another consideration
Josh Mandel (May 28 2020 at 19:10):
Re: header size, this is a slightly different issue, since the access token doesn't need to include literal SMART scopes inside (but obviously it's nice if they can).
Josh Mandel (May 28 2020 at 19:12):
For an app that's fetching data about dozens of resource types, are the current SMART scopes hitting some practical limits? Or do we just not have experience with apps like that?
Josh Mandel (May 28 2020 at 19:12):
Given the relatively small focus of US Core?
Josh Mandel (May 28 2020 at 19:15):
Basically I want some way to decide whether we need to so something more extreme about scope size, like having clients send hashes of or references to a full scope list, rather than transmitting full details about scopes in the URL
Josh Mandel (May 28 2020 at 19:19):
For example, if we wanted to support a 2048 character URL limit, including space for stuff that is not scopes, we would have maybe a kilobyte to work with for scopes. That clearly breaks down if you are individually listing fhir resources.
Jenni Syed (May 28 2020 at 19:24):
If we did that/recommended that, we would likely also want to recommend auth servers actually use the scopes param in the token response to communicate what was actually granted
Jenni Syed (May 28 2020 at 19:26):
@Josh Mandel Not following the comment on header - you just mean that (if a server doesn't require callback to central authority) the token wouldn't need to be literal SMART scopes? If so, that may affect what out of the box auth servers you could use (that don't understand SMART first class)
Josh Mandel (May 28 2020 at 19:28):
Yes, that's all I meant (i.e., we don't specify anything about access token format).
Jenni Syed (May 28 2020 at 19:29):
I don't think we need to do things that are extreme, but more want to understand that there are reasons to find a balance between verbosity and compactness :)
Josh Mandel (May 28 2020 at 19:29):
But for choices that are within a factor of, say .5-1.5x of the size our current approach, I'm having a hard time knowing whether this matters.
Josh Mandel (May 28 2020 at 19:29):
On one assessment, our current approach already doesn't scale, and anything we add to it only makes it worse.
Jenni Syed (May 28 2020 at 19:46):
yeah, I'm not too worried if it doesn't expand to "all the things you could query on" :)
Jenni Syed (May 28 2020 at 19:46):
Google has some "longer" API scopes, but also not sure how common it is for an app to use a bunch
Jenni Syed (May 28 2020 at 19:47):
Today, we haven't hit limits with the URLs, and we do have some apps that ask for every combination of scope that we offer in sandbox :)
Jenni Syed (May 28 2020 at 19:48):
That is usually whittled down before prod, so that the "conflicting" scopes are no longer requested (eg: both patient/{}.read and user/{}.read don't make sense)
Josh Mandel (May 28 2020 at 19:49):
But right now support in your server is limited to a subset of the FHIR API, and some of the generic servers would have many more resource types to contend with. Plus layering on the complexity of sub resource scopes like specific categories or tags... We are obviously going to need more space to express these policies.
John Moehrke (Jun 01 2020 at 18:04):
I would like to offer that these needs to get more and more comprehensive might be a good reason to help security out with Permission resource. This is a very drafty draft. We have already found many problems with the draft. But the idea of Permission is to carry access control rules. Meaning, don't bother looking at the Permission resource we have, it is just a first draft placeholder.
John Moehrke (Jun 01 2020 at 18:06):
I hope we can come up with a OAuth scope pattern that meets majority needs, while pushing more detailed needs into a Permission resource. Where that resource might be referenced or contained; where that resource might be used in other ways too
Grahame Grieve (Jun 04 2020 at 03:09):
how would you represent scopes in a Permission?
John Moehrke (Jun 04 2020 at 13:18):
Grahame Grieve said:
how would you represent scopes in a Permission?
There have been discussions of having scopes be json encoded. That seems like an opportunity to have the same json be a subset of a Permission resource. If it gets complex enough the scope could be a reference rather than contained in the scope. --- and key to this is that Permission draft in the spec today is highly drafty and needs major re-design. I am simply pointing out that the needs of a OAuth scope is the same needs as are driving Permission.
John Moehrke (Jun 04 2020 at 13:19):
I do think that we can do some much more achievable step that doesn't not require json encoding.
Josh Mandel (Jun 04 2020 at 13:19):
I'm assuming you have an extra negative in there :-)
Josh Mandel (Jun 04 2020 at 13:19):
For our next Argonaut call I would love it if people could bring additional proposals so that we can compare them to the approach I laid out last week.
Josh Mandel (Jun 04 2020 at 13:21):
I worry we're not exploring this design space effectively yet, And it's hard to discuss things like size requirements in the abstract.
John Moehrke (Jun 04 2020 at 13:30):
agree. simple achievable next step.
Jenni Syed (Jun 04 2020 at 14:02):
The primary concern was the "unbounded" scope description using a query
Jenni Syed (Jun 04 2020 at 14:04):
eg: I can easily (and we have seen it happen) query for observations "labs" using many many loincs just to get at 3 "basic" labs (because I try to account for all the different methods that can be pre-coordinated into the code). So many that I immediately blow through typical URL length limits :)
John Moehrke (Jun 04 2020 at 14:32):
I was expecting that with the query syntax model, we would have a well-defined initial set.. not unconstrained. The advantage of having the query model was that it set a pattern that we could grow into as explicit use-case priority needs came up.
Jenni Syed (Jun 04 2020 at 15:21):
code was one of the initial examples given :)
Jenni Syed (Jun 04 2020 at 15:21):
(eg: limit to a specific type of result) - even though I don't know if that would be original scope
Josh Mandel (Jun 08 2020 at 16:22):
@Jenni Syed in your example here ("using many many LOINCs" and blowing through URL length limits)... is this something where developers are hitting length limits in their GET-based FHIR search API calls? Like, with browsers that impose limits not just on window.location length but on AJAX request URLs too? Is this something that they can address with POST-based search?
Josh Mandel (Jun 08 2020 at 16:22):
Is it related to authorization, or just a query example where URL limits come into play?
Jenni Syed (Jun 08 2020 at 19:21):
The example in question was solved for them switching to POST (they hit the limit with the URL when they did a GET), but the concern I had for the scopes was if we allowed something similar, you can't switch that to POST for the authorization request
Jenni Syed (Jun 08 2020 at 19:21):
in our case, they hit a tomcat limit, not browser
Josh Mandel (Jun 08 2020 at 19:52):
Gotcha. So this week we can talk through approaches like https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-5.2.2 to limit size over the wire, specifically for the authorize endpoint.
Jenni Syed (Jun 08 2020 at 22:02):
that looks like it died from an IETF perspective... (it's expired)
Jenni Syed (Jun 08 2020 at 22:04):
My coworker pointed out that OpenId Connect allows the authorization to use a form POST
Jenni Syed (Jun 08 2020 at 22:04):
which would leave this to be mostly token size issue
Jenni Syed (Jun 08 2020 at 22:06):
and I know some cloud providers have special errors they provide when you've asked for scopes that push their token size beyond implementation limits
Jenni Syed (Jun 08 2020 at 22:07):
which would imply that you start breaking up your token requests by workflow...
Jenni Syed (Jun 08 2020 at 22:07):
and if you're getting so many that it's a concern, that's probably a reasonable thing to do for your own sanity and token managment
Josh Mandel (Jun 08 2020 at 22:33):
"Hasn't yet been re-re-renewed yet"' isn't the same as dead. OpenId also already allows for request objects to be passed by request_uri, so this spec is really ietf formalizing that same pattern.
Josh Mandel (Jun 09 2020 at 01:17):
Re: submission via POST, that's a great trick that OIDC already defines (I never knew -- thanks for the heads-up). That takes off the URL size pressure for the request step. For the response step, https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html takes off the pressure. Both of these leave things up to client discretion (but obviously clients that will fail on GET, will be incentivized to POST).
Josh Mandel (Jun 09 2020 at 01:17):
That just leaves the authorization header itself, which we've always left out of scope.
Dharmesh Patel (Sep 15 2020 at 02:12):
A SMART App submits a PATCH Request to change the value of the patient reference in an AllergyIntolerance resource whose current patient value is set to 'Patient/{validPatientID'. The request has an access token with scope = 'patient/AllergyIntolerance.write' and patient="Patient/{validPatientID}". The body of the request contains another valid PatientID. Question #1: Should the request be allowed or denied? Question #2: Should the same request be allowed or denied if the scope='user/AllergyIntolerance.write'?
Josh Mandel (Sep 15 2020 at 02:47):
1) the access token has scopes only for patient 1; it shouldn't be able to put allergies in patient 2's compartment
Josh Mandel (Sep 15 2020 at 02:48):
2) assuming the user in question is allowed to modify records for both patients, then user level write permissions should confer this ability to an app
Josh Mandel (Sep 15 2020 at 02:48):
Note that the smart scope language provides no way to say which users have access to performance operations under the hood...
Dharmesh Patel (Sep 15 2020 at 06:46):
Thanks Josh.
Last updated: Apr 12 2022 at 19:14 UTC
