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. without providing specific values. Why can't we do the same for refresh tokens? On Sat, Jul 20, 2019 at 2:10 AM Neil Madden <neil.mad...@forgerock.com> wrote: > Can somebody spell out why refresh tokens require more protection than > access tokens? What threat are we worried about? > > The security benefits and risks of refresh tokens seem to be consistently > emphasised, yet nobody seems to ever spell out exactly what they are. > > The main benefit is allowing timely revocation without the RS having to > call a token introspection endpoint. That’s primarily an architectural > decision rather than a security one. > > — Neil > > On 20 Jul 2019, at 03:57, Justin Richer <jric...@mit.edu> wrote: > > I think it can be as simple as: > > SHOULD NOT use refresh tokens without client authentication or key proof > of some kind. > > In other words, no bearer refresh tokens. > > — Justin > > On Jul 19, 2019, at 7:49 PM, Aaron Parecki <aa...@parecki.com> wrote: > > So what I'm hearing in this thread is essentially that: > > 1) depending on how it's implemented, using a refresh token in a SPA can > provide security benefits over using only access tokens > 2) it is still "dangerous" to allow refresh tokens to be used without > client authentication > 3) if there is a way to do some sort of dynamic client registration or > proof of possession, then using a refresh token would in fact be more secure > > Since these points are in conflict with each other, and depend on things > currently in flux, it seems like the best thing to do at this time is to > remove the guidance on refresh tokens in browser-based apps. Maybe leaving > the mention of rotating the refresh token on every use, but I'm inclined to > remove the "SHOULD NOT issue refresh tokens" statement in order to leave > room for DPoP or similar in the future. > > Sound reasonable? > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk <http://twitter.com/aaronpk> > > > > On Thu, Jul 11, 2019 at 2:52 PM George Fletcher <gffle...@aol.com> wrote: > >> 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 >> @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 >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf..org/mailman/listinfo/oauth >> <https://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 > > _______________________________________________ > 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
