This cannot be answered without understanding your environment more.
- Is this all within your own domain or are these externals connecting to your service?
- Do these services require a different set of permissions from each other?
- Are these services use to delegate a user identity that is use downstream?
- How are these services communicating to each other? REST? Binary?
- What is the tech stack you are working with?
Client certificates are useful as a way to authenticate but if your requirement is to have different permissions for services accessing your own service a client certificate by itself is not going to help. As mentioned above you will need to manage certificates you have issued - but this constrant exists with JWTs that require to be signed as well. If you have multiple certificates for externals you will
JWTs are useful if the consumers have different permissions and are accessing your service via REST. If the communication isn't REST then don't bother with JWT's. You will need to manage the signing certificate in JWTs as well. If you are going to use JWTs be aware of the weaknesses they have:
- Algorithim attacks against libraries that respect the none value
- JWT replay attacks
- JWTs require TLS on the transport layer
- Some JWT frameworks allow you to attack the system by switch algorithim types from RS256 to HS256 and signing with the public key
There is nothing wrong with JWTs when implemented correctly, its just people can screw up the JWT implementation. I'm bias because I am currently trying to address JWT patterns in my own organization that lead to security holes because validation ignored expiry dates...