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
