> On Jul 20, 2019, at 12:38 PM, Leo Tohill <leotoh...@gmail.com> wrote: > > Access tokens and refresh tokens, stored browser-side, are equally vulnerable > to theft, because the storage options are identical. > > We are more concerned about the theft of the refresh token, because it > (commonly) has a longer usable lifetime than the access token. > > Still , its a matter of degree. Since we accept the risk of access token > theft, why can't we accept the risk of refresh token theft? We ameliorate > the access token risk by using short lifetimes, but there is no standard for > that value: it is situational. Why doesn't the same reasoning apply to > refresh tokens? > > This reasoning assumes that refresh tokens also have a limited lifetime. I > am unsure that this is always the case. When one uses a refresh token to > acquire a new access token, AND that operation issues a new refresh token, > does the new refresh token get a new lifetime? If so, then a refresh token > can be used to retain access infinitely (or until it is revoked server-side). > In this scenario, the risks associated with browser-side storage of refresh > token are much higher. > > In summary, I'd say that IF the lifetime of a refresh token can be limited, > then refresh tokens pose identical risk as access tokens, and so the same > considerations apply.
Agreed I think there is an unwritten framework for evaluating the security of all tokens, regardless of type. For example: access tokens are shared with resources, so their security protections in the Security BCP including limiting replay against other resources, and optionally against new requests against the same resource. Because it is complex and unwritten, it is hard to do a true evaluation. My impression was always that refresh tokens were more ‘risky’ for public clients because “offline” refresh tokens may be good for an indeterminate period of time, and because lack of credentials means theft of the token is sufficient. In addition, a public client which does not use its refresh token in an “offline” manner may have theft go unnoticed for a considerable period of time, and the operational model of public clients usually puts detection of local token theft in the hand of the end user and client software, not an administrator or organizational security staff. But those concerns are mostly mitigated if the OP can set policy to control refresh token usage in concert with the authentication session. -DW _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
