Stream: smart
Topic: Should I set ClientID as input parameter
Yunwei Wang (Feb 04 2019 at 16:43):
I am trying to setup one client to serve two Smart server. Because two servers provide two different clientIDs, my client need to pickup the correct clientID during the lanch process. I am thinking to add clientID into registered launch url. For example, the registered launch url looks like:
http://myserver.com/launch?clientID=1234
The actual launch request sent from SMART server would be:
http://myserver.com/launch?clientID=1234&iss=smartserver.com
Technically, this should work.
Is there any problem from SMART spec?
Josh Mandel (Feb 04 2019 at 16:50):
The SMART EHR Launch specification provides an iss parameter that your app can you use to know which server is launching your app. The details of the client ID should be stored in your app itself, with the issuer parameter used by your app to perform a lookup.
Josh Mandel (Feb 04 2019 at 16:51):
you should avoid adding a new URL parameter because if your app depends this new parameter it will be incompatible with existing servers
Yunwei Wang (Feb 04 2019 at 17:32):
you should avoid adding a new URL parameter because if your app depends this new parameter it will be incompatible with existing servers
This can be resolved by using value from clientID parameter if exists otherwise use value from server config.
My most concern is about this:
The details of the client ID should be stored in your app itself, with the issuer parameter used by your app to perform a lookup
What is the problem/drawback for exposing clientID? I first thought there were some security risks but anyone can get clientID by looking at the authorization request from launch page.
I just don't know if I missed anything during my analysis.
Josh Mandel (Feb 04 2019 at 18:00):
I don't see a security risk, but I don't understand what your goal would be in adding a new parameter like this. It will lead to poor compatibility of your app with the ecosystem, and on my assessment, it does not open up any new use cases beyond what you can accomplish simply by maintaining a map between issuer values and client ID values within your application.
Josh Mandel (Feb 04 2019 at 18:01):
It's possible I have missed something about what you are trying to accomplish or the constraints that you are working with.
Brian Postlethwaite (Feb 05 2019 at 08:32):
And some servers may want you to have a secret with that client id?
Yunwei Wang (Feb 05 2019 at 15:05):
@Brian Postlethwaite My client is a Angular client and it does not use client secret.
@Josh Mandel Here is my situation. I have an Angular app developed for one EHR and now I need to tune this app for second EHR. I have three options:
1) Use separate servers. Each server has its own environment configuration.
2) Use iss parameter to decide which server sends the request
3) Add client ID to server registration.
Josh Mandel (Feb 05 2019 at 15:06):
I'm not sure what you mean by (3).
Yunwei Wang (Feb 05 2019 at 15:13):
That is what I mentioned in my first post. For example, my client registered launch URL is http://myserver.com/launch. I can add clientID as a url parameter to it and change the registered launch URL to http://myserver.com/launch?clientID=my-client-id. When launched from SMARTserver, the request sending to myserver.com would be http://myserver.com/launch?clientID=my-client-id&iss=fhirserver.com
Josh Mandel (Feb 05 2019 at 15:41):
What I'm confused about is that the client ID can be fully inferred (by the client), given the issuer value.
Josh Mandel (Feb 05 2019 at 15:41):
Is there some reason this isn't true in your case?
Yunwei Wang (Feb 05 2019 at 17:03):
(deleted)
Yunwei Wang (Feb 05 2019 at 17:33):
@Josh Mandel When I check all my app registrations, I found that Cerner allows ONLY one pair of launch/redirect URLs per client registration. Since I have dev, qa, staging and prod servers, I have 4 client registrations on Cerner. So yes, one issuer could map to multiple client ids.
Josh Mandel (Feb 05 2019 at 17:36):
Sure, but I think you're saying that your different environments have different redirect urls, which implies they are hosted at different locations. In this case, doesn't your production instance know that it is a production instance, and your development instance knows that it is a development since?
Brian Postlethwaite (Jul 20 2021 at 06:03):
Reading back through this again, and rechecking my understanding, is it the Auth server that allocates the Client ID, or does that "depend".
The use case I'm struggling with is that will have thousands of on-prem PMS systems (primary care) that will be calling the smart app, (even if they are all the one vendor) and each one has their own issuer (the on prem server)...
Josh Mandel (Jul 20 2021 at 13:27):
Servers assign client_ids. Of course, a server could have a strategy that reflects the job back onto the client (e.g., using a client domain name or client signed JWT as a client_id)-- but 1) that's pretty unusual, and 2) the server still is in charge, and needs to enforce whatever rules it sets
Josh Mandel (Jul 20 2021 at 13:31):
You can make registration work at scale using a convention for client IDs (as long as clients use asymmetric auth), or using dynamic registration (if clients need a symmetric secret).
Last updated: Apr 12 2022 at 19:14 UTC
