For service-to-service authentication inside a cluster, would you use mTLS, OAuth client credentials, or both?

What the interviewer is testing

Whether you can separate the two concerns these mechanisms address, rather than treating them as alternatives.

What each provides

mTLS authenticates the transport: both ends prove their identity with certificates, and the channel is encrypted. It answers "which workload is at the other end of this connection" — strongly, with automatic rotation if the platform issues short-lived certificates.

What it does not carry is context: on whose behalf is this call being made, with what scope, for what purpose. A certificate identifies a service, not a request.

OAuth client credentials authenticate the application and can carry scopes, but on their own they also lack user context and are bearer credentials — a stolen token works from anywhere, whereas a stolen mTLS certificate requires the private key.

The combination

mTLS for channel identity and encryption, plus a token carrying request context — the end user's identity where one exists, the scope, and the delegation chain.

That gives: mutual authentication that is not bearer-based; encryption in transit; and request-level authorisation that can be evaluated at the resource against the actual principal.

The token should be audience-restricted to the specific service, via token exchange, so a stolen token is useful in one place only.

The practical consideration

mTLS at scale means certificate lifecycle management for every workload — issuance, rotation, revocation, trust distribution. That is precisely what a service mesh or a workload identity framework provides, and doing it by hand is where mTLS programmes fail.

If that infrastructure does not exist and the estate is small, platform-level encryption plus token-based authorisation is a defensible interim position — provided the token is not the only thing standing between an attacker on the network and the service.

What a strong answer adds

The point that decides the architecture: network position must not be an authorisation. Whatever mechanism is chosen, a service must reject a well-formed request from an unauthorised caller even when that caller is inside the cluster.

Common weak answers

mTLS alone, leaving no request-level authorisation. Choosing based on which is easier to configure.