> 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

Reply via email to