The spec states the ClientCredentials grant type MUST NOT allow for the issuing of refresh tokens. So the answer is, you have to use a different grant type to receive a refresh token with your access token.

This is the second hit when googling this, so to be absolutely correct it should be noted that the client credentials grant type SHOULD NOT issue a refresh token (http://tools.ietf.org/html/rfc6749#section-4.4.3). I think you are confusing it with the implicit grant, in which refresh tokens MUST NOT be issued.

Ok thanks for the clarification guys...

Does anyone know the rationale for this? I actually can't figure out why this would be the case. Seems like an arbitrary decision?..

My first thought was that client_credentials grant doesn't require a username and password so an attacker who compromises your application key would find it easier to stay hidden?

Maybe because it makes no sense to refresh a token, when you can just as easy get a new one (no user approval required for getting a token when using client credentials).

@bshaffer, just to clarify: are we reading SHOULD NOT cases as MUST NOT on the current implementation of the package, just like in this refresh token case?

@oytuntez no, just in this case, and even here it was an accident. We can definitely open Client Credentials up for Refresh Tokens

I posted this many months ago..

http://stackoverflow.com/questions/29233772/why-is-a-refresh-token-not-provided-by-oauth2-servers-responding-to-a-client-cr

Yeah, good points by @Kalyse. Since it's not strictly forbidden, I wouldn't mind if a PR was submitted to add this, but it is not a priority for me.