Mutual TLS on a gRPC channel proves something important: the server presented a certificate the client trusts, and, when client certificates are required, the client presented one the server accepts. It does not automatically answer which RPC method that client may call, which tenant it may query, or whether a particular message is allowed. Transport authentication and application authorization are related but distinct checks.
gRPC uses HTTP/2 and carries metadata with calls. The transport can be encrypted and authenticated with TLS or another supported credential mechanism. Application code can attach bearer tokens, API keys, or workload credentials as call metadata. A service that accepts a valid client certificate and then trusts a role claim embedded in the request without verifying the claim issuer has moved authorization into an untrusted input.
Establish the channel identity
The server should require a supported TLS configuration, validate client certificates against an explicit trust store, and reject connections that lack the required identity. The client should verify the server's hostname and trust chain rather than disabling verification for convenience. Certificate revocation and short-lived credentials need an operational plan, including what happens when the revocation source is unavailable.
Do not infer an application role from a certificate subject string unless the issuing process and naming policy make that safe. A certificate authority may issue names for several environments, and a subject can contain a value the application misreads. Map an authenticated principal to a server-side authorization record with an explicit issuer and audience.
Authorize each method and object
Create an interceptor or policy layer that evaluates the method, the authenticated principal, and the target object. A common mistake is to check authentication once at connection time and then let every call from that channel proceed. Long-lived connections and client-side load balancing can keep a channel alive while the user's session or permissions change.
The authorization check should be consistent across unary and streaming calls. For server streaming, check the scope before sending the first response and decide whether permission changes should interrupt an active stream. For client streaming, do not treat the first message's validated field as authority for later messages without checking each relevant object.
Metadata is user-controlled unless the server verifies it. Treat authorization headers, tenant IDs, user IDs, and trace identifiers as input. Validate token signatures, issuer, audience, and expiry through the service's normal credential path. Keep credentials out of logs and error messages.
Test the cross-product
Use a test server with at least two clients and two object scopes. Verify that:
a client without a certificate is rejected
a client with a valid certificate but no application permission is rejected
a client with permission for object A cannot read or modify object B
an expired or wrong-audience token is rejected even when the channel certificate is valid
a streaming call cannot switch objects after authorization
a metadata tenant value cannot override the server-side principal mapping
The tests should observe the server's decision; client error text is insufficient. Capture the principal, method, object, policy version, and result in audit records without storing the raw credential.
Plan rotation and failure
A certificate or token rotation can cause a service-wide outage if the client and server do not overlap trust correctly. Test a rollover in a staging cluster, including a client pool that reconnects at different times. Define whether the service fails closed when the policy store or revocation service is unavailable. A cached decision may be appropriate for a short, bounded period, but it should have an owner and a measurable expiry.
The useful design is layered. TLS protects the channel, a verified token or workload identity names the caller, and an application policy decides which method and object are allowed. Each layer should be observable and independently testable. When one layer reports success, the next layer should not assume the answer.