Re: [OAUTH-WG] Refresh tokens

[Neil Madden <[e-mail]>]

Thank you both for your replies, my responses are below:

On 20 Jul 2019, at 19:54, David Waite <[e-mail]> wrote:
> 
>> On Jul 20, 2019, at 12:38 PM, Leo Tohill <[e-mail]> 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.

Access tokens (without PoP) are also usable without credentials, so this is not a reason why refresh tokens are more risky. From the responses, it appears that token lifetime is the primary concern - access tokens usually have a limited lifespan but refresh tokens are unlimited. But there are very few threats that are eliminated by short token lifetimes. For example, when somebody goes for a coffee leaving their computer or phone unlocked. But even in these cases you are normally concerned with idle-timeouts rather than overall token lifetime. The token should become invalid after 3 minutes of inactivity, for example.

> 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.

Given that a refresh token has to be used at the AS, isn't the situation here *better* for refresh tokens? Every time an attacker uses a stolen refresh token you get a nice ping against your centralised token endpoint, giving you a great opportunity to run contextual checks to decide if something looks fishy. 

> 
> But those concerns are mostly mitigated if the OP can set policy to control refresh token usage in concert with the authentication session.

I'm not sure that OAuth should tie itself to a concept of authentication session. Would it be better to say that all tokens issued to browser-based clients should have a short idle timeout?

There's also a privacy aspect to linking refresh tokens to a user's authentication session, as it gives the 3rd-party client a way to detect when you are/are not logged into Facebook or whatever. That may be desirable in some cases, but not necessarily always. 

-- Neil