More Thoughts on OAuth2 Dynamic Client Registration in SMART on FHIR

Avinash Shanbhag writes:

---

Hi Keith

We had a question for you,  on your blog on “Dynamic Registration”, which I tried to post on the blog, but, somehow I don’t see it posted (Not sure, if you have ONC/HHS email filter on the commentsJ).

http://motorcycleguy.blogspot.com/2017/08/thoughts-on-oauth2-dynamic-client.html?utm_source=feedburner&utm_medium=twitter&utm_campaign=Feed%3A+MotorcycleGuy+%28Healthcare+Standards%29

==== Excerpt from Blog ==

Think about the fact that the application on your phone and the same application on your wife's phone, even though they are talking to the same endpoint, don't necessarily know about each other, and so if using Dynamic Registration probably get assigned separate client_id and client_secret values.

==== Upto here ===

From the above excerpt, it seems to indicate that each instance of App would get a separate Client ID/Secret. Is that really true? Our understanding is that the client ID/Secret is generated at the “App” level, same as any manual or self-service registration process would do;  and once done, the same ID (and secret if Confidential App) will be used by each instance of the App. So, in a sense, dynamic registration is no different than manual registration other than the obvious fact that this is done via API.

Here’s link to the SMART team’s web page that describes both the manual and dynamic approach

http://docs.smarthealthit.org/sandbox/register/

Could you clarify if we misunderstood your point, or if our understanding of the dynamic registration spec is wrong? If my post gets published, feel free to comment publicly.

Thanks in advance and looking forward to seeing you at the Interop Forum tomorrow!

Regards

Avinash

---

If this is the dynamic registration call (extracted from the link above):

POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: authorize-dstu2.smarthealthit.org

{
   "client_name": "Cool SMART App",
   "redirect_uris": [
     "https://srv.me/app/cool"
   ],
   "token_endpoint_auth_method": "none",
   "grant_types": ["authorization_code"],
   "initiate_login_uri": "https://srv.me/app/launch.html",
   "logo_uri": "https://srv.me/img/cool.png",
   "scope": "launch launch/patient launch/encounter patient/*.read user/*.* openid profile"
}

Here are some of the problems I see in it:

1. There's nothing in the above that allows me to trust the application registration content in any way.
   
   Anyone can use this same data to register an application.  The application itself runs on the patient's device.  If giving the same data gives back the same client_id and client_secret, then these items really aren't secret.  Anyone get the redirect_uri, the initiate_login_uri, and the logo_uri and the client_name.  How does one get these?  Build a FHIR Endpoint and ask the application to register itself against your endpoint.  It will gleefully tell you what it uses to register itself.
2. Knowing what an application uses to register itself, one can easily determine what client_id and client_secret is assigned to that application.
   
   This can be done by building an application that follows the dynamic registration protocol using the values extracted via the exploit I explain in #1 above.
3. There's nothing linking this registration back to a responsible party EXCEPT for an https: URL or three.
   
   I have 30 or 40 HTTPS urls I control, and all I needed was an email address to create one.  I think that providers need to take some precautions to safeguard healthcare data, and that means that there needs to be some way to trace it back to a responsible entity. That's a little bit more than what is required to create an https URL.  Also, not all redirect or login URIs would be to the Interwebs.
4. Use of token_endpoint_auth_method assumes public apps are supported (applications that cannot manage a client_secret), and that client_secret won't be used.
   
   I'd prefer to put a "somebody else's problem field" around application identity management if I could.  Otherwise, I have to deal with a lot more infrastructure that I want, but some identity providers barf at this today (you know who you are).  Either I have to use an identity provider that supports public apps, or I can restrict support to private apps.  The latter seems to be preferable given the infrastructure needed to manage application identities.
   
   In the example given, there's no reason why this application needs to be public, given that it's redirect and login URIs are "on the web".

So, client_id and client_secret, if created and maintained on a per-registration basis, needs something extra to ensure that you can safely consolidate multiple registrations to a singular client_id and client_secret for any application registering with the same information.  Otherwise, to have these values actually be an id and a secret that MEAN anything, you have to do more work.  What good is a secret if everyone can know it.

That's where I get into the "too much infrastructure" problem, because now we start introducing stuff like PKI to be able to verify publishers of software statements, or external trust bundles (a la DirectTrust or NATE or ...) and ...

Dynamic registration might be the way forward, but it doesn't appear to be ready yet for prime time.

   Keith

Thoughts on OAuth2 Dynamic Client Registration in SMART on FHIR

Some weeks I'm just slow.  I probably spent a week trying to figure out how to deal with Client registration for SMART on FHIR applications.  One of the things I discovered in the process after I did the math:

Think about the number of different applications that patients could use.  Oh, maybe a 100 if we are lucky.  Most of us will use one or two. I know from previous experience the average number will be around 1.1 (at least at first).

Think about the number of patients a provider sees in a year.  Say they have a panel of 2-3 thousand patients, they probably see somewhere between 1/4 to 1/2 of these annually.  Call it an even 1000.

Think about the fact that the application on your phone and the same application on your wife's phone, even though they are talking to the same endpoint, don't necessarily know about each other, and so if using Dynamic Registration probably get assigned separate client_id and client_secret values.

Now, look at a 100 provider practice, and understand that some of the providers in that practice see the same patients that other providers do.  So 100 * 1000 * 50% (for overlap) 50,000 patients seen in that practice (NOTE: These are rough numbers, what is important is the magnitude).

Now, just think about the fact that if every 50% of the patients each use an application, and each one

requires its own client_id and client_secret, you now have 25,000 client_id and client_secret values for what, maybe 100 applications.  And if any of those applications are busted (meaning they register more often than they need to because someone missed something in the spec), you could have some applications registering daily or hourly or whatever the expiration time is on the authorization token, and now that number could really balloon.

Is this realistic?  Is it valuable?  Is it worth having to manage? Would it not be better to have 100 client secrets and client ids which you could then manage if necessary?

I know ONC is promoting use of Dynamic Client Registration, but I look at the cost of doing that, and I am quite certain that there really is a better way.  It's interesting that Twitter, Facebook, Google and many other API publishers outside of healthcare haven't been using OAuth 2.0 Dynamic Application Registration.

I'm wondering, is Dynamic Application Registration really Smart?

   Keith

Handling Extra OAuth2 Authentication Parameters

I'm deep into spec'ing out an OAuth 2 implementation, which means that I have to give all the detailed rules about what to do with parameters sent to the authorization endpoint of an OAuth2 server.  The question arose, what do we do with parameters that aren't recognized.  Fortunately, OAuth2 clearly resolves this issue for us (and for you):

In the section describing the OAuth2 Authorization endpoint, what OAuth2 says is

"The authorization server MUST ignore unrecognized request parameters."

There's a very good reason for this.  It allows profilers of OAuth2 to add parameters with additional specified behaviors.  You won't find the SMART on FHIR "launch" parameter anywhere in the OAuth2 spec. For those endpoints that do recognize it, they can do something useful with it.

The same thing works for unrecognized scopes.  If you don't recognize it, it isn't an error, just ignore it and it should go away (the application that sent it should be expected to behave correctly when it is ignored).

Postel's law rules.