On Sun, May 9, 2010 at 2:00 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > Seems like extra complexity for little gain. The only benefit is saving > server resources when a refresh token isn't going to be used by the client, > but since most clients are likely to use it, the saving isn't much.
You could be right, it all depends on how many clients will end up ignoring the refresh token. The only flow where most clients will probably ignore a refresh token, if ever sent by authz servers, is User-Agent. Saving server resources is one advantage, the other is making the flows a bit more secure, less chance to leak a very powerful token. Marius > > EHL > >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Marius Scurtescu >> Sent: Tuesday, May 04, 2010 11:41 AM >> To: OAuth WG >> Subject: [OAUTH-WG] explicit request for refresh token >> >> Currently all flows return an optional refresh token and I think it was >> mentioned that the Autonomous Client flows should never return a refresh >> token. >> >> While a refresh token will probably be used in most cases by the other flows, >> in some cases the refresh token will be just ignored by the client. Ideally >> in >> these cases the refresh token is not issued at all. >> >> Also, Torsten suggested that when a new access token is requested then >> also a new refresh token is issued, this would allow the authorization server >> to detected if a refresh token was leaked and used by an attacker. However, >> this will not work in all cases. >> >> I suggest we add a parameter to the requests that normally issues the >> refresh token as a hint to the authorization server that the client wants a >> multi-use, single-use or no refresh token at all. This will be just a hint, >> the >> authorization server can decide how to proceed. >> >> For example, this parameter could look something like: >> - refresh_token_type = [none | multi | single] >> >> The default would be "none". "multi" is the normal refresh token and >> "single" is the refresh token suggested by Torsten. >> >> If the server does not support "single" type refresh tokens then it will >> issue a >> regular token and when the access token is renewed then it will not send a >> new refresh token. If for a certain flow or client the authz server does not >> want to issue refresh tokens at all then it can ignore the refresh_token_type >> request and just not issue one. If "multi" is requested then either "multi" >> or >> "none" should be issued. >> >> This refresh token type request parameter could be implemented as an >> extension as well. >> >> Thoughts? >> >> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
