Yes, it is important to remember that when you make allowances for one flow you affect other flows, I understand that. I understand that if in the implicit flow you return a refresh token, you then allow other flows to use authorization server endpoint to refresh the token without a client secret.
If a provider chooses to do that though, in the attack you described, they could still revoke the refresh token to stop the abuse when it is discovered, and that is still easier in my opinion than rotating a client secret but yes, allowing that does make the client secret pointless for refreshing tokens. Like the client secret though, the refresh token is only exchanged with the authorization server and only over https. I think the fact that the refresh token is only exchanged with the authorization server and not the resource servers, still makes it useful to apps that can't be shipped with a client secret. I'm not a fan of the implicit flow and JS clients but would like to be able to use the other flows with native apps that can't be authenticated (like an iPhone app). So it would be nice if client authentication was not required to refresh a token. On May 31, 2011, at 11:05 PM, Brian Eaton wrote: > On Tue, May 31, 2011 at 10:39 PM, Kris Selden <[email protected]> wrote: >> Why can't you just revoke the refresh token for a client when you change the >> client secret? >> >> Is it not easier to revoke a token than it is to rotate the client secret >> (which is usually configured or embedded in the client whereas the token is >> issued)? > > As I noted in my original e-mail on this thread, I was talking > specifically about the web server flow. > > This is one area where the security considerations for installed > applications are different than for web servers. _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
