Stream: Security and Privacy
Topic: Advice on FHIR server authentication/authorization pattern
Jo-Jo Feng (Aug 25 2021 at 15:14):
(X-post from #implementers)
Hello everyone!
I work for a healthcare technology startup. We have embedded a FHIR server in what seems to be a fairly unusual backend architecture and I am seeking advice on how to manage authentication/authorization within this architecture.
We are currently building out a FHIR server as a backend microservice, which will be responsible for handling all transactions on our FHIR data. We have a separate microservice that serves as our core application backend (call it our "API server"), which is the server that our frontend clients make direct requests to. In our current conception, when a patient wants to query their data, the patient frontend clients make requests to the API server, which in turn makes requests to our FHIR server. We want to implement some sort of authentication pattern by which we can restrict access to our FHIR server. Based on my reading, it seems like the backend services authorization profile (https://hl7.org/fhir/uv/bulkdata/authorization/index.html) is most relevant to our architecture. For example, we can treat our API server as a pre-authorized client with global scopes to access/modify all data in the FHIR server, and then rely on existing access-control code in the API server to prevent patients from requesting/modifying data from the FHIR server that does not belong to them. This seems feasible, but in an ideal world, we would implement patient-level scopes for requests from the API server to the FHIR server, which we imagine would be more secure. That is, instead of issuing a client-level access token to the API server, we could issue multiple end-user-level access tokens to the API server. This model does not seem aligned to any of the FHIR auth profiles I have seen online, and would be a significant deviation from the backend services authorization profile.
I wonder if anyone has any insight into an authentication pattern that would be suitable in this scenario, or if I am missing something? We are trying to keep our FHIR server implementation as close to well-documented standards as possible. In general, I may be a little bit confused on whether there are existing, published standards to handle these "internal" auth scenarios, or if we should just follow guidelines set out in the HL7 security docs (https://www.hl7.org/fhir/security.html).
Please let me know if you have any questions, suggestions, or advice! This is my first time posting in this forum so forgive me if I'm posting in the wrong place :)
Thank you!
Jo-Jo Feng (Aug 25 2021 at 15:14):
I also wanted to add that, in the future, we would also likely want to allow some of our internal frontend clients to interact directly with the FHIR server (without the API server as an intermediate), in which case we will likely need to implement a different protocol to identify the party using the frontend client and provide access control depending on their identity. The SMART App Launch profiles seem like they could be relevant in this situation (it "connects third-party applications to Electronic Health Record data, allowing apps to launch from inside or outside the user interface of an EHR system"), but it doesn't seem to me that internally managed clients should fall under the umbrella of "third-party clients", in which case we might be able to do something else. Do you have any ideas as to how we could handle authentication/authorization in this case?
Last updated: Apr 12 2022 at 19:14 UTC
