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

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

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


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 tim

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 at

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 just

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 r

Re: [OAUTH-WG] Refresh tokens

[George Fletcher]

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

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 shorte

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 access

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

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

[OAUTH-WG] Refresh tokens

[Leo Tohill]

Ok, I'm creating a new posting for this feedback. :)

Here's where I probably just need some enlightenment, so please help me
out.

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

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?

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

I'd say that A is safer. (Unless, when the refresh token is used, a new
refresh token is issued, the NEW refresh token gets another 1 hour.  If
this is the case, one could maintain refresh tokens infinitely. Is this
point addressed somewhere?)
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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  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=1&code=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
>> 
>> 

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

[John Bradley]

gt;> 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=1&code=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
> >>>>  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  >>>> <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 co

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

[Sergey Beryozkin]

rant 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
 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 
<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.
Madjid>>If 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.
Madjid>>agreed, 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.
Madjid>>Are 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.
Madjid>>I 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 
<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 

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

[Bill Mills]

e 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
>>>>  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 >>> <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.
>>>>>> Madjid>>If 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 

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=1&code=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 
>  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 
> mailto:m.nakhj...@samsung.com>  > 
> <mailto:m.nakhj...@samsung.com <mailto:m.nakhj...@samsung.com>>> wrote:
>  >
>  >> Hi J

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

[John Bradley]

t;>> 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
>>>>  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 >>> <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.
>>>>>> Madjid>>If 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.
>>>>>> Madjid>>agreed, but for the signed object to be self-sustained, again
>>>>>> would I not need something beyond a “population” client_ID

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

[Sergey Beryozkin]

 2014, at 1:24 PM, Madjid Nakhjiri 
<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.
Madjid>>If 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.
Madjid>>agreed, 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.
Madjid>>Are 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.
Madjid>>I 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 
<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:

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

[John Bradley]

On 27/06/14 19:21, John Bradley wrote:
>> > Inline
>> >
>> > On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri > <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.
>> >> Madjid>>If 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.
>> >> Madjid>>agreed, 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.
>> >> Madjid>>Are 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.
>> >> Madjid>>I 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 > <mailto:m.nakhj...@samsung.com>
>> >

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  
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=1&code=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
>  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  <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
&g

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=1&code=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
 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 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.
 >> Madjid>>If 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 endp

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  
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  <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.
>> Madjid>>If 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.
>> Madjid>>agreed, 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.
>> Madjid>>Are 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.
>> Madjid>>I 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 

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 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.
Madjid>>If 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.
Madjid>>agreed, 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.
Madjid>>Are 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.
Madjid>>I 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 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
sp

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

 

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

Madjid>>agreed, 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.

 

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

 

Madjid>>I 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)

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

[John Bradley]

Inline

On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri  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.
>  
> Madjid>>If 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. 
> Madjid>>agreed, 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.
>  
> Madjid>>Are 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.
>  
> Madjid>>I 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  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]

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.

 

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

Madjid>>agreed, 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.

 

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

 

Madjid>>I 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  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]

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.

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. 
The spec is silent on the exact programming method that the Authorization 
server uses.

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.

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

[OAUTH-WG] refresh tokens and client instances

[Madjid Nakhjiri]

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

Re: [OAUTH-WG] Refresh tokens

[Eran Hammer-Lahav]

Re: #5

It was part of section 4 but people found it more confusing.

EHL

From: William Mills mailto:wmi...@yahoo-inc.com>>
Reply-To: William Mills mailto:wmi...@yahoo-inc.com>>
Date: Mon, 28 Nov 2011 10:09:38 -0700
To: Bart Wiegmans mailto:b...@all4students.nl>>, oauth WG 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Refresh tokens

1&2) 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 mailto:b...@all4students.nl>>
To: oauth WG mailto: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> 
[mailto: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<http://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<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
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh tokens

[William Mills]

1&2) 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 
To: oauth WG  
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

[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

[OAUTH-WG] Refresh tokens

[Bart Wiegmans]

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

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

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



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

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

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

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

[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  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" 
> 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 
> *To:* Eran Hammer-Lahav 
> *Cc:* "OAuth WG (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
>
>  *F

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  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"  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 
> To: Eran Hammer-Lahav 
> Cc: "OAuth WG (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"  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"  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 
> Date: Thu, 11 Aug 2011 12:41:28 -0700
> To: Eran Hammer-lahav , Dick Hardt
> 
> Cc: "OAuth WG (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 
> Date: Thu, 11 Aug 2011 11:15:28 -0700
> To: Dick Hardt 
> Cc: "OAuth WG (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 to

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" 
mailto: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 mailto:tony...@microsoft.com>>
To: Eran Hammer-Lahav mailto:e...@hueniverse.com>>
Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" 
mailto: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<mailto: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.com>tony...@microsoft.com<mailto: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.org>oauth@ietf.org<mailto: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.com>tony...@microsoft.com<mailto: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.org>oauth@ietf.org<mailto: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.com>tony...@microsoft.com<mailto:tony...@microsoft.com>>
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav 
<<mailto:e...@hueniverse.com>e...@hueniverse.com<mailto:e...@hueniverse.com>>, 
Dick Hardt 
<<mailto:dick.ha...@gmail.com>dick.ha...@gmail.com<mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)" 
<<mailto:oauth@ietf.org>oauth@ietf.org<mailto: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>mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto: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.com>tony...@microsoft.com<mailto:tony...@microso

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" 
mailto: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.org<mailto: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.com>tony...@microsoft.com<mailto: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.org>oauth@ietf.org<mailto: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.com>tony...@microsoft.com<mailto: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.org>oauth@ietf.org<mailto: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.com>tony...@microsoft.com<mailto:tony...@microsoft.com>>
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav 
<<mailto:e...@hueniverse.com>e...@hueniverse.com<mailto:e...@hueniverse.com>>, 
Dick Hardt 
<<mailto:dick.ha...@gmail.com>dick.ha...@gmail.com<mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)" 
<<mailto:oauth@ietf.org>oauth@ietf.org<mailto: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>mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto: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.com>tony...@microsoft.com<mailto:tony...@microsoft.com>>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt 
<<mailto:dick.ha...@gmail.com>dick.ha...@gmail.com<mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)" 
<<mailto:oauth@ietf.org>oauth@ietf.org<mailto: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>mailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)
Subject: Re: [OAUTH-WG] Refresh Tokens

My recollection of

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 
To: Eran Hammer-Lahav 
Cc: "OAuth WG (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"  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"  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 
>>Date: Thu, 11 Aug 2011 12:41:28 -0700
>>To: Eran Hammer-lahav , Dick Hardt 
>>Cc: "OAuth WG (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 
>>>Date: Thu, 11 Aug 2011 11:15:28 -0700
>>>To: Dick Hardt 
>>>Cc: "OAuth WG (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 
>>>>r

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" 
mailto: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.org<mailto: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.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.org<mailto: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.com>>
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav mailto:e...@hueniverse.com>>, Dick 
Hardt mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" 
mailto: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<mailto: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.com>>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" 
mailto: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<mailto: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 cl

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" 
mailto: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<mailto: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.com>tony...@microsoft.com<mailto: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.org>oauth@ietf.org<mailto: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.com>tony...@microsoft.com<mailto:tony...@microsoft.com>>
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav 
<<mailto:e...@hueniverse.com>e...@hueniverse.com<mailto:e...@hueniverse.com>>, 
Dick Hardt 
<<mailto:dick.ha...@gmail.com>dick.ha...@gmail.com<mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)" 
<<mailto:oauth@ietf.org>oauth@ietf.org<mailto: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>mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto: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.com>tony...@microsoft.com<mailto:tony...@microsoft.com>>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt 
<<mailto:dick.ha...@gmail.com>dick.ha...@gmail.com<mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)" 
<<mailto:oauth@ietf.org>oauth@ietf.org<mailto: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>mailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto: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 introd

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" 
mailto: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.org<mailto: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.com>>
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav mailto:e...@hueniverse.com>>, Dick 
Hardt mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" 
mailto: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<mailto: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.com>>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" 
mailto: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<mailto: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<mailto: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" 
mailto: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<mailto: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.com>tony...@microsoft.com<mailto:tony...@microsoft.com>>
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav 
<<mailto:e...@hueniverse.com>e...@hueniverse.com<mailto:e...@hueniverse.com>>, 
Dick Hardt 
<<mailto:dick.ha...@gmail.com>dick.ha...@gmail.com<mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)" 
<<mailto:oauth@ietf.org>oauth@ietf.org<mailto: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>mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto: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.com>tony...@microsoft.com<mailto:tony...@microsoft.com>>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt 
<<mailto:dick.ha...@gmail.com>dick.ha...@gmail.com<mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)" 
<<mailto:oauth@ietf.org>oauth@ietf.org<mailto: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>mailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto: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.org>OAuth@ietf.org<mailto: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

[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 
To: Eran Hammer-Lahav ; Dick Hardt 
Cc: "OAuth WG (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 
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav , Dick Hardt 
Cc: "OAuth WG (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 
>Date: Thu, 11 Aug 2011 11:15:28 -0700
>To: Dick Hardt 
>Cc: "OAuth WG (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

[William J. Mills]

All I'm saying is that anonymity is not unique to refresh tokens, it's true for 
refresh and access tokens.




From: Anthony Nadalin 
To: Eran Hammer-Lahav ; Dick Hardt 
Cc: "OAuth WG (oauth@ietf.org)" 
Sent: Thursday, August 11, 2011 12:41 PM
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 
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt 
Cc: "OAuth WG (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

[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 mailto:tony...@microsoft.com>>
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav mailto:e...@hueniverse.com>>, Dick 
Hardt mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" 
mailto: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<mailto: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.com>>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" 
mailto: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<mailto: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<mailto: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 mailto:tony...@microsoft.com>>
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav mailto:e...@hueniverse.com>>, Dick 
Hardt mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" 
mailto: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<mailto: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.com>>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" 
mailto: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<mailto: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<mailto: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]

Reading over your anonymous story at at the bottom, I don't see what difference 
a refresh token has over an access token. You could do the same thing with just 
an access token. Am I missing something?

On 2011-08-11, at 1:30 PM, Anthony Nadalin wrote:

> 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] 
> 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 
> Date: Thu, 11 Aug 2011 11:15:28 -0700
> To: Dick Hardt 
> Cc: "OAuth WG (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.org<mailto: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.com>>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" 
mailto: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<mailto: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<mailto: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

[Peter Saint-Andre]

Maybe the feature was added anonymously. ;-)

On 8/11/11 2:25 PM, Dick Hardt wrote:
> 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

___
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 
> Date: Thu, 11 Aug 2011 11:15:28 -0700
> To: Dick Hardt 
> Cc: "OAuth WG (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]

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 mailto:tony...@microsoft.com>>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" 
mailto: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<mailto: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<mailto: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 mailto:tony...@microsoft.com>>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" 
mailto: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<mailto: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<mailto: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 mailto:tony...@microsoft.com>>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" 
mailto: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<mailto: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<mailto: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

[Justin Richer]

Isn't this what section 1.5 is already there for? 

   Refresh tokens are credentials used to obtain access tokens.  Refresh
   tokens are issued to the client by the authorization server and are
   used to obtain a new access token when the current access token
   becomes invalid or expires, or to obtain additional access tokens
   with identical or narrower scope (access tokens may have a shorter
   lifetime and fewer permissions than authorized by the resource
   owner).  Issuing a refresh token is optional and is included when
   issuing an access token.

   A refresh token is a string representing the authorization granted to
   the client by the resource owner.  The string is usually opaque to
   the client.  The token denotes an identifier used to retrieve the
   authorization information.  Unlike access tokens, refresh tokens are
   intended for use only with authorization servers and are never sent
   to resource servers.

What could make this text clearer? 

(Though while I'm here, I just noticed a nit: 
  "Issuing a refresh token is optional and is included when issuing an
access token." 

Could be clearer, as in something like: 

 "Issuing a refresh token is optional, but when one is issued it is
included along with an access token.")

 -- Justin

On Thu, 2011-08-11 at 14:21 -0400, William J. Mills wrote:
> Does it want to be in the main definition or the security
> considerations section?
> 
> 
> 
> 
> __
> From: Anthony Nadalin 
> To: Dick Hardt 
> Cc: "OAuth WG (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

[William J. Mills]

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




From: Anthony Nadalin 
To: Dick Hardt 
Cc: "OAuth WG (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

[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.org<mailto: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 
To: "OAuth WG (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

[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

[OAUTH-WG] Refresh Tokens

[Anthony Nadalin]

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

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

[Phil Hunt]

+ 1

Phil

@independentid
www.independentid.com
phil.h...@oracle.com





On 2011-06-15, at 1:39 PM, Brian Eaton wrote:

> Yeah, I agree with that change.
> 
> On Wed, Jun 15, 2011 at 1:24 PM, William J. Mills  
> wrote:
> 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 
> To: Eran Hammer-Lahav 
> Cc: OAuth WG 
> 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  
> 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

___
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 wrote:

> 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 
> *To:* Eran Hammer-Lahav 
> *Cc:* OAuth WG 
> *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 
> 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

[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 
To: Eran Hammer-Lahav 
Cc: OAuth WG 
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  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

[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

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

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

[Brian Eaton]

On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav 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-WG] Refresh tokens

[Eran Hammer-Lahav]

The main source of confusion about refresh token is caused by the protocol lack 
of clear definition of access token lifetime, even in relative terms, and the 
objectives of refresh tokens. For example, the authorization server can issue:

- an access token good for an hour, with a refresh token good for a year or 
good-till-revoked
- an access token good-till-revoked without a refresh token
- an access token good-till-revoked with a refresh token, used to obtain 
additional access tokens for a distributed environment

In large scale systems access tokens are often self-describing, including all 
the information needed by the resource server to validate them. In such a 
setup, access tokens cannot be revoked until expired. Refresh tokens on the 
other hand, require a database lookup for the resource owner grant, and can be 
revoked.

The only real difference between the implicit and authorization code grant 
types is the inclusion of a refresh token. The point is not to issue long term 
credentials without client authentication, relying on the presence of the 
resource owner for authenticating the client. However, we don't say that 
anywhere, or define the goals of the two token types design with enough detail 
to offer sound security.

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.

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

EHL



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

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

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

[Torsten Lodderstedt]

Am 04.05.2010 21:44, schrieb Marius Scurtescu:

On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt
  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

[Marius Scurtescu]

On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt
 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

[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 Lodderstedt"  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

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

[OAUTH-WG] Refresh tokens security enhancement

[Torsten Lodderstedt]

Hi all,

I discussed OAuth with some of the security experts here at Deutsche 
Telekom. We came up w/ an idea for enhancing refresh token handling I 
would like to discuss in the WG.


Assumption: refresh tokens have a very long duration (month to 
unlimited) and are stored at the client in a persistent storage (e.g. 
database or filesystem)

Question: How can token theft automatically be detected/prevented?

Let me detail the problem using three scenarios:

1) Client is a web site
Let's assume an attacker breaks into the server and gets access all 
tokens stored there along with the client's secret. Abuse could be 
prevented by changing the client secret, but this requires to _detect_ 
the theft first!


2) Mobile application/malware on same device
Let's assume an application on a mobile device, which stores refresh 
token(s) in the device's file system. A malware on the same device could 
read the token(s) from long-term storage and send it to a server under 
the attackers control. One could prevent such an attack by using a 
client secret (probably burned into the application), but that's not a 
very reliable measure. Filesystem security could be used to prevent 
eavesdropping, but its quality varies very much among mobile operating 
systems. The token could be invalidated by the user, after he/she 
realized the theft using some user self care function. But again, the 
theft has to be detected.


3) Mobile application/cloning device software and configuration
Someone could clone a device (operating system, configuration, 
applications and refresh tokens/client secrets) e.g. using a debug API 
when the user has left the device unattended. According to our experts, 
this does not take that much time and is typically not detectable 
afterwards. The clone could be run on another device identical  in 
construction and could be used to access all applications on behalf of 
the legitimate end user.
As a possible countermeasure, one could bind a refresh token to a device 
specific properties, e.g. the IMEI - International Mobile Station 
Equipment Identity. But not every device has a 3G module and access to 
this data might not be possible on some platforms.


The impact of all attacks illustrated above strongly depends on the 
power associated with a token. As soon as the attacker is able to spend 
the end user's money or gets access to medical records it's getting 
serious!


All countermeasures mentioned on the scenarios are either out of reach 
of the Oauth spec, platform specific, or not very effective. What we 
would like to achive is an automatic detection and at best prevention of 
such attacks.


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.


a) If the end user uses the refresh token first, the stolen token is 
invalidated automatically, any attempts of the attacker to obtain an 
access token are refused by the authorization server.
b) Attacker uses the token first: The end users application attempts to 
obtain an access token using the (already invalidated) refresh token are 
refused. The client should notify the user of the problem and recomend 
him/her to check its application authorizations (refresh tokens) in a 
user self care portal. There, the user should have acces to information 
on when the token has been used the last time and therewith detect any 
odd behavior. The user could then revoke the token and/or alarm its 
providers helpdesk.


We think the proposed change to the API would significantly contribute 
to the overall security level of OAuth.


Thoughts?

regards,
Torsten.

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