# 3.2 — Bearer token validation (GREEN)

Phase: 3 — Authentication
Stage: GREEN
Depends on: [3.1](3.1-jwks-fetch-and-rotation.md)

- [ ] `Authorization: Bearer <jwt>` is the credential the gateway accepts on protected routes
- [ ] The scheme match is case-insensitive, as the HTTP spec requires — `bearer`, `Bearer` and `BEARER` all work
- [ ] A valid, unexpired token signed by a currently published Authentik key returns the upstream response
- [ ] Missing header, wrong scheme, malformed token, bad signature, expired token, and wrong issuer or audience each return 401 with `WWW-Authenticate` set
- [ ] Rejections are RFC 9457 `application/problem+json`, and the reason is logged without logging the token
- [ ] The `Authorization` header is not forwarded to upstreams
- [ ] The validated caller identity is available to later stages, since [3.5](3.5-capability-authorization.md) authorizes on it
- [ ] Signature verification is real: a token with a valid-looking payload and a forged signature is rejected

This is precisely what Kong OSS `key-auth` could not do. Verified live: a raw
`apikey:` header succeeded with 200 while `Authorization: Bearer` failed with 401,
which hard-blocked every OpenAI-compatible client and is why authentication is OFF
on the model API today.

Authentik is at `https://authentik.riotpiao.com`. A local stub issuer must be enough
to work this task — no cluster, no credentials.

## Verify

```bash
curl -s -o /dev/null -w '%{http_code}\n' localhost:8080/v1/chat/completions \
  -H "authorization: Bearer $VALID_TOKEN" -H 'content-type: application/json' \
  -d '{"model":"reasoning","messages":[]}'
# expected: 200

curl -s -i localhost:8080/v1/chat/completions -H 'content-type: application/json' -d '{"model":"reasoning"}'
# expected: 401, WWW-Authenticate present, content-type application/problem+json

curl -s -o /dev/null -w '%{http_code}\n' localhost:8080/v1/models -H "apikey: $OLD_KONG_KEY"
# expected: 401 — the retired Kong credential form is not accepted
```