Reflected token in OAuth validation error body (credential leak)

[rsharath]

Summary

Validation errors on the OAuth form endpoints echo the entire request body — including the submitted token — back to the client in the error response. This reflected token can leak into logs, proxies, and error-tracking pipelines.

Reproduction

$ curl -X POST -d "token=12345&azz=123" http://localhost:8899/oauth2/token/introspect
{"$schema":"http://localhost:8899/schemas/ErrorModel.json","title":"Unprocessable Entity","status":422,"detail":"validation failed","errors":[{"message":"unexpected property","location":"body.azz","value":{"azz":"123","token":"12345"}}]}

Note the value field reflects {"azz":"123","token":"12345"} — the token (12345) is now in the response body and any log that captures it.

Cause

Huma's validation error includes a value field containing the offending request body. On the OAuth endpoints this body carries the bearer/refresh/access token.

Fix

• Stop reflecting the request body value in error responses on the OAuth endpoints (suppress the field, or replace with a redacted placeholder).
• Audit other error paths for the same body-reflection pattern.
• This is largely subsumed by moving these endpoints off Huma to plain chi handlers (linked), but the leak should be closed regardless of how/when that lands.

Severity

Security — credential material in response bodies / logs.

---

Reported by Andrii Deinega via WIMSE WG review of ZeroID.

[rsharath]

Root cause shared with #190 — moving these endpoints off Huma (#190) removes the body-reflection source. This issue tracks closing the leak regardless of timing.