Re: [OAUTH-WG] Refresh tokens

[Leo Tohill]

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 
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  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  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 
>
>
>
> On Thu, Jul 11, 2019 at 2:52 PM George Fletcher  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 

Re: [OAUTH-WG] Refresh tokens

[David Waite]

> On Jul 20, 2019, at 12:38 PM, Leo Tohill  wrote:
> 
> 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. 

Agreed

I think there is an unwritten framework for evaluating the security of all 
tokens, regardless of type. For example: access tokens are shared with 
resources, so their security protections in the Security BCP including limiting 
replay against other resources, and optionally against new requests against the 
same resource.

Because it is complex and unwritten, it is hard to do a true evaluation. My 
impression was always that refresh tokens were more ‘risky’ for public clients 
because “offline” refresh tokens may be good for an indeterminate period of 
time, and because lack of credentials means theft of the token is sufficient.

In addition, a public client which does not use its refresh token in an 
“offline” manner may have theft go unnoticed for a considerable period of time, 
and the operational model of public clients usually puts detection of local 
token theft in the hand of the end user and client software, not an 
administrator or organizational security staff.

But those concerns are mostly mitigated if the OP can set policy to control 
refresh token usage in concert with the authentication session.

-DW
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh tokens

[Leo Tohill]

I did some looking around regarding the lifetime of refresh tokens in
various OP services.

Auth0 ,and google

do not appear to support a limited lifetime on refresh tokens.
AWS
supports
a lifetime, but with day granularity (minimum 1 day).  It does not issue a
new refresh token when one is redeemed.
IdentityServer
allows
a choice of behavior on refresh token expiration time.  It can have a
absolute expiration time, or use a sliding window.

I couldn't find anything in oauth or openid specs regarding refresh token
lifetime.

I'm thinking that our language might say that "if the OP supports refresh
token (absolute) lifetime, refresh tokens may be used (in the browser), but
should (must?) specify a expiration time."





On Sat, Jul 20, 2019 at 2:54 PM David Waite 
wrote:

>
>
> > On Jul 20, 2019, at 12:38 PM, Leo Tohill  wrote:
> >
> > 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.
>
> Agreed
>
> I think there is an unwritten framework for evaluating the security of all
> tokens, regardless of type. For example: access tokens are shared with
> resources, so their security protections in the Security BCP including
> limiting replay against other resources, and optionally against new
> requests against the same resource.
>
> Because it is complex and unwritten, it is hard to do a true evaluation.
> My impression was always that refresh tokens were more ‘risky’ for public
> clients because “offline” refresh tokens may be good for an indeterminate
> period of time, and because lack of credentials means theft of the token is
> sufficient.
>
> In addition, a public client which does not use its refresh token in an
> “offline” manner may have theft go unnoticed for a considerable period of
> time, and the operational model of public clients usually puts detection of
> local token theft in the hand of the end user and client software, not an
> administrator or organizational security staff.
>
> But those concerns are mostly mitigated if the OP can set policy to
> control refresh token usage in concert with the authentication session.
>
> -DW
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

[Benjamin Kaduk]

On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote:
> On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba  wrote:
> 
> > >> — Section 6 —
> > >> Should “TLS” here have a citation and normative reference?
> > >
> > > I didn't include an explicit reference here because TLS is transitively
> > referenced by other
> > > normative references (including 6749 of which this whole thing is an
> > extension) and TLS
> > > is pretty widely recognized even without citation.
> > ...
> > > I'm happy to add a citation here but it does raise the question of what
> > the most appropriate
> > > way to cite TLS is right now - 1.3, 1.2, or the BCP or some combination
> > thereof?
> >
> > I wondered the same thing, and you're also right that it might not
> > need a reference in this document.  I only even flagged it because
> > it's the subject of a MUST.  I'll leave it to the Sec ADs (who
> > obviously didn't flag it themselves, so maybe they agree that it's not
> > necessary).
> >
> 
> I'm gonna just leave it as-is then, unless I hear otherwise from the Sec
> ADs.

I'll throw it out there that "TLS" is marked as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt ...

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

[Benjamin Kaduk]

On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote:
> On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba  wrote:
> 
> >
> > >> — Section 1.1 —
> > >> Given the extensive discussion of impersonation here, what strikes me as
> > >> missing is pointing out that impersonation here is still controlled,
> > that “A is
> > >> B” but only to the extent that’s allowed by the token.  First, it might
> > be
> > >> limited by number of instances (one transaction only), by time of day
> > (only for
> > >> 10 minutes), and by scope (in regard to B’s address book, but not B’s
> > email).
> > >> Second, there is accountability: audit information still shows that the
> > token
> > >> authorized acting as B.  Is that not worth clarifying?
> > >
> > > My initial response was going to be "sure, I'll add some bits in sec 1.1
> > along those lines to clarify
> > > that." However, as I look again at that section for good opportunities
> > to make such additions, I feel
> > > like it is already said that impersonation is controlled.
> > ...
> > > So I think it already says that and I'm gonna have to flip it back and
> > ask if you have concrete
> > > suggestions for changes or additions that would say it more clearly or
> > more to your liking?
> >
> > It is mentioned, true, and that might be enough.  But given that Eve
> > also replied that she would like more here, let me suggest something,
> > the use of which is entirely optional -- take it, don't take it,
> > modify it, riff on it, ignore it completely, as you think best.  What
> > do you think about changing the last sentence of the paragraph?: "For
> > all intents and purposes, when A is impersonating B, A is B within the
> > rights context authorized by the token, which could be limited in
> > scope or time, or by a one-time-use restriction."
> >
> 
> Sure, I think that or some slight modification thereof can work just fine.
> I'll do that and get it and the rest of these changes published when the
> I-D submission embargo is lifted for Montreal.

My brain is apparntly storming and not sleeping.  Another option for
consideration, is to have two sentences:

For all intents and purposes, when A is impersonating B, A is B within the
rights context authorized by the token.  A's ability to impersonate B could
be limited in scope or time, or even with a one-time-use restriction,
whether via the contents of the token or an out-of-band mechanism.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth