Wouldn't the OAuth 2.0 client credentials flow be more secure with the option of using refresh tokens?

Question

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.

Answer 1

The OAuth standard requires client authentication in case of confidential clients when refreshing a token:

If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.

So using the refresh token grant does not do the trick.

But there is a standard compliant way to request an access token without transmitting the client secret:
RFC 7523 and OpenID Connect define a method for authenticating with a JWT instead of a client secret sent in plain text. The JWT can be either HMACed with the client secret or signed with the client’s private key.