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 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
