Thank you both for your replies, my responses are below:
On 20 Jul 2019, at 19:54, David Waite <da...@alkaline-solutions.com> wrote:
>
>> 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.
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
