To set up an access control gateway that enforces both mutual TLS (mTLS) and JWT authentication for internal APIs, place a reverse-proxy / API gateway (or service-mesh ingress) in front of your services. The gateway terminates TLS, requires a valid client certificate (mTLS), validates a JWT, and only then routes the request to the upstream internal API.

Kong Gateway is one of the most common and well-documented choices for this combination; Envoy Gateway, NGINX, AWS API Gateway, and service meshes (Istio / Kong Mesh) are strong alternatives.

High-level architecture

Clients (other services or trusted callers) present a client certificate and a JWT (usually in the Authorization: Bearer header).

Gateway performs the mTLS handshake and verifies the certificate against a trusted CA.

Gateway validates the JWT (signature, issuer, audience, expiry, optional claims/scopes).

Only requests that pass both checks are forwarded to the internal microservice.

Optionally map the client certificate or JWT claims to a consumer/identity for fine-grained authorization and logging.

Recommended approach with Kong Gateway

Deploy Kong

Run Kong in DB-less / declarative mode (or with a database) on Kubernetes, VMs, or containers. Expose only the proxy port (8000/8443) to internal callers; keep the Admin API locked down.

Prepare certificates

Create or obtain a Certificate Authority (CA).

Issue server certificates for the gateway.

Issue client certificates for each calling service (or group of services).

Store the CA certificate(s) so Kong can trust them.

Use short-lived certificates and automate rotation (cert-manager, HashiCorp Vault, cloud private CA, etc.).

Configure mTLS authentication

Enable the mtls-auth plugin (Kong Enterprise feature in many setups; open-source alternatives or header-based cert forwarding also exist).

Upload the trusted CA certificates.

Map client certificate Common Name (CN) or Subject Alternative Name (SAN) to Kong Consumers if you need identity-based policies.

Attach the plugin to the relevant Service or Route so only clients presenting a valid certificate can proceed.

Configure JWT authentication

Enable the jwt plugin on the same Service or Route.

Create Consumers and associate JWT credentials (HS256 secret or RS256/ES256 public key).

Configure the plugin to look for the token in the Authorization header (or a custom header).

Require claims such as exp, iss, aud, and any custom scopes.

Kong verifies the signature and claims before proxying.

Declarative example (simplified kong.yml)YAML_format_version: "3.0"

services:

• • name: internal-api
• url: http://my-internal-service:8080

routes:

• • name: internal-route
• paths: ["/internal"]

plugins:

• • name: mtls-auth
• service: internal-api

config:

CA certificates and consumer mapping configured here or via Admin API

• • name: jwt
• service: internal-api

config:

• claims_to_verify: ["exp", "nbf"]
• key_claim_name: kidApply with deck sync or the Kong Ingress Controller in Kubernetes.

Test the setup

Call the gateway with a valid client certificate + valid JWT → should succeed.

Omit the certificate, use an expired/invalid JWT, or present a certificate from an untrusted CA → should be rejected (401/403).

Verify that upstream services only receive authenticated requests (optionally with identity headers injected by Kong).

Operational hardening

Enforce TLS 1.2+ only.

Rotate certificates and JWT signing keys regularly.

Log successful and failed authentications.

Combine with rate-limiting, IP allow-lists, or OPA/Cedar policies for finer authorization.

Use GitOps (decK, Helm, or KIC) so the configuration is version-controlled and reviewed.

Alternatives

• Envoy Gateway / Istio — Native support for JWT via SecurityPolicy / RequestAuthentication and mTLS via PeerAuthentication or ClientTrafficPolicy. Excellent for Kubernetes-native environments.
• NGINX / NGINX Plus — Configure ssl_verify_client on for mTLS and use the auth_jwt module (or Lua/njs) for JWT validation.
• AWS API Gateway — Enable mutual TLS on a custom domain (truststore in S3) and add a JWT authorizer (or Cognito/Lambda authorizer).
• Service mesh only — For pure east-west traffic, enable STRICT mTLS in the mesh and validate JWTs at the sidecar or application level.

Best practices for internal APIs

Prefer mTLS for service identity (machine-to-machine) and JWT for user/request-level authorization and claims.

Keep certificate and key management automated.

Do not terminate mTLS too early if you need end-to-end encryption; consider re-encrypting to the upstream or using a mesh.

Always validate iss, aud, and exp on JWTs.

Monitor certificate expiry and authentication failure rates.

Start with a single internal service behind the gateway, prove the mTLS + JWT flow works end-to-end, then expand the configuration to the rest of your internal APIs. Official Kong, Envoy Gateway, and cloud-provider documentation contain the exact current plugin and CRD syntax for your version.