Stream: cds hooks
Topic: SMART web messaging security
Josh Mandel (Sep 27 2019 at 17:42):
We've had a long-standing open issue about whether/how to address security in SMART Web Messaging. I've added https://github.com/smart-on-fhir/smart-web-messaging/pull/4/files?short_path=04c6e90#diff-04c6e90faac2675aa89e2176d2eec7d8to document one approach -- namely, defining a smart_web_messaging_token that acts like a limited-purpose access token (specifically designed to be safely movable into the browser environment, even for apps that keep their full access_tokens on a secure server; and conferring limited access only to web messaging APIs).
Would love thoughts on this, and alternatives we should consider.
Isaac Vetter (Sep 27 2019 at 17:57):
with the idea being that the smart_web_messaging_token isn't exactly authentication, but rather a convenient way for the container to correlate a recently established OAuth session/set of granted scopes with the embedded app?
Josh Mandel (Sep 27 2019 at 18:21):
That's correct. Correlation is exactly how I'd put it (correlating a specific browser window with the authorization context from the app launch).
Brendan Keeler (Oct 03 2019 at 14:32):
Line 199 is where my brain immediately jumps
Brendan Keeler (Oct 03 2019 at 14:33):
We now have a server auth token and a browser auth token, essentially. What makes the browser one more secure?
Josh Mandel (Oct 03 2019 at 14:54):
Nothing makes it more secure -- it just comes with limited permissions, so apps that don't otherwise need to push an access token into the browser don't have to.
Josh Mandel (Oct 03 2019 at 14:56):
The web messaging token is focused entirely on web messaging (i.e., helps the EHR correlate a given browser window with a session).
Isaac Vetter (Oct 04 2019 at 00:04):
Perhaps reusing the word "token" in a smart spec is a mistake. Inappropriate expectations and such. You really mean this to be a session id. Note that if you called it hub.topic, you'd potentially enable fhircast web messages.
Josh Mandel (Oct 04 2019 at 20:50):
We can name it whatever, if we like that idea of having it in the first place...( smart_web_messaging_handle maybe). The main question I have is whether people like this approach.
Brendan Keeler (Oct 08 2019 at 00:45):
I like it
Isaac Vetter (Oct 11 2019 at 16:23):
@Raj M - does WK have insight or feedback on this?
Raj M (Oct 11 2019 at 18:38):
we follow similar pattern internally between smart containers and apps running within the container. we call it appToken. I don't have any particular preference on the naming, smart_web_messaging_handle is good. one feedback we got from our security folks when we implemented it, is to have expiry logic (end of session) on the smart_web_messaging_handle which I guess is assumed but it will be good to elucidate that in the spec
Josh Mandel (Oct 14 2019 at 17:30):
Thanks @Raj M! I've updated the PR to include a quick description of expiration logic, and typing the handle to one window. (See here.)
Raj M (Oct 16 2019 at 14:24):
:+1:
Josh Mandel (Nov 07 2019 at 18:05):
Thanks to @Matt Randall for a good discussion on threat models + what we're trying to enable with a smart_web_messaging_handle. I've merged the PR defining this feature; let's plan to discuss here + in our argonaut calls before calling this a wrap.
Last updated: Apr 12 2022 at 19:14 UTC
