We are trying to implement the client credential flow as describe in link above. Difference is we would authenticate the client with mTLS instead of basic authentication.
Our KONG API gateway would authenticate with the IdP to generate the access token. But since the client is authenticated with a robust mechanism already, we might store the client credentials in the gateway instead of requiring the client to send it over on every request.
The pros is there will be no need for managing the IdP credentials between us and the client, and no need for transmitting the credential through header which means a simpler client.
Typically you want to mint a token for a client that you are authenticating. So separating that means client is authenticated one way and token is obtained by another means. You will not be able to get a token meant for that client. Each client that is registered with the IDP will have different scopes, access controls etc. All these are encoded into the token when its minted. So if you split that up and have kong obtain a token for each of those clients with its own credentials, it will always be the same token regardless of the client. So this pattern needs careful thinking if that is acceptable for your case.