Re: [OAUTH-WG] Refresh tokens

[Aaron Parecki <[e-mail]>]

>
> 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
@aaronpk <http://twitter.com/aaronpk>



On Tue, Jul 9, 2019 at 9:16 AM George Fletcher <gffletch=
[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]> 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 [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>