Re: [OAUTH-WG] Refresh tokens in Security BCP -15

[Daniel Fett]

Am 06.04.20 um 15:59 schrieb Aaron Parecki:
> Keeping the details in section 4 makes sense. I think why I was
> confused is that there isn't a subheader in section 2 for refresh
> tokens so it's not immediately obvious until you get to section 4.
> What about adding a new subhead in section 2 with just that short
> summary and referring to section 4 for details?

Sounds good to me. I will do that for the next version.

-Daniel

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

Re: [OAUTH-WG] Refresh tokens in Security BCP -15

[Aaron Parecki]

Keeping the details in section 4 makes sense. I think why I was confused is
that there isn't a subheader in section 2 for refresh tokens so it's not
immediately obvious until you get to section 4. What about adding a new
subhead in section 2 with just that short summary and referring to section
4 for details?

Aaron




On Mon, Apr 6, 2020 at 12:24 AM Daniel Fett  wrote:

> Hi Aaron,
>
> Am 05.04.20 um 21:24 schrieb Aaron Parecki:
>
> I believe the document would flow better if section 4.12 about Refresh
> Tokens were moved into section 2. The Refresh Token section contains
> descriptions of some pretty significant normative behavior, and I worry
> that it will get lost in the long list of attacks and mitigations.
>
> Section 2 starts with a description: "This section describes the set of
> security mechanisms the OAuth working group recommends to OAuth
> implementers.", and the whole section on refresh tokens seems like a pretty
> significant recommendation.
>
> So far the approach was to keep the recommendations in Section 2 rather
> brief and to have the details in Section 4. I would like to keep it that
> way.
>
> The Refresh Token section in Section 4 has a lot of discussion that puts
> the recommendations in context. Section 2 refers to that section with the
> sentence "Refresh tokens MUST be sender-constrained or use refresh token
> rotation as described in Section 4.12.". It catches the main normative
> change and refers Section 4 for details.
>
> I propose to just highlight that sentence a little bit more (make it its
> own paragraph).
>
> -Daniel
>
-- 

Aaron Parecki
aaronparecki.com
@aaronpk 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh tokens

[Aaron Parecki]

Ok thanks for the input here everyone. I'm not seeing much of a consensus,
but these are all excellent points and I've collected them for discussion
during the meeting on Friday.


Aaron Parecki
aaronparecki.com
@aaronpk 



On Mon, Jul 22, 2019 at 8:12 AM Torsten Lodderstedt 
wrote:

> Hi Neil,
>
> > On 22. Jul 2019, at 13:59, Neil Madden 
> wrote:
> >
> >> 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.
> >
> > Given that a refresh token has to be used at the AS, isn't the situation
> here *better* for refresh tokens? Every time an attacker uses a stolen
> refresh token you get a nice ping against your centralised token endpoint,
> giving you a great opportunity to run contextual checks to decide if
> something looks fishy.
>
> I agree with your assessment.
>
> That why the Security BCP (
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4...12)
> requires authorisation servers to detect refresh token replay. Even if the
> refresh token cannot be sender constraint, one-time refresh tokens (or
> refresh token rotation) is a viable option when used in combination with
> conditional revocation of the active refresh token if something looks fishy.
>
> kind regards,
> Torsten. ___
> 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

Re: [OAUTH-WG] Refresh tokens

[Torsten Lodderstedt]

Hi Neil,

> On 22. Jul 2019, at 13:59, Neil Madden  wrote:
> 
>> 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.
> 
> Given that a refresh token has to be used at the AS, isn't the situation here 
> *better* for refresh tokens? Every time an attacker uses a stolen refresh 
> token you get a nice ping against your centralised token endpoint, giving you 
> a great opportunity to run contextual checks to decide if something looks 
> fishy. 

I agree with your assessment. 

That why the Security BCP 
(https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4..12) 
requires authorisation servers to detect refresh token replay. Even if the 
refresh token cannot be sender constraint, one-time refresh tokens (or refresh 
token rotation) is a viable option when used in combination with conditional 
revocation of the active refresh token if something looks fishy.

kind regards,
Torsten. 

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh tokens

[Neil Madden]

Thank you both for your replies, my responses are below:

On 20 Jul 2019, at 19:54, 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.

Access tokens (without PoP) are also usable without credentials, so this is not 
a reason why refresh tokens are more risky. From the responses, it appears that 
token lifetime is the primary concern - access tokens usually have a limited 
lifespan but refresh tokens are unlimited. But there are very few threats that 
are eliminated by short token lifetimes. For example, when somebody goes for a 
coffee leaving their computer or phone unlocked. But even in these cases you 
are normally concerned with idle-timeouts rather than overall token lifetime. 
The token should become invalid after 3 minutes of inactivity, for example.

> 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.

Given that a refresh token has to be used at the AS, isn't the situation here 
*better* for refresh tokens? Every time an attacker uses a stolen refresh token 
you get a nice ping against your centralised token endpoint, giving you a great 
opportunity to run contextual checks to decide if something looks fishy. 

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

I'm not sure that OAuth should tie itself to a concept of authentication 
session. Would it be better to say that all tokens issued to browser-based 
clients should have a short idle timeout?

There's also a privacy aspect to linking refresh tokens to a user's 
authentication session, as it gives the 3rd-party client a way to detect when 
you are/are not logged into Facebook or whatever. That may be desirable in some 
cases, but not necessarily always. 

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

Re: [OAUTH-WG] Refresh tokens

[Tomek Stojecki]

> FWIW, in addition, those can be used together -- sliding & absolute. 

Azure AD does both at this point. They used to do 90 days absolute, now it is a 
sliding, 72 hours by default I believe. 

Good discussion overall, would this be a good summary for the type of a client 
the spec is for:

SHOULD NOT use refresh tokens unless the token endpoint mirrors user 
authentication or the OP supports expiration, rotation and revocation of 
refresh tokens

On Sunday, July 21, 2019, 04:45:07 PM GMT+2, Brock Allen  
wrote: 

> IdentityServer allows a choice of behavior on refresh token expiration time. 
>It can have a absolute expiration time, or use a sliding window.

FWIW, in addition, those can be used together -- sliding & absolute. Finally, 
refresh tokens can be re-use or one-time use only. These are all per-client 
settings.

-Brock


___
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

Re: [OAUTH-WG] Refresh tokens

[Leo Tohill]

I left out Okta
(how could
I?)  - it supports a refresh token expiration, but I couldn't find doc on
the details.


On Sun, Jul 21, 2019 at 10:44 AM Brock Allen  wrote:

> > IdentityServer allows a choice of behavior on refresh token expiration
> time. It can have a absolute expiration time, or use a sliding window.
>
> FWIW, in addition, those can be used together -- sliding & absolute.
> Finally, refresh tokens can be re-use or one-time use only. These are all
> per-client settings.
>
> -Brock
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh tokens

[Brock Allen]

> IdentityServer allows a choice of behavior on refresh token expiration time. 
>It can have a absolute expiration time, or use a sliding window.

FWIW, in addition, those can be used together -- sliding & absolute. Finally, 
refresh tokens can be re-use or one-time use only. These are all per-client 
settings.

-Brock
___
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] 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]

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

[Neil Madden]

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 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
 
 
 
> On Tue, Jul 9, 2019 at 9:16 AM George Fletcher 
>  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 

Re: [OAUTH-WG] Refresh tokens

[Justin Richer]

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 
mailto: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



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



On Tue, Jul 9, 2019 at 9:16 AM George Fletcher 
mailto: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 
mailto: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 

Re: [OAUTH-WG] Refresh tokens

[David Waite]

I believe that access tokens and any refresh token policy should be guided by 
the user authentication process and session lifetime policy of the AS.

There’s a case to be made that whether someone gets access to my access token 
directly or a refresh token that allows someone to grant a new access token, 
they have still gotten access to protected resources.

The case could be made that refresh tokens however are made more powerful by 
dynamic features:
- requesting an access token with additional scopes
- requesting an access token targeting a new audience/resource (via either 
scopes-as-resources, or directly with resource indicators)

However, the client has already been granted these scopes or resource access in 
this theoretical case, so I could just as easily attempt to gather such an 
access token through the authorization endpoint and code exchange.

So as general points of guidance, how about:
- Refresh tokens serve the same purpose as in general OAuth
- For applications which represent access as part of a user session, access and 
refresh tokens lifetimes and policy should mirror that session.
- Specifically, an AS should not grant “offline” refresh tokens meant to 
provide access for an unfixed/extended period of time, as the resource owner 
may expect other users of the browser would not get access to protected 
resources
- It is recommended that an AS requires refresh tokens grants to be 
authenticated to a client instance, be it via a unique client identity through 
DCR, or ephemerally through a proof-of-possession mechanism (token binding, 
mtls, dpop)
- Other security BCP stuff should apply.

-DW

> On Jul 19, 2019, at 5: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 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 
>> 
>> 
>> 
>> On Tue, Jul 9, 2019 at 9:16 AM George Fletcher 
>> mailto:40aol@dmarc.ietf.org>> wrote:
>> I'll 

Re: [OAUTH-WG] Refresh tokens

[Aaron Parecki]

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 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 
>
>
>
> On Tue, Jul 9, 2019 at 9:16 AM George Fletcher  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  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 

Re: [OAUTH-WG] Refresh tokens

[Aaron Parecki]

>
> 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 



On Tue, Jul 9, 2019 at 9:16 AM George Fletcher  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  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 

Re: [OAUTH-WG] Refresh tokens

[George Fletcher]

For historical references only... the Google model around refresh tokens 
and the AOL model around refresh tokens were slightly different. So I 
proposed a bunch of the OIDC text around refresh tokens and offline 
access to allow for both models.


At AOL, the model was that refresh_tokens were bound to the 
authentication session by default. The only way to get an "unbound" 
refresh_token was to request the 'offline_access' scope. We restricted 
which clients could request the 'offline_access' scope and limited it 
mostly to native apps.


I'm happy to recommend errata text (as long as it's just explanatory) to 
the OIDC spec should someone have a recommendation they'd like to make:)


On 7/9/19 2:08 AM, David Waite wrote:



On Jul 8, 2019, at 8:39 PM, Aaron Parecki > wrote:


These are all very good points! I think the challenge here is 
figuring out where this kind of guidance is most appropriate.


It does seem like some of these issues are unique to a browser 
environment (particularly where the browser itself is managing the 
access and refresh tokens), so maybe it makes the most sense to 
include this guidance in the browser based app BCP?


Yes, the location is a challenge - the ???offline??? distinction is 
defined (arguably under-defined) by OpenID Connect. OAuth (on the 
other hand) does not take a stand on user authentication sessions, 
since the tokens are for delegated access.


For confidential clients, both online and offline options make sense. 
For native apps, the push is usually for long-term access or for a 
session separate from the external user agent. But for browser apps, 
you typically want to mirror user authentication.


If there are situations in which this advice is applicable in other 
scenarios in addition to browser apps, then I think it would make 
more sense to include it in the general OAuth security BCP.


The Security BCP already has some language around refresh tokens, but 
I haven't reviewed it in a while to see if all of these points might 
be already covered there.


If folks think the Browser BCP is the best place for this kind of 
thing I am definitely open to it, and I can work with David on the 
specific language to add.


- Aaron


-DW

___
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

Re: [OAUTH-WG] Refresh tokens

[George Fletcher]

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 > 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 

Re: [OAUTH-WG] Refresh tokens

[David Waite]

> On Jul 8, 2019, at 8:39 PM, Aaron Parecki  wrote:
> 
> These are all very good points! I think the challenge here is figuring out 
> where this kind of guidance is most appropriate.
> 
> It does seem like some of these issues are unique to a browser environment 
> (particularly where the browser itself is managing the access and refresh 
> tokens), so maybe it makes the most sense to include this guidance in the 
> browser based app BCP?

Yes, the location is a challenge - the “offline” distinction is defined 
(arguably under-defined) by OpenID Connect. OAuth (on the other hand) does not 
take a stand on user authentication sessions, since the tokens are for 
delegated access.

For confidential clients, both online and offline options make sense. For 
native apps, the push is usually for long-term access or for a session separate 
from the external user agent. But for browser apps, you typically want to 
mirror user authentication.
 
> If there are situations in which this advice is applicable in other scenarios 
> in addition to browser apps, then I think it would make more sense to include 
> it in the general OAuth security BCP.
> 
> The Security BCP already has some language around refresh tokens, but I 
> haven't reviewed it in a while to see if all of these points might be already 
> covered there.
> 
> If folks think the Browser BCP is the best place for this kind of thing I am 
> definitely open to it, and I can work with David on the specific language to 
> add.
> 
> - Aaron

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

Re: [OAUTH-WG] Refresh tokens

[Aaron Parecki]

These are all very good points! I think the challenge here is figuring out
where this kind of guidance is most appropriate.

It does seem like some of these issues are unique to a browser environment
(particularly where the browser itself is managing the access and refresh
tokens), so maybe it makes the most sense to include this guidance in the
browser based app BCP?

If there are situations in which this advice is applicable in other
scenarios in addition to browser apps, then I think it would make more
sense to include it in the general OAuth security BCP.

The Security BCP already has some language around refresh tokens, but I
haven't reviewed it in a while to see if all of these points might be
already covered there.

If folks think the Browser BCP is the best place for this kind of thing I
am definitely open to it, and I can work with David on the specific
language to add.

- Aaron



On Mon, Jul 8, 2019 at 8:18 PM David Waite 
wrote:

>
> On Jul 8, 2019, at 7:10 PM, Leo Tohill  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.
>
> 

Re: [OAUTH-WG] Refresh tokens

[David Waite]

> On Jul 8, 2019, at 7:10 PM, Leo Tohill  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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] refresh tokens and client instances

[Sergey Beryozkin]

mailto:m.nakhj...@samsung.com

mailto:m.nakhj...@samsung.com mailto:m.nakhj...@samsung.com wrote:


Hi John,
Thank you for your reply. Would appreciate if you consider my inline
comments below and respond again!
R,
Madjid
*From:*John Bradley [mailto:ve7...@ve7jtb.com

mailto:ve7...@ve7jtb.com]

*Sent:*Wednesday, June 25, 2014 5:56 PM
*To:*Madjid Nakhjiri
*Cc:*oauth@ietf.org mailto:oauth@ietf.org mailto:oauth@ietf.org

mailto:oauth@ietf.org

*Subject:*Re: [OAUTH-WG] refresh tokens and client instances
In 3.3 It is saying that the refresh token is a secret that the
Authorization server has bound to the client_id, that the
Authorization server effectively uses to differentiate between
instances of that client_id.
MadjidIf I have 10,000s of devices, each with an instance of the
OAUTH client, but they are all using the same client ID, how would the
server know which token to use for what client? unless when I am
creating a token, I also include something that uniquely identifies
each instance? Don’t I have to use SOMETHING that is unique to that
instance (user grant/ID?)?

When the grant is issued you create and store a refresh token which is
effectively the identifier for that instance/grant combination.
When it comes back on a request to the token endpoint you look up the
grants associated with it.  You also hack that the client_id sent in
the request matches to detect errors mostly)


When the refresh token is generated, it can be stored in a table with
the client_id and the information about the grant.  You could also do
it statelesly by creating a signed object as the refresh token.
Madjidagreed, but for the signed object to be self-sustained, again
would I not need something beyond a “population” client_ID? Are we
prescriptive what “information about the grant” is?

You would be creating a bearer token as long as the AS signs it you can
put whatever grant grant info you like in it, that is implementation
specific.  It  could be a list of the scopes granted and the subject.

The spec is silent on the exact programming method that the
Authorization server uses.
MadjidAre there any other specs in IETF or elsewhere (OASIS, etc?)
that prescribe token calculation (e.g. hash function, parameters, etc)?


You can look at JOSE and JWT for a way to create tokens
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token

In 3.7 Deployment independent describes using the same client_id
across multiple instances of a native client, or multiple instances of
a Java Script client running in a browsers with the same callback uri.
Since the publishing of this RFC we have also developed a spec for
dynamic client registration so it is possible to give every native
client it's own client_id and secret making them confidential clients.
MadjidI would need to look at those specs, however, I thought that
the “confidential client” designation has to do with the client
ability to hold secrets and perform a-by-server-acceptable
authentication. Does dynamic client registration affect client’s
ability in that aspect?


Yes it doesn't require the secret to be in the downloaded instance of
the native app.  It can be populated at first run, changing it from
public to confidential.
Confidential is not just for web servers any more.

There is also a middle ground some people take by doing a proof of
possession for code in native applications to prevent the interception
of responses to the client by malicious applications on the device.
https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
John B.
On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri m.nakhj...@samsung.com

mailto:m.nakhj...@samsung.com

mailto:m.nakhj...@samsung.com mailto:m.nakhj...@samsung.com wrote:


Hi all,
I am new to OAUTH list and OAUTH, so apologies if this is very

off-topic.

I am evaluating an OAUTH 2.0 implementation that is done based on bare
bone base OAUTH2.0 RFC. From what I understand, many (or some) client
implementations use a “global ID/secret” pair for all instances of the
client.  Looking at RFC 6819 and there seem to be a whole page on this
topic, if I understand it correctly. So questions:
1)Section 3.7 talks about deployment-independent versus deployment
specific client IDs. I am guessing “deployment-independent” refers to
what I called “global”, meaning if I have the same client with the
same client ID installed in many end devices, that is a deployment
independent case, correct?
2)Section 3.3 on refresh token mentions that the token is secret bound
to the client ID and client instance. Could somebody please point me
to where the token generation and binding is described? Also how is
the client instance is identified?
Thanks a lot in advance,
Madjid Nakhjiri
___
OAuth mailing list
OAuth@ietf.org mailto:OAuth@ietf.org mailto:OAuth@ietf.org

mailto:OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






___
OAuth mailing list
OAuth@ietf.org mailto:OAuth

Re: [OAUTH-WG] refresh tokens and client instances

[John Bradley]

 instances.
 
 AFAIK refresh tokens would only go on the wire, assuming they are
 supported, when a client exchanges a grant for a new access token.
 And when the client uses a refresh token grant.
 
 Was it really about a refresh token grant where the incoming client id
 and refresh token pair can uniquely identify the actual client instance
 ? That would make sense.
 
 Something else I'd like to clarify.
 John mentions a refresh token is created at the authorization grant
 initialization time. Would it make any difference, as far as the
 security properties of a grant are concerned, if refresh token was only
 created at a grant to access token exchange point of time ?
 
 Thanks, Sergey
 
 On 27/06/14 19:21, John Bradley wrote:
 Inline
 
 On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri m.nakhj...@samsung.com
 mailto:m.nakhj...@samsung.com
 mailto:m.nakhj...@samsung.com mailto:m.nakhj...@samsung.com wrote:
 
 Hi John,
 Thank you for your reply. Would appreciate if you consider my inline
 comments below and respond again!
 R,
 Madjid
 *From:*John Bradley [mailto:ve7...@ve7jtb.com
 mailto:ve7...@ve7jtb.com]
 *Sent:*Wednesday, June 25, 2014 5:56 PM
 *To:*Madjid Nakhjiri
 *Cc:*oauth@ietf.org mailto:oauth@ietf.org mailto:oauth@ietf.org
 mailto:oauth@ietf.org
 *Subject:*Re: [OAUTH-WG] refresh tokens and client instances
 In 3.3 It is saying that the refresh token is a secret that the
 Authorization server has bound to the client_id, that the
 Authorization server effectively uses to differentiate between
 instances of that client_id.
 MadjidIf I have 10,000s of devices, each with an instance of the
 OAUTH client, but they are all using the same client ID, how would the
 server know which token to use for what client? unless when I am
 creating a token, I also include something that uniquely identifies
 each instance? Don’t I have to use SOMETHING that is unique to that
 instance (user grant/ID?)?
 When the grant is issued you create and store a refresh token which is
 effectively the identifier for that instance/grant combination.
 When it comes back on a request to the token endpoint you look up the
 grants associated with it.  You also hack that the client_id sent in
 the request matches to detect errors mostly)
 
 When the refresh token is generated, it can be stored in a table with
 the client_id and the information about the grant.  You could also do
 it statelesly by creating a signed object as the refresh token.
 Madjidagreed, but for the signed object to be self-sustained, again
 would I not need something beyond a “population” client_ID? Are we
 prescriptive what “information about the grant” is?
 You would be creating a bearer token as long as the AS signs it you can
 put whatever grant grant info you like in it, that is implementation
 specific.  It  could be a list of the scopes granted and the subject.
 The spec is silent on the exact programming method that the
 Authorization server uses.
 MadjidAre there any other specs in IETF or elsewhere (OASIS, etc?)
 that prescribe token calculation (e.g. hash function, parameters, etc)?
 
 You can look at JOSE and JWT for a way to create tokens
 http://tools.ietf.org/html/draft-ietf-oauth-json-web-token
 In 3.7 Deployment independent describes using the same client_id
 across multiple instances of a native client, or multiple instances of
 a Java Script client running in a browsers with the same callback uri.
 Since the publishing of this RFC we have also developed a spec for
 dynamic client registration so it is possible to give every native
 client it's own client_id and secret making them confidential clients.
 MadjidI would need to look at those specs, however, I thought that
 the “confidential client” designation has to do with the client
 ability to hold secrets and perform a-by-server-acceptable
 authentication. Does dynamic client registration affect client’s
 ability in that aspect?
 
 Yes it doesn't require the secret to be in the downloaded instance of
 the native app.  It can be populated at first run, changing it from
 public to confidential.
 Confidential is not just for web servers any more.
 There is also a middle ground some people take by doing a proof of
 possession for code in native applications to prevent the interception
 of responses to the client by malicious applications on the device.
 https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
 John B.
 On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri m.nakhj...@samsung.com
 mailto:m.nakhj...@samsung.com
 mailto:m.nakhj...@samsung.com mailto:m.nakhj...@samsung.com wrote:
 
 
 Hi all,
 I am new to OAUTH list and OAUTH, so apologies if this is very
 off-topic.
 I am evaluating an OAUTH 2.0 implementation that is done based on bare
 bone base OAUTH2.0 RFC. From what I understand, many (or some) client
 implementations use a “global ID/secret” pair for all instances of the
 client.  Looking at RFC 6819 and there seem to be a whole page on this
 topic, if I understand it correctly. So

Re: [OAUTH-WG] refresh tokens and client instances

[Madjid Nakhjiri]

Hi Sergey,

Thanks for capturing the question. Yes, the issue was how we distinguish 
between different instances of client, all using the same client ID. From 
answers I have gotten so far, it seems that the uniqueness of the instance may 
be provided through the uniqueness of a code grant. However, I have not figure 
out what the spec says on how to create the grant and how the grant code is 
unique to authorization server. If anybody could point me to that part of spec, 
I would appreciate it (I did not find it). 

Your description of a user authorizes a given device and gets a grant code and 
enters it into device securely we have a client instance... would require a 
device identifier, otherwise how does the fact that the client is on a 
different device identifies that instance as a unique instance?

I need to look at the spec for refresh versus access tokens. Do you need 
different grant code types for each type of token?

Thanks,
Madjid
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Sergey Beryozkin
Sent: Thursday, July 03, 2014 9:29 AM
To: Bill Mills; oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens and client instances

Hi
On 03/07/14 16:40, Bill Mills wrote:
 Implementations may/SHOULD bind refresh tokens to specific client 
 instances.  Yes, it's possible that the client ID with dynamic 
 registration is unique to each client, but many of the token theft use 
 cases include the possibility of stealing the client ID too if you 
 know you need to.

What exactly is a 'client instance' when we talk about having a single client 
id registration, with the id shared between multiple devices (which is what I 
believe this thread started from).

What I understood, as far as the authorization service is concerned, a 'client 
instance' for AS is a combination of a client id + code grant.

+ (optional) refresh token (as was mentioned earlier). But it appears to
me a client instance can be uniquely identified by two values only without a 
refresh token.

When a user authorizes a given device and gets a grant code and enters it into 
the device securely we have a 'client instance' ready to get the tokens, with 
that device (client instance) using a client id and the grant code to get an 
access token and a refresh token.

Lets say it sends a client_id=1code=2 sequence to get the tokens.
A client id + a code value constitutes a client instance, because a code would 
be unique per every authorization, right ?

So the service will return an access token + refresh token to the device. 
Refresh Token could've been associated with a record containing a client id + 
grant code info earlier or at the moment the code is exchanged for an access 
token.

During the subsequent refresh token grant request we have client id + refresh 
token as a client instance.

I'm not sure what exactly I'd like to ask here :-), but I wonder if the above 
sounds right, then I guess I'd like to conclude that when we talk about the 
authorization code grant then a refresh token is not the only key that uniquely 
identifies a client instance:

Initially it is a client id + code grant, a refresh token does not offer an 
extra uniqueness at the point of the client device requesting an access token 
with a code. Refresh token only starts acting as the key client instance 
identifier at a refresh token grant time.

Sorry for a long email, I'm very likely missing something, so any 
clarifications will be welcome

Thanks, Sergey







 -bill


 On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin 
 sberyoz...@gmail.com wrote:


 Hi

 I'm finding the answers from John interesting but I'm failing to 
 understand why refresh tokens are mentioned in scope of identifying 
 the specific client instances.

 AFAIK refresh tokens would only go on the wire, assuming they are 
 supported, when a client exchanges a grant for a new access token.
 And when the client uses a refresh token grant.

 Was it really about a refresh token grant where the incoming client id 
 and refresh token pair can uniquely identify the actual client 
 instance ? That would make sense.

 Something else I'd like to clarify.
 John mentions a refresh token is created at the authorization grant 
 initialization time. Would it make any difference, as far as the 
 security properties of a grant are concerned, if refresh token was 
 only created at a grant to access token exchange point of time ?

 Thanks, Sergey

 On 27/06/14 19:21, John Bradley wrote:
   Inline
  
   On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri 
 m.nakhj...@samsung.com mailto:m.nakhj...@samsung.com   
 mailto:m.nakhj...@samsung.com mailto:m.nakhj...@samsung.com wrote:
  
   Hi John,
   Thank you for your reply. Would appreciate if you consider my 
 inline   comments below and respond again!
   R,
   Madjid
   *From:*John Bradley [mailto:ve7...@ve7jtb.com 
 mailto:ve7...@ve7jtb.com]   *Sent:*Wednesday, June 25, 2014 5:56 
 PM   *To:*Madjid Nakhjiri   *Cc:*oauth@ietf.org

Re: [OAUTH-WG] refresh tokens and client instances

[Bill Mills]

 at a refresh token grant time.
 
 Sorry for a long email, I'm very likely missing something, so any 
 clarifications will be welcome
 
 Thanks, Sergey
 
 
 
 
 
 
 
 -bill
 
 
 On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin
 sberyoz...@gmail.com wrote:
 
 
 Hi
 
 I'm finding the answers from John interesting but I'm failing to
 understand why refresh tokens are mentioned in scope of identifying the
 specific client instances.
 
 AFAIK refresh tokens would only go on the wire, assuming they are
 supported, when a client exchanges a grant for a new access token.
 And when the client uses a refresh token grant.
 
 Was it really about a refresh token grant where the incoming client id
 and refresh token pair can uniquely identify the actual client instance
 ? That would make sense.
 
 Something else I'd like to clarify.
 John mentions a refresh token is created at the authorization grant
 initialization time. Would it make any difference, as far as the
 security properties of a grant are concerned, if refresh token was only
 created at a grant to access token exchange point of time ?
 
 Thanks, Sergey
 
 On 27/06/14 19:21, John Bradley wrote:
 Inline
 
 On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri m.nakhj...@samsung.com
 mailto:m.nakhj...@samsung.com
 mailto:m.nakhj...@samsung.com mailto:m.nakhj...@samsung.com wrote:
 
 Hi John,
 Thank you for your reply. Would appreciate if you consider my inline
 comments below and respond again!
 R,
 Madjid
 *From:*John Bradley [mailto:ve7...@ve7jtb.com
 mailto:ve7...@ve7jtb.com]
 *Sent:*Wednesday, June 25, 2014 5:56 PM
 *To:*Madjid Nakhjiri
 *Cc:*oauth@ietf.org mailto:oauth@ietf.org mailto:oauth@ietf.org
 mailto:oauth@ietf.org
 *Subject:*Re: [OAUTH-WG] refresh tokens and client instances
 In 3.3 It is saying that the refresh token is a secret that the
 Authorization server has bound to the client_id, that the
 Authorization server effectively uses to differentiate between
 instances of that client_id.
 MadjidIf I have 10,000s of devices, each with an instance of the
 OAUTH client, but they are all using the same client ID, how would the
 server know which token to use for what client? unless when I am
 creating a token, I also include something that uniquely identifies
 each instance? Don’t I have to use SOMETHING that is unique to that
 instance (user grant/ID?)?
 When the grant is issued you create and store a refresh token which is
 effectively the identifier for that instance/grant combination.
 When it comes back on a request to the token endpoint you look up the
 grants associated with it.  You also hack that the client_id sent in
 the request matches to detect errors mostly)
 
 When the refresh token is generated, it can be stored in a table with
 the client_id and the information about the grant.  You could also do
 it statelesly by creating a signed object as the refresh token.
 Madjidagreed, but for the signed object to be self-sustained, again
 would I not need something beyond a “population” client_ID? Are we
 prescriptive what “information about the grant” is?
 You would be creating a bearer token as long as the AS signs it you can
 put whatever grant grant info you like in it, that is implementation
 specific.  It  could be a list of the scopes granted and the subject.
 The spec is silent on the exact programming method that the
 Authorization server uses.
 MadjidAre there any other specs in IETF or elsewhere (OASIS, etc?)
 that prescribe token calculation (e.g. hash function, parameters, etc)?
 
 You can look at JOSE and JWT for a way to create tokens
 http://tools.ietf.org/html/draft-ietf-oauth-json-web-token
 In 3.7 Deployment independent describes using the same client_id
 across multiple instances of a native client, or multiple instances of
 a Java Script client running in a browsers with the same callback uri.
 Since the publishing of this RFC we have also developed a spec for
 dynamic client registration so it is possible to give every native
 client it's own client_id and secret making them confidential clients.
 MadjidI would need to look at those specs, however, I thought that
 the “confidential client” designation has to do with the client
 ability to hold secrets and perform a-by-server-acceptable
 authentication. Does dynamic client registration affect client’s
 ability in that aspect?
 
 Yes it doesn't require the secret to be in the downloaded instance of
 the native app.  It can be populated at first run, changing it from
 public to confidential.
 Confidential is not just for web servers any more.
 There is also a middle ground some people take by doing a proof of
 possession for code in native applications to prevent the interception
 of responses to the client by malicious applications on the device.
 https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
 John B.
 On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri m.nakhj...@samsung.com
 mailto:m.nakhj...@samsung.com
 mailto:m.nakhj...@samsung.com mailto:m.nakhj...@samsung.com wrote

Re: [OAUTH-WG] refresh tokens and client instances

[Sergey Beryozkin]

 
clarifications will be welcome

Thanks, Sergey








-bill


On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin
sberyoz...@gmail.com wrote:


Hi

I'm finding the answers from John interesting but I'm failing to
understand why refresh tokens are mentioned in scope of identifying the
specific client instances.

AFAIK refresh tokens would only go on the wire, assuming they are
supported, when a client exchanges a grant for a new access token.
And when the client uses a refresh token grant.

Was it really about a refresh token grant where the incoming client id
and refresh token pair can uniquely identify the actual client instance
? That would make sense.

Something else I'd like to clarify.
John mentions a refresh token is created at the authorization grant
initialization time. Would it make any difference, as far as the
security properties of a grant are concerned, if refresh token was only
created at a grant to access token exchange point of time ?

Thanks, Sergey

On 27/06/14 19:21, John Bradley wrote:

Inline

On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri m.nakhj...@samsung.com

mailto:m.nakhj...@samsung.com

mailto:m.nakhj...@samsung.com mailto:m.nakhj...@samsung.com wrote:


Hi John,
Thank you for your reply. Would appreciate if you consider my inline
comments below and respond again!
R,
Madjid
*From:*John Bradley [mailto:ve7...@ve7jtb.com

mailto:ve7...@ve7jtb.com]

*Sent:*Wednesday, June 25, 2014 5:56 PM
*To:*Madjid Nakhjiri
*Cc:*oauth@ietf.org mailto:oauth@ietf.org mailto:oauth@ietf.org

mailto:oauth@ietf.org

*Subject:*Re: [OAUTH-WG] refresh tokens and client instances
In 3.3 It is saying that the refresh token is a secret that the
Authorization server has bound to the client_id, that the
Authorization server effectively uses to differentiate between
instances of that client_id.
MadjidIf I have 10,000s of devices, each with an instance of the
OAUTH client, but they are all using the same client ID, how would the
server know which token to use for what client? unless when I am
creating a token, I also include something that uniquely identifies
each instance? Don’t I have to use SOMETHING that is unique to that
instance (user grant/ID?)?

When the grant is issued you create and store a refresh token which is
effectively the identifier for that instance/grant combination.
When it comes back on a request to the token endpoint you look up the
grants associated with it.  You also hack that the client_id sent in
the request matches to detect errors mostly)


When the refresh token is generated, it can be stored in a table with
the client_id and the information about the grant.  You could also do
it statelesly by creating a signed object as the refresh token.
Madjidagreed, but for the signed object to be self-sustained, again
would I not need something beyond a “population” client_ID? Are we
prescriptive what “information about the grant” is?

You would be creating a bearer token as long as the AS signs it you can
put whatever grant grant info you like in it, that is implementation
specific.  It  could be a list of the scopes granted and the subject.

The spec is silent on the exact programming method that the
Authorization server uses.
MadjidAre there any other specs in IETF or elsewhere (OASIS, etc?)
that prescribe token calculation (e.g. hash function, parameters, etc)?


You can look at JOSE and JWT for a way to create tokens
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token

In 3.7 Deployment independent describes using the same client_id
across multiple instances of a native client, or multiple instances of
a Java Script client running in a browsers with the same callback uri.
Since the publishing of this RFC we have also developed a spec for
dynamic client registration so it is possible to give every native
client it's own client_id and secret making them confidential clients.
MadjidI would need to look at those specs, however, I thought that
the “confidential client” designation has to do with the client
ability to hold secrets and perform a-by-server-acceptable
authentication. Does dynamic client registration affect client’s
ability in that aspect?


Yes it doesn't require the secret to be in the downloaded instance of
the native app.  It can be populated at first run, changing it from
public to confidential.
Confidential is not just for web servers any more.

There is also a middle ground some people take by doing a proof of
possession for code in native applications to prevent the interception
of responses to the client by malicious applications on the device.
https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
John B.
On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri m.nakhj...@samsung.com

mailto:m.nakhj...@samsung.com

mailto:m.nakhj...@samsung.com mailto:m.nakhj...@samsung.com wrote:


Hi all,
I am new to OAUTH list and OAUTH, so apologies if this is very

off-topic.

I am evaluating an OAUTH 2.0 implementation that is done based on bare
bone base OAUTH2.0 RFC. From what I

Re: [OAUTH-WG] refresh tokens and client instances

[John Bradley]

' ready to get the 
  tokens, with that device (client instance) using a client id and the 
  grant code to get an access token and a refresh token.
  
  Lets say it sends a client_id=1code=2 sequence to get the tokens.
  A client id + a code value constitutes a client instance, because a code 
  would be unique per every authorization, right ?
  
  So the service will return an access token + refresh token to the device. 
  Refresh Token could've been associated with a record containing a client 
  id + grant code info earlier or at the moment the code is exchanged for 
  an access token.
  
  During the subsequent refresh token grant request we have client id + 
  refresh token as a client instance.
  
  I'm not sure what exactly I'd like to ask here :-), but I wonder if the 
  above sounds right, then I guess I'd like to conclude that when we talk 
  about the authorization code grant then a refresh token is not the only 
  key that uniquely identifies a client instance:
  
  Initially it is a client id + code grant, a refresh token does not offer 
  an extra uniqueness at the point of the client device requesting an 
  access token with a code. Refresh token only starts acting as the key 
  client instance identifier at a refresh token grant time.
  
  Sorry for a long email, I'm very likely missing something, so any 
  clarifications will be welcome
  
  Thanks, Sergey
  
  
  
  
  
  
  
  -bill
  
  
  On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin
  sberyoz...@gmail.com wrote:
  
  
  Hi
  
  I'm finding the answers from John interesting but I'm failing to
  understand why refresh tokens are mentioned in scope of identifying the
  specific client instances.
  
  AFAIK refresh tokens would only go on the wire, assuming they are
  supported, when a client exchanges a grant for a new access token.
  And when the client uses a refresh token grant.
  
  Was it really about a refresh token grant where the incoming client id
  and refresh token pair can uniquely identify the actual client instance
  ? That would make sense.
  
  Something else I'd like to clarify.
  John mentions a refresh token is created at the authorization grant
  initialization time. Would it make any difference, as far as the
  security properties of a grant are concerned, if refresh token was only
  created at a grant to access token exchange point of time ?
  
  Thanks, Sergey
  
  On 27/06/14 19:21, John Bradley wrote:
  Inline
  
  On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri m.nakhj...@samsung.com
  mailto:m.nakhj...@samsung.com
  mailto:m.nakhj...@samsung.com mailto:m.nakhj...@samsung.com wrote:
  
  Hi John,
  Thank you for your reply. Would appreciate if you consider my inline
  comments below and respond again!
  R,
  Madjid
  *From:*John Bradley [mailto:ve7...@ve7jtb.com
  mailto:ve7...@ve7jtb.com]
  *Sent:*Wednesday, June 25, 2014 5:56 PM
  *To:*Madjid Nakhjiri
  *Cc:*oauth@ietf.org mailto:oauth@ietf.org mailto:oauth@ietf.org
  mailto:oauth@ietf.org
  *Subject:*Re: [OAUTH-WG] refresh tokens and client instances
  In 3.3 It is saying that the refresh token is a secret that the
  Authorization server has bound to the client_id, that the
  Authorization server effectively uses to differentiate between
  instances of that client_id.
  MadjidIf I have 10,000s of devices, each with an instance of the
  OAUTH client, but they are all using the same client ID, how would the
  server know which token to use for what client? unless when I am
  creating a token, I also include something that uniquely identifies
  each instance? Don’t I have to use SOMETHING that is unique to that
  instance (user grant/ID?)?
  When the grant is issued you create and store a refresh token which is
  effectively the identifier for that instance/grant combination.
  When it comes back on a request to the token endpoint you look up the
  grants associated with it.  You also hack that the client_id sent in
  the request matches to detect errors mostly)
  
  When the refresh token is generated, it can be stored in a table with
  the client_id and the information about the grant.  You could also do
  it statelesly by creating a signed object as the refresh token.
  Madjidagreed, but for the signed object to be self-sustained, again
  would I not need something beyond a “population” client_ID? Are we
  prescriptive what “information about the grant” is?
  You would be creating a bearer token as long as the AS signs it you can
  put whatever grant grant info you like in it, that is implementation
  specific.  It  could be a list of the scopes granted and the subject.
  The spec is silent on the exact programming method that the
  Authorization server uses.
  MadjidAre there any other specs in IETF or elsewhere (OASIS, etc?)
  that prescribe token calculation (e.g. hash function, parameters, etc)?
  
  You can look at JOSE and JWT for a way to create tokens
  http://tools.ietf.org/html/draft-ietf-oauth-json-web-token
  In 3.7 Deployment independent

Re: [OAUTH-WG] refresh tokens and client instances

[John Bradley]

The client always needs a client_id.  

After the user authorizes the client the AS creates a code (there are lots of 
ways to do it, a database entry works for most people), and returns it to the 
client.

The client instance by possession  of that code is differentiated from other 
instances of that client in it's requests to the token endpoint by having a 
unique code or refresh_token.
That code and refresh token have grants associated with them for the user.

The user doesn't enter the code it is returned to the client in a query 
parameter appended to the redirect_uri.

The code is exchanged for a access token and optionally a refresh token,  after 
the access token expires the client can use the refresh token to get another 
access token. 
If the client doesn't have a refresh token it needs to go through authorization 
again.

John B.

On Jul 7, 2014, at 5:17 PM, Madjid Nakhjiri m.nakhj...@samsung.com wrote:

 Hi Sergey,
 
 Thanks for capturing the question. Yes, the issue was how we distinguish 
 between different instances of client, all using the same client ID. From 
 answers I have gotten so far, it seems that the uniqueness of the instance 
 may be provided through the uniqueness of a code grant. However, I have not 
 figure out what the spec says on how to create the grant and how the grant 
 code is unique to authorization server. If anybody could point me to that 
 part of spec, I would appreciate it (I did not find it). 
 
 Your description of a user authorizes a given device and gets a grant code 
 and enters it into device securely we have a client instance... would 
 require a device identifier, otherwise how does the fact that the client is 
 on a different device identifies that instance as a unique instance?
 
 I need to look at the spec for refresh versus access tokens. Do you need 
 different grant code types for each type of token?
 
 Thanks,
 Madjid
 -Original Message-
 From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Sergey Beryozkin
 Sent: Thursday, July 03, 2014 9:29 AM
 To: Bill Mills; oauth@ietf.org
 Subject: Re: [OAUTH-WG] refresh tokens and client instances
 
 Hi
 On 03/07/14 16:40, Bill Mills wrote:
 Implementations may/SHOULD bind refresh tokens to specific client 
 instances.  Yes, it's possible that the client ID with dynamic 
 registration is unique to each client, but many of the token theft use 
 cases include the possibility of stealing the client ID too if you 
 know you need to.
 
 What exactly is a 'client instance' when we talk about having a single client 
 id registration, with the id shared between multiple devices (which is what I 
 believe this thread started from).
 
 What I understood, as far as the authorization service is concerned, a 
 'client instance' for AS is a combination of a client id + code grant.
 
 + (optional) refresh token (as was mentioned earlier). But it appears to
 me a client instance can be uniquely identified by two values only without a 
 refresh token.
 
 When a user authorizes a given device and gets a grant code and enters it 
 into the device securely we have a 'client instance' ready to get the tokens, 
 with that device (client instance) using a client id and the grant code to 
 get an access token and a refresh token.
 
 Lets say it sends a client_id=1code=2 sequence to get the tokens.
 A client id + a code value constitutes a client instance, because a code 
 would be unique per every authorization, right ?
 
 So the service will return an access token + refresh token to the device. 
 Refresh Token could've been associated with a record containing a client id + 
 grant code info earlier or at the moment the code is exchanged for an access 
 token.
 
 During the subsequent refresh token grant request we have client id + 
 refresh token as a client instance.
 
 I'm not sure what exactly I'd like to ask here :-), but I wonder if the above 
 sounds right, then I guess I'd like to conclude that when we talk about the 
 authorization code grant then a refresh token is not the only key that 
 uniquely identifies a client instance:
 
 Initially it is a client id + code grant, a refresh token does not offer an 
 extra uniqueness at the point of the client device requesting an access token 
 with a code. Refresh token only starts acting as the key client instance 
 identifier at a refresh token grant time.
 
 Sorry for a long email, I'm very likely missing something, so any 
 clarifications will be welcome
 
 Thanks, Sergey
 
 
 
 
 
 
 
 -bill
 
 
 On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin 
 sberyoz...@gmail.com wrote:
 
 
 Hi
 
 I'm finding the answers from John interesting but I'm failing to 
 understand why refresh tokens are mentioned in scope of identifying 
 the specific client instances.
 
 AFAIK refresh tokens would only go on the wire, assuming they are 
 supported, when a client exchanges a grant for a new access token.
 And when the client uses a refresh token grant.
 
 Was it really about

Re: [OAUTH-WG] refresh tokens and client instances

[Sergey Beryozkin]

Hi

I'm finding the answers from John interesting but I'm failing to 
understand why refresh tokens are mentioned in scope of identifying the 
specific client instances.


AFAIK refresh tokens would only go on the wire, assuming they are 
supported, when a client exchanges a grant for a new access token.

And when the client uses a refresh token grant.

Was it really about a refresh token grant where the incoming client id 
and refresh token pair can uniquely identify the actual client instance 
? That would make sense.


Something else I'd like to clarify.
John mentions a refresh token is created at the authorization grant 
initialization time. Would it make any difference, as far as the 
security properties of a grant are concerned, if refresh token was only 
created at a grant to access token exchange point of time ?


Thanks, Sergey

On 27/06/14 19:21, John Bradley wrote:

Inline

On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri m.nakhj...@samsung.com
mailto:m.nakhj...@samsung.com wrote:


Hi John,
Thank you for your reply. Would appreciate if you consider my inline
comments below and respond again!
R,
Madjid
*From:*John Bradley [mailto:ve7...@ve7jtb.com]
*Sent:*Wednesday, June 25, 2014 5:56 PM
*To:*Madjid Nakhjiri
*Cc:*oauth@ietf.org mailto:oauth@ietf.org
*Subject:*Re: [OAUTH-WG] refresh tokens and client instances
In 3.3 It is saying that the refresh token is a secret that the
Authorization server has bound to the client_id, that the
Authorization server effectively uses to differentiate between
instances of that client_id.
MadjidIf I have 10,000s of devices, each with an instance of the
OAUTH client, but they are all using the same client ID, how would the
server know which token to use for what client? unless when I am
creating a token, I also include something that uniquely identifies
each instance? Don’t I have to use SOMETHING that is unique to that
instance (user grant/ID?)?

When the grant is issued you create and store a refresh token which is
effectively the identifier for that instance/grant combination.
When it comes back on a request to the token endpoint you look up the
grants associated with it.   You also hack that the client_id sent in
the request matches to detect errors mostly)


When the refresh token is generated, it can be stored in a table with
the client_id and the information about the grant.   You could also do
it statelesly by creating a signed object as the refresh token.
Madjidagreed, but for the signed object to be self-sustained, again
would I not need something beyond a “population” client_ID? Are we
prescriptive what “information about the grant” is?

You would be creating a bearer token as long as the AS signs it you can
put whatever grant grant info you like in it, that is implementation
specific.  It  could be a list of the scopes granted and the subject.

The spec is silent on the exact programming method that the
Authorization server uses.
MadjidAre there any other specs in IETF or elsewhere (OASIS, etc?)
that prescribe token calculation (e.g. hash function, parameters, etc)?


You can look at JOSE and JWT for a way to create tokens
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token

In 3.7 Deployment independent describes using the same client_id
across multiple instances of a native client, or multiple instances of
a Java Script client running in a browsers with the same callback uri.
Since the publishing of this RFC we have also developed a spec for
dynamic client registration so it is possible to give every native
client it's own client_id and secret making them confidential clients.
MadjidI would need to look at those specs, however, I thought that
the “confidential client” designation has to do with the client
ability to hold secrets and perform a-by-server-acceptable
authentication. Does dynamic client registration affect client’s
ability in that aspect?


Yes it doesn't require the secret to be in the downloaded instance of
the native app.  It can be populated at first run, changing it from
public to confidential.
Confidential is not just for web servers any more.

There is also a middle ground some people take by doing a proof of
possession for code in native applications to prevent the interception
of responses to the client by malicious applications on the device.
https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
John B.
On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri m.nakhj...@samsung.com
mailto:m.nakhj...@samsung.com wrote:


Hi all,
I am new to OAUTH list and OAUTH, so apologies if this is very off-topic.
I am evaluating an OAUTH 2.0 implementation that is done based on bare
bone base OAUTH2.0 RFC. From what I understand, many (or some) client
implementations use a “global ID/secret” pair for all instances of the
client.  Looking at RFC 6819 and there seem to be a whole page on this
topic, if I understand it correctly. So questions:
1)Section 3.7 talks about deployment-independent versus deployment
specific client IDs. I am guessing

Re: [OAUTH-WG] refresh tokens and client instances

[Bill Mills]

Implementations may/SHOULD bind refresh tokens to specific client instances.  
Yes, it's possible that the client ID with dynamic registration is unique to 
each client, but many of the token theft use cases include the possibility of 
stealing the client ID too if you know you need to.

-bill


On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin sberyoz...@gmail.com 
wrote:
 


Hi

I'm finding the answers from John interesting but I'm failing to 
understand why refresh tokens are mentioned in scope of identifying the 
specific client instances.

AFAIK refresh tokens would only go on the wire, assuming they are 
supported, when a client exchanges a grant for a new access token.
And when the client uses a refresh token grant.

Was it really about a refresh token grant where the incoming client id 
and refresh token pair can uniquely identify the actual client instance 
? That would make sense.

Something else I'd like to clarify.
John mentions a refresh token is created at the authorization grant 
initialization time. Would it make any difference, as far as the 
security properties of a grant are concerned, if refresh token was only 
created at a grant to access token exchange point of time ?

Thanks, Sergey

On 27/06/14 19:21, John Bradley wrote:
 Inline

 On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri m.nakhj...@samsung.com
 mailto:m.nakhj...@samsung.com wrote:

 Hi John,
 Thank you for your reply. Would appreciate if you consider my inline
 comments below and respond again!
 R,
 Madjid
 *From:*John Bradley [mailto:ve7...@ve7jtb.com]
 *Sent:*Wednesday, June 25, 2014 5:56 PM
 *To:*Madjid Nakhjiri
 *Cc:*oauth@ietf.org mailto:oauth@ietf.org
 *Subject:*Re: [OAUTH-WG] refresh tokens and client instances
 In 3.3 It is saying that the refresh token is a secret that the
 Authorization server has bound to the client_id, that the
 Authorization server effectively uses to differentiate between
 instances of that client_id.
 MadjidIf I have 10,000s of devices, each with an instance of the
 OAUTH client, but they are all using the same client ID, how would the
 server know which token to use for what client? unless when I am
 creating a token, I also include something that uniquely identifies
 each instance? Don’t I have to use SOMETHING that is unique to that
 instance (user grant/ID?)?
 When the grant is issued you create and store a refresh token which is
 effectively the identifier for that instance/grant combination.
 When it comes back on a request to the token endpoint you look up the
 grants associated with it.   You also hack that the client_id sent in
 the request matches to detect errors mostly)

 When the refresh token is generated, it can be stored in a table with
 the client_id and the information about the grant.   You could also do
 it statelesly by creating a signed object as the refresh token.
 Madjidagreed, but for the signed object to be self-sustained, again
 would I not need something beyond a “population” client_ID? Are we
 prescriptive what “information about the grant” is?
 You would be creating a bearer token as long as the AS signs it you can
 put whatever grant grant info you like in it, that is implementation
 specific.  It  could be a list of the scopes granted and the subject.
 The spec is silent on the exact programming method that the
 Authorization server uses.
 MadjidAre there any other specs in IETF or elsewhere (OASIS, etc?)
 that prescribe token calculation (e.g. hash function, parameters, etc)?

 You can look at JOSE and JWT for a way to create tokens
 http://tools.ietf.org/html/draft-ietf-oauth-json-web-token
 In 3.7 Deployment independent describes using the same client_id
 across multiple instances of a native client, or multiple instances of
 a Java Script client running in a browsers with the same callback uri.
 Since the publishing of this RFC we have also developed a spec for
 dynamic client registration so it is possible to give every native
 client it's own client_id and secret making them confidential clients.
 MadjidI would need to look at those specs, however, I thought that
 the “confidential client” designation has to do with the client
 ability to hold secrets and perform a-by-server-acceptable
 authentication. Does dynamic client registration affect client’s
 ability in that aspect?

 Yes it doesn't require the secret to be in the downloaded instance of
 the native app.  It can be populated at first run, changing it from
 public to confidential.
 Confidential is not just for web servers any more.
 There is also a middle ground some people take by doing a proof of
 possession for code in native applications to prevent the interception
 of responses to the client by malicious applications on the device.
 https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
 John B.
 On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri m.nakhj...@samsung.com
 mailto:m.nakhj...@samsung.com wrote:


 Hi all,
 I am new to OAUTH list and OAUTH, so apologies if this is very off-topic.
 I am

Re: [OAUTH-WG] refresh tokens and client instances

[Sergey Beryozkin]

Hi
On 03/07/14 16:40, Bill Mills wrote:

Implementations may/SHOULD bind refresh tokens to specific client
instances.  Yes, it's possible that the client ID with dynamic
registration is unique to each client, but many of the token theft use
cases include the possibility of stealing the client ID too if you know
you need to.

What exactly is a 'client instance' when we talk about having a single 
client id registration, with the id shared between multiple devices 
(which is what I believe this thread started from).


What I understood, as far as the authorization service is concerned, a 
'client instance' for AS is a combination of a client id + code grant.


+ (optional) refresh token (as was mentioned earlier). But it appears to 
me a client instance can be uniquely identified by two values only 
without a refresh token.


When a user authorizes a given device and gets a grant code and enters 
it into the device securely we have a 'client instance' ready to get the 
tokens, with that device (client instance) using a client id and the 
grant code to get an access token and a refresh token.


Lets say it sends a client_id=1code=2 sequence to get the tokens.
A client id + a code value constitutes a client instance, because a code 
would be unique per every authorization, right ?


So the service will return an access token + refresh token to the 
device. Refresh Token could've been associated with a record containing 
a client id + grant code info earlier or at the moment the code is 
exchanged for an access token.


During the subsequent refresh token grant request we have client id + 
refresh token as a client instance.


I'm not sure what exactly I'd like to ask here :-), but I wonder if the 
above sounds right, then I guess I'd like to conclude that when we talk 
about the authorization code grant then a refresh token is not the only 
key that uniquely identifies a client instance:


Initially it is a client id + code grant, a refresh token does not offer 
an extra uniqueness at the point of the client device requesting an 
access token with a code. Refresh token only starts acting as the key 
client instance identifier at a refresh token grant time.


Sorry for a long email, I'm very likely missing something, so any 
clarifications will be welcome


Thanks, Sergey








-bill


On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin
sberyoz...@gmail.com wrote:


Hi

I'm finding the answers from John interesting but I'm failing to
understand why refresh tokens are mentioned in scope of identifying the
specific client instances.

AFAIK refresh tokens would only go on the wire, assuming they are
supported, when a client exchanges a grant for a new access token.
And when the client uses a refresh token grant.

Was it really about a refresh token grant where the incoming client id
and refresh token pair can uniquely identify the actual client instance
? That would make sense.

Something else I'd like to clarify.
John mentions a refresh token is created at the authorization grant
initialization time. Would it make any difference, as far as the
security properties of a grant are concerned, if refresh token was only
created at a grant to access token exchange point of time ?

Thanks, Sergey

On 27/06/14 19:21, John Bradley wrote:
  Inline
 
  On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri m.nakhj...@samsung.com
mailto:m.nakhj...@samsung.com
  mailto:m.nakhj...@samsung.com mailto:m.nakhj...@samsung.com wrote:
 
  Hi John,
  Thank you for your reply. Would appreciate if you consider my inline
  comments below and respond again!
  R,
  Madjid
  *From:*John Bradley [mailto:ve7...@ve7jtb.com
mailto:ve7...@ve7jtb.com]
  *Sent:*Wednesday, June 25, 2014 5:56 PM
  *To:*Madjid Nakhjiri
  *Cc:*oauth@ietf.org mailto:oauth@ietf.org mailto:oauth@ietf.org
mailto:oauth@ietf.org
  *Subject:*Re: [OAUTH-WG] refresh tokens and client instances
  In 3.3 It is saying that the refresh token is a secret that the
  Authorization server has bound to the client_id, that the
  Authorization server effectively uses to differentiate between
  instances of that client_id.
  MadjidIf I have 10,000s of devices, each with an instance of the
  OAUTH client, but they are all using the same client ID, how would the
  server know which token to use for what client? unless when I am
  creating a token, I also include something that uniquely identifies
  each instance? Don’t I have to use SOMETHING that is unique to that
  instance (user grant/ID?)?
  When the grant is issued you create and store a refresh token which is
  effectively the identifier for that instance/grant combination.
  When it comes back on a request to the token endpoint you look up the
  grants associated with it.  You also hack that the client_id sent in
  the request matches to detect errors mostly)
 
  When the refresh token is generated, it can be stored in a table with
  the client_id and the information about the grant.  You could also do
  it statelesly by creating a signed

Re: [OAUTH-WG] refresh tokens and client instances

[Bill Mills]

You might have a public client, the Flickr client for example (which uses OAuth 
1 right now but it's a useful example) where the client ID is baked into the 
install.  In this case binding the token to the client ID means only that 
someone who steals the token and tries to use it with a different client ID 
would fail.

With DynReg that client could generate a nonce and include it in a dynamically 
registered client ID and then the credential could be bound to that specific 
software instance.

A 3rd possibility is multiple clients on a device sharing the same auth 
context, in which case they all use the same library perhaps and so several 
installed apps all would share the same client id from the servers 
perspective (the one for the auth API) but they might each get different scopes.


On Thursday, July 3, 2014 9:28 AM, Sergey Beryozkin sberyoz...@gmail.com 
wrote:
 


Hi
On 03/07/14 16:40, Bill Mills wrote:
 Implementations may/SHOULD bind refresh tokens to specific client
 instances.  Yes, it's possible that the client ID with dynamic
 registration is unique to each client, but many of the token theft use
 cases include the possibility of stealing the client ID too if you know
 you need to.

What exactly is a 'client instance' when we talk about having a single 
client id registration, with the id shared between multiple devices 
(which is what I believe this thread started from).

What I understood, as far as the authorization service is concerned, a 
'client instance' for AS is a combination of a client id + code grant.

+ (optional) refresh token (as was mentioned earlier). But it appears to 
me a client instance can be uniquely identified by two values only 
without a refresh token.

When a user authorizes a given device and gets a grant code and enters 
it into the device securely we have a 'client instance' ready to get the 
tokens, with that device (client instance) using a client id and the 
grant code to get an access token and a refresh token.

Lets say it sends a client_id=1code=2 sequence to get the tokens.
A client id + a code value constitutes a client instance, because a code 
would be unique per every authorization, right ?

So the service will return an access token + refresh token to the 
device. Refresh Token could've been associated with a record containing 
a client id + grant code info earlier or at the moment the code is 
exchanged for an access token.

During the subsequent refresh token grant request we have client id + 
refresh token as a client instance.

I'm not sure what exactly I'd like to ask here :-), but I wonder if the 
above sounds right, then I guess I'd like to conclude that when we talk 
about the authorization code grant then a refresh token is not the only 
key that uniquely identifies a client instance:

Initially it is a client id + code grant, a refresh token does not offer 
an extra uniqueness at the point of the client device requesting an 
access token with a code. Refresh token only starts acting as the key 
client instance identifier at a refresh token grant time.

Sorry for a long email, I'm very likely missing something, so any 
clarifications will be welcome

Thanks, Sergey







 -bill


 On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin
 sberyoz...@gmail.com wrote:


 Hi

 I'm finding the answers from John interesting but I'm failing to
 understand why refresh tokens are mentioned in scope of identifying the
 specific client instances.

 AFAIK refresh tokens would only go on the wire, assuming they are
 supported, when a client exchanges a grant for a new access token.
 And when the client uses a refresh token grant.

 Was it really about a refresh token grant where the incoming client id
 and refresh token pair can uniquely identify the actual client instance
 ? That would make sense.

 Something else I'd like to clarify.
 John mentions a refresh token is created at the authorization grant
 initialization time. Would it make any difference, as far as the
 security properties of a grant are concerned, if refresh token was only
 created at a grant to access token exchange point of time ?

 Thanks, Sergey

 On 27/06/14 19:21, John Bradley wrote:
   Inline
  
   On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri m.nakhj...@samsung.com
 mailto:m.nakhj...@samsung.com
   mailto:m.nakhj...@samsung.com mailto:m.nakhj...@samsung.com wrote:
  
   Hi John,
   Thank you for your reply. Would appreciate if you consider my inline
   comments below and respond again!
   R,
   Madjid
   *From:*John Bradley [mailto:ve7...@ve7jtb.com
 mailto:ve7...@ve7jtb.com]
   *Sent:*Wednesday, June 25, 2014 5:56 PM
   *To:*Madjid Nakhjiri
   *Cc:*oauth@ietf.org mailto:oauth@ietf.org mailto:oauth@ietf.org
 mailto:oauth@ietf.org
   *Subject:*Re: [OAUTH-WG] refresh tokens and client instances
   In 3.3 It is saying that the refresh token is a secret that the
   Authorization server has bound to the client_id, that the
   Authorization server effectively uses to differentiate

Re: [OAUTH-WG] refresh tokens and client instances

[John Bradley]

 mailto:oauth@ietf.org
  *Subject:*Re: [OAUTH-WG] refresh tokens and client instances
  In 3.3 It is saying that the refresh token is a secret that the
  Authorization server has bound to the client_id, that the
  Authorization server effectively uses to differentiate between
  instances of that client_id.
  MadjidIf I have 10,000s of devices, each with an instance of the
  OAUTH client, but they are all using the same client ID, how would the
  server know which token to use for what client? unless when I am
  creating a token, I also include something that uniquely identifies
  each instance? Don’t I have to use SOMETHING that is unique to that
  instance (user grant/ID?)?
  When the grant is issued you create and store a refresh token which is
  effectively the identifier for that instance/grant combination.
  When it comes back on a request to the token endpoint you look up the
  grants associated with it.  You also hack that the client_id sent in
  the request matches to detect errors mostly)
 
  When the refresh token is generated, it can be stored in a table with
  the client_id and the information about the grant.  You could also do
  it statelesly by creating a signed object as the refresh token.
  Madjidagreed, but for the signed object to be self-sustained, again
  would I not need something beyond a “population” client_ID? Are we
  prescriptive what “information about the grant” is?
  You would be creating a bearer token as long as the AS signs it you can
  put whatever grant grant info you like in it, that is implementation
  specific.  It  could be a list of the scopes granted and the subject.
  The spec is silent on the exact programming method that the
  Authorization server uses.
  MadjidAre there any other specs in IETF or elsewhere (OASIS, etc?)
  that prescribe token calculation (e.g. hash function, parameters, etc)?
 
  You can look at JOSE and JWT for a way to create tokens
  http://tools.ietf.org/html/draft-ietf-oauth-json-web-token
  In 3.7 Deployment independent describes using the same client_id
  across multiple instances of a native client, or multiple instances of
  a Java Script client running in a browsers with the same callback uri.
  Since the publishing of this RFC we have also developed a spec for
  dynamic client registration so it is possible to give every native
  client it's own client_id and secret making them confidential clients.
  MadjidI would need to look at those specs, however, I thought that
  the “confidential client” designation has to do with the client
  ability to hold secrets and perform a-by-server-acceptable
  authentication. Does dynamic client registration affect client’s
  ability in that aspect?
 
  Yes it doesn't require the secret to be in the downloaded instance of
  the native app.  It can be populated at first run, changing it from
  public to confidential.
  Confidential is not just for web servers any more.
  There is also a middle ground some people take by doing a proof of
  possession for code in native applications to prevent the interception
  of responses to the client by malicious applications on the device.
  https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
  John B.
  On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri m.nakhj...@samsung.com
 mailto:m.nakhj...@samsung.com
  mailto:m.nakhj...@samsung.com mailto:m.nakhj...@samsung.com wrote:
 
 
  Hi all,
  I am new to OAUTH list and OAUTH, so apologies if this is very
 off-topic.
  I am evaluating an OAUTH 2.0 implementation that is done based on bare
  bone base OAUTH2.0 RFC. From what I understand, many (or some) client
  implementations use a “global ID/secret” pair for all instances of the
  client.  Looking at RFC 6819 and there seem to be a whole page on this
  topic, if I understand it correctly. So questions:
  1)Section 3.7 talks about deployment-independent versus deployment
  specific client IDs. I am guessing “deployment-independent” refers to
  what I called “global”, meaning if I have the same client with the
  same client ID installed in many end devices, that is a deployment
  independent case, correct?
  2)Section 3.3 on refresh token mentions that the token is secret bound
  to the client ID and client instance. Could somebody please point me
  to where the token generation and binding is described? Also how is
  the client instance is identified?
  Thanks a lot in advance,
  Madjid Nakhjiri
  ___
  OAuth mailing list
  OAuth@ietf.org mailto:OAuth@ietf.org mailto:OAuth@ietf.org
 mailto:OAuth@ietf.org
  https://www.ietf.org/mailman/listinfo/oauth
 
 
 
 
  ___
  OAuth mailing list
  OAuth@ietf.org mailto:OAuth@ietf.org
  https://www.ietf.org/mailman/listinfo/oauth
 
 
 ___
 OAuth mailing list
 OAuth@ietf.org mailto:OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] refresh tokens and client instances

[Madjid Nakhjiri]

Hi John,

 

Thank you for your reply. Would appreciate if you consider my inline
comments below and respond again!

 

R,

Madjid

 

From: John Bradley [mailto:ve7...@ve7jtb.com] 
Sent: Wednesday, June 25, 2014 5:56 PM
To: Madjid Nakhjiri
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens and client instances

 

In 3.3 It is saying that the refresh token is a secret that the
Authorization server has bound to the client_id, that the Authorization
server effectively uses to differentiate between instances of that
client_id.

 

MadjidIf I have 10,000s of devices, each with an instance of the OAUTH
client, but they are all using the same client ID, how would the server know
which token to use for what client? unless when I am creating a token, I
also include something that uniquely identifies each instance? Don't I have
to use SOMETHING that is unique to that instance (user grant/ID?)?

 

When the refresh token is generated, it can be stored in a table with the
client_id and the information about the grant.   You could also do it
statelesly by creating a signed object as the refresh token. 

Madjidagreed, but for the signed object to be self-sustained, again would
I not need something beyond a population client_ID? Are we prescriptive
what information about the grant is?

 

The spec is silent on the exact programming method that the Authorization
server uses.

 

MadjidAre there any other specs in IETF or elsewhere (OASIS, etc?) that
prescribe token calculation (e.g. hash function, parameters, etc)?

 

In 3.7 Deployment independent describes using the same client_id across
multiple instances of a native client, or multiple instances of a Java
Script client running in a browsers with the same callback uri.

 

Since the publishing of this RFC we have also developed a spec for dynamic
client registration so it is possible to give every native client it's own
client_id and secret making them confidential clients.

 

MadjidI would need to look at those specs, however, I thought that the
confidential client designation has to do with the client ability to hold
secrets and perform a-by-server-acceptable authentication. Does dynamic
client registration affect client's ability in that aspect?

 

There is also a middle ground some people take by doing a proof of
possession for code in native applications to prevent the interception of
responses to the client by malicious applications on the device.

https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/

 

John B.

 

On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri m.nakhj...@samsung.com wrote:





Hi all,

 

I am new to OAUTH list and OAUTH, so apologies if this is very off-topic.

 

I am evaluating an OAUTH 2.0 implementation that is done based on bare bone
base OAUTH2.0 RFC. From what I understand, many (or some) client
implementations use a global ID/secret pair for all instances of the
client.  Looking at RFC 6819 and there seem to be a whole page on this
topic, if I understand it correctly. So questions:

 

1)  Section 3.7 talks about deployment-independent versus deployment
specific client IDs. I am guessing deployment-independent refers to what I
called global, meaning if I have the same client with the same client ID
installed in many end devices, that is a deployment independent case,
correct?

2)  Section 3.3 on refresh token mentions that the token is secret bound
to the client ID and client instance. Could somebody please point me to
where the token generation and binding is described? Also how is the client
instance is identified?   

 

Thanks a lot in advance,

Madjid Nakhjiri

 

___
OAuth mailing list
 mailto:OAuth@ietf.org OAuth@ietf.org
 https://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

Re: [OAUTH-WG] refresh tokens and client instances

[John Bradley]

Inline

On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri m.nakhj...@samsung.com wrote:

 Hi John,
  
 Thank you for your reply. Would appreciate if you consider my inline comments 
 below and respond again!
  
 R,
 Madjid
  
 From: John Bradley [mailto:ve7...@ve7jtb.com] 
 Sent: Wednesday, June 25, 2014 5:56 PM
 To: Madjid Nakhjiri
 Cc: oauth@ietf.org
 Subject: Re: [OAUTH-WG] refresh tokens and client instances
  
 In 3.3 It is saying that the refresh token is a secret that the Authorization 
 server has bound to the client_id, that the Authorization server effectively 
 uses to differentiate between instances of that client_id.
  
 MadjidIf I have 10,000s of devices, each with an instance of the OAUTH 
 client, but they are all using the same client ID, how would the server know 
 which token to use for what client? unless when I am creating a token, I also 
 include something that uniquely identifies each instance? Don’t I have to use 
 SOMETHING that is unique to that instance (user grant/ID?)?
  
When the grant is issued you create and store a refresh token which is 
effectively the identifier for that instance/grant combination. 
When it comes back on a request to the token endpoint you look up the grants 
associated with it.   You also hack that the client_id sent in the request 
matches to detect errors mostly)

 When the refresh token is generated, it can be stored in a table with the 
 client_id and the information about the grant.   You could also do it 
 statelesly by creating a signed object as the refresh token. 
 Madjidagreed, but for the signed object to be self-sustained, again would I 
 not need something beyond a “population” client_ID? Are we prescriptive what 
 “information about the grant” is?
  
You would be creating a bearer token as long as the AS signs it you can put 
whatever grant grant info you like in it, that is implementation specific.  It  
could be a list of the scopes granted and the subject.
 The spec is silent on the exact programming method that the Authorization 
 server uses.
  
 MadjidAre there any other specs in IETF or elsewhere (OASIS, etc?) that 
 prescribe token calculation (e.g. hash function, parameters, etc)?

You can look at JOSE and JWT for a way to create tokens 
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token
  
 In 3.7 Deployment independent describes using the same client_id across 
 multiple instances of a native client, or multiple instances of a Java Script 
 client running in a browsers with the same callback uri.
  
 Since the publishing of this RFC we have also developed a spec for dynamic 
 client registration so it is possible to give every native client it's own 
 client_id and secret making them confidential clients.
  
 MadjidI would need to look at those specs, however, I thought that the 
 “confidential client” designation has to do with the client ability to hold 
 secrets and perform a-by-server-acceptable authentication. Does dynamic 
 client registration affect client’s ability in that aspect?

Yes it doesn't require the secret to be in the downloaded instance of the 
native app.  It can be populated at first run, changing it from public to 
confidential.
Confidential is not just for web servers any more.
  
 There is also a middle ground some people take by doing a proof of possession 
 for code in native applications to prevent the interception of responses to 
 the client by malicious applications on the device.
 https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
  
 John B.
  
 On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri m.nakhj...@samsung.com wrote:
 
 
 Hi all,
  
 I am new to OAUTH list and OAUTH, so apologies if this is very off-topic.
  
 I am evaluating an OAUTH 2.0 implementation that is done based on bare bone 
 base OAUTH2.0 RFC. From what I understand, many (or some) client 
 implementations use a “global ID/secret” pair for all instances of the 
 client.  Looking at RFC 6819 and there seem to be a whole page on this topic, 
 if I understand it correctly. So questions:
  
 1)  Section 3.7 talks about deployment-independent versus deployment 
 specific client IDs. I am guessing “deployment-independent” refers to what I 
 called “global”, meaning if I have the same client with the same client ID 
 installed in many end devices, that is a deployment independent case, correct?
 2)  Section 3.3 on refresh token mentions that the token is secret bound 
 to the client ID and client instance. Could somebody please point me to where 
 the token generation and binding is described? Also how is the client 
 instance is identified?   
  
 Thanks a lot in advance,
 Madjid Nakhjiri
  
 ___
 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

Re: [OAUTH-WG] refresh tokens and client instances

[Madjid Nakhjiri]

Thank you for the response. I guess I am still not clear on the
token-instance-grant binding. Let me look at the specs to see what the grant
looks like to see if I understand. Any pointer is appreciated.

 

R,

Madjid

 

From: John Bradley [mailto:ve7...@ve7jtb.com] 
Sent: Friday, June 27, 2014 11:22 AM
To: Madjid Nakhjiri
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens and client instances

 

Inline

 

On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri m.nakhj...@samsung.com wrote:





Hi John,

 

Thank you for your reply. Would appreciate if you consider my inline
comments below and respond again!

 

R,

Madjid

 

From: John Bradley [ mailto:ve7...@ve7jtb.com mailto:ve7...@ve7jtb.com] 
Sent: Wednesday, June 25, 2014 5:56 PM
To: Madjid Nakhjiri
Cc:  mailto:oauth@ietf.org oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens and client instances

 

In 3.3 It is saying that the refresh token is a secret that the
Authorization server has bound to the client_id, that the Authorization
server effectively uses to differentiate between instances of that
client_id.

 

MadjidIf I have 10,000s of devices, each with an instance of the OAUTH
client, but they are all using the same client ID, how would the server know
which token to use for what client? unless when I am creating a token, I
also include something that uniquely identifies each instance? Don't I have
to use SOMETHING that is unique to that instance (user grant/ID?)?

 

When the grant is issued you create and store a refresh token which is
effectively the identifier for that instance/grant combination. 

When it comes back on a request to the token endpoint you look up the grants
associated with it.   You also hack that the client_id sent in the request
matches to detect errors mostly)





When the refresh token is generated, it can be stored in a table with the
client_id and the information about the grant.   You could also do it
statelesly by creating a signed object as the refresh token. 

Madjidagreed, but for the signed object to be self-sustained, again would
I not need something beyond a population client_ID? Are we prescriptive
what information about the grant is?

 

You would be creating a bearer token as long as the AS signs it you can put
whatever grant grant info you like in it, that is implementation specific.
It  could be a list of the scopes granted and the subject.



The spec is silent on the exact programming method that the Authorization
server uses.

 

MadjidAre there any other specs in IETF or elsewhere (OASIS, etc?) that
prescribe token calculation (e.g. hash function, parameters, etc)?

 

You can look at JOSE and JWT for a way to create tokens
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token



 

In 3.7 Deployment independent describes using the same client_id across
multiple instances of a native client, or multiple instances of a Java
Script client running in a browsers with the same callback uri.

 

Since the publishing of this RFC we have also developed a spec for dynamic
client registration so it is possible to give every native client it's own
client_id and secret making them confidential clients.

 

MadjidI would need to look at those specs, however, I thought that the
confidential client designation has to do with the client ability to hold
secrets and perform a-by-server-acceptable authentication. Does dynamic
client registration affect client's ability in that aspect?

 

Yes it doesn't require the secret to be in the downloaded instance of the
native app.  It can be populated at first run, changing it from public to
confidential.

Confidential is not just for web servers any more.



 

There is also a middle ground some people take by doing a proof of
possession for code in native applications to prevent the interception of
responses to the client by malicious applications on the device.

 https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/

 

John B.

 

On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri 
mailto:m.nakhj...@samsung.com m.nakhj...@samsung.com wrote:






Hi all,

 

I am new to OAUTH list and OAUTH, so apologies if this is very off-topic.

 

I am evaluating an OAUTH 2.0 implementation that is done based on bare bone
base OAUTH2.0 RFC. From what I understand, many (or some) client
implementations use a global ID/secret pair for all instances of the
client.  Looking at RFC 6819 and there seem to be a whole page on this
topic, if I understand it correctly. So questions:

 

1)  Section 3.7 talks about deployment-independent versus deployment
specific client IDs. I am guessing deployment-independent refers to what I
called global, meaning if I have the same client with the same client ID
installed in many end devices, that is a deployment independent case,
correct?

2)  Section 3.3 on refresh token mentions that the token is secret bound
to the client ID and client instance. Could somebody please point me

Re: [OAUTH-WG] Refresh tokens

[Bart Wiegmans]

I forgot the following question:

5. If refresh taken are just another way of requesting access tokens, I
believe they should be specified in section 4, with other grant types.
But there must be a reason for the way it is now, so why?

With kind regards,
Bart Wiegmans | Developer

-Oorspronkelijk bericht-
Van: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] Namens Bart
Wiegmans
Verzonden: maandag 28 november 2011 16:13
Aan: oauth WG
Onderwerp: [OAUTH-WG] Refresh tokens

Hello everybody,

This is my first post on this mailing list, so I will introduce myself.
My name is Bart Wiegmans, I work in Groningen, the Netherlands. I am
involved with OAuth2 because I am implementing an authorization server
for my employer, all4students / studenten.net.

I have few remarks about refresh tokens.

1. The way I understand it, they are a way to limit the impact of access
token exposure. Which I find desirable.
2. However, they can also be seen as credentials for an access token
request. In which case, refresh token exposure is a more serious risk
than access token exposure.
3. Are there, or will there ever be, multiple refresh token types as
there are access token types?
4. Can a public client use refresh tokens at all, or is this
meaningless? If not, are public clients that are installed on a users'
computer or smartphone required to re-authorise every time an access
token expires? (This would be undesirable). Should they request
long-lived access tokens? 

About MAC tokens, I wonder about the practicality of public (javascript)
clients using them as a token type. 

With kind regards,
Bart Wiegmans | Developer
___
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

Re: [OAUTH-WG] Refresh tokens

[William Mills]

12) Yep.  This is why flows using Refresh Tokens must always use SSL.

3) Refresh tokens are comparable to access tokens in that you can scope them 
etc.  In fact it makes a great deal of sense to limit them in the same way the 
access tokens are limited.

4) The answer here depends on the security requirements for your app.  It all 
depends on whether you feel the client can keep a secret, either a MAC signing 
secret or a token.  Whether you store them on disk or not depends a lot on how 
you'd plan to store them, if it's in a browser then you're pretty much trusting 
the user level file security on the computer.

5) Not sure, might be that Eran wanted to generalize it so as not to be putting 
specific authentication scheme constructs into the base framework.

-bill





 From: Bart Wiegmans b...@all4students.nl
To: oauth WG oauth@ietf.org 
Sent: Monday, November 28, 2011 7:20 AM
Subject: Re: [OAUTH-WG] Refresh tokens
 
I forgot the following question:

5. If refresh taken are just another way of requesting access tokens, I
believe they should be specified in section 4, with other grant types.
But there must be a reason for the way it is now, so why?

With kind regards,
Bart Wiegmans | Developer

-Oorspronkelijk bericht-
Van: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] Namens Bart
Wiegmans
Verzonden: maandag 28 november 2011 16:13
Aan: oauth WG
Onderwerp: [OAUTH-WG] Refresh tokens

Hello everybody,

This is my first post on this mailing list, so I will introduce myself.
My name is Bart Wiegmans, I work in Groningen, the Netherlands. I am
involved with OAuth2 because I am implementing an authorization server
for my employer, all4students / studenten.net.

I have few remarks about refresh tokens.

1. The way I understand it, they are a way to limit the impact of access
token exposure. Which I find desirable.
2. However, they can also be seen as credentials for an access token
request. In which case, refresh token exposure is a more serious risk
than access token exposure.
3. Are there, or will there ever be, multiple refresh token types as
there are access token types?
4. Can a public client use refresh tokens at all, or is this
meaningless? If not, are public clients that are installed on a users'
computer or smartphone required to re-authorise every time an access
token expires? (This would be undesirable). Should they request
long-lived access tokens? 

About MAC tokens, I wonder about the practicality of public (javascript)
clients using them as a token type. 

With kind regards,
Bart Wiegmans | Developer
___
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

Re: [OAUTH-WG] Refresh Tokens

[Torsten Lodderstedt]

OAuth allows a client to access user resources without revealing the 
resource owner's identity to the client. Isn't this anonymity? I 
consider this an important property of the protocol.


regards,
Torsten.


On Thu, 11 Aug 2011 21:00:54 -0400, Barry Leiba wrote:

This seems to need a chair to step in.  Tony is taking a strong stand
and maintaining it:

On Thu, Aug 11, 2011 at 1:40 PM, Anthony Nadalin
tony...@microsoft.com wrote:
Nowhere in the specification is there explanation for refresh 
tokens, The
reason that the Refresh token was introduced was for anonymity. The 
scenario
is that a client asks the user for access. The user wants to grant 
the
access but not tell the client the user's identity. By issuing the 
refresh
token as an 'identifier' for the user (as well as other context data 
like

the resource) it's possible now to let the client get access without
revealing anything about the user. Recommend that the above 
explanation be

included so developers understand why the refresh tokens are there.


So far, though it's been only half a day, I've seen several posts
disagreeing with Tony, and none supporting any change to the text for
this.  We're close to ending WGLC, so please post here if you agree
with Tony's suggested change.  Otherwise, it looks like consensus is
against.

Barry, as chair
___
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

Re: [OAUTH-WG] Refresh Tokens

[Aaron Parecki]

Many APIs in practice have a method such as /me or /profile for
applications to retrieve the profile information of the resource owner given
their access token. IMO this is a completely appropriate use of OAuth, even
though the resource owner is no longer anonymous in this case. I agree that
it's implementation specific.

My understanding was that OAuth is designed to give limited, revokable,
and/or temporary access to a third party without revealing the resource
owner's credentials. This has nothing to do with anonymity.

Also this is not unique to refresh tokens, the same applies to access
tokens.

Aaron Parecki


On Fri, Aug 12, 2011 at 8:10 AM, Torsten Lodderstedt 
tors...@lodderstedt.net wrote:

 OAuth allows a client to access user resources without revealing the
 resource owner's identity to the client. Isn't this anonymity? I consider
 this an important property of the protocol.

 regards,
 Torsten.



 On Thu, 11 Aug 2011 21:00:54 -0400, Barry Leiba wrote:

 This seems to need a chair to step in.  Tony is taking a strong stand
 and maintaining it:

 On Thu, Aug 11, 2011 at 1:40 PM, Anthony Nadalin
 tony...@microsoft.com wrote:

 Nowhere in the specification is there explanation for refresh tokens, The
 reason that the Refresh token was introduced was for anonymity. The
 scenario
 is that a client asks the user for access. The user wants to grant the
 access but not tell the client the user's identity. By issuing the
 refresh
 token as an 'identifier' for the user (as well as other context data like
 the resource) it's possible now to let the client get access without
 revealing anything about the user. Recommend that the above explanation
 be
 included so developers understand why the refresh tokens are there.


 So far, though it's been only half a day, I've seen several posts
 disagreeing with Tony, and none supporting any change to the text for
 this.  We're close to ending WGLC, so please post here if you agree
 with Tony's suggested change.  Otherwise, it looks like consensus is
 against.

 Barry, as chair
 __**_
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/**listinfo/oauthhttps://www.ietf.org/mailman/listinfo/oauth


 __**_
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/**listinfo/oauthhttps://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Refresh Tokens

[Aiden Bell]

In some sense, but it is an indirect consequence of the fact the protocol is
for granting access
without requiring the revealing of user credentials, which in most (but not
all) cases means
hiding the user's identity on the system.

In many cases however, their identity is simply translated/embodied by into
tokens exchanged and
the service using OAuth will expose identity.

Therefore an implicit property is the negotiation of access to resources
without revealing a
user's identity ... but identity goes well beyond login credentials in most
useful systems.
Even then, you can use OAuth with login credentials (in native apps etc)
(4.3) to authenticate.

Because identity and anonymity may possibly be implemented using OAuth
doesn't mean
that it is an explicit design feature in OAuth itself.

I think it is very dangerous to go down this route, as bringing explicit
anonymity into the mix
will confuse the purpose and scope of OAuth, when anonymity is a restriction
on some system
using OAuth.

I don't see OAuth as being anymore a system with anonymity properties than
say, my web browser.
Depends on how you use it; entirely.

Aiden Bell


On 12 August 2011 16:10, Torsten Lodderstedt tors...@lodderstedt.netwrote:

 OAuth allows a client to access user resources without revealing the
 resource owner's identity to the client. Isn't this anonymity? I consider
 this an important property of the protocol.

 regards,
 Torsten.



 On Thu, 11 Aug 2011 21:00:54 -0400, Barry Leiba wrote:

 This seems to need a chair to step in.  Tony is taking a strong stand
 and maintaining it:

 On Thu, Aug 11, 2011 at 1:40 PM, Anthony Nadalin
 tony...@microsoft.com wrote:

 Nowhere in the specification is there explanation for refresh tokens, The
 reason that the Refresh token was introduced was for anonymity. The
 scenario
 is that a client asks the user for access. The user wants to grant the
 access but not tell the client the user's identity. By issuing the
 refresh
 token as an 'identifier' for the user (as well as other context data like
 the resource) it's possible now to let the client get access without
 revealing anything about the user. Recommend that the above explanation
 be
 included so developers understand why the refresh tokens are there.


 So far, though it's been only half a day, I've seen several posts
 disagreeing with Tony, and none supporting any change to the text for
 this.  We're close to ending WGLC, so please post here if you agree
 with Tony's suggested change.  Otherwise, it looks like consensus is
 against.

 Barry, as chair
 __**_
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/**listinfo/oauthhttps://www.ietf.org/mailman/listinfo/oauth


 __**_
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/**listinfo/oauthhttps://www.ietf.org/mailman/listinfo/oauth




-- 
--
Never send sensitive or private information via email unless it is
encrypted. http://www.gnupg.org
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh Tokens

[Igor Faynberg]

Precisely!  In fact the anonymity of this sort can be achieved even 
without a refresh token: as long as the end user is not required to 
authenticate to the client.


But for all I remember, we have never had a SINGLE USE CASE (sorry to 
transition to my pet peeve) that required anonymity.  The original and 
overarching OAuth requirement has been not to reveal user credentials; 
the refresh tokens were required in order to make end-user's life 
easier. In short, I do not recall anonimity being the end.


I have no doubt that Tony has a new important use case, and I think we 
should document it, derive requirements from it, and pursue this in the 
next OAuth release.


Igor



On 8/12/2011 11:10 AM, Torsten Lodderstedt wrote:
OAuth allows a client to access user resources without revealing the 
resource owner's identity to the client. Isn't this anonymity? I 
consider this an important property of the protocol.


regards,
Torsten.


On Thu, 11 Aug 2011 21:00:54 -0400, Barry Leiba wrote:

This seems to need a chair to step in.  Tony is taking a strong stand
and maintaining it:

On Thu, Aug 11, 2011 at 1:40 PM, Anthony Nadalin
tony...@microsoft.com wrote:
Nowhere in the specification is there explanation for refresh 
tokens, The
reason that the Refresh token was introduced was for anonymity. The 
scenario

is that a client asks the user for access. The user wants to grant the
access but not tell the client the user's identity. By issuing the 
refresh
token as an 'identifier' for the user (as well as other context data 
like

the resource) it's possible now to let the client get access without
revealing anything about the user. Recommend that the above 
explanation be

included so developers understand why the refresh tokens are there.


So far, though it's been only half a day, I've seen several posts
disagreeing with Tony, and none supporting any change to the text for
this.  We're close to ending WGLC, so please post here if you agree
with Tony's suggested change.  Otherwise, it looks like consensus is
against.

Barry, as chair
___
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

Re: [OAUTH-WG] Refresh Tokens

[Dick Hardt]

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked 
by not issuing new access tokens. A resource does not need to query the 
authorization server to see if the access token is valid.This simplifies access 
token validation and makes it easier to scale and support multiple 
authorization servers.  There is a window of time when an access token is 
valid, but authorization is revoked. 



On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:

 Nowhere in the specification is there explanation for refresh tokens, The 
 reason that the Refresh token was introduced was for anonymity. The scenario 
 is that a client asks the user for access. The user wants to grant the access 
 but not tell the client the user's identity. By issuing the refresh token as 
 an 'identifier' for the user (as well as other context data like the 
 resource) it's possible now to let the client get access without revealing 
 anything about the user. Recommend that the above explanation be included so 
 developers understand why the refresh tokens are there.
 ___
 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

Re: [OAUTH-WG] Refresh Tokens

[William J. Mills]

Refresh tokens have a different main goal, in my opinion.  They are useful to 
allow a log lived durable replacement for username/password.  This means the 
user's primary credential is not stored in the client.  Refresh tokens can be 
revoked by the user without requiring password change.  They are also always 
used over a secure channel, and can fetch a (sometimes much) shorter lived 
token used over a clear channel.  Yahoo! Messenger and others use a model like 
this now.  Refresh tokens can also be issued to a particular client requiring 
authentication, so are not useful if the client authentication credential is 
not also compromised.

They do have the property of anonymity as well, but that's true of both teh 
refresh token and access token, so it's not specific to refresh tokens.

-bill




From: Anthony Nadalin tony...@microsoft.com
To: OAuth WG (oauth@ietf.org) oauth@ietf.org
Sent: Thursday, August 11, 2011 10:40 AM
Subject: [OAUTH-WG] Refresh Tokens


 
Nowhere in the specification is there explanation for refresh tokens, The 
reason that the Refresh token was introduced was for anonymity. The scenario is 
that a client asks the user for access. The user wants to grant the access but 
not tell the client the user's identity. By issuing the refresh token as an 
'identifier' for the user (as well as other context data like the resource) 
it's possible now to let the client get access without revealing anything about 
the user. Recommend that the above explanation be included so developers 
understand why the refresh tokens are there.
___
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

Re: [OAUTH-WG] Refresh Tokens

[Anthony Nadalin]

Many reasons, but none are explained in the specification

From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked 
by not issuing new access tokens. A resource does not need to query the 
authorization server to see if the access token is valid.This simplifies access 
token validation and makes it easier to scale and support multiple 
authorization servers.  There is a window of time when an access token is 
valid, but authorization is revoked.



On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:


Nowhere in the specification is there explanation for refresh tokens, The 
reason that the Refresh token was introduced was for anonymity. The scenario is 
that a client asks the user for access. The user wants to grant the access but 
not tell the client the user's identity. By issuing the refresh token as an 
'identifier' for the user (as well as other context data like the resource) 
it's possible now to let the client get access without revealing anything about 
the user. Recommend that the above explanation be included so developers 
understand why the refresh tokens are there.
___
OAuth mailing list
OAuth@ietf.orgmailto:OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Refresh Tokens

[William J. Mills]

Does it want to be in the main definition or the security considerations 
section?




From: Anthony Nadalin tony...@microsoft.com
To: Dick Hardt dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.org) oauth@ietf.org
Sent: Thursday, August 11, 2011 11:15 AM
Subject: Re: [OAUTH-WG] Refresh Tokens


 
Many reasons, but none are explained in the specification
 
From:Dick Hardt [mailto:dick.ha...@gmail.com] 
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
 
My recollection of refresh tokens was for security and revocation.
 
security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access
 
revocation: if the access token is self contained, authorization can be revoked 
by not issuing new access tokens. A resource does not need to query the 
authorization server to see if the access token is valid.This simplifies access 
token validation and makes it easier to scale and support multiple 
authorization servers.  There is a window of time when an access token is 
valid, but authorization is revoked. 
 
 
 
On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:


Nowhere in the specification is there explanation for refresh tokens, The 
reason that the Refresh token was introduced was for anonymity. The scenario is 
that a client asks the user for access. The user wants to grant the access but 
not tell the client the user's identity. By issuing the refresh token as an 
'identifier' for the user (as well as other context data like the resource) 
it's possible now to let the client get access without revealing anything about 
the user. Recommend that the above explanation be included so developers 
understand why the refresh tokens are there.
___
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

Re: [OAUTH-WG] Refresh Tokens

[Eran Hammer-Lahav]

Section 1.5 already covers refresh tokens. There are many use cases for refresh 
tokens. They are basically a protocol feature used to make scalability and 
security more flexible. Anonymity was never part of their design, and by the 
nature of this protocol, is more in the domain of the resource server (based on 
what information it exposes via its API). In fact, your email if the first such 
suggestion of anonymity.

EHL

From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt dick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) 
oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens

Many reasons, but none are explained in the specification

From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked 
by not issuing new access tokens. A resource does not need to query the 
authorization server to see if the access token is valid.This simplifies access 
token validation and makes it easier to scale and support multiple 
authorization servers.  There is a window of time when an access token is 
valid, but authorization is revoked.



On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:


Nowhere in the specification is there explanation for refresh tokens, The 
reason that the Refresh token was introduced was for anonymity. The scenario is 
that a client asks the user for access. The user wants to grant the access but 
not tell the client the user's identity. By issuing the refresh token as an 
'identifier' for the user (as well as other context data like the resource) 
it's possible now to let the client get access without revealing anything about 
the user. Recommend that the above explanation be included so developers 
understand why the refresh tokens are there.
___
OAuth mailing list
OAuth@ietf.orgmailto:OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Refresh Tokens

[Anthony Nadalin]

Anonymity was certainly part of the design for WRAP

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

Section 1.5 already covers refresh tokens. There are many use cases for refresh 
tokens. They are basically a protocol feature used to make scalability and 
security more flexible. Anonymity was never part of their design, and by the 
nature of this protocol, is more in the domain of the resource server (based on 
what information it exposes via its API). In fact, your email if the first such 
suggestion of anonymity.

EHL

From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt dick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) 
oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens

Many reasons, but none are explained in the specification

From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked 
by not issuing new access tokens. A resource does not need to query the 
authorization server to see if the access token is valid.This simplifies access 
token validation and makes it easier to scale and support multiple 
authorization servers.  There is a window of time when an access token is 
valid, but authorization is revoked.



On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:



Nowhere in the specification is there explanation for refresh tokens, The 
reason that the Refresh token was introduced was for anonymity. The scenario is 
that a client asks the user for access. The user wants to grant the access but 
not tell the client the user's identity. By issuing the refresh token as an 
'identifier' for the user (as well as other context data like the resource) 
it's possible now to let the client get access without revealing anything about 
the user. Recommend that the above explanation be included so developers 
understand why the refresh tokens are there.
___
OAuth mailing list
OAuth@ietf.orgmailto:OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Refresh Tokens

[Anthony Nadalin]

Section 1.5 does not explain why refresh tokens are there. If implementers 
don't understand why we did something then how are they supposed to get the 
implementation right?

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

Section 1.5 already covers refresh tokens. There are many use cases for refresh 
tokens. They are basically a protocol feature used to make scalability and 
security more flexible. Anonymity was never part of their design, and by the 
nature of this protocol, is more in the domain of the resource server (based on 
what information it exposes via its API). In fact, your email if the first such 
suggestion of anonymity.

EHL

From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt dick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) 
oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens

Many reasons, but none are explained in the specification

From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked 
by not issuing new access tokens. A resource does not need to query the 
authorization server to see if the access token is valid.This simplifies access 
token validation and makes it easier to scale and support multiple 
authorization servers.  There is a window of time when an access token is 
valid, but authorization is revoked.



On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:



Nowhere in the specification is there explanation for refresh tokens, The 
reason that the Refresh token was introduced was for anonymity. The scenario is 
that a client asks the user for access. The user wants to grant the access but 
not tell the client the user's identity. By issuing the refresh token as an 
'identifier' for the user (as well as other context data like the resource) 
it's possible now to let the client get access without revealing anything about 
the user. Recommend that the above explanation be included so developers 
understand why the refresh tokens are there.
___
OAuth mailing list
OAuth@ietf.orgmailto:OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Refresh Tokens

[Dick Hardt]

If it was, no one told me.

On 2011-08-11, at 12:41 PM, Anthony Nadalin wrote:

 Anonymity was certainly part of the design for WRAP
  
 From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] 
 Sent: Thursday, August 11, 2011 12:35 PM
 To: Anthony Nadalin; Dick Hardt
 Cc: OAuth WG (oauth@ietf.org)
 Subject: Re: [OAUTH-WG] Refresh Tokens
  
 Section 1.5 already covers refresh tokens. There are many use cases for 
 refresh tokens. They are basically a protocol feature used to make 
 scalability and security more flexible. Anonymity was never part of their 
 design, and by the nature of this protocol, is more in the domain of the 
 resource server (based on what information it exposes via its API). In fact, 
 your email if the first such suggestion of anonymity.
  
 EHL
  
 From: Anthony Nadalin tony...@microsoft.com
 Date: Thu, 11 Aug 2011 11:15:28 -0700
 To: Dick Hardt dick.ha...@gmail.com
 Cc: OAuth WG (oauth@ietf.org) oauth@ietf.org
 Subject: Re: [OAUTH-WG] Refresh Tokens
  
 Many reasons, but none are explained in the specification
  
 From: Dick Hardt [mailto:dick.ha...@gmail.com] 
 Sent: Thursday, August 11, 2011 10:51 AM
 To: Anthony Nadalin
 Cc: OAuth WG (oauth@ietf.org)
 Subject: Re: [OAUTH-WG] Refresh Tokens
  
 My recollection of refresh tokens was for security and revocation.
  
 security: By having a short lived access token, a compromised access token 
 would limit the time an attacker would have access
  
 revocation: if the access token is self contained, authorization can be 
 revoked by not issuing new access tokens. A resource does not need to query 
 the authorization server to see if the access token is valid.This simplifies 
 access token validation and makes it easier to scale and support multiple 
 authorization servers.  There is a window of time when an access token is 
 valid, but authorization is revoked. 
  
  
  
 On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:
 
 
 
 Nowhere in the specification is there explanation for refresh tokens, The 
 reason that the Refresh token was introduced was for anonymity. The scenario 
 is that a client asks the user for access. The user wants to grant the access 
 but not tell the client the user's identity. By issuing the refresh token as 
 an 'identifier' for the user (as well as other context data like the 
 resource) it's possible now to let the client get access without revealing 
 anything about the user. Recommend that the above explanation be included so 
 developers understand why the refresh tokens are there.
 ___
 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

Re: [OAUTH-WG] Refresh Tokens

[Anthony Nadalin]

Could be! But a definite from Yaron.

From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 1:25 PM
To: Anthony Nadalin
Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

If it was, no one told me.

On 2011-08-11, at 12:41 PM, Anthony Nadalin wrote:


Anonymity was certainly part of the design for WRAP

From: Eran Hammer-Lahav 
[mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

Section 1.5 already covers refresh tokens. There are many use cases for refresh 
tokens. They are basically a protocol feature used to make scalability and 
security more flexible. Anonymity was never part of their design, and by the 
nature of this protocol, is more in the domain of the resource server (based on 
what information it exposes via its API). In fact, your email if the first such 
suggestion of anonymity.

EHL

From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt dick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) 
oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens

Many reasons, but none are explained in the specification

From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked 
by not issuing new access tokens. A resource does not need to query the 
authorization server to see if the access token is valid.This simplifies access 
token validation and makes it easier to scale and support multiple 
authorization servers.  There is a window of time when an access token is 
valid, but authorization is revoked.



On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:




Nowhere in the specification is there explanation for refresh tokens, The 
reason that the Refresh token was introduced was for anonymity. The scenario is 
that a client asks the user for access. The user wants to grant the access but 
not tell the client the user's identity. By issuing the refresh token as an 
'identifier' for the user (as well as other context data like the resource) 
it's possible now to let the client get access without revealing anything about 
the user. Recommend that the above explanation be included so developers 
understand why the refresh tokens are there.
___
OAuth mailing list
OAuth@ietf.orgmailto:OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


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

Re: [OAUTH-WG] Refresh Tokens

[Eran Hammer-Lahav]

That's irrelevant given WRAP does not mention anonymity or anything else about 
refresh token not explicitly addressed already by v2. Your email is the very 
first time this has been raised on this list.

EHL

From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, Dick 
Hardt dick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) 
oauth@ietf.orgmailto:oauth@ietf.org
Subject: RE: [OAUTH-WG] Refresh Tokens

Anonymity was certainly part of the design for WRAP

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

Section 1.5 already covers refresh tokens. There are many use cases for refresh 
tokens. They are basically a protocol feature used to make scalability and 
security more flexible. Anonymity was never part of their design, and by the 
nature of this protocol, is more in the domain of the resource server (based on 
what information it exposes via its API). In fact, your email if the first such 
suggestion of anonymity.

EHL

From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt dick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) 
oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens

Many reasons, but none are explained in the specification

From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked 
by not issuing new access tokens. A resource does not need to query the 
authorization server to see if the access token is valid.This simplifies access 
token validation and makes it easier to scale and support multiple 
authorization servers.  There is a window of time when an access token is 
valid, but authorization is revoked.



On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:



Nowhere in the specification is there explanation for refresh tokens, The 
reason that the Refresh token was introduced was for anonymity. The scenario is 
that a client asks the user for access. The user wants to grant the access but 
not tell the client the user's identity. By issuing the refresh token as an 
'identifier' for the user (as well as other context data like the resource) 
it's possible now to let the client get access without revealing anything about 
the user. Recommend that the above explanation be included so developers 
understand why the refresh tokens are there.
___
OAuth mailing list
OAuth@ietf.orgmailto:OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Refresh Tokens

[Anthony Nadalin]

There are no use cases at all in WRAP to help explain choices taken, it does 
not matter if there were or were not previous issues raised, it is being raised 
now.

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 1:46 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

That's irrelevant given WRAP does not mention anonymity or anything else about 
refresh token not explicitly addressed already by v2. Your email is the very 
first time this has been raised on this list.

EHL

From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, Dick 
Hardt dick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) 
oauth@ietf.orgmailto:oauth@ietf.org
Subject: RE: [OAUTH-WG] Refresh Tokens

Anonymity was certainly part of the design for WRAP

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

Section 1.5 already covers refresh tokens. There are many use cases for refresh 
tokens. They are basically a protocol feature used to make scalability and 
security more flexible. Anonymity was never part of their design, and by the 
nature of this protocol, is more in the domain of the resource server (based on 
what information it exposes via its API). In fact, your email if the first such 
suggestion of anonymity.

EHL

From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt dick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) 
oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens

Many reasons, but none are explained in the specification

From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked 
by not issuing new access tokens. A resource does not need to query the 
authorization server to see if the access token is valid.This simplifies access 
token validation and makes it easier to scale and support multiple 
authorization servers.  There is a window of time when an access token is 
valid, but authorization is revoked.



On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:




Nowhere in the specification is there explanation for refresh tokens, The 
reason that the Refresh token was introduced was for anonymity. The scenario is 
that a client asks the user for access. The user wants to grant the access but 
not tell the client the user's identity. By issuing the refresh token as an 
'identifier' for the user (as well as other context data like the resource) 
it's possible now to let the client get access without revealing anything about 
the user. Recommend that the above explanation be included so developers 
understand why the refresh tokens are there.
___
OAuth mailing list
OAuth@ietf.orgmailto:OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Refresh Tokens

[William J. Mills]

I maintain my opinion that anonymity be discussed in the security 
considerations section.  For the purposes of the spec tokens are opaque strings 
not intended to be parsed by the client.




From: Anthony Nadalin tony...@microsoft.com
To: Eran Hammer-Lahav e...@hueniverse.com; Dick Hardt dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.org) oauth@ietf.org
Sent: Thursday, August 11, 2011 1:51 PM
Subject: Re: [OAUTH-WG] Refresh Tokens


 
There are no use cases at all in WRAP to help explain choices taken, it does 
not matter if there were or were not previous issues raised, it is being raised 
now.
 
From:Eran Hammer-Lahav [mailto:e...@hueniverse.com] 
Sent: Thursday, August 11, 2011 1:46 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
 
That's irrelevant given WRAP does not mention anonymity or anything else about 
refresh token not explicitly addressed already by v2. Your email is the very 
first time this has been raised on this list.
 
EHL
 
From: Anthony Nadalin tony...@microsoft.com
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav e...@hueniverse.com, Dick Hardt dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.org) oauth@ietf.org
Subject: RE: [OAUTH-WG] Refresh Tokens
 
Anonymity was certainly part of the design for WRAP
 
From:Eran Hammer-Lahav [mailto:e...@hueniverse.com] 
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
 
Section 1.5 already covers refresh tokens. There are many use cases for 
refresh tokens. They are basically a protocol feature used to make scalability 
and security more flexible. Anonymity was never part of their design, and by 
the nature of this protocol, is more in the domain of the resource server 
(based on what information it exposes via its API). In fact, your email if the 
first such suggestion of anonymity.
 
EHL
 
From: Anthony Nadalin tony...@microsoft.com
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.org) oauth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens
 
Many reasons, but none are explained in the specification
 
From:Dick Hardt [mailto:dick.ha...@gmail.com] 
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
 
My recollection of refresh tokens was for security and revocation.
 
security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access
 
revocation: if the access token is self contained, authorization can be 
revoked by not issuing new access tokens. A resource does not need to query 
the authorization server to see if the access token is valid.This simplifies 
access token validation and makes it easier to scale and support multiple 
authorization servers.  There is a window of time when an access token is 
valid, but authorization is revoked. 
 
 
 
On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:





Nowhere in the specification is there explanation for refresh tokens, The 
reason that the Refresh token was introduced was for anonymity. The scenario 
is that a client asks the user for access. The user wants to grant the access 
but not tell the client the user's identity. By issuing the refresh token as 
an 'identifier' for the user (as well as other context data like the 
resource) it's possible now to let the client get access without revealing 
anything about the user. Recommend that the above explanation be included so 
developers understand why the refresh tokens are there.
___
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

Re: [OAUTH-WG] Refresh Tokens

[Eran Hammer-Lahav]

1. Process-wise it does. This is a brand new concept *here* and was not 
mentioned in the charter or any use cases. Therefore, out of scope.

2. The current text provides all the information needed to imement. No one 
raised an implementation issue on the current text.

3. Refresh token do not provide anonymity. An implementation could but this was 
never considered in the design.

4. If you have suggested text, present it before the WGLC is over. I am not 
adding issues to my list without suggested text and wg consensus.

EHL

On Aug 11, 2011, at 17:44, Anthony Nadalin 
tony...@microsoft.commailto:tony...@microsoft.com wrote:

There are no use cases at all in WRAP to help explain choices taken, it does 
not matter if there were or were not previous issues raised, it is being raised 
now.

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 1:46 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

That's irrelevant given WRAP does not mention anonymity or anything else about 
refresh token not explicitly addressed already by v2. Your email is the very 
first time this has been raised on this list.

EHL

From: Anthony Nadalin 
mailto:tony...@microsoft.comtony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav 
mailto:e...@hueniverse.come...@hueniverse.commailto:e...@hueniverse.com, 
Dick Hardt 
mailto:dick.ha...@gmail.comdick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org) 
mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org
Subject: RE: [OAUTH-WG] Refresh Tokens

Anonymity was certainly part of the design for WRAP

From: Eran Hammer-Lahav [mailto:e...@hueniverse.commailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

Section 1.5 already covers refresh tokens. There are many use cases for refresh 
tokens. They are basically a protocol feature used to make scalability and 
security more flexible. Anonymity was never part of their design, and by the 
nature of this protocol, is more in the domain of the resource server (based on 
what information it exposes via its API). In fact, your email if the first such 
suggestion of anonymity.

EHL

From: Anthony Nadalin 
mailto:tony...@microsoft.comtony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt 
mailto:dick.ha...@gmail.comdick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org) 
mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens

Many reasons, but none are explained in the specification

From: Dick Hardt [mailto:dick.ha...@gmail.commailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked 
by not issuing new access tokens. A resource does not need to query the 
authorization server to see if the access token is valid.This simplifies access 
token validation and makes it easier to scale and support multiple 
authorization servers.  There is a window of time when an access token is 
valid, but authorization is revoked.



On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:




Nowhere in the specification is there explanation for refresh tokens, The 
reason that the Refresh token was introduced was for anonymity. The scenario is 
that a client asks the user for access. The user wants to grant the access but 
not tell the client the user's identity. By issuing the refresh token as an 
'identifier' for the user (as well as other context data like the resource) 
it's possible now to let the client get access without revealing anything about 
the user. Recommend that the above explanation be included so developers 
understand why the refresh tokens are there.
___
OAuth mailing list
mailto:OAuth@ietf.orgOAuth@ietf.orgmailto:OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauthhttps://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Refresh Tokens

[Anthony Nadalin]

I’m raising the issue on the current text, I already provided text if the 
original append.

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 3:03 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

1. Process-wise it does. This is a brand new concept *here* and was not 
mentioned in the charter or any use cases. Therefore, out of scope.

2. The current text provides all the information needed to imement. No one 
raised an implementation issue on the current text.

3. Refresh token do not provide anonymity. An implementation could but this was 
never considered in the design.

4. If you have suggested text, present it before the WGLC is over. I am not 
adding issues to my list without suggested text and wg consensus.

EHL

On Aug 11, 2011, at 17:44, Anthony Nadalin 
tony...@microsoft.commailto:tony...@microsoft.com wrote:
There are no use cases at all in WRAP to help explain choices taken, it does 
not matter if there were or were not previous issues raised, it is being raised 
now.

From: Eran Hammer-Lahav 
[mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 1:46 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

That's irrelevant given WRAP does not mention anonymity or anything else about 
refresh token not explicitly addressed already by v2. Your email is the very 
first time this has been raised on this list.

EHL

From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, Dick 
Hardt dick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) 
oauth@ietf.orgmailto:oauth@ietf.org
Subject: RE: [OAUTH-WG] Refresh Tokens

Anonymity was certainly part of the design for WRAP

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

Section 1.5 already covers refresh tokens. There are many use cases for refresh 
tokens. They are basically a protocol feature used to make scalability and 
security more flexible. Anonymity was never part of their design, and by the 
nature of this protocol, is more in the domain of the resource server (based on 
what information it exposes via its API). In fact, your email if the first such 
suggestion of anonymity.

EHL

From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt dick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) 
oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens

Many reasons, but none are explained in the specification

From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked 
by not issuing new access tokens. A resource does not need to query the 
authorization server to see if the access token is valid.This simplifies access 
token validation and makes it easier to scale and support multiple 
authorization servers.  There is a window of time when an access token is 
valid, but authorization is revoked.



On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:





Nowhere in the specification is there explanation for refresh tokens, The 
reason that the Refresh token was introduced was for anonymity. The scenario is 
that a client asks the user for access. The user wants to grant the access but 
not tell the client the user's identity. By issuing the refresh token as an 
'identifier' for the user (as well as other context data like the resource) 
it's possible now to let the client get access without revealing anything about 
the user. Recommend that the above explanation be included so developers 
understand why the refresh tokens are there.
___
OAuth mailing list
OAuth@ietf.orgmailto:OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Refresh Tokens

[Eran Hammer-Lahav]

The text is wrong. This is not why refresh tokens were introduced (originally 
by Yahoo then in WRAP). And is also technically unfounded. Refresh tokens have 
no special anonymity properties.

EHL

On Aug 11, 2011, at 18:18, Anthony Nadalin 
tony...@microsoft.commailto:tony...@microsoft.com wrote:

I’m raising the issue on the current text, I already provided text if the 
original append.

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 3:03 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

1. Process-wise it does. This is a brand new concept *here* and was not 
mentioned in the charter or any use cases. Therefore, out of scope.

2. The current text provides all the information needed to imement. No one 
raised an implementation issue on the current text.

3. Refresh token do not provide anonymity. An implementation could but this was 
never considered in the design.

4. If you have suggested text, present it before the WGLC is over. I am not 
adding issues to my list without suggested text and wg consensus.

EHL

On Aug 11, 2011, at 17:44, Anthony Nadalin 
mailto:tony...@microsoft.comtony...@microsoft.commailto:tony...@microsoft.com
 wrote:
There are no use cases at all in WRAP to help explain choices taken, it does 
not matter if there were or were not previous issues raised, it is being raised 
now.

From: Eran Hammer-Lahav 
[mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 1:46 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

That's irrelevant given WRAP does not mention anonymity or anything else about 
refresh token not explicitly addressed already by v2. Your email is the very 
first time this has been raised on this list.

EHL

From: Anthony Nadalin 
mailto:tony...@microsoft.comtony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav 
mailto:e...@hueniverse.come...@hueniverse.commailto:e...@hueniverse.com, 
Dick Hardt 
mailto:dick.ha...@gmail.comdick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org) 
mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org
Subject: RE: [OAUTH-WG] Refresh Tokens

Anonymity was certainly part of the design for WRAP

From: Eran Hammer-Lahav [mailto:e...@hueniverse.commailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

Section 1.5 already covers refresh tokens. There are many use cases for refresh 
tokens. They are basically a protocol feature used to make scalability and 
security more flexible. Anonymity was never part of their design, and by the 
nature of this protocol, is more in the domain of the resource server (based on 
what information it exposes via its API). In fact, your email if the first such 
suggestion of anonymity.

EHL

From: Anthony Nadalin 
mailto:tony...@microsoft.comtony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt 
mailto:dick.ha...@gmail.comdick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org) 
mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens

Many reasons, but none are explained in the specification

From: Dick Hardt [mailto:dick.ha...@gmail.commailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked 
by not issuing new access tokens. A resource does not need to query the 
authorization server to see if the access token is valid.This simplifies access 
token validation and makes it easier to scale and support multiple 
authorization servers.  There is a window of time when an access token is 
valid, but authorization is revoked.



On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:





Nowhere in the specification is there explanation for refresh tokens, The 
reason that the Refresh token was introduced was for anonymity. The scenario is 
that a client asks the user for access. The user wants to grant the access but 
not tell the client the user's identity. By issuing the refresh token as an 
'identifier' for the user (as well as other context data like the resource) 
it's possible now to let the client get access without revealing anything

Re: [OAUTH-WG] Refresh Tokens

[Anthony Nadalin]

Disagree, this was our rational and this is one way it’s used today with our 
scenarios. This needs to be assigned an issue.

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 3:39 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

The text is wrong. This is not why refresh tokens were introduced (originally 
by Yahoo then in WRAP). And is also technically unfounded. Refresh tokens have 
no special anonymity properties.

EHL

On Aug 11, 2011, at 18:18, Anthony Nadalin 
tony...@microsoft.commailto:tony...@microsoft.com wrote:
I’m raising the issue on the current text, I already provided text if the 
original append.

From: Eran Hammer-Lahav 
[mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 3:03 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

1. Process-wise it does. This is a brand new concept *here* and was not 
mentioned in the charter or any use cases. Therefore, out of scope.

2. The current text provides all the information needed to imement. No one 
raised an implementation issue on the current text.

3. Refresh token do not provide anonymity. An implementation could but this was 
never considered in the design.

4. If you have suggested text, present it before the WGLC is over. I am not 
adding issues to my list without suggested text and wg consensus.

EHL

On Aug 11, 2011, at 17:44, Anthony Nadalin 
tony...@microsoft.commailto:tony...@microsoft.com wrote:
There are no use cases at all in WRAP to help explain choices taken, it does 
not matter if there were or were not previous issues raised, it is being raised 
now.

From: Eran Hammer-Lahav 
[mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 1:46 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

That's irrelevant given WRAP does not mention anonymity or anything else about 
refresh token not explicitly addressed already by v2. Your email is the very 
first time this has been raised on this list.

EHL

From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, Dick 
Hardt dick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) 
oauth@ietf.orgmailto:oauth@ietf.org
Subject: RE: [OAUTH-WG] Refresh Tokens

Anonymity was certainly part of the design for WRAP

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

Section 1.5 already covers refresh tokens. There are many use cases for refresh 
tokens. They are basically a protocol feature used to make scalability and 
security more flexible. Anonymity was never part of their design, and by the 
nature of this protocol, is more in the domain of the resource server (based on 
what information it exposes via its API). In fact, your email if the first such 
suggestion of anonymity.

EHL

From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt dick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) 
oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens

Many reasons, but none are explained in the specification

From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked 
by not issuing new access tokens. A resource does not need to query the 
authorization server to see if the access token is valid.This simplifies access 
token validation and makes it easier to scale and support multiple 
authorization servers.  There is a window of time when an access token is 
valid, but authorization is revoked.



On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:






Nowhere in the specification is there explanation for refresh tokens, The 
reason that the Refresh token was introduced was for anonymity. The scenario is 
that a client asks the user for access. The user wants to grant the access but 
not tell the client the user's identity. By issuing the refresh token as an 
'identifier' for the user (as well as other context data like the resource) 
it's possible now to let the client get access without revealing anything about

Re: [OAUTH-WG] Refresh Tokens

[William J. Mills]

It's implementation specific.  You can choose to make them anonymous or you can 
issue signed plaintext tokens that conceal nothing.  The spec doesn't care.  
It's a security consideration of the end implementation, just like the need for 
tamper protection.  The spec needs only to define them as opaque blobs with a 
particular syntax.  We are not specifying what encryption you have to use here, 
and we should not.





From: Anthony Nadalin tony...@microsoft.com
To: Eran Hammer-Lahav e...@hueniverse.com
Cc: OAuth WG (oauth@ietf.org) oauth@ietf.org
Sent: Thursday, August 11, 2011 3:45 PM
Subject: Re: [OAUTH-WG] Refresh Tokens


 
Disagree, this was our rational and this is one way it’s used today with our 
scenarios. This needs to be assigned an issue.
 
From:Eran Hammer-Lahav [mailto:e...@hueniverse.com] 
Sent: Thursday, August 11, 2011 3:39 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
 
The text is wrong. This is not why refresh tokens were introduced (originally 
by Yahoo then in WRAP). And is also technically unfounded. Refresh tokens have 
no special anonymity properties. 
 
EHL

On Aug 11, 2011, at 18:18, Anthony Nadalin tony...@microsoft.com wrote:
I’m raising the issue on the current text, I already provided text if the 
original append.  
 
From:Eran Hammer-Lahav [mailto:e...@hueniverse.com] 
Sent: Thursday, August 11, 2011 3:03 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
 
1. Process-wise it does. This is a brand new concept *here* and was not 
mentioned in the charter or any use cases. Therefore, out of scope. 
 
2. The current text provides all the information needed to imement. No one 
raised an implementation issue on the current text.
 
3. Refresh token do not provide anonymity. An implementation could but this 
was never considered in the design. 
 
4. If you have suggested text, present it before the WGLC is over. I am not 
adding issues to my list without suggested text and wg consensus. 
 
EHL

On Aug 11, 2011, at 17:44, Anthony Nadalin tony...@microsoft.com wrote:
There are no use cases at all in WRAP to help explain choices taken, it does 
not matter if there were or were not previous issues raised, it is being 
raised now.
 
From:Eran Hammer-Lahav [mailto:e...@hueniverse.com] 
Sent: Thursday, August 11, 2011 1:46 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
 
That's irrelevant given WRAP does not mention anonymity or anything else 
about refresh token not explicitly addressed already by v2. Your email is the 
very first time this has been raised on this list.
 
EHL
 
From: Anthony Nadalin tony...@microsoft.com
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav e...@hueniverse.com, Dick Hardt dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.org) oauth@ietf.org
Subject: RE: [OAUTH-WG] Refresh Tokens
 
Anonymity was certainly part of the design for WRAP
 
From:Eran Hammer-Lahav [mailto:e...@hueniverse.com] 
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
 
Section 1.5 already covers refresh tokens. There are many use cases for 
refresh tokens. They are basically a protocol feature used to make 
scalability and security more flexible. Anonymity was never part of their 
design, and by the nature of this protocol, is more in the domain of the 
resource server (based on what information it exposes via its API). In fact, 
your email if the first such suggestion of anonymity.
 
EHL
 
From: Anthony Nadalin tony...@microsoft.com
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt dick.ha...@gmail.com
Cc: OAuth WG (oauth@ietf.org) oauth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens
 
Many reasons, but none are explained in the specification
 
From:Dick Hardt [mailto:dick.ha...@gmail.com] 
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
 
My recollection of refresh tokens was for security and revocation.
 
security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access
 
revocation: if the access token is self contained, authorization can be 
revoked by not issuing new access tokens. A resource does not need to query 
the authorization server to see if the access token is valid.This 
simplifies access token validation and makes it easier to scale and support 
multiple authorization servers.  There is a window of time when an access 
token is valid, but authorization is revoked. 
 
 
 
On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:







Nowhere in the specification is there explanation for refresh tokens, The 
reason that the Refresh token was introduced was for anonymity. The 
scenario is that a client asks the user for access. The user

Re: [OAUTH-WG] Refresh Tokens

[Eran Hammer-Lahav]

Your original post does not explain how anonymity is achieved or what it 
actually means.

Not wearing my editor heat I'm strongly opposed to this entire concept.

EHL

On Aug 11, 2011, at 18:49, Anthony Nadalin 
tony...@microsoft.commailto:tony...@microsoft.com wrote:

Disagree, this was our rational and this is one way it’s used today with our 
scenarios. This needs to be assigned an issue.

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 3:39 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

The text is wrong. This is not why refresh tokens were introduced (originally 
by Yahoo then in WRAP). And is also technically unfounded. Refresh tokens have 
no special anonymity properties.

EHL

On Aug 11, 2011, at 18:18, Anthony Nadalin 
mailto:tony...@microsoft.comtony...@microsoft.commailto:tony...@microsoft.com
 wrote:
I’m raising the issue on the current text, I already provided text if the 
original append.

From: Eran Hammer-Lahav 
[mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 3:03 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG 
(mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

1. Process-wise it does. This is a brand new concept *here* and was not 
mentioned in the charter or any use cases. Therefore, out of scope.

2. The current text provides all the information needed to imement. No one 
raised an implementation issue on the current text.

3. Refresh token do not provide anonymity. An implementation could but this was 
never considered in the design.

4. If you have suggested text, present it before the WGLC is over. I am not 
adding issues to my list without suggested text and wg consensus.

EHL

On Aug 11, 2011, at 17:44, Anthony Nadalin 
mailto:tony...@microsoft.comtony...@microsoft.commailto:tony...@microsoft.com
 wrote:
There are no use cases at all in WRAP to help explain choices taken, it does 
not matter if there were or were not previous issues raised, it is being raised 
now.

From: Eran Hammer-Lahav 
[mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 1:46 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

That's irrelevant given WRAP does not mention anonymity or anything else about 
refresh token not explicitly addressed already by v2. Your email is the very 
first time this has been raised on this list.

EHL

From: Anthony Nadalin 
mailto:tony...@microsoft.comtony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav 
mailto:e...@hueniverse.come...@hueniverse.commailto:e...@hueniverse.com, 
Dick Hardt 
mailto:dick.ha...@gmail.comdick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org) 
mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org
Subject: RE: [OAUTH-WG] Refresh Tokens

Anonymity was certainly part of the design for WRAP

From: Eran Hammer-Lahav [mailto:e...@hueniverse.commailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

Section 1.5 already covers refresh tokens. There are many use cases for refresh 
tokens. They are basically a protocol feature used to make scalability and 
security more flexible. Anonymity was never part of their design, and by the 
nature of this protocol, is more in the domain of the resource server (based on 
what information it exposes via its API). In fact, your email if the first such 
suggestion of anonymity.

EHL

From: Anthony Nadalin 
mailto:tony...@microsoft.comtony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt 
mailto:dick.ha...@gmail.comdick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org) 
mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens

Many reasons, but none are explained in the specification

From: Dick Hardt [mailto:dick.ha...@gmail.commailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked 
by not issuing new access tokens. A resource does not need to query the 
authorization server to see if the access token is valid.This simplifies access

Re: [OAUTH-WG] Refresh Tokens

[Eran Hammer-Lahav]

I strongly agree. I don't see what value there is in discussing anonymity which 
brings identity into the spec without any justification.

EHL

On Aug 11, 2011, at 19:26, William J. Mills 
wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com wrote:

It's implementation specific.  You can choose to make them anonymous or you can 
issue signed plaintext tokens that conceal nothing.  The spec doesn't care.  
It's a security consideration of the end implementation, just like the need for 
tamper protection.  The spec needs only to define them as opaque blobs with a 
particular syntax.  We are not specifying what encryption you have to use here, 
and we should not.




From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
To: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com
Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) 
oauth@ietf.orgmailto:oauth@ietf.org
Sent: Thursday, August 11, 2011 3:45 PM
Subject: Re: [OAUTH-WG] Refresh Tokens

Disagree, this was our rational and this is one way it’s used today with our 
scenarios. This needs to be assigned an issue.

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 3:39 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

The text is wrong. This is not why refresh tokens were introduced (originally 
by Yahoo then in WRAP). And is also technically unfounded. Refresh tokens have 
no special anonymity properties.

EHL

On Aug 11, 2011, at 18:18, Anthony Nadalin 
mailto:tony...@microsoft.comtony...@microsoft.commailto:tony...@microsoft.com
 wrote:
I’m raising the issue on the current text, I already provided text if the 
original append.

From: Eran Hammer-Lahav 
[mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 3:03 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG 
(mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

1. Process-wise it does. This is a brand new concept *here* and was not 
mentioned in the charter or any use cases. Therefore, out of scope.

2. The current text provides all the information needed to imement. No one 
raised an implementation issue on the current text.

3. Refresh token do not provide anonymity. An implementation could but this was 
never considered in the design.

4. If you have suggested text, present it before the WGLC is over. I am not 
adding issues to my list without suggested text and wg consensus.

EHL

On Aug 11, 2011, at 17:44, Anthony Nadalin 
mailto:tony...@microsoft.comtony...@microsoft.commailto:tony...@microsoft.com
 wrote:
There are no use cases at all in WRAP to help explain choices taken, it does 
not matter if there were or were not previous issues raised, it is being raised 
now.

From: Eran Hammer-Lahav 
[mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 1:46 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

That's irrelevant given WRAP does not mention anonymity or anything else about 
refresh token not explicitly addressed already by v2. Your email is the very 
first time this has been raised on this list.

EHL

From: Anthony Nadalin 
mailto:tony...@microsoft.comtony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav 
mailto:e...@hueniverse.come...@hueniverse.commailto:e...@hueniverse.com, 
Dick Hardt 
mailto:dick.ha...@gmail.comdick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org) 
mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org
Subject: RE: [OAUTH-WG] Refresh Tokens

Anonymity was certainly part of the design for WRAP

From: Eran Hammer-Lahav [mailto:e...@hueniverse.commailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

Section 1.5 already covers refresh tokens. There are many use cases for refresh 
tokens. They are basically a protocol feature used to make scalability and 
security more flexible. Anonymity was never part of their design, and by the 
nature of this protocol, is more in the domain of the resource server (based on 
what information it exposes via its API). In fact, your email if the first such 
suggestion of anonymity.

EHL

From: Anthony Nadalin 
mailto:tony...@microsoft.comtony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt 
mailto:dick.ha...@gmail.comdick.ha...@gmail.commailto:dick.ha...@gmail.com
Cc: OAuth WG (mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org) 
mailto:oauth@ietf.orgoauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens

Re: [OAUTH-WG] Refresh Tokens

[David Recordon]

Agreed as well on this being implementation specific. Also don't
remember ever seeing anonymity mentioned as a use case.


On Thu, Aug 11, 2011 at 4:28 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
 I strongly agree. I don't see what value there is in discussing anonymity
 which brings identity into the spec without any justification.
 EHL

 On Aug 11, 2011, at 19:26, William J. Mills wmi...@yahoo-inc.com wrote:

 It's implementation specific.  You can choose to make them anonymous or you
 can issue signed plaintext tokens that conceal nothing.  The spec doesn't
 care.  It's a security consideration of the end implementation, just like
 the need for tamper protection.  The spec needs only to define them as
 opaque blobs with a particular syntax.  We are not specifying what
 encryption you have to use here, and we should not.


 
 From: Anthony Nadalin tony...@microsoft.com
 To: Eran Hammer-Lahav e...@hueniverse.com
 Cc: OAuth WG (oauth@ietf.org) oauth@ietf.org
 Sent: Thursday, August 11, 2011 3:45 PM
 Subject: Re: [OAUTH-WG] Refresh Tokens

 Disagree, this was our rational and this is one way it’s used today with our
 scenarios. This needs to be assigned an issue.

 From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
 Sent: Thursday, August 11, 2011 3:39 PM
 To: Anthony Nadalin
 Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
 Subject: Re: [OAUTH-WG] Refresh Tokens

 The text is wrong. This is not why refresh tokens were introduced
 (originally by Yahoo then in WRAP). And is also technically unfounded.
 Refresh tokens have no special anonymity properties.

 EHL

 On Aug 11, 2011, at 18:18, Anthony Nadalin tony...@microsoft.com wrote:

 I’m raising the issue on the current text, I already provided text if the
 original append.

 From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
 Sent: Thursday, August 11, 2011 3:03 PM
 To: Anthony Nadalin
 Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
 Subject: Re: [OAUTH-WG] Refresh Tokens

 1. Process-wise it does. This is a brand new concept *here* and was not
 mentioned in the charter or any use cases. Therefore, out of scope.

 2. The current text provides all the information needed to imement. No one
 raised an implementation issue on the current text.

 3. Refresh token do not provide anonymity. An implementation could but this
 was never considered in the design.

 4. If you have suggested text, present it before the WGLC is over. I am not
 adding issues to my list without suggested text and wg consensus.

 EHL
 On Aug 11, 2011, at 17:44, Anthony Nadalin tony...@microsoft.com wrote:

 There are no use cases at all in WRAP to help explain choices taken, it does
 not matter if there were or were not previous issues raised, it is being
 raised now.

 From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
 Sent: Thursday, August 11, 2011 1:46 PM
 To: Anthony Nadalin; Dick Hardt
 Cc: OAuth WG (oauth@ietf.org)
 Subject: Re: [OAUTH-WG] Refresh Tokens

 That's irrelevant given WRAP does not mention anonymity or anything else
 about refresh token not explicitly addressed already by v2. Your email is
 the very first time this has been raised on this list.

 EHL

 From: Anthony Nadalin tony...@microsoft.com
 Date: Thu, 11 Aug 2011 12:41:28 -0700
 To: Eran Hammer-lahav e...@hueniverse.com, Dick Hardt
 dick.ha...@gmail.com
 Cc: OAuth WG (oauth@ietf.org) oauth@ietf.org
 Subject: RE: [OAUTH-WG] Refresh Tokens


 Anonymity was certainly part of the design for WRAP

 From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
 Sent: Thursday, August 11, 2011 12:35 PM
 To: Anthony Nadalin; Dick Hardt
 Cc: OAuth WG (oauth@ietf.org)
 Subject: Re: [OAUTH-WG] Refresh Tokens

 Section 1.5 already covers refresh tokens. There are many use cases for
 refresh tokens. They are basically a protocol feature used to make
 scalability and security more flexible. Anonymity was never part of their
 design, and by the nature of this protocol, is more in the domain of the
 resource server (based on what information it exposes via its API). In fact,
 your email if the first such suggestion of anonymity.

 EHL

 From: Anthony Nadalin tony...@microsoft.com
 Date: Thu, 11 Aug 2011 11:15:28 -0700
 To: Dick Hardt dick.ha...@gmail.com
 Cc: OAuth WG (oauth@ietf.org) oauth@ietf.org
 Subject: Re: [OAUTH-WG] Refresh Tokens


 Many reasons, but none are explained in the specification

 From: Dick Hardt [mailto:dick.ha...@gmail.com]
 Sent: Thursday, August 11, 2011 10:51 AM
 To: Anthony Nadalin
 Cc: OAuth WG (oauth@ietf.org)
 Subject: Re: [OAUTH-WG] Refresh Tokens

 My recollection of refresh tokens was for security and revocation.

 security: By having a short lived access token, a compromised access token
 would limit the time an attacker would have access

 revocation: if the access token is self contained, authorization can be
 revoked by not issuing new access tokens. A resource does not need to query
 the authorization server to see if the access token is valid.This simplifies
 access

Re: [OAUTH-WG] Refresh Tokens

[Aiden Bell]

I have been following this thread with my jaw slightly open...

As an implementor, the purpose of the refresh token I felt was clear in 1.5.
I just don't see the anonymity
slant here at all ... any more than any other part of the spec. It all
depends on what your service/api or
whatever allows for a faceless authorisation session.

I'm with anyone who thinks it belongs well away from the spec.


On 12 August 2011 00:28, Eran Hammer-Lahav e...@hueniverse.com wrote:

 I strongly agree. I don't see what value there is in discussing anonymity
 which brings identity into the spec without any justification.

 EHL


 On Aug 11, 2011, at 19:26, William J. Mills wmi...@yahoo-inc.com
 wrote:

 It's implementation specific.  You can choose to make them anonymous or you
 can issue signed plaintext tokens that conceal nothing.  The spec doesn't
 care.  It's a security consideration of the end implementation, just like
 the need for tamper protection.  The spec needs only to define them as
 opaque blobs with a particular syntax.  We are not specifying what
 encryption you have to use here, and we should not.



 --
 *From:* Anthony Nadalin tony...@microsoft.com
 *To:* Eran Hammer-Lahav e...@hueniverse.com
 *Cc:* OAuth WG (oauth@ietf.org) oauth@ietf.org
 *Sent:* Thursday, August 11, 2011 3:45 PM
 *Subject:* Re: [OAUTH-WG] Refresh Tokens

  Disagree, this was our rational and this is one way it’s used today with
 our scenarios. This needs to be assigned an issue.

  *From:* Eran Hammer-Lahav [mailto:e...@hueniverse.com]
 *Sent:* Thursday, August 11, 2011 3:39 PM
 *To:* Anthony Nadalin
 *Cc:* Dick Hardt; OAuth WG (oauth@ietf.org)
 *Subject:* Re: [OAUTH-WG] Refresh Tokens

  The text is wrong. This is not why refresh tokens were introduced
 (originally by Yahoo then in WRAP). And is also technically unfounded.
 Refresh tokens have no special anonymity properties.

  EHL

 On Aug 11, 2011, at 18:18, Anthony Nadalin  tony...@microsoft.com
 tony...@microsoft.com wrote:

  I’m raising the issue on the current text, I already provided text if the
 original append.

  *From:* Eran Hammer-Lahav [mailto:e...@hueniverse.com]
 *Sent:* Thursday, August 11, 2011 3:03 PM
 *To:* Anthony Nadalin
 *Cc:* Dick Hardt; OAuth WG ( oauth@ietf.orgoauth@ietf.org)
 *Subject:* Re: [OAUTH-WG] Refresh Tokens

  1. Process-wise it does. This is a brand new concept *here* and was not
 mentioned in the charter or any use cases. Therefore, out of scope.

  2. The current text provides all the information needed to imement. No
 one raised an implementation issue on the current text.

  3. Refresh token do not provide anonymity. An implementation could but
 this was never considered in the design.

  4. If you have suggested text, present it before the WGLC is over. I am
 not adding issues to my list without suggested text and wg consensus.

  EHL

 On Aug 11, 2011, at 17:44, Anthony Nadalin  tony...@microsoft.com
 tony...@microsoft.com wrote:

  There are no use cases at all in WRAP to help explain choices taken, it
 does not matter if there were or were not previous issues raised, it is
 being raised now.

  *From:* Eran Hammer-Lahav [mailto:e...@hueniverse.com]
 *Sent:* Thursday, August 11, 2011 1:46 PM
 *To:* Anthony Nadalin; Dick Hardt
 *Cc:* OAuth WG ( oauth@ietf.orgoauth@ietf.org)
 *Subject:* Re: [OAUTH-WG] Refresh Tokens

  That's irrelevant given WRAP does not mention anonymity or anything else
 about refresh token not explicitly addressed already by v2. Your email is
 the very first time this has been raised on this list.

  EHL

  *From: *Anthony Nadalin  tony...@microsoft.comtony...@microsoft.com
 *Date: *Thu, 11 Aug 2011 12:41:28 -0700
 *To: *Eran Hammer-lahav  e...@hueniverse.come...@hueniverse.com, Dick
 Hardt  dick.ha...@gmail.comdick.ha...@gmail.com
 *Cc: *OAuth WG ( oauth@ietf.orgoauth@ietf.org)  oauth@ietf.org
 oauth@ietf.org
 *Subject: *RE: [OAUTH-WG] Refresh Tokens


  Anonymity was certainly part of the design for WRAP

  *From:* Eran Hammer-Lahav [ e...@hueniverse.com
 mailto:e...@hueniverse.com e...@hueniverse.com]
 *Sent:* Thursday, August 11, 2011 12:35 PM
 *To:* Anthony Nadalin; Dick Hardt
 *Cc:* OAuth WG ( oauth@ietf.orgoauth@ietf.org)
 *Subject:* Re: [OAUTH-WG] Refresh Tokens

  Section 1.5 already covers refresh tokens. There are many use cases for
 refresh tokens. They are basically a protocol feature used to make
 scalability and security more flexible. Anonymity was never part of their
 design, and by the nature of this protocol, is more in the domain of the
 resource server (based on what information it exposes via its API). In fact,
 your email if the first such suggestion of anonymity.

  EHL

  *From: *Anthony Nadalin  tony...@microsoft.comtony...@microsoft.com
 *Date: *Thu, 11 Aug 2011 11:15:28 -0700
 *To: *Dick Hardt  dick.ha...@gmail.comdick.ha...@gmail.com
 *Cc: *OAuth WG ( oauth@ietf.orgoauth@ietf.org)  oauth@ietf.org
 oauth@ietf.org
 *Subject: *Re: [OAUTH-WG] Refresh Tokens


  Many

Re: [OAUTH-WG] Refresh Tokens

[Barry Leiba]

This seems to need a chair to step in.  Tony is taking a strong stand
and maintaining it:

On Thu, Aug 11, 2011 at 1:40 PM, Anthony Nadalin tony...@microsoft.com wrote:
 Nowhere in the specification is there explanation for refresh tokens, The
 reason that the Refresh token was introduced was for anonymity. The scenario
 is that a client asks the user for access. The user wants to grant the
 access but not tell the client the user's identity. By issuing the refresh
 token as an 'identifier' for the user (as well as other context data like
 the resource) it's possible now to let the client get access without
 revealing anything about the user. Recommend that the above explanation be
 included so developers understand why the refresh tokens are there.

So far, though it's been only half a day, I've seen several posts
disagreeing with Tony, and none supporting any change to the text for
this.  We're close to ending WGLC, so please post here if you agree
with Tony's suggested change.  Otherwise, it looks like consensus is
against.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh tokens

[Lodderstedt, Torsten]

+1

Von: Brian Eaton [mailto:bea...@google.com]
Gesendet: Mittwoch, 15. Juni 2011 20:33
An: Eran Hammer-Lahav
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] Refresh tokens

On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav 
e...@hueniverse.commailto:e...@hueniverse.com wrote:
I would like to add a quick discussion of access token and refresh token 
recommended deployment setup, providing clear guidelines when a refresh token 
SHOULD and SHOULD NOT be issued, and when issues, how it is difference from the 
access token.

Is this a start?

http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html

It's time we stop trying to accommodate every possible combination and make 
some hard choices.

+1.  Yes please.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh tokens

[Eran Hammer-Lahav]

Yes, this is useful and on my list of changes to apply.

But I would like to start with a more basic, normative definition of what a 
refresh token is for. Right now, we have a very vague definition for it, and it 
is not clear how developers should use it alongside access tokens.

EHL

From: Brian Eaton [mailto:bea...@google.com]
Sent: Wednesday, June 15, 2011 11:33 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Refresh tokens

On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav 
e...@hueniverse.commailto:e...@hueniverse.com wrote:
I would like to add a quick discussion of access token and refresh token 
recommended deployment setup, providing clear guidelines when a refresh token 
SHOULD and SHOULD NOT be issued, and when issues, how it is difference from the 
access token.

Is this a start?

http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html

It's time we stop trying to accommodate every possible combination and make 
some hard choices.

+1.  Yes please.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh tokens

[Kris Selden]

There is a scalability reason, in that the access_token could be verifiable on 
the resource server without DB lookup or a call out to a central server, then 
the refresh token serves as the means for revoking in the an access token good 
for an hour, with a refresh token good for a year or good-till-revoked.

There is a security reason, the refresh_token is only ever exchanged with 
authorization server whereas the access_token is exchanged with resource 
servers.  This mitigates the risk of a long-lived access_token leaking (query 
param in a log file on an insecure resource server, beta or poorly coded 
resource server app, JS SDK client on a non https site that puts the 
access_token in a cookie, etc) in the an access token good for an hour, with a 
refresh token good for a year or good-till-revoked vs an access token 
good-till-revoked without a refresh token.

On Jun 15, 2011, at 11:56 AM, Eran Hammer-Lahav wrote:

 Yes, this is useful and on my list of changes to apply.
  
 But I would like to start with a more basic, normative definition of what a 
 refresh token is for. Right now, we have a very vague definition for it, and 
 it is not clear how developers should use it alongside access tokens.
  
 EHL
  

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

Re: [OAUTH-WG] Refresh tokens

[Eran Hammer-Lahav]

And we need to say that explicitly.

Even if we allow servers to use the two tokens differently, we should clearly 
state their design considerations and apply any needed restrictions to make 
that clear. We are leaving way too much to the whims of the individual 
developer.

Are the access tokens issued using the implicit grant short lived or long lived?
Is it valid to issue valid-till-revoked access tokens alongside refresh tokens?
What are the requirements for allowing resource owners to revoke access, when 
it comes to issued access tokens and refresh tokens?
Why even issue a refresh token, if the client can authenticate with the 
authorization server. Why not just include the client identifier and user 
identifier and let the authorization server lookup what the user already 
authorized? Yes, this requires different client identifiers for different 
access rights, but that's easy to do.

There are many more open questions. I have been convinced from reading the last 
80 or so messages on the list, that we have given developers too much 
flexibility. We're at a point where I am no longer sure what's the right way of 
deploying this. I would like to see use enforce a common-sense approach to 
deploying these tokens, based on the collective wisdom and deployment 
experience of this group. We have enough hands-on knowledge to agree on how to 
narrow this down.

I am not looking for dramatic changes. I'm looking for restrictions. I want the 
protocol to be more helpful to developers who are not security experts to make 
the right decisions, and that includes me.

Yes, some use cases will suffer, but that's just what standards are about.

EHL



From: Kris Selden [mailto:kris.sel...@gmail.com]
Sent: Wednesday, June 15, 2011 12:21 PM
To: Eran Hammer-Lahav
Cc: Brian Eaton; OAuth WG
Subject: Re: [OAUTH-WG] Refresh tokens

There is a scalability reason, in that the access_token could be verifiable on 
the resource server without DB lookup or a call out to a central server, then 
the refresh token serves as the means for revoking in the an access token good 
for an hour, with a refresh token good for a year or good-till-revoked.

There is a security reason, the refresh_token is only ever exchanged with 
authorization server whereas the access_token is exchanged with resource 
servers.  This mitigates the risk of a long-lived access_token leaking (query 
param in a log file on an insecure resource server, beta or poorly coded 
resource server app, JS SDK client on a non https site that puts the 
access_token in a cookie, etc) in the an access token good for an hour, with a 
refresh token good for a year or good-till-revoked vs an access token 
good-till-revoked without a refresh token.

On Jun 15, 2011, at 11:56 AM, Eran Hammer-Lahav wrote:


Yes, this is useful and on my list of changes to apply.

But I would like to start with a more basic, normative definition of what a 
refresh token is for. Right now, we have a very vague definition for it, and it 
is not clear how developers should use it alongside access tokens.

EHL


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

Re: [OAUTH-WG] Refresh tokens

[William J. Mills]

I like your draft in general, but 


 10.1.3. Access Tokens

 Access tokens are shorter-lived versions of refresh tokens.

Doesn't work for me.  Access tokens are credentials used to access protected 
resources.  Refresh 
tokens are credentials used to obtain access tokens.

-bill




From: Brian Eaton bea...@google.com
To: Eran Hammer-Lahav e...@hueniverse.com
Cc: OAuth WG oauth@ietf.org
Sent: Wednesday, June 15, 2011 11:32 AM
Subject: Re: [OAUTH-WG] Refresh tokens


On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:

I would like to add a quick discussion of access token and refresh token 
recommended deployment setup, providing clear guidelines when a refresh token 
SHOULD and SHOULD NOT be issued, and when issues, how it is difference from the 
access token.

Is this a start?

http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html
  
It’s time we stop trying to accommodate every possible combination and make 
some hard choices.

+1.  Yes please.
___
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

Re: [OAUTH-WG] Refresh tokens

[Brian Eaton]

Yeah, I agree with that change.

On Wed, Jun 15, 2011 at 1:24 PM, William J. Mills wmi...@yahoo-inc.comwrote:

 I like your draft in general, but


  10.1.3. Access Tokens

  Access tokens are shorter-lived versions of refresh tokens.

 Doesn't work for me.  Access tokens are credentials used to access protected 
 resources.  Refresh
 tokens are credentials used to obtain access tokens.

 -bill


 --
 *From:* Brian Eaton bea...@google.com
 *To:* Eran Hammer-Lahav e...@hueniverse.com
 *Cc:* OAuth WG oauth@ietf.org
 *Sent:* Wednesday, June 15, 2011 11:32 AM

 *Subject:* Re: [OAUTH-WG] Refresh tokens

 On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav 
 e...@hueniverse.comwrote:

 I would like to add a quick discussion of access token and refresh token
 recommended deployment setup, providing clear guidelines when a refresh
 token SHOULD and SHOULD NOT be issued, and when issues, how it is difference
 from the access token.


 Is this a start?

 http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html


 **
 It’s time we stop trying to accommodate every possible combination and make
 some hard choices.
 **


 +1.  Yes please.

 ___
 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

Re: [OAUTH-WG] Refresh tokens security enhancement

[Eran Hammer-Lahav]

Draft -02 made this possible already.

I added the following text:

The authorization server MAY issue a new refresh token in which case 
the client MUST NOT
use the previous refresh token and replace it with the newly issued 
refresh token.

EHL

 -Original Message-
 From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
 Of Torsten Lodderstedt
 Sent: Wednesday, May 05, 2010 12:28 PM
 To: Marius Scurtescu
 Cc: OAuth WG (oauth@ietf.org)
 Subject: Re: [OAUTH-WG] Refresh tokens security enhancement
 
 Am 04.05.2010 21:44, schrieb Marius Scurtescu:
  On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt
  tors...@lodderstedt.net  wrote:
 
  Am 03.05.2010 18:55, schrieb Allen Tom:
 
  Invalidating the Refresh Token (and presumably also invalidating any
  outstanding Access Tokens) would make sense as an option for
  applications that require a high level of security. However, I do
  not think that invalidating the Refresh Token on every Refresh
  request should be required in the spec - it should be an implementation
 specific detail.
 
 
  It could be an optional feature of the spec (as many other features).
 
  Torsten, can you please have a look a the explicit request for
  refresh token thread?
 
  Would a refresh_token_type=single parameter solve the above?
 
 
  Marius
 
 
 Hi Marius,
 
 I expected the authorization server to decide which kind of token to use.
 Your proposal makes sense as well.
 So the client can act according to its security requirements. If the
 authorization server would like to enforce its own policy, it can detect any
 mismatch during token issuance.
 
 Nevertheless, support for the optional refresh_token response parameter
 of the refresh request is the prerequisite.
 
 regards,
 Torsten.
 
 
 ___
 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

Re: [OAUTH-WG] Refresh tokens security enhancement

[Eran Hammer-Lahav]

The text is in -04. -02 made the refresh token available in token refresh.

EHL

 -Original Message-
 From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
 Sent: Sunday, May 09, 2010 2:57 PM
 To: Eran Hammer-Lahav
 Cc: OAuth WG (oauth@ietf.org)
 Subject: Re: [OAUTH-WG] Refresh tokens security enhancement
 
 Hi Eran,
 
 I cannot find this text in -02 or -03. Would you please refer my to the
 respective page/section?
 
 regads,
 Torsten.
 
 Am 09.05.2010 19:56, schrieb Eran Hammer-Lahav:
  Draft -02 made this possible already.
 
  I added the following text:
 
   The authorization server MAY issue a new refresh token in which 
  case
 the client MUST NOT
   use the previous refresh token and replace it with the newly issued
 refresh token.
 
  EHL
 
 
  -Original Message-
  From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
  Behalf Of Torsten Lodderstedt
  Sent: Wednesday, May 05, 2010 12:28 PM
  To: Marius Scurtescu
  Cc: OAuth WG (oauth@ietf.org)
  Subject: Re: [OAUTH-WG] Refresh tokens security enhancement
 
  Am 04.05.2010 21:44, schrieb Marius Scurtescu:
 
  On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt
  tors...@lodderstedt.net   wrote:
 
 
  Am 03.05.2010 18:55, schrieb Allen Tom:
 
 
  Invalidating the Refresh Token (and presumably also invalidating
  any outstanding Access Tokens) would make sense as an option for
  applications that require a high level of security. However, I do
  not think that invalidating the Refresh Token on every Refresh
  request should be required in the spec - it should be an
  implementation
 
  specific detail.
 
 
 
  It could be an optional feature of the spec (as many other features).
 
 
  Torsten, can you please have a look a the explicit request for
  refresh token thread?
 
  Would a refresh_token_type=single parameter solve the above?
 
 
  Marius
 
 
  Hi Marius,
 
  I expected the authorization server to decide which kind of token to use.
  Your proposal makes sense as well.
  So the client can act according to its security requirements. If the
  authorization server would like to enforce its own policy, it can
  detect any mismatch during token issuance.
 
  Nevertheless, support for the optional refresh_token response
  parameter of the refresh request is the prerequisite.
 
  regards,
  Torsten.
 
 
  ___
  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

Re: [OAUTH-WG] Refresh tokens security enhancement

[Torsten Lodderstedt]

Am 04.05.2010 21:44, schrieb Marius Scurtescu:

On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt
tors...@lodderstedt.net  wrote:
   

Am 03.05.2010 18:55, schrieb Allen Tom:
 

Invalidating the Refresh Token (and presumably also invalidating any
outstanding Access Tokens) would make sense as an option for applications
that require a high level of security. However, I do not think that
invalidating the Refresh Token on every Refresh request should be required
in the spec - it should be an implementation specific detail.

   

It could be an optional feature of the spec (as many other features).
 

Torsten, can you please have a look a the explicit request for
refresh token thread?

Would a refresh_token_type=single parameter solve the above?


Marius
   


Hi Marius,

I expected the authorization server to decide which kind of token to 
use. Your proposal makes sense as well.
So the client can act according to its security requirements. If the 
authorization server would like to enforce its

own policy, it can detect any mismatch during token issuance.

Nevertheless, support for the optional refresh_token response 
parameter of the refresh request is the prerequisite.


regards,
Torsten.


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

Re: [OAUTH-WG] Refresh tokens security enhancement

[Torsten Lodderstedt]

Hi Allen,

Am 03.05.2010 18:55, schrieb Allen Tom:

Hi Torsten,

Thanks for posting this idea - I think that issuing a new Refresh Token (and
invalidating the old one) on every refresh request would help detect token
theft.

HOWEVER - in practice, this mechanism could make implementations very
tricky. For example, some  applications are highly distributed, with each
instance (or component) having its own copy of the Refresh Token. Keeping
the Refresh Token in sync would not really be feasible for these types of
apps.
   


You are right, this approach might make implementing a client more 
difficult, especially clustered web applications.
That's not the case for autonomous devices (gaming consoles, mobile 
phones e.t.c) where the application
architecture will typically be much simpler. On the other hand, these 
are exactly the clients where the current
version of the specification does not contain any countermeasure against 
token theft.



Invalidating the Refresh Token (and presumably also invalidating any
outstanding Access Tokens) would make sense as an option for applications
that require a high level of security. However, I do not think that
invalidating the Refresh Token on every Refresh request should be required
in the spec - it should be an implementation specific detail.
   


It could be an optional feature of the spec (as many other features). An 
authorization server could decide
when to use it based on its policy. For example, the authorization 
server could make this decision
depend on client type (mobile vs. web application), client id, or target 
service (security level).


The definition could be as follows

 refresh_token
 OPTIONAL.  A new refresh token replacing the refresh_token 
used as input parameter.
 If set, the client must use this token for the next refresh 
request. The former refresh

 token has been invalidated by the authorization server.

The benefit of making it an (optional) spec feature is support by 
libraries, standard service and
applications. From my point of view, OAuth2 has the potential to become 
THE standard for
securing standard protocols like IMAP, SyncML, SIP, WebDav and many 
others. Every feature
defined by the standard is most likely supported by standard clients and 
servers. So depending
on the authorization servers policy, all of this clients could be 
secured with the proposed

countermeasure.



At Yahoo, we've used the Refresh Flow for all of our proprietary
authorization APIs for many years, and I know of several applications which
would break if the Refresh Token (and Access Token) were invalidated on
every refresh request. Off the top of my head, I know of server based apps,
mobile apps, and desktop apps which are composed of several components which
asynchronously and independently keep their own copies of the user's
credentials.
   


As I said, it could be an optional feature, which offers out of the box 
token theft prevention. Every

deployment can decide to use it or not.

The proposed change is small in terms of specification but we could 
demonstrate that OAuth is also

suited for applications with a higher level of security.

regards,
Torsten.


Thanks
Allen






On 5/2/10 10:48 AM, Torsten Lodderstedttors...@lodderstedt.net  wrote:

   

We came up with the following idea:

The authorization server automatically creates a new refresh token with
every refresh request (section 4) and invalidated the previous refresh
token. The client must use this new token for the next refresh
request. All attempts to obtain access tokens with an invalidated
refresh token are refused. Additionally, the authorization server should
hold a history of when the refresh token has been used. The client
application behavior depends on who uses the refresh token first after
it has been stolen.
 
   



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

Re: [OAUTH-WG] Refresh tokens security enhancement

[Marius Scurtescu]

On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
 Am 03.05.2010 18:55, schrieb Allen Tom:
 Invalidating the Refresh Token (and presumably also invalidating any
 outstanding Access Tokens) would make sense as an option for applications
 that require a high level of security. However, I do not think that
 invalidating the Refresh Token on every Refresh request should be required
 in the spec - it should be an implementation specific detail.


 It could be an optional feature of the spec (as many other features).

Torsten, can you please have a look a the explicit request for
refresh token thread?

Would a refresh_token_type=single parameter solve the above?


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

Re: [OAUTH-WG] Refresh tokens security enhancement

[Allen Tom]

Hi Torsten,

Thanks for posting this idea - I think that issuing a new Refresh Token (and
invalidating the old one) on every refresh request would help detect token
theft.

HOWEVER - in practice, this mechanism could make implementations very
tricky. For example, some  applications are highly distributed, with each
instance (or component) having its own copy of the Refresh Token. Keeping
the Refresh Token in sync would not really be feasible for these types of
apps.

Invalidating the Refresh Token (and presumably also invalidating any
outstanding Access Tokens) would make sense as an option for applications
that require a high level of security. However, I do not think that
invalidating the Refresh Token on every Refresh request should be required
in the spec - it should be an implementation specific detail.

At Yahoo, we've used the Refresh Flow for all of our proprietary
authorization APIs for many years, and I know of several applications which
would break if the Refresh Token (and Access Token) were invalidated on
every refresh request. Off the top of my head, I know of server based apps,
mobile apps, and desktop apps which are composed of several components which
asynchronously and independently keep their own copies of the user's
credentials.

Thanks
Allen






On 5/2/10 10:48 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote:

 We came up with the following idea:
 
 The authorization server automatically creates a new refresh token with
 every refresh request (section 4) and invalidated the previous refresh
 token. The client must use this new token for the next refresh
 request. All attempts to obtain access tokens with an invalidated
 refresh token are refused. Additionally, the authorization server should
 hold a history of when the refresh token has been used. The client
 application behavior depends on who uses the refresh token first after
 it has been stolen.

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