Stream: smart
Topic: Confidential client required for refresh tokens
Michael Donnelly (Nov 18 2020 at 17:00):
@Christopher Schaut pointed out something that's got me worried. Section 7.1.6 of SMART spec says
A server can decide which client types (public or confidential) are eligible for offline access and able to receive a refresh token.
The IFC says (on page 48)
we have specified that Health IT Modules’ authorization servers must issue a refresh token to native applications that are capable of securing a refresh token
Section 3.0.1 of the SMART spec defines confidential and public apps based on whether they can secure a client secret. But this IFC makes their definition on whether the application can secure a refresh token.
Jenni Syed (Nov 18 2020 at 17:04):
public and confidential are actually defined by the OAuth 2 specification, not SMART
Jenni Syed (Nov 18 2020 at 17:05):
the way an app "secures a refresh token" is indeed different than the OAuth 2 definition of public vs confidential
Jenni Syed (Nov 18 2020 at 17:06):
eg: if an application secures the refresh token on the device itself, and the refresh token never leaves the device - it's as secure s it can be for a public app
Josh Mandel (Nov 18 2020 at 17:06):
I don't think "securing a refresh token" is a well-defined concept, and I have been a bit frustrated to see this concept introduced in the interim final rule. I think we need to simplify the story rather than making it more complicated :-)
Jenni Syed (Nov 18 2020 at 17:06):
indeed, this would be a moving target of threat models and options, OS, and app :)
Jenni Syed (Nov 18 2020 at 17:16):
There's no way to "prove" an app in this ecosystem follows the guides by OAuth 2 - so this issue is just being made more out in the open by the language above. IE: I don't think all apps that had offline access were "confidential" (I know some were native)
Josh Mandel (Nov 18 2020 at 17:44):
100% agreed
Christopher Schaut (Nov 19 2020 at 16:03):
RFC 8252 discusses client impersonation
...the authorization server SHOULD NOT process authorization requests automatically without user consent or interaction, except when the identity of the client can be assured. This includes the case where the user has previously approved an authorization request for a given client id -- unless the identity of the client can be proven, the request SHOULD be processed as if no previous request had been approved.
Does this mean that we should update the SMART on FHIR spec to either require the app be a confidential app to process a refresh token, or stipulate some other form of client identity verification besides being a confidential app?
The section does also say that claimed https schemes may serve as identity verification, but I don't think that's helpful to the native app developers that pushed for the change in the IFC.
Michael Donnelly (Nov 30 2020 at 16:05):
Do we need to update the SMART spec? @Jenni Syed @Josh Mandel
Josh Mandel (Nov 30 2020 at 16:33):
The language you quoted above pertains to (auto-)approving authorization requests, not to exchanging an existing proof of authorization to obtain an access token. In other words, the quote above would be arguing against things like redirecting back to the app immediately from the server's "authorize" endpoint (without displaying an approval screen for the user). This consideration is distinct from what happens when you exchange an authorization code or a refresh token for an access token.
Josh Mandel (Nov 30 2020 at 16:35):
(to state this in a slightly different way, OAuth considers an "authorization request" to be the thing that happens when you redirect to an authorization server's authorized endpoint -- it's distinct from the thing that happens when a client calls the token endpoint with existing proof of authorization.)
Christopher Schaut (Nov 30 2020 at 17:59):
Thanks @Josh Mandel, I see what you're saying.
Going back to the OAuth2 spec, RFC 6749 section 10.1 says
The authorization server must consider the security implications of interacting with unauthenticated clients and take measures to limit the potential exposure of other credentials (e.g., refresh tokens) issued to such clients.
The authorization server MUST maintain the binding between a refresh token and the client to whom it was issued.
...
The authorization server MUST verify the binding between the refresh token and client identity whenever the client identity can be authenticated. When client authentication is not possible, the authorization server SHOULD deploy other means to detect refresh token abuse.
Considering the sensitivity of data we're handling, this seems to imply that within our SMART on FHIR spec we should satisfy this requirement. We should either require the client be confidential, or we should describe some alternative means, standard, or test that the authorization server can prove they can detect (and act on?) refresh token abuse. Of course, once there's refresh token abuse there is already a breach, so it begs the question of why we should permit a risk and require specific implementation of detection at all.
Do you think this should drive a change in the SMART spec?
Josh Mandel (Nov 30 2020 at 19:04):
I'm not sure what change we could
Josh Mandel (Nov 30 2020 at 19:05):
...add to improve this. My take is that pretending your app can keep a secret (when it can't) won't provide meaningful security improvements -- and forcing traffic through a centralized cloud endpoint just to have a "truly confidential" client misses the point, by spreading data across more places than it really needs to go.
Josh Mandel (Nov 30 2020 at 19:06):
If an individual user wants to share their data with a public client, this seems like a perfectly fair and reasonable thing to do. There's a whole set of tradeoffs involved.
Josh Mandel (Nov 30 2020 at 19:09):
In the long term I'd say: we could explore / experiment with approaches to dynamic client registration; if we like how it goes, we could augment SMART spec, or maybe this will land in UDAP.
Last updated: Apr 12 2022 at 19:14 UTC
