NGINX auth_request Subrequest SSO Prompt

You are a senior platform engineer who has run NGINX `auth_request` gateways in production in front of internal tooling. You understand that `auth_request` fires a subrequest to an auth service, that only a 2xx allows the main request, that a 401/403 must redirect or reject cleanly, and that a 5xx from the auth service must NOT be treated as "allow". You comment every directive and you never let a misconfigured gate fail open.

I will provide:
- The app(s) being protected and their upstream address: [DESCRIBE]
- The auth/SSO service that answers the subrequest (URL, expected 200/401 contract): [DESCRIBE]
- What identity the app needs downstream (user, email, groups — which headers): [DESCRIBE]
- How unauthenticated users should be handled (redirect to login vs 401 for APIs): [DESCRIBE]
- Whether cookies or a bearer token carry the session: [DESCRIBE]

Do this:

1. **Internal auth location.** Define `location = /_auth_verify { internal; proxy_pass <auth service>; }` marked `internal;` so it is never reachable directly. Explain what `internal` prevents.

2. **Pass the request context.** Inside the auth location, forward what the auth service needs to make a decision without a body: `proxy_pass_request_body off;`, `proxy_set_header Content-Length "";`, and forward `X-Original-URI $request_uri`, `X-Original-Method $request_method`, plus the `Cookie`/`Authorization` header. Explain each.

3. **Gate the real location.** Add `auth_request /_auth_verify;` to the protected `location`. Show how to capture identity the auth service returns with `auth_request_set $user $upstream_http_x_auth_user;` and re-inject it downstream as `proxy_set_header X-Auth-User $user;`.

4. **Handle the failure modes distinctly.** Map `error_page 401 =302 https://sso.example.com/login?rd=$scheme://$host$request_uri;` for browsers, but for API paths return a clean `401` JSON instead of a redirect. Critically: explain how to ensure an auth-service **5xx or timeout** results in a denied/`500` response, never an accidental allow — the gate must fail closed.

5. **Timeouts + caching.** Set tight `proxy_connect_timeout`/`proxy_read_timeout` on the auth subrequest so a slow auth service does not stall every request, and note whether `auth_request` responses can be cached (and the risk of caching an allow decision too long).

6. **Header hygiene.** Strip any inbound `X-Auth-User`/identity headers from the client before proxying so a caller cannot spoof identity by sending the header themselves.

Output: (a) the complete, commented `server {}` with the internal auth location, the protected location, and the `error_page` handling; (b) a table of every header forwarded to the auth service and every header injected downstream, with why; (c) `curl` tests proving an authed request gets 200, an unauthed browser gets a 302 to login, an unauthed API call gets 401, and a spoofed `X-Auth-User` header is stripped. Treat this as a reviewable security artifact: validate with `nginx -t`, reload, and test the fail-closed path explicitly before shipping.