On Thu, Jun 2, 2011 at 11:05 PM, Shane B Weeden <swee...@au1.ibm.com> wrote: > 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?
Are you asking why would an authorization server issue a refresh token when the client credentials grant type is used? My guess is that in most cases authorization servers will not issue a refresh token in this case. Refresh tokens are optional, see sections 4.4.3 and 5.1. I think that the example in 4.4.3 should show only an access token. Also, section 4.4.3 should probably state that in this case the authorization server SHOULD not issue a refresh token. Section numbers are for draft 16. Marius > > 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
