Stream: smart
Topic: Refresh token for online access
Sagar Shah (Dec 15 2020 at 00:21):
In what scenarios, clients need to ask for online_access scope? If user is online, what capability it gives to the client to get new token? Can't client generate new access token using authorization code workflow without requiring user to login (but just with session cookie). I am trying to understand use case behind it and see, if anyone already implemented this using any OIDC server? Any suggestions are appreciated!
Josh Mandel (Dec 15 2020 at 00:47):
Can't client generate new access token using authorization code workflow without requiring user to login (but just with session cookie).
In general this requires a user interaction. Some EHRs may be configured to allow it without clicks, but it still requires a pair of redirects and takes things out of an app's control. Using a refresh token is a better fit when the app can be authorized appropriately, since it allows a fully automated flow.
Sagar Shah (Dec 15 2020 at 12:57):
Appreciate your inputs! I understand the need but I see the limitations with at least the existing OIDC providers I have looked into.
- Keycloak - This does support refresh token that's by default linked to user session (that can support online_access) and when offline_access is requested, it can return the token that's generally persisted and can work longer. But it does not have a way to NOT pass refresh token if client does not have either of online_access or offline_access scope
2 ORY Hydra - This supports issuing refresh token only as long as offline_access scope is requested and does not support linking refresh token to user sessions on the ground that refresh token should NOT be confused with user sessions and should not have any link/association with user session.
So trying to understand best approach to resolve this.
Josh Mandel (Dec 15 2020 at 15:48):
This capability might not be the best fit for an authorization server that is highly decoupled from the EHR. I certainly wouldn't points to it as the low-hanging fruit for implantation :-)
Sagar Shah (Dec 22 2020 at 03:38):
However, if one is asked to implement an OIDC solution that complies with SMART on FHIR, is it not mandatory to support online_access scope (as per SMART on FHIR specs) that generates the refresh token tied to the user session, which is in general not suggested as per OIDC.
Specifically, I am referring to 21st century Cures Act, which requires Auth server for FHIR API access to be SMART on FHIR compliant, but that itself does not mention any criteria about online_access scope anywhere. So I am not certain if online access is a mandatory need or not?
Ref: https://www.ory.sh/hydra/docs/concepts/before-oauth2/#access-and-refresh-tokens-are-not-sessions
Please suggest your thoughts onto this.
Robert Scanlon (Dec 22 2020 at 15:04):
ONC's Standardized API Criteria requires implementation of all SMART Core Capabilities, and the online_access scope is not associated with any of those core capabilities. So for certification to that criteria (g10) using v1.0.0 of the SMART App Launch Framework, you do not need to demonstrate that functionality.
Robert Scanlon (Dec 22 2020 at 15:19):
That's the technical reason why there is not testing associated with offline_access online_access in the test procedure. But it also makes sense that online access isn't a requirement because it is more restrictive access-wise than offline access (it doesn't give apps more access than other available scopes), and it imposes tighter coupling between components within the 'ehr' which may be difficult for some health it developers to implement.
Josh Mandel (Dec 22 2020 at 15:22):
Re: offline, do you just test for refresh token capabilities without involving this scope?
Robert Scanlon (Dec 22 2020 at 15:23):
We only test using "offline_access" scope -- systems must support that scope specifically to get refresh tokens.
Robert Scanlon (Dec 22 2020 at 15:24):
Systems can support online_access additionally, of course. But they can't only support online_access and not offline_access.
Sagar Shah (Dec 22 2020 at 15:47):
Thank you for all the clarifications @Robert Scanlon and @Josh Mandel . That does make sense to me. We do plan to support offline_access scope in our auth server, which will be required by the clients, if they need refresh tokens.
Robert Scanlon (Dec 22 2020 at 17:59):
I just realized I bungled offline_access/online_access in my response a few messages back, which hopefully didn't cause too much confusion (see the strikeout/replacement). But based on your last message it seems like you were able to read through it. Sorry!
Jenni Syed (Jan 06 2021 at 20:39):
Ironically, all of our production provider apps today use online_access as the apps don't get data after the user closes the app :) We found it sad that ONC didn't mention it at all
Jenni Syed (Jan 06 2021 at 20:41):
Leaving a refresh token out and valid (esp for public apps) when an application doesn't need that type of access is an unfortunate security vulnerability
Jenni Syed (Jan 06 2021 at 20:42):
And the "one time use" (short term use) token isn't a great alternative for apps like that
Last updated: Apr 12 2022 at 19:14 UTC
