Subject: [OAUTH-WG] Consistency across access token replies

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Apr 2010 13:51:01 -0700

Right now most of the flows return the same parameters (access token,
expiration, refresh token). A few do not return a refresh token. When we add
signatures, we will need to add token secret and algorithm type.

I know there are good reasons why certain flows do not return a refresh
token but instead rely on the client repeating the request. However, there
is a lot of value in simplicity and consistency in making every request
return the same parameters.

It will also allow specifying it one time instead of over and over again.

Thoughts?

EHL

---

From: Dick Hardt <[email-masked]>
Date: Wed, 7 Apr 2010 20:05:42 -0700

I would envision that the requests from different flows will have a different mode value, which makes them uniquely different requests for the AS.

I think returning a refresh token when it can't be used will lead to confusion for Client and AS developers.

-- Dick

On 2010-04-07, at 1:51 PM, Eran Hammer-Lahav wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Sarah Faulkner <[email-masked]>
Date: Wed, 7 Apr 2010 20:23:24 -0700

I think it depends on which profiles we end up with. If we have the web and
rich client profiles from Dick's WRAP draft plus the JS profile from David's
draft, I would want to return the refresh token with the first two profiles
but not with the third. Since our refresh tokens are going to be very long
lived in most cases (months), I'd like to promote that they are kept
server-side. I don't want to return the refresh token to the client in the
JS profile and have it sent to the server over HTTP or set in a cookie.

At the very least, I would like the refresh token return to be optional if
it's not returned in a server-to-server or to a device that has secure
storage.

This brings up the question of the device profile -- there are some devices
(ex. xbox) that have a way to secure the refresh token, there are others
that do not. It may be good to either allow the device to self-declare (in
the request, specifically ask for the refresh token) or allow the provider
to optionally return the refresh token based on what they know about the
device.

On Wed, Apr 7, 2010 at 8:05 PM, Dick Hardt <[email-masked]> wrote:

> I would envision that the requests from different flows will have a
> different mode value, which makes them uniquely different requests for the
> AS.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Apr 2010 23:13:04 -0700

My point is simple. *Server* should be allowed to include a refresh token
with every access token issued. It is already optional everywhere it is
included. What I suggested is to allow it to be optional everywhere.

If the server doesn't support refresh tokens for some flows, it should
simply not provide one. Its a deployment decision. Nowhere in the spec can
the client demand it so this is purely a server deployment decision.

If my server supports refresh tokens in the client credentials flow or
assertion flow, it should be allowed to issue one. What is the gain from
forbidding it? The gain from allowing it (as optional) is consistency and
simplicity. What's the gain from not letting servers decide?

EHL

On 4/7/10 8:23 PM, "Sarah Faulkner" <[email-masked]> wrote:

> server-side. I don't want to return the refresh token to the client in the JS
> profile and have it sent to the server over HTTP or set in a cookie.
>  
> (ex. xbox) that have a way to secure the refresh token, there are others that
> do not. It may be good to either allow the device to self-declare (in the
> request, specifically ask for the refresh token) or allow the provider to
> optionally return the refresh token based on what they know about the device.
> 
> 
>> I would envision that the requests from different flows will have a different
>> mode value, which makes them uniquely different requests for the AS.
>>

---

From: David Recordon <[email-masked]>
Date: Thu, 8 Apr 2010 09:35:13 -0700

+1, I support servers being allowed to optionally include refresh
tokens with every access token.

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 8 Apr 2010 11:03:34 -0700

> simplicity. What's the gain from not letting servers decide?

Would it make sense to allow the client to explicitly request a
refresh token and potentially have one returned only in this case?

If the client will not use a refresh token then by telling this to the
authorization server both security and load on the server are
improved. Managing these tokens on the server is quite expensive. If
some implementation of the User-Agent flow, for example, cannot use
these refresh tokens then it would be much preferred to not even send
them back.

Marius

---

From: Sarah Faulkner <[email-masked]>
Date: Thu, 8 Apr 2010 12:43:00 -0700

Yes, I don't see a problem with returning the refresh token with every
access token response as long as its optional.

On Wed, Apr 7, 2010 at 11:13 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> that
> different

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 8 Apr 2010 15:36:21 -0700

This seems reasonable, but it does add more complexity for the client. The thing is, there is no point in a refresh token if the token lifetime is the same as the access grant. Should the server ignore the client's request in such cases?

EHL

On 4/8/10 11:03 AM, "Marius Scurtescu" <[email-masked]> wrote:

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 8 Apr 2010 16:25:29 -0700

On Thu, Apr 8, 2010 at 3:36 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> This seems reasonable, but it does add more complexity for the client.

True, but not that much. Just an extra request parameter if it wants a
refresh token. Default could be "no".

> The
> thing is, there is no point in a refresh token if the token lifetime is the
> same as the access grant. Should the server ignore the client’s request in
> such cases?

Lost you. What do you mean by access grant? The refresh token is
probably unlimited, at least long lived. The client cannot control the
lifetime of the access token either.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 8 Apr 2010 17:01:11 -0700

> refresh token. Default could be "no".

Its a growing list... :-)

If the client can ask for a refresh token, why not also let it ask for a
secret in each flow, and a username, and specific UI, etc. At some point we
cross a line and the protocol becomes complex (even if rich). I'm asking
where that line is, and if this qualifies as worth of extra complexity. I
don't have an answer.

>> same as the access grant. Should the server ignore the client¹s request in
>> such cases?
> 

User approves access to his resources for 2 weeks (the access grant). The
server issues an access token good for 2 weeks. The client asked for a
refresh token (not knowing it is pointless). What should the server do?

EHL

---

From: David Recordon <[email-masked]>
Date: Fri, 9 Apr 2010 08:51:23 +0100

> where that line is, and if this qualifies as worth of extra complexity. I

I'm also prefer to reduce the number of parameters. If an AS returns a
refresh token and the Client chooses to ignore it, that's easy code to
write. :)

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 09 Apr 2010 09:53:11 +0200

> refresh token and the Client chooses to ignore it, that's easy code to

the same holds for token secrets, why not returning them with every 
response?

regards,
Torsten.

---

From: "Shafi, Saleem" <[email-masked]>
Date: Tue, 13 Apr 2010 07:48:48 -0700

Hello..

Despite the fact that it might complicate the spec, I would like to see the ability to get a token secret without having to make an extra refresh token request..  if "secret_type" were added to the request parameters in 3.4.1.2 (Client Requests Access Token), the response could contain the token secret instead of the refresh_token..  Perhaps it isn't as clean in other flows, but at least in this one, I think it's worthwhile..

Not only would this match the interactions in Oauth 1.0 better (easy migration path for those wanting to adopt 2.0), but it eliminates an extra API call..  I imagine that refresh tokens and token secrets are generally mutually-exlusive..  It's unlikely that I will need to expire an access token that is properly signed, so no need for a refresh token..  But, the way the spec is written now, I'm forced to deal with a refresh token just to get the secret, which feels a bit strange..

Though the spec might be simpler as-is, implementation won't be easier for the folks wanting to use token secrets..  Providers will have to manage a new type of token, or at least pretend to (make the refresh and access tokens the same)..  And clients will have to make an extra API call per flow execution for no discernable benefit..

My 2 cents,

Saleem.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Friday, April 09, 2010 2:53 AM
To: David Recordon
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Consistency across access token replies

>> If the client can ask for a refresh token, why not also let it ask 
>> for a secret in each flow, and a username, and specific UI, etc. At 
>> some point we cross a line and the protocol becomes complex (even if 
>> rich). I'm asking where that line is, and if this qualifies as worth 
>> of extra complexity. I don't have an answer.
>>      

the same holds for token secrets, why not returning them with every response?

regards,
Torsten.