Does refresh_token make sense with client credentials oauth flow?

Question

I am testing keycloak for learning purposes. I am testing the client credentials flow token endpoint to return a jwt for rest api use.

The endpoint returns an access_token and a refresh_token (refresh token is disabled by default unless I enable it in console for the client). I can call the same token endpoint with a refresh token generated from the first client credentials call but it still requires a client secret.

Is it not possible to regenerate an access token in the client credentials flow with just a refresh token?

If not why would I ever bother to pass a grant_type of refresh_token - wouldn't I just call the client_credential flow again since they both require a client secret? I have to guess the answer will be that refresh tokens don't make sense to be used with client_credential flows?

token parameters:

refresh token parameters:

Answer 1

You guess right, refresh tokens don't make sense for the client_credentials grant type. Refresh tokens are used for interactive clients ie a person. The idea of the refresh token is to remove the requirement for them to have to frequently re-authenticate eg re-enter their username and password, whilst still allowing the token expiry time to be kept short. The reason you want to keep the expiry time short is that once it is issued it is usually not possible to revoke it. On the other hand if an account has been suspended or the password has been changed and a refresh token has been presented the reissuing of the token can be refused by the identity provider.

As the client credentials flow is used for machine to machine authentication frequently re-authenticating is not a problem. The OAuth RFC specifically states "refresh token SHOULD NOT be included." in the response for the client_credentials grant type.

Answer 2

@James Adcock's answer is right on the spot, aside from a minor detail that I will hopefully clarify with my answer since I have seen this inaccuracy a few times already on stack overflow:

The OAuth2 documentation link states explicitly that "A refresh token SHOULD NOT be included" for client_credentials grant type.

First, one needs to clarify the meaning of "SHOULD NOT" in that context. According to rfc2119 :

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Note that the force of these words is modified by the requirement
level of the document in which they are used.

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.

2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful , but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

As you can read, "SHOULD NOT" does not mean that the specification prohibits it but rather that it does not recommend it.

I have to guess the answer will be that refresh tokens dont make sense to be used with client_credential flows?

As you have seen, the specification does not explicitly prohibits it. Notwithstanding, conceptually, (as already point out by James) it does not make sense to have a refresh token when using the client credentials flow since the backend already has the client secret stored locally anyway, and can simply acquire a new access token without the hassle of either having to store user credentials or request the user to enter them again.

A bit of historical reasoning on why Keycloak allows you to use the refresh token. From this thread of the keycloak mailing list :

Hi,

Currently, every time a confidential client tries to get a new access token from the token endpoint a new session is created on the server. This can lead to multiple active sessions for a single client/service account when doing multiple requests to token endpoint.

To avoid that the client should store the access token/refresh token and use a refresh token when appropriate in case the access token has expired. That is fine.

one can infer that the reason why Keycloak had (at that time) the refresh token available (by default) for the client credential flows was to be used as a workaround to a technical issue with their client credential flow implementation ( ie, creating too many sessions).