An Istio RequestAuthentication resource is applied to a workload with a jwtRules entry for your identity provider, yet requests carrying no token at all still reach the application. Why, and what makes the endpoint actually require a valid token?

## Two resources, two jobs Istio separates *authentication* — deciding whether a presented credential is genuine — from *authorization* — deciding whether the request may proceed. `RequestAuthentication` does only the first, and only for end-user tokens: ```yaml apiVersion: security.istio.io/v1 kind: RequestAuthentication metadata: name: idp namespace: payments spec: selector: matchLabels: app: api jwtRules: - issuer: "https://idp.example.com" jwksUri: "https://idp.example.com/.well-known/jwks.json" audiences: ["payments-api"] ``` This produces exactly three outcomes for an inbound request: - **A valid token** — the proxy records an end-user identity and, where configured, the token's claims become available to policy. - **A token that fails validation** — bad signature, wrong issuer, expired, wrong audience — rejected with **401**. - **No token at all** — allowed through with no identity. This is the case people do not expect, and it is intentional: it lets one resource cover an endpoint that serves both anonymous and authenticated traffic. ## Making a token mandatory ```yaml apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: require-user namespace: payments spec: selector: matchLabels: app: api action: ALLOW rules: - from: - source: requestPrincipals: ["*"] ``` `requestPrincipals` matches the end-user identity derived from a validated token, formed by joining the issuer and the subject claim. The wildcard means "any authenticated user", and naming a specific value pins it to one issuer and subject. Because this is the first ALLOW policy selecting the workload, the workload flips to default-deny, and a tokenless request now matches no rule and gets 403. Note which code appears when: **401 comes from failed validation, 403 from failed authorization.** A tokenless request therefore fails with 403, not 401 — surprising the first time, and a useful diagnostic once you know it. ## Peer identity and end-user identity are different axes This is the distinction the leaf is really about. `source.principals` matches the *calling workload*, taken from its mesh certificate. `source.requestPrincipals` matches the *end user*, taken from a validated token. They answer different questions — which service is calling, and on whose behalf — and a single rule can require both: ```yaml rules: - from: - source: principals: ["cluster.local/ns/web/sa/frontend"] requestPrincipals: ["https://idp.example.com/*"] to: - operation: paths: ["/v1/accounts/*"] ``` That reads: the request must arrive over mutual TLS from the frontend's identity *and* carry a valid token from that issuer. Neither alone is sufficient. Expressing this is the practical reason the two mechanisms exist side by side rather than being collapsed. ## Claim-based rules Beyond presence, individual claims can gate access through `when` conditions keyed on the request's authenticated claims — a group, a role, a tenant. That lets coarse decisions live at the mesh boundary while the application keeps the fine-grained ones, and it means a claim used for access control is validated at a layer the application cannot accidentally skip. ## Operational edges - **Key set availability.** Validation needs the issuer's public keys. Pointing at a remote key set makes the control plane's ability to fetch and refresh it part of your request path's dependency graph; inlining the keys removes that dependency but makes rotation your problem. - **Multiple issuers.** Several `jwtRules` entries can coexist, which is how a migration between identity providers is run — but during that window "any authenticated user" spans both, so pin the issuer in the rule if that matters. - **The token is still forwarded.** By default the original token continues to the application unless configured otherwise, so an application that also validates it is not broken by adding the mesh layer — which makes rolling this out ahead of removing in-app validation safe. - **Selector mismatch is the silent failure.** A `RequestAuthentication` whose selector matches nothing produces no error and no effect. If tokens seem never to be validated, confirm the selector matches the workload's labels before suspecting the issuer configuration.