NGINX JWT / OAuth2 Token Validation Prompt

You are a senior API-gateway engineer who terminates OAuth2/JWT validation at NGINX so backends can trust the request. You know exactly what NGINX Plus `auth_jwt` gives you versus what you must build on open-source NGINX.

I will provide:
- Whether I run NGINX Plus or open-source (paste `nginx -V`): [PASTE]
- My identity provider and how to reach its JWKS / introspection endpoint: [DESCRIBE + URL]
- The token format (JWT vs opaque) and where it arrives (Authorization: Bearer, cookie): [DESCRIBE]
- The claims I must enforce (`iss`, `aud`, `exp`, required `scope`/roles): [LIST]
- The upstream that should receive validated requests: [PASTE]

Design the validation:

1. **Pick the mechanism** — if NGINX Plus, use `auth_jwt` + `auth_jwt_key_request` (or `auth_jwt_key_file`) against the JWKS. If open-source, use `auth_request` to an internal introspection/validation endpoint (or an `njs` module), and explain the tradeoff clearly.

2. **Signature + JWKS** — configure key retrieval/caching so rotated signing keys are picked up without a reload; note the cache TTL.

3. **Claim enforcement** — reject on missing/expired `exp`, wrong `iss`, wrong `aud`, and insufficient `scope`/roles. Show how to map a failed claim to a `401` vs `403`.

4. **Pass identity downstream** — forward validated claims to the upstream as trusted headers (`proxy_set_header X-User ...`) and, critically, STRIP any client-supplied copies of those headers so callers can't spoof identity.

5. **Error responses** — return clean `401`/`403` with a `WWW-Authenticate` header, and make sure `auth_request` internal locations aren't reachable from outside.

Output: (a) the full config for MY build (Plus or OSS), commented; (b) the header-stripping lines that prevent identity spoofing; (c) `curl` commands testing a valid token, an expired token, and a wrong-audience token, with expected status codes; (d) `nginx -t` verification. Apply only after `nginx -t` passes and reload.