On Thu, Apr 8, 2010 at 3:36 PM, Eran Hammer-Lahav <[email protected]> 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 > > EHL > > > On 4/8/10 11:03 AM, "Marius Scurtescu" <[email protected]> wrote: > > 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? > > 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 > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
