It can be done but I believe you need an intervening actor , between the webapp and the Healthcare API, to mediate security.
Firebase auth will onboard the new user, and when they login, it will generate an ID token (JWT format), and return it to the webapp, or mobile app.
But that token won’t be something the Healthcare API will use directly to authenticate the request. Said another way: Supposing that your app then sent a request bearing that token directly to Healthcare API, Healthcare API wouldn’t be able to make an authorization decision based on that token.
This document (https://cloud.google.com/healthcare-api/docs/fhir-access-control) describes how to control access to FHIR resources in Healthcare API, using the X-Consent-Scope header, the permissions model built-in to Healthcare API, and a “smart proxy” or some other intervening actor between the user-facing app and Healthcare API. Note, there’s a bunch of setup you need to do in Healthcare API to make this possible.
Getting back to the “intervening actor”…That doc page says the role of the smart proxy is to:
- accept a request from a client containing an ID token.
- validate the token through a JWT authorization server (in your case, this would be the firebase auth JWKS endpoint).
- extract the claims in the token , and maps them, into a Scope statement,
- Send the request containing the Scope calculated above injected into the X-Consent-Scope header to Healthcare API on behalf of the app (aka “proxy the request to Healthcare API”)
- The Healthcare API receives the request with the header and validates it to enforce consent directives on the request. The Cloud Healthcare API then returns a response through the proxy to the client.
The proxy in this case would be a trusted delegate. It would need to authenticate to healthcare api as itself (via service account), and pass in the X-Cosnent-scope header which will be different for each different request.
The Scope assertion in the X-Consent-Scope header looks something like
actor/Patient/123 env/App/abc
There are two tricky parts. One is setting up the permissions model in FHIR API. The other is mapping the ID token to a consent Scope.
The first part is the “setup” I referred to above; the steps are described in that FHIR Access Control doc link I shared above. For the second, I think it is enough to use
actor/Patient/
as the scope, where the unique-id is known to the FHIR store (Healthcare API).
Using Firebase auth, a user signs in , and the app gets a standard ID token. There is no Scope in that token of the form required by Healthcare API. But there is a unique ID, in the sub claim. So for Step 3, above, you could have your intervening proxy just extract that sub claim and insert it into a Scope string like I showed above. And then follow with steps 4 and 5.
I haven’t done this. But this is what I would try. This assumes the sub used by firebase auth is the same “patient ID” used by FHIR API.
BTW it would be really simple to use Apigee as the smart proxy, to do the 5 steps above. Or you could write your own cloud function to do it, or use some other configurable proxy I guess.