These are all very good points! I think the challenge here is figuring out where this kind of guidance is most appropriate.
It does seem like some of these issues are unique to a browser environment (particularly where the browser itself is managing the access and refresh tokens), so maybe it makes the most sense to include this guidance in the browser based app BCP? If there are situations in which this advice is applicable in other scenarios in addition to browser apps, then I think it would make more sense to include it in the general OAuth security BCP. The Security BCP already has some language around refresh tokens, but I haven't reviewed it in a while to see if all of these points might be already covered there. If folks think the Browser BCP is the best place for this kind of thing I am definitely open to it, and I can work with David on the specific language to add. - Aaron On Mon, Jul 8, 2019 at 8:18 PM David Waite <da...@alkaline-solutions.com> wrote: > > On Jul 8, 2019, at 7:10 PM, Leo Tohill <leotoh...@gmail.com> wrote: > Re 8. Refresh Tokens > > "For public clients, the risk of a leaked refresh token is much > greater than leaked access tokens, since an attacker can potentially > continue using the stolen refresh token to obtain new access without > being detectable by the authorization server. " > > (first, note the typo "stoken".) > > Is it always "higher risk"? I could even argue that leakage of a refresh > token is lower risk. As a bearer document, a leaked access token allows > access to resources until it expires. A leaked refresh token, to be > useful, requires an exchange with the AS, and the AS would have the > opportunity to check whether the refresh token is still valid (has not been > revoked). (of course revocation might NOT have happened, but then again, > it might have.) > > > I agree (with caveats, of course). > > Access tokens and refresh tokens may or may not be attached (by policy) to > an authentication session lifetime. It is far easier to picture refresh > tokens which are not attached to an authentication session (sometimes > called ‘offline’ access) being inappropriate for a browser-based app, which > is nearly always a client that the resource owner is interacting with. > > Variants that may want offline tokens are less easy to imagine - perhaps > browser extensions? > > I believe the language currently there is due to AS implementations > predominantly treating refresh tokens as being for offline access, and > access token lifetime being short enough to not outlast an authentication > session. > > Furthermore, since the access token is transmitted to other servers, the > risk of exposure is greater, due to possible vulnerabilities in those > called systems (e.g., logs). Isn't this the reason that we have refresh > tokens? Don't refresh tokens exist because access tokens should have short > TTL, because they are widely distributed? > > > Yes. Once you acknowledge the existence of ‘online’ refresh tokens, they > become a strong security component: > > - Refresh tokens let you shorten the access token lifetime > - A shorter access token lifetime lets you have centralized policy to > invalidate access without needing to resort to token > introspection/revocation > - Token refresh can theoretically be used to represent other policy > changes by both the client (creating tokens targeting a new resource server > or with reduced scopes) and server (changing entitlements and > attributes/claims embedded within a structured token) > - Refresh tokens can be one-time-use, as recommenced by the security BCP. > A exfiltrated refresh token will result in either the attacker or the user > losing access on the next refresh, and a double refresh is a detectable > security event by the AS. > > "Additionally, browser-based applications provide many attack vectors by > which a refresh token can be leaked." > > The risks of leaking a refresh token from the browser are identical to the > risks of leaking an access token, right? This sentence could be changed to > "... by which *a token* can be leaked." > > A refresh token is "higher risk" because its TTL is usually greater than > the access token's TTL. But if our advice here leads to people using > longer-lived access tokens (because of the problems with getting a new > access token without involving the user), then the advice will be counter > productive. The longer life gives more time for the usefulness of a > browser-side theft, and more time for the usefulness of a server-side > theft. > > Which scenario is safer? > > A) using an access token with a 10 minute TTL, accompanied by a refresh > token with a 1 hour TTL > B) using an access token with a 1 hour TTL, and no refresh token. > > > > Given tokens that track authentication lifetime, it is hard to make a case > that refresh tokens which last for the authentication session are a greater > security risk than opaque access tokens (requiring token introspection) > that will last the same time. > > Typically an AS (or OP) would issue a structured access token with a > lifetime expected to expire before the authentication session, with new > tokens issued via requests made in an embedded, iframe (hidden, > prompt=none). There may be benefits here of user cookies (or perhaps > managed-device information) against an authorization endpoint being used to > make decisions that could not be made by a refresh against the token > endpoint. > > I’d be interested in hearing how strong of an implementation issue this > might be for deployments - I could see a non-security argument that the BCP > should only have one recommended approach here, and that there are > deployments needing the iframe approach. > > -DW > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- ---- Aaron Parecki aaronparecki.com @aaronpk <http://twitter.com/aaronpk>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
