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
