The OAuth 2.0 specification states that "A refresh token SHOULD NOT be included" in responses to access token requests in the client credentials flow and that, even if they were used, the client credentials would need to be sent in the refresh token grant request anyway.
That means that every time the access token expires, the client should ask for a new one including their ID and secret in the request.
I understand that in the client credentials flow it is necessary that your client is confidential and that the secret can be stored with it; However, it isn't realistic to expect one to be able to guarantee that the secret will never be leaked.
For an example of where this is especially dangerous, I am currently researching what authentication and authorization model to use for an API in my company. The OAuth Clients are services running in servers, and thus the client credentials flow seems best. However, these OAuth Clients will be running in our "clients'" servers, not ours. They're still "confidential", but I can't help but feel that it's too risky to have these credentials - which would allow anyone to completely impersonate the client - communicating through the Internet every 15min or so.
Thus the question:
I understand that "refresh tokens" in the OAuth 2.0 spec were not designed for this; Having said that, wouldn't the client credentials flow be more secure with the option of using refresh tokens? In contrast to stealing the client credentials, which would give full access to an attacker potentially forever to an API, stealing the refresh token would only give them access for a few hours or so, even if they were never caught.