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 protected]>wrote: > 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 protected]> wrote: > > > 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 protected]> 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. > >> > >> 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: > >> > >>> 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 > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> _______________________________________________ > >> OAuth mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
