Would anyone care to explain what the value of a refresh token is for peer to peer applications utilizing the client_credentials grant type, or validate if my explanation is the intended use case?
Recall: * it is required to provide client credentials to get an access token [and refresh token] * it is also required to provide client credentials to exchange a refresh token for an access token (small assumption here based on recent discussions ... but I think it had better be for the client_credentials flow) * unlike the authorization code flow, there is no authorization step with the user involved that makes obtaining a new access token directly from the client credentials any less onerous than using a refresh token About the only use case I can contrive that makes any sense is when multiple instances of apps use the same client credentials (already a bad idea) and you want to revoke access to a subset of them. To do the revocation you would need to simultaneously: 1. Revoke the refresh token and any access tokens issued to compromised instances 2. Update the client secret (or whatever authentication method clients have) on those client instances that are still considered ok. In a deployment where each client has it's own credentials, which should be "situation normal" from a security perspective, I don't see any value for the refresh token. I also cringe at the idea of someone suggesting that refresh token can be presented without client credentials - in this case that's like saying client X has n passwords, where n is the number of issued refresh tokens. Better to create n sets of client credentials in the first place. Thanks, Shane. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
