+1, I support servers being allowed to optionally include refresh tokens with every access token.
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 > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
