FHIR Chat · Looking for FHIR and OAuth (via Auth0) Expertise

Stream: implementers

Topic: Looking for FHIR and OAuth (via Auth0) Expertise

Ajay Prashar (Dec 04 2020 at 22:01):

Looking for someone that knows if it is possible to use Auth0’s OAUTH implementation, to store a piece of data, like a PatientID, within the OAuth response/Callback.

We have a system where we have WEBAPP_A, WEBAPP_B, and AUTH0 as the IdP.

We need:

a user in WEBAPP_A to authenticate to WEBAPP_B via OAUTH (Done)
upon successful authentication, WEBAPP_A sends a PatientID to WEBAPP_B within the Auth0 OAUTH response
WEBAPP_B will, upon receiving a PatientID, request additional information from WEBAPP_A
WEBAPP_A will then receive a query string that leads to WEBAPP_B’s application via a new browser tab.

We need to figure out how WEBAPP_A sends metadata (PatientID) along with the request for authentication.

I am hoping I explained the issue accurately but understand that I am not a developer.

Auth0 Enterprise Support is not an option for us so we are looking for a consultant.

-Ajay

Lloyd McKenzie (Dec 05 2020 at 02:34):

@Josh Mandel @Isaac Vetter

Josh Lamb (Dec 06 2020 at 00:57):

SMART on FHIR defines a few sequences that may be useful. It sounds like you are most interested in creating a patient context outside of an existing session (app_a has to deliver a token to app_b, that grants access to a single patient). Until the big guy gets here, I suggest checking out the launch/patient scope in the SMART on FHIR specification (http://www.hl7.org/fhir/smart-app-launch/scopes-and-launch-context/). When the launch/patient scope is fulfilled by a SMART Authorization Server the token payload will include a property called "patient", which will hold the value of the FHIR patient id.

Venu Gopal (Dec 06 2020 at 02:38):

@Ajay Prashar I did this using Okta, but it's very similar in Auth0 too. I am assuming WEBAPP_B (_B) is OIDC using Auth0 IdP.

1) You don't send any metadata from WEBAPP_A (_A)

2) You provide an option to login using _B in _A. The user when they use it is taken to the login page of _B and enters their credentials in _B

3) _B authenticates the user attaches all the authorization scopes, if you are using SMART on FHIR then they are like patient/Patient.read and so on.. and send the accessToken to redirectURL of _A

4) _A then uses it to grants access to FHIR resources on their side

5) If for some reason _B is not attaching the custom scopes, then _A should handle the authorization

Ajay Prashar (Dec 07 2020 at 15:25):

@Venu Gopal @josh lamb A big "Thank you" to you both as I appreciate your guidance in this area. My hope is that the devs on my side will, not only understand your guidance, but put into action in the form of a technology solution that impacts lives. We will be reviewing your comments in a meeting today.