Request-level auth (JWT)

Validate tokens; authorize on verified claims.

Workload identity answers "which service is calling". Request-level authentication answers "on whose behalf" — validating end-user or caller tokens so policy can authorize on verified claims, adding a second, finer layer of identity on top of mTLS.

JWT validation at the proxy

A mesh can validate JWTs at the proxy using a RequestAuthentication resource: it checks the token’s signature against the issuer’s keys and rejects invalid ones, then makes the verified claims available to authorization policy. This lets you enforce request-level rules — this endpoint requires a token from our IdP with the "admin" scope, that endpoint requires a valid user token at all — without every service re-implementing JWT verification. Combined with the workload mTLS identity, you now have two dimensions: the calling service (proven by its certificate) and the principal on whose behalf the request is made (proven by the JWT).

# Require and validate JWTs from the corporate IdP for the api workload.
apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata: { name: jwt, namespace: prod }
spec:
  selector: { matchLabels: { app: api } }
  jwtRules:
    - issuer: "https://idp.acme.com"
      jwksUri: "https://idp.acme.com/.well-known/jwks.json"
---
# Authorize on a verified claim: only tokens with scope "admin" may DELETE.
kind: AuthorizationPolicy
spec:
  rules:
    - to: [{ operation: { methods: ["DELETE"] } }]
      when: [{ key: request.auth.claims[scope], values: ["admin"] }]

Composing service and request identity

The two identity layers compose into fine-grained, defense-in-depth policy: "the frontend service (mTLS identity) may call the orders API, and only for requests carrying a valid user token (JWT) whose claims permit the action". This is far stronger than either alone — a stolen user token cannot be replayed from an unauthorized service, and a compromised service cannot act without a valid user token where one is required. It pushes verification down to the individual request, which is the essence of continuous, per-request zero-trust authorization. As always, keep these policies as reviewed code and roll them out carefully so a misconfigured JWT rule does not lock out legitimate callers.