Maybe consider, for your machine-to-machine scenarios, using a grant type like jwt-bearer. (See RFC 7523) That eliminates the need for transmitting secrets, and eliminates the need for a shared secret completely. Basically in the request-for-token, the client sends a JWT signed with RS256 or PS256. Apigee validates the signed JWT, before issuing a bearer token.
Each client would get its own RSA key pair. The client would possess and store the private key, and Apigee would store and manage the corresponding public key for each client. (Apigee won't need the private key). This eliminates the need for a certificate for each client app. And it provides better security than a grant type based on transmitting a clientid + secret in the request-for-token.
If this is what you do, then... you don't need to change much on the Apigee side. You need two token dispensing endpoints - one for users, and one for the M-to-M case. For the user case you will want to use OpenID connect or something like that, I guess. Or a modified "Password" grant, using an already-issued ID token as the user credential.
In both paths, user or M-to-M, the result is... an OAuth token. And so subsequent calls just present the token, and Apigee uses OAuthV2/VerifyAccessToken, and everything is good.
If you still need or want mTLS for the M-to-M scenario, then... you need to modify your "verify" logic on the Apigee side to inspect the inbound token and do different things depending on whether user or M-M. And you'd need a separate Load Balancer -one that supports mTLS for yuor M-M case, and 1-way TLS for the user cases.
LinkedIn
Twitter
