Re: [OAUTH-WG] Refresh tokens

[George Fletcher <[e-mail]>]

You are correct that client authentication is not required for public 
clients (which doesn't preclude the use of refresh_tokens) but from my 
perspective it weakens the security because anyone with the 
refresh_token is able to get new access_tokens without any additional proof.

Now if the SPA performs some sort of Dynamic Client Registration or DPoP 
then I think it's a completely different scenario and it doesn't bother 
me as much for their to be refresh_tokens in the browser. This of course 
is just my perspective:)

On 7/10/19 7:56 PM, Aaron Parecki wrote:
>
>     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. 
>
>
> RFC6749 says "If the client type is confidential or??the client was 
> issued client credentials,??the client MUST authenticate..." which I 
> take to mean that refresh tokens could be used without a 
> client_secret, both for native an javascript apps.
>
> This discussion of offline vs online refresh tokens is interesting, 
> but I worry that we may be narrowing our focus here too much.
>
> There's a use where JavaScript apps may be able to take advantage of 
> offline access, which is around Service Workers. This allows a website 
> to install some code from a website which can continue to run in the 
> background, though sometimes only while triggered from external 
> events. One useful example of this is a syncing daemon, where a push 
> notification can be sent from a web server to a Service Worker, which 
> could cause that code in the browser to need to make a request to an 
> API, which then may need to be able to get a new access token, which 
> is effectively offline access.
>
> ----
> Aaron Parecki
> aaronparecki.com <http://aaronparecki.com>
> @aaronpk <http://twitter.com/aaronpk>
>
>
>
> On Tue, Jul 9, 2019 at 9:16 AM George Fletcher 
> <gffletch=[e-mail] <mailto:[e-mail]>> 
> wrote:
>
>     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]  <mailto:[e-mail]>
>>     https://www.ietf..org/mailman/listinfo/oauth  <https://www.ietf.org/mailman/listinfo/oauth>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth