Stream: argonaut
Topic: Bullet points re: public apps etc
Josh Mandel (May 03 2021 at 17:44):
- Refresh tokens are important for providing a seamless consumer experience. If an app is ineligible for refresh tokens, the developer is likely to seek other means of achieving this (e.g., saving a user's password and simulating login; or moving to a cloud-based architecture even though there's no use case for managing data off-device).
Josh Mandel (May 03 2021 at 17:47):
- Client architectures that put data in the cloud (e.g., confidential apps) are open to certain attacks that purely-on-device apps are not subject to (e.g., cloud server becomes compromised and tokens/secrets leak). A breach in this context can be widespread, across many users.
Josh Mandel (May 03 2021 at 17:48):
- Public clients (including, e.g., most native apps today, where an app is only registered once with a given EHR) are open to certain attacks that confidential clients can avoid (e.g., a malicious app on your device might steal tokens from a valid app, or might impersonate a valid app). A breach in this context is more likely to be isolated to a given user or device.
Josh Mandel (May 03 2021 at 17:49):
--> The choice of app architecture should be based based on context. Apps that already need to manage data in the cloud should consider a confidential client architecture; apps that don't should consider a purely-on-device architecture.
Josh Mandel (May 03 2021 at 17:50):
But this decision only works if refresh tokns are available in either case; otherwise, app developers will switch architectures just to be able to maintain persistent access, even if the overall security posture is dimnished.
^^ Is this assessment worth capturing in a "best practices / considerations" page?
Brett Marquard (May 03 2021 at 17:50):
Don't worry, you didn't miss a meeting....Josh + I + Dan had a call to prepare for Friday call and thought why not post some thoughts to help generate discussion.
Cooper Thompson (May 03 2021 at 18:27):
What options exist that let an auth server verify that a client can secure a refresh token? Dynamic Client Registration I think is one option. Are there any others?
Cooper Thompson (May 03 2021 at 18:29):
Other than a simple self-attestation.
Josh Mandel (May 03 2021 at 18:30):
What options exist that let an auth server verify that a client can secure a refresh token? Dynamic Client Registration I think is one option. Are there any others?
I don't think dynamic client registration itself does this, right? If this is per-device, then the refresh token and the per-device client_secret can leak through the same channels.
Josh Mandel (May 03 2021 at 18:30):
I think attestation is a good practice from the "make sure everyone is thinking about this" perspective -- but it breaks down if apps that "admit" the truth aren't eligible for the access they need.
So: attestation with the right incentives seems like a good pattern.
Jenni Syed (May 07 2021 at 21:29):
(deleted)
Matt Randall (May 07 2021 at 21:38):
OAuth 2.1 provides mechanisms for public clients to protect refresh tokens. See [1] for details, but in summary cryptographic token binding is one mechanism, rotation of detection and replay of refresh tokens is another.
[1]: https://tools.ietf.org/html/draft-ietf-oauth-v2-1-02#section-6.1
Matt Randall (May 07 2021 at 21:39):
In particular, DPOP should be a readily-accessible method for most applications to perform such cryptographic binding. See https://tools.ietf.org/html/draft-ietf-oauth-dpop-02
Josh Mandel (May 07 2021 at 21:52):
And the recommendations for refresh token rotation are something servers can do in a way that's totally transparent for (non-malicious) clients.
Josh Mandel (May 07 2021 at 22:06):
The DPOP spec is really nice, but early. @Matt Randall do you think this will move ahead?
DPoP does not ensure the integrity of the payload or headers of requests. The DPoP proof only contains claims for the HTTP URI and method, but not, for example, the message body or general request headers.
This is an intentional design decision intended to keep DPoP simple to use,
That's a really good call. Still, this is a fair amount of new surface area.
Matt Randall (May 07 2021 at 22:57):
@Josh Mandel DPOP seems to have some weight behind it, I hadn't even realized I had linked to a previous version - draft 3 apparently was released last month, so it's definitely under active development.
Refresh token rotation seems fairly achievable without adding a 2nd draft spec into the mix, but has the negative side effect that if something goes awry in managing the state of that token on either side (client or authorization server), it could result in the user having to go back through the authorization flow.
DPOP on the other hand seems fairly robust and relatively straightforward for both client and server to implement, with the only drawback I see is that the crypto used to bind the refresh token initially won't last forever (after many years, whatever algorithm or key strength that was used would be considered defunct, likely requiring a revocation).
Matt Randall (May 07 2021 at 22:59):
To add my opinion, refresh rotation seems favorable initially, given that refresh rotation as a possibility is already covered in 2.0 [1].
[1] https://tools.ietf.org/html/rfc6749#section-10.4
Josh Mandel (May 07 2021 at 23:00):
I like that DPOP provides an answer to "how to mitigate the risk of tokens leaving a device". (We had discussed the idea of dynamic registration + asymmetric keys for otherwise public apps, which can also help in this situation; it's functionally pretty close, if you constrain the scope of "dynamic registration" to be "registering a local device instance associated with all the metadata about some already registered client")
Last updated: Apr 12 2022 at 19:14 UTC
