Question: Shouldn't the Client Credentials flow not include a refresh token in the response?

[alronlam]

Hi, I was trying out the Client Credentials flow with Kong and it returned a refresh token. I also tried obtaining another access token through the refresh token. However, I noticed that the client id and secret still had to be passed to Kong when doing so. And this got me thinking as to what advantage the refresh token has to offer in this case, because the client id and secret are still being passed to Kong.

If I understood this correctly, in the context of a Resource Owner Password Credentials Grant flow, the refresh token is useful so that we don't have to let the user re-authenticate. And that the OAuth2 spec requires passing the client id and secret so that if the refresh token gets compromised, the attacker still could not request for a new access token. And so the use of a refresh token seems to make sense for the ROPC flow.

However, for the Client Credentials flow, this doesn't seem to be the case, since we don't really need the refresh tokens because we're just authenticating the client.

So I ended up reading the Client Credentials flow here (https://tools.ietf.org/html/rfc6749#section-4.4) and I came across this section.

4.4.3. Access Token Response

If the access token request is valid and authorized, the
authorization server issues an access token as described in
Section 5.1. A refresh token SHOULD NOT be included. If the request
failed client authentication or is invalid, the authorization server
returns an error response as described in Section 5.2.

I'm not sure if my understanding is correct though. Would love to hear your thoughts on it.

[subnetmarco]

That's correct - let me push a fix for this.