API Gateway vs Service Mesh: Where to Place Authentication and Authorisation

Teams that run both an API gateway and a service mesh often cannot say which layer is responsible for authenticating callers and authorising requests, so controls end up duplicated in some paths and missing in others. The gateway governs north-south traffic: external clients calling your APIs. The mesh governs east-west traffic: services calling each other inside the platform. They overlap in features (TLS, routing, rate limits, JWT checks), but they prove different things about different callers. This guide covers the threat model and architecture of each, where authentication and authorisation belong, workload identity with mTLS and SPIFFE, how to avoid redundant token validation without leaving gaps, failure modes and a reference architecture. It is for platform engineers, API owners and security architects designing or reviewing cloud-native platforms.

Key takeaways

• Different callers, different proofs. The gateway authenticates external users and client applications with OAuth tokens or API keys; the mesh authenticates workloads to each other with certificates.
• Coarse at the edge, fine in the service. Put token validity, client identity, quotas and coarse scope checks at the gateway; put service-to-service allow rules in the mesh; keep object-level decisions in the service.
• Mesh defaults are usually permissive. Istio accepts plain text in PERMISSIVE mode and allows all requests when no authorisation policy exists; Linkerd's default inbound policy allows all requests. Enforcement is something you switch on.
• Do not forward the edge token everywhere. Exchange it for a narrower internal token or pass verified claims over mTLS, so an internal compromise does not yield a token valid at the edge.
• Duplication is fine when deliberate. Validating a token twice costs little; the failure is two layers that each assume the other checked.

The short answer

You usually need both once you have more than a handful of services exposed externally. An API gateway alone leaves internal calls trusted by network location, which NIST SP 800-207A moves away from: it argues that access control should rely on application and service identities, not only network parameters, enforced by "API gateways, sidecar proxies" and identity infrastructure such as SPIFFE. A mesh alone gives strong workload identity but is a poor place to manage external developer onboarding, API keys, usage plans and public API contracts. Small platforms with a few services may run a gateway plus Kubernetes network policies and in-service token validation, and add a mesh when the number of internal callers makes per-service mTLS impractical.

How each architecture works

API gateway: the north-south policy point

A gateway terminates client TLS at the edge, authenticates the caller (OAuth 2.0 access token, mTLS client certificate or API key), applies rate limits and quotas, validates request shape against an API schema, routes to a backend and often transforms headers. Its threat model is the internet: credential stuffing against token endpoints, stolen or replayed tokens, scraping, resource exhaustion and attacks on inventory gaps such as shadow or deprecated API versions. The OWASP API Security Top 10 2023 risks it helps with most directly are API2:2023 Broken Authentication, API4:2023 Unrestricted Resource Consumption and API9:2023 Improper Inventory Management. Hardening the gateway itself is covered in the API Gateway Security Guide.

Service mesh: the east-west policy point

A mesh places a proxy beside each workload (sidecar) or on each node (sidecarless or ambient designs) and a control plane that issues identities and pushes policy. NIST SP 800-204A describes the benefit as enforcing security and resiliency consistently "without making changes to individual microservice code". Mesh products are listed alphabetically. Istio provisions "strong identities to every workload with X.509 certificates" and rotates them automatically; Linkerd authenticates clients through automatic mTLS and its MeshTLSAuthentication resource. The threat model is the inside: a compromised pod calling services it never should, lateral movement, interception of plain text traffic, and stolen tokens replayed internally. The mesh's own security, including control plane hardening, is in the Service Mesh Security Guide.

Side by side

Where authentication and authorisation belong

A useful rule is to place each decision at the layer that holds the facts needed to make it, and no higher.

Externalised policy engines can be called from either proxy (Istio's CUSTOM action delegates to an external authoriser), which helps keep rules consistent; see the Policy-as-Code for Authorisation Guide. Whatever engine you use, the object-level check still needs the object's data.

Workload identity, mTLS and SPIFFE

The mesh's core contribution is a workload identity that does not depend on IP addresses. SPIFFE defines it as a URI, spiffe://trust-domain/workload-identifier, carried in a SPIFFE Verifiable Identity Document (SVID) that is valid only if "signed by an authority within the SPIFFE ID's trust domain". Workloads obtain short-lived keys, SVIDs and trust bundles from the Workload API, which rotates them automatically. Istio exposes the peer identity from mTLS as source.principal, so policy is written against identities, not addresses.

Two choices matter for the comparison:

• X.509-SVID or JWT-SVID: SPIFFE warns that tokens "are susceptible to replay attacks" and recommends X.509-SVIDs "whenever possible", accepting JWT-SVIDs where an L7 proxy or load balancer sits between workloads. This is exactly the case when traffic passes through a gateway that terminates TLS, so design the hop after the gateway with care.
• Trust domains: SPIFFE advises separate trust domains for environments with different security practices, such as staging and production. A gateway that routes into several trust domains must present an identity each accepts.

Deeper coverage: SPIFFE and SPIRE Guide and mTLS vs Signed Tokens for Service Authentication.

Token validation duplication and propagation

The question of whether to validate a JWT at the gateway, in every service or both is covered in depth in API Gateway vs In-Service Token Validation. What changes when a mesh is added is that there are now three places a token can be checked (gateway, mesh proxy, service code) and two identities on every internal request (the workload from mTLS, the user from the token).

Patterns, from weakest to strongest:

1. Trust the header: the gateway validates and passes a user ID header; services trust it because traffic came from inside. Any compromised workload can forge the header. Avoid.
2. Header plus mesh source check: the mesh only accepts the user header from the gateway's workload identity (an authorisation policy on source.principal). Much better, but the claim is not cryptographically bound to the request beyond the hop.
3. Forward the original token and revalidate: each service, or its proxy via Istio RequestAuthentication, validates the same edge token. Simple, but the edge token now travels deep into the platform and is valid at the edge if stolen internally.
4. Exchange for an internal token: the gateway calls a token service using OAuth 2.0 Token Exchange (RFC 8693, grant type urn:ietf:params:oauth:grant-type:token-exchange) for a short-lived token with an internal audience and, for delegation, an act claim recording the acting service. Internal tokens are useless at the edge, and scope can narrow per hop. See OAuth Token Exchange vs Token Passthrough and OAuth Transaction Tokens (Txn-Tokens) Guide.

One Istio behaviour causes many gaps: RequestAuthentication rejects invalid tokens, but "when requests carry no token, they are accepted by default". A service that relies on the proxy for JWT checks must also have an AuthorizationPolicy requiring requestPrincipals, or unauthenticated requests pass. Istio also notes that requests with more than one valid JWT are not supported because the resulting principal is undefined, which matters if the gateway adds its own token beside the client's.

Default postures to change

Istio evaluates CUSTOM, then DENY, then ALLOW, so a matching deny cannot be overridden by an allow, and once any ALLOW policy applies to a workload, unmatched requests are denied.

Failure modes and overlap

• Gateway bypass: backends reachable directly (a public load balancer, a NodePort, a forgotten ingress) skip every edge check. Fix with network policy and mesh rules that accept external-origin traffic only from the gateway's identity; see the Kubernetes Network Policy Guide.
• Permissive mode left on: a migration to mTLS that never moved from PERMISSIVE to STRICT, so plain text calls still succeed.
• Policy split brain: the gateway blocks an admin route, but an internal path to the same service has no mesh rule, so any compromised pod reaches it.
• Header trust: identity headers accepted from any internal caller (pattern 1 above).
• Edge token sprawl: the client's bearer token forwarded to every downstream service and logged in some of them; see the JWT and Session Tokens in Code and Logs Guide.
• Unmeshed workloads: Linkerd enforces policy only on meshed pods, and Istio's STRICT mode breaks unmeshed clients, so jobs or legacy services outside the mesh become either outages or exceptions nobody revisits.

Where identity fits

Every mesh certificate and every internal token is a non-human identity. Treat the mesh CA and signing keys as tier-0 secrets, keep certificate lifetimes short with automatic rotation, and map each SPIFFE ID or service account to an owning team so authorisation policies can be reviewed. The gateway's own credentials (client secrets for token exchange, keys to backends) belong in a secrets manager. See the Cloud Workload Identity Guide for issuing identities outside the cluster.

Decision criteria

1. Who are the callers? External developers and partners need gateway capabilities; dozens of internal services calling each other need mesh identity.
2. How many internal hops carry user context? Beyond one or two, plan token exchange or transaction tokens instead of forwarding the edge token.
3. Can you run a mesh? A mesh adds a control plane, certificate authority and upgrade cycle. Without platform capacity, start with a gateway, network policy and in-service validation.
4. Compliance pressure on internal encryption? If internal traffic must be encrypted and mutually authenticated, a mesh is the least intrusive route to it.
5. Kubernetes only, or mixed? SPIFFE identities can span VMs and clusters; a gateway can front all of them. Mixed estates favour SPIFFE-based identity behind a single gateway tier.

Reference architecture and worked scenario

A retailer exposes order and payment APIs to a mobile app and partners, behind which 40 services run on Kubernetes.

1. Edge: the API gateway validates OAuth access tokens (issuer, audience, expiry, signature), enforces client quotas, rejects unknown API versions and blocks admin routes from the internet.
2. Gateway to mesh: the gateway runs inside the mesh with its own workload identity. It exchanges the client token via RFC 8693 for an internal token with audience orders-internal, valid for minutes.
3. Mesh: PeerAuthentication STRICT in all application namespaces; an allow-nothing baseline; ALLOW policies such as "orders may call payments on POST /authorise only". Only the gateway identity may call public-facing services.
4. Service: the order service validates the internal token itself and checks that the user owns the order before returning it.
5. Outcome: a compromised recommendations pod cannot call payments (mesh denies), cannot forge a user header (no header trust), and any token it steals is not accepted at the edge.

How to implement

1. Inventory paths: list every route into each service, including non-gateway ingress, and every service-to-service call from mesh telemetry.
2. Fix the edge: make the gateway the only external entry and validate tokens there.
3. Enable mTLS in stages: PERMISSIVE namespace by namespace, confirm all traffic is mTLS in telemetry, then STRICT.
4. Authorisation in audit first: Linkerd audit default policy, or Istio policies trialled in a staging namespace, then a deny baseline with explicit allows.
5. Replace header trust: introduce token exchange or source-principal checks for identity headers.
6. Roll back safely: revert a namespace to PERMISSIVE or remove a new deny policy as a single, version-controlled change; keep policies in Git with review.

Detection and measurement

• mTLS coverage: percentage of east-west requests over mTLS, from mesh telemetry; target 100 percent in application namespaces.
• Policy coverage: share of services with an explicit ALLOW policy rather than the default.
• Gateway bypass attempts: requests reaching public-facing services from any identity other than the gateway.
• Denied internal calls: mesh authorisation denials by source and destination; spikes suggest compromise or a broken deployment.
• Edge token depth: number of services receiving the original client token; should trend to zero with token exchange.
• Token validation failures: at gateway and service, split by reason (expired, audience, signature).

Framework mapping

Practitioner checklist

• Write down, per decision, which layer owns it: token validity, client quota, workload allow, object access.
• Make the gateway the only external entry and block direct backend exposure.
• Move every application namespace to mTLS STRICT.
• Apply a deny-by-default authorisation baseline in the mesh.
• Pair Istio RequestAuthentication with an AuthorizationPolicy requiring requestPrincipals.
• Stop trusting identity headers from arbitrary internal callers.
• Exchange edge tokens for short-lived internal tokens where user context crosses several hops.
• Keep object-level authorisation in service code and test it.
• Store mesh and gateway policies in version control with review and staged rollout.

Standards and references

• NIST: SP 800-207A A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments
• NIST: SP 800-204A Building Secure Microservices-based Applications Using Service-Mesh Architecture
• IETF: RFC 8693 OAuth 2.0 Token Exchange
• SPIFFE: SPIFFE Concepts
• OWASP: API Security Top 10 2023
• Istio: Security concepts
• Linkerd: Authorization policy
• Kubernetes Gateway API: Service mesh (GAMMA)

Related NHI Mgmt Group resources: API Gateway vs In-Service Token Validation, Kubernetes Ingress Controller vs Service Mesh, Service Mesh Security Guide, NIST SP 800-207A Zero Trust for Cloud-Native Applications Guide.