z/OS Connect doesn't have all standard OAUTH provider authentication methods implemented as per RFC 6749 and

z/OS Connect currently only supports either basic authentication or private key JWT authentication methods (2.3.1.  Client Password) in RFC 6749 while authenticating with OAUTH JWT providers to procure the JWT token and inject into the API call. Due to which it mandates API requester sending Client ID and Client Secret. But all enterprise OAUTH providers support entire RFC 6749 including the 2.3.2.  Other Authentication Methods based on RFC 8705. The main USP of mainframe application is completion of transactions in milliseconds and if the transaction has outbound API calls with multiple back & forth calls going between z/OS Connect and OAUTH JWT providers to get the JWT token, its highly inefficient and unnecessarily blocks the transactions to buffer & pileup leading to issues. Hence single call with pure mTLS is the best efficient options that is not supported by z/OS Connect. To be precise, yes mTLS can be configured between z/OS Connect & OAUTH JWT providers, but it also sends Client ID & Client Secret which is not supported by standard RFC 8705 based OAUTH JWT providers. Hence fix z/OS Connect to mandate API requester to send both Client ID and Client Secret even for mTLS authentication method by removing mandating Client Secret. More details in the additional details section.

Reference:
1. https://datatracker.ietf.org/doc/html/rfc6749#section-2.3.2
2. https://datatracker.ietf.org/doc/html/rfc8705