Protect One Route, Not Your Whole API

The short answer: The safest default is selective protection: keep health and onboarding routes public, and enable auth: true only on routes that actually need identity checks.

When to read this

• You are adding auth to an existing API without breaking public endpoints.
• You need explicit route-by-route access control at the edge.
• You want downstream services to receive verified identity context.

What matters in practice

• Use the gateway authorizer once and opt specific routes into protection.
• Keep /health and public bootstrap routes unauthenticated for operability.
• Map verified claims into headers for downstream services instead of re-validating tokens everywhere.

Concrete example

        {
        "authorizer": {
          "type": "jwt",
          "secret": "$secret.JWT_SECRET",
          "algorithm": "HS256",
          "issuer": "https://issuer.example.com",
          "audience": "api-audience"
        },
        "paths": [
          { "method": "GET", "path": "/health", "response": { "status": "ok" } },
          {
            "method": "GET",
            "path": "/private/orders",
            "auth": true,
            "integration": { "type": "http_proxy", "server": "orders" }
          }
        ]
      }

The example above is intentionally small because the best gateway configs stay readable. Add only the route, auth, and mapping behavior you actually need.

How this maps to the current gateway

The current codebase already supports the behavior discussed here through its config schema, route matcher, and integration handlers. That is why this project is a good fit for reader-first examples: the docs and blog can point to real, implemented behavior instead of hypothetical gateway features.

What this product does not do

• The JWT flow in this repo is built around shared-secret HS256 validation.
• There is no built-in RBAC or policy language beyond route-level auth and claim mapping.

FAQ

Can I protect only POST while keeping GET public?

Yes. Routes are matched by path and method, so you can require auth on one method and leave another public.

What happens without a bearer token?

The gateway returns a deterministic auth error response before the request reaches the upstream.

Related docs

• jwt protect only selected routes
• jwt common 401 errors
• auth route design public vs private

Last reviewed: March 6, 2026