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.
EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
