CodersSecret

Module 4 of 8

JWT and JWKS Validation at Envoy

Use Envoy jwt_authn to verify signed tokens before requests reach product APIs.

95 minutes1 exercisesFree
Watch as Slides Course overviewInline lab below

Start here

Learning objectives

  • Configure Envoy to validate JWT issuer, audience, expiry, and signature
  • Understand remote JWKS and key rotation at a beginner level
  • Forward verified token payload safely through dynamic metadata
  • Know when JWT validation is enough and when ext_authz is still needed
JWT and JWKS Validation at Envoy A central Envoy edge checks identity before traffic reaches product services. Token browser or service Envoy enforcement point JWKS IdP or policy service when needed API Kubernetes app Authenticate once, validate every request, authorize before forwarding.

The Request Flow

A user or service sends an access token in the Authorization header. Envoy checks the token signature using public keys from the JWKS endpoint. Envoy also checks issuer, audience, and expiry. If the token is invalid, the request stops at the edge.

Envoy JWT Authn Example

This config validates JWTs for API routes. It is a teaching example: replace issuer, audience, cluster names, and routing with your real platform values.

http_filters:
- name: envoy.filters.http.jwt_authn
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.jwt_authn.v3.JwtAuthentication
    providers:
      platform_idp:
        issuer: https://login.example.com
        audiences:
        - product-platform
        remote_jwks:
          http_uri:
            uri: https://login.example.com/.well-known/jwks.json
            cluster: platform_idp_jwks
            timeout: 2s
          cache_duration: 300s
        forward: true
        payload_in_metadata: verified_jwt
    rules:
    - match: { prefix: "/api/" }
      requires:
        provider_name: platform_idp
- name: envoy.filters.http.router
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

What Envoy Can Decide Locally

  • The token is signed by a trusted key.
  • The issuer is allowed.
  • The token is meant for this platform or API audience.
  • The token has not expired.

What Envoy Should Not Guess

JWT validation does not automatically mean the user can perform every action. If the API needs row-level, tenant-level, billing-plan, or product-object permissions, call an authorization service or let the product perform a domain-specific check.

JWKS Caching

JWKS caching keeps token verification fast. The tradeoff is key-rotation timing. Your IdP, Envoy cache duration, and emergency key revocation process must be designed together.

Real world

Where this shows up

  • A Kubernetes platform with many internal products that should share one login and one enforcement layer
  • Developer portals, data tools, admin consoles, APIs, and service-to-service calls protected at the edge
  • Migration from product-specific auth logic to centralized policy checks without rewriting every product first

Production notes

Keep these close

  • Monitor JWT validation failures by route and issuer
  • Keep JWKS cache duration short enough for practical key rotation but long enough to avoid IdP pressure
  • Use different audiences for UI, API, and machine-to-machine tokens where possible

Common mistakes

What usually breaks

  • Checking the signature but not the audience
  • Accepting tokens from multiple issuers without route-level intent
  • Forwarding the original Authorization header to products unnecessarily

Security risks

Threats to watch

  • Token replay is easier when tokens are long-lived
  • A compromised signing key affects every service trusting that issuer
  • Products that trust client-supplied identity headers can be bypassed unless Envoy strips and rewrites them

Tradeoffs

Design choices you should be able to defend

JWT verification at Envoy

Pros

  • Low latency after key cache
  • No auth-service call for simple routes
  • Standardized edge rejection

Cons

  • Harder immediate revocation
  • Complex permissions still need another decision point

Central auth service decision for every request

Pros

  • Fine-grained revocation and policy
  • One decision engine for many token types

Cons

  • Extra latency
  • Auth service must scale with request volume

Think like an engineer

Questions to answer before shipping

  • Which identity is making the request: a human, a service, or a federated cloud principal?
  • Which check belongs at Envoy, and which check must remain inside the product domain model?
  • What happens when the identity provider, JWKS endpoint, or auth service is slow or unavailable?

Key terms

Vocabulary used in this module

Issuer

The identity provider or token service that created the token.

Audience

The intended recipient or API for a token.

JWKS cache

Envoy storage of public verification keys for a limited time.

Token replay

Reusing a stolen valid token to make unauthorized requests.

Exercises

Practice inside the lesson

45-60 minutesBeginner to Intermediate

Write a JWT Validation Checklist

Turn JWT validation into a repeatable review checklist for every product API route.

  1. Choose an issuer value for your platform IdP
  2. Choose an audience value for product APIs
  3. List which routes require JWT validation
  4. Decide how long JWKS should be cached
  5. Write what happens when the JWT is missing, expired, or signed by an unknown key

Recap

Key takeaways

  • Envoy can validate JWTs locally with JWKS
  • Issuer, audience, expiry, and signature checks are non-negotiable
  • JWT validation proves token validity, not all business permissions

Related resources

Keep learning across CodersSecret

Related guides

Read practical engineering walkthroughs that connect this lesson to real systems.

Cheatsheets

Keep command references and production checklists close while you practice.

Interactive labs

Practice infrastructure decisions through short, scenario-driven exercises.

Glossary terms

Build the vocabulary needed to explain architecture clearly in reviews.