Stream: Security and Privacy
Topic: best practices? app shares access token with aggregator
Isaac Vetter (Oct 28 2021 at 22:26):
I'm hoping to hear the community's perspective on the following scenario --
A SMART on FHIR app contracts with a 3rd party middleware vendor. The app passes it's access_token to the middleware which reads and writes to the resource server on its behalf. Please indicate in which scenarios you'd deem this appropriate:
Isaac Vetter (Oct 28 2021 at 22:27):
/poll the middleware is a library or compiled in SDK
Yes, that's okay
Isaac Vetter (Oct 28 2021 at 22:29):
/poll the app is patient facing and the patient agreed to the disclosure in the EULA
yes, okay
No, bad security
Isaac Vetter (Oct 28 2021 at 22:29):
/poll the app is operated by a covered entity and the CE signed a BAA with both parties
yes, okay
no, bad security
Isaac Vetter (Oct 28 2021 at 22:30):
/poll instead of acquiring then sharing the access token, the middleware performs the full auth code flow on behalf of the app
yes, okay
no, bad security
Grahame Grieve (Oct 28 2021 at 22:54):
@Isaac Vetter I'm not sure how to answer these. Who's the "CE"? What's the details of the contract between app vendor and middleware vendor? Who offered the app to the patient? What's do you mean by 'security'? (some of you options appear to provide good technical security - maybe - and you're asking about perceptions). in the last option, how does the app authz to the middleware?
Josh Mandel (Oct 28 2021 at 23:42):
I don't think the blanket terms "okay" and "bad" are meaningful here. Practices must be evaluated in the context of individual agency, informedness, understanding, expectations...
Jeffy Mathew Jose (Oct 29 2021 at 11:49):
In general, sharing of access_token is not a good security practice. The whole idea of OAuth and related specs builds on the idea of not sharing security tokens/secrets (which has caused issues). There are standards (or ideas in draft) for delegated access which can be better than blind sharing.
Having said that there may be cases where some business partnership nudges towards common access token b/w systems which need to be evaluated case by case. (those should be exceptional and rare)
Grahame Grieve (Oct 29 2021 at 11:57):
@Jeffy Mathew Jose you 'share' your token with your application libraries without even thinking about it. Why would splitting libraries into client and server module be any different? There's some reasons, yes, but not convincing ones - depends on how. I think the problem is in 'horizontal' sharing = between apps, rather than vertical sharing. but that also assumes a particular concept of 'between apps'
Vadim Peretokin (Oct 29 2021 at 12:31):
While there's always exceptions, it seems fine to give an opinion on the 'general case'.
Cooper Thompson (Oct 29 2021 at 13:06):
It seems fine to share an access token with a party that you explicitly trust for a specific purpose. But the "explicit trust" is the essential part.
Cooper Thompson (Oct 29 2021 at 13:06):
And should probably involve vetting, security review, etc.
John Moehrke (Oct 29 2021 at 14:03):
Grahame Grieve said:
Jeffy Mathew Jose you 'share' your token with your application libraries without even thinking about it. Why would splitting libraries into client and server module be any different? There's some reasons, yes, but not convincing ones - depends on how. I think the problem is in 'horizontal' sharing = between apps, rather than vertical sharing. but that also assumes a particular concept of 'between apps'
that is the last case we were asked about. The first cases didn't express a business relationship.
John Moehrke (Oct 29 2021 at 14:04):
These all seem to be asking for a legal opinion on a policy statement relative to HIPAA and other USA regulations.... I am not a lawyer
John Moehrke (Oct 29 2021 at 14:06):
As a security person, I would favor architectures that have a clear chain of trust. Implied trust (where the intermediary is allowed to hit the backend onbehalf of the app and user based solely on some unstated trust) are always problematic. But sometimes they can be build using good old legal contracts. But there needs to be a clear chain of trust.
John Moehrke (Oct 29 2021 at 14:07):
thus, the all could be acceptable... but generally only the last one is provable in technical terms.
Isaac Vetter (Oct 29 2021 at 18:35):
Thank you, guys. The real-world scenario is an intermediary (that perhaps aggregates) in front of a provider-facing app sold to health systems.
Isaac Vetter (Oct 29 2021 at 18:35):
To answer Grahame's questions explicitly:
-
Who's the "CE"?
** A healthcare delivery system in the US. -
What's the details of the contract between app vendor and middleware vendor?
** I don't know. Re: business contract -- the app vendor pays the middleware vendor. Re: technical contract -- I'm guessing that the middleware vendor provides a RESTful and messaging FHIR server that the app vendor entirely interacts with. And that they've established some type of tenant id to identify which health system is using the app. I don't know how the app authnz's to the middleware. -
Who offered the app to the patient?
** This was a made-up scenario, the straighforward case would be that the app developer offered the app (e.g. not a covered entity). -
What's do you mean by 'security'?
** I think security best practice or maybe technical acceptableness.
Last updated: Apr 12 2022 at 19:14 UTC
