Stream: smart
Topic: access_token & id_token in the access token response
Sagar Shah (Oct 25 2020 at 13:49):
image.png
Above image is from the SMART simulated app example, where when we decode access_token value from the access token response, we also find id_token within the access_token. Is that a requirement of OIDC or SMART on FHIR? OR is that not really required? In many of the OIDC implementations, I have seen that base64 decoded access_token value has a "sub" field that generally represents the user identifier.
Josh Mandel (Oct 25 2020 at 18:59):
The access token format in smart is totally unspecified. Client applications should not rely on this as anything except an opaque value.
Josh Mandel (Oct 25 2020 at 19:00):
https://www.youtube.com/watch?v=X2lmbHAeOMg goes into some of the details here and talks a little bit about the design of our testing server, which stashes all kinds of information in the access token in order to remain stateless.
Sagar Shah (Oct 25 2020 at 22:38):
Thank you for clarifying. So considering that access token as an opaque value, client (3rd party App) is now able to hit API on behalf of patient or any provider user based on the scope available to the app, And all that access is made available or denied based on scope config and specific resource access. But where and how user permissions/access needs to be checked in this flow in an ideal scenario so that if the user himself does not have access to perform certain action, then the action gets denied
Josh Mandel (Oct 25 2020 at 23:04):
that is not something SMART tries to standardize, and indeed real-world policies can be incredibly complicated (e.g., to follow differing state regulations and so forth). SMART helps delegate a user's permissions to an app; but the user's permissions themselves must be defined and enforced by the system below this.
Sagar Shah (Oct 25 2020 at 23:18):
Thanks for clarifications on this, @Josh Mandel .
Last updated: Apr 12 2022 at 19:14 UTC
