> > 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= 40aol....@dmarc.ietf.org> 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 <leotoh...@gmail.com> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
