Re: [OAUTH-WG] Refresh tokens

[George Fletcher <[e-mail]>]

I'll just add a couple more thoughts around refresh_tokens.

1. I agree with David that refresh_tokens are valuable in an "online" 
scenario and should be used there.

2. To use a refresh token at the /token endpoint, client authentication 
is required. This is where it gets difficult for default SPAs because 
they are public clients and the only mechanism to authenticate them is 
the client_id which is itself public. For me, this is the real risk of 
exposing the refresh_token in the browser.

3. If the AS supports rotation of refresh_tokens and an attacker steals 
one and uses it, then the SPA will get an error on it's next attempt 
because it's refresh_token will now be invalid. If the refresh_tokens 
are bound to the user's authentication session, then the user can logout 
to lockout the attacker. However, that is a lot of "ifs" and still 
provides the attacker with time to leverage access via the compromised 
refresh_token.

In principle, I agree with the recommendation that SPAs shouldn't have 
refresh_tokens in the browser. If it's not possible to easily refresh 
the access token via a hidden iframe (becoming more difficult with all 
the browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to 
use a simple server component such that the backend for the SPA can use 
authorization_code flow and protect a client_secret.

Thanks,
George

On 7/8/19 11:17 PM, David Waite wrote:
>
>> On Jul 8, 2019, at 7:10 PM, Leo Tohill <[e-mail] 
>> <mailto:[e-mail]>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth