Explain the internal working of Spring CredHub's OAuth2 client-credentials authentication?

When OAuth2 properties are present, a dedicated auto-configuration path takes over instead of the plain mutual-TLS configuration. It builds a client-credentials resource definition from the configured OAuth2 client registration, and wires it into the same CredHubTemplate used elsewhere — the difference is entirely in how that template's RestTemplate is constructed, not in a different CredHubOperations implementation.

Concretely, the RestTemplate gets an interceptor that, before each outgoing request, checks whether it's holding a still-valid access token. If not, it makes a client-credentials grant request to the configured UAA token URI using the client ID and secret, caches the returned token for its lifetime, and attaches it as an Authorization: Bearer header.

Because that happens inside an interceptor rather than in application code, every call through credHubOperations.credentials(), .permissions(), or any other sub-interface automatically carries a valid token — application code never touches UAA directly, and a token refresh is invisible to the caller.