Stream: smart
Topic: ONC preamble - security issue for token introspection?
Cooper Thompson (Jun 03 2021 at 14:56):
In the preamble for ONC's 21st Century Cures rule, there is this blurb:
Token introspection will allow implementers of § 170.315(g)(10)-certified
Health IT Modules to use API authorization servers and authorization tokens
with various resource servers. This functionality has the potential to
reduce complexity for implementers of § 170.315(g)(10)-certified
Health IT Modules authorizing access to several resource servers and
reduces the overall effort and subsequent use of § 170.315(g)(10)-certified
Health IT Modules consistent with the goals of section 4002 of the Cures Act
to enable the use of APIs without “special effort.” Although we do not
specify a standard for token introspection, we encourage industry to
coalesce around using a common standard,
like OAuth 2.0 Token Introspection (RFC 7662).
I think this proposed use of token introspection adds a security issue in the case where a system allowed delegated (proxy) access, unless the token introspection response includes the patient FHIR ID associated with the token (similar to how SMART prescribes sending back the patient ID in the oauth2/token response.
I think in order to get to ONC's goal here, we need to (conditionally) require the patient FHIR ID be returned in the introspect response.
The issue is: how does a 3rd party resource server determine what patient's data the access token grants access to? The patient FHIR ID is provided by the patient app to the resource server, alongside the access token issued by the certified API auth server. However, since the client-provided patient FHIR ID can't be trusted, the resource server needs to have some way to discover to which patient the access token grants access. Since RFC 7662 (and the current draft SMART introspect profile) only has the "sub" (which is the user, not the patient), doing introspect alone doesn't give the resource server a way to determine which patient data should be shared with the app.
Cooper Thompson (Jun 03 2021 at 14:56):
FHIR#32849 - but I'm interested if folks think I'm missing something and this isn't actually a problem.
Josh Mandel (Jun 03 2021 at 16:08):
We write in SMARTv2 spec, currently under ballot reconciliation:
SMART Launch Context. If a launch context parameter defined in Scopes and Launch Context (e.g., patient or intent) was included in the original access token response, the parameter SHALL be included in the token introspection response.
Josh Mandel (Jun 03 2021 at 16:09):
This is something we've tested at the past few connectathons; does this address the concern? (I can't see your Jira issue right now because Jira's down.)
Cooper Thompson (Jun 03 2021 at 17:50):
:face_palm: Yeah. It's right there in the build. Thanks for pointing that out. I withdrew the Jira.
Josh Mandel (Jun 03 2021 at 20:50):
Excellent -- I appreciate the attention to detail on this. It's a "small thing" from the spec perspective, but a critical detail if we want to unlock the flexibility ONC is referring to.
Last updated: Apr 12 2022 at 19:14 UTC
