[FIXED] Why does machine-to-machine interaction in OAuth2 disallow the refresh_token grant without providing the client_secret?

Issue

We are implementing JWT-based authentication for our APIs, using Keycloak as an identity provider and token endpoint.

We found the idea of OAuth2 attractive, as it reduces the need for long-lived credentials to travel over the network. Instead of issuing our end-users an API key which they would put into a header for every request they send our way, they can use a client ID and secret to request an access token with a relatively short lifespan.

I mistakenly assumed that the clients would also receive a refresh token and be able to get new access/refresh token pairs using that (and not using the client secret). This would further lessen the need for the client secret to go back and forth over the network.

---

Here's some background for my initial reasoning:

• Client gets access/refresh tokens with client credentials
• Client uses access token until expiry
• Client uses refresh token to obtain a new access/refresh pair.
• The old refresh token is invalidated (this is possible to do with Keycloak by tweaking max sessions).
• Retrieving an access/refresh pair with static credentials similarly invalidates a refresh token.

In this case an attacker sniffing network traffic would be very lucky to ever see static credentials passed and the compromise of credentials (whether static or refresh) is very visible, since the legitimate client would notice that its refresh token no longer works.

---

However, from what I gathered in the standards, the generally accepted way for machine-to-machine interaction to happen under OAuth2 is with the client credential grant type, which does not return refresh tokens and the client must request a new access token with its credentials every 10-15 minutes or so.

This leaves me confused: is this not, basically, another convoluted type of basic auth then, where we repeatedly send static credentials over a potentially insecure network? Sure, most requests are done with an access token, but an attacker will know for sure that every 10-15 minutes the static credentials will be sent to the authorization server.

Is there another way to do machine-to-machine interaction which is better secured against an attacker, who has managed to sniff our traffic? To be more specific, something which avoids, or mostly avoids sending static credentials.

Solution

Regarding your question about another way to do machine-to-machine interaction which is better secured against an attacker, who has managed to sniff our traffic, there are alternative authentication methods that a client can use.

The default client auth method is based on a shared key, called client secret in OAuth 2.0 spec. Client id and secret must be sent to the auth server to obtain an access token. This has to happen every time previously issued access token expires. This increases the risk of client secret exposure. This method does not require a refresh token as the client is obtaining a token for itself. This method is performed over SSL which reduces the risk of exposure. In addition, active IP monitoring further reduces the risk of compromised client secret. Client secret can be invalidated if a request is issued from an IP that has not been seen.

However, a more secure alternative to a shared client key is a private key and a signed JWT authentication. A client uses a private key and signs a set of assertions in a JWT token. This JWT is sent with the token request. The JWT is extremely short lived with expiry set to a few seconds from the issue. The auth server is configured with a corresponding public key and is able to validate JWT signature this authenticating the client's request. This JWT is a single use token and should include a unique token id. Auth server can persist unique JWT id until expiry to prevent token replay.

In addition to a short lived JWT, client IP monitoring can be implemented so that the client is only allowed to use this key from an established set of IP addresses or from previously observed set of IP addresses.

OAuth 2.0 also provides for a client to authenticate via a X.509 certificate submitted to the auth server during TLS handshake.

https://datatracker.ietf.org/doc/html/rfc8705

Answered By - Delta George

Answer Checked By - David Goodson (PHPFixing Volunteer)