Token value reflected in Huma 422 validation error (info disclosure)

[saucam]

Problem

The OAuth form endpoints reject unknown request parameters with a Huma strict-schema 422, and the error's value field echoes the entire request body — including the submitted token. From the WIMSE review:

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

The reflected token lands in the HTTP response and plausibly in access/error logs — disclosure of a (possibly valid) credential. This affects the strict-schema form/JSON endpoints:

• /oauth2/token/introspect — IntrospectInput (internal/handler/oauth.go:113-117)
• /oauth2/token/revoke — OAuthRevokeInput (internal/handler/oauth.go:123-127)
• /oauth2/token — TokenInput (internal/handler/oauth.go:21-65)

Two coupled problems:

1. It should not 422 on unknown params at all. OAuth endpoints should ignore unrecognized request parameters (RFC 6749 §3.2 / RFC 7662 posture), not reject them. The 422 is a side effect of Huma's strict-schema validation.
2. Even on a legitimate validation error, the request body value must never be echoed — it can carry secrets (token, client_secret).

Proposed change

• Configure Huma to ignore unknown properties on these structs (Huma 2 supports relaxing additionalProperties per-struct / globally — per @adeinega's follow-up), so extra params don't 422 and spec-compliant "ignore unrecognized parameter" behavior is restored.
• Independently, scrub the value field (or redact secret-bearing fields) from validation-error responses so no submitted credential is ever reflected, and ensure these bodies are not logged verbatim.

References

• RFC 6749 §3.2 / RFC 7662 — ignore unrecognized request parameters
• Huma — disabling strict unknown-property rejection (Huma 2 can be told to ignore unknown JSON properties)
• Code: internal/handler/oauth.go:21-65, 113-131 (input structs), :184 (form content-type)
• Reported by Andrii Deinega via WIMSE WG review of ZeroID. Related: OAuth introspection & revocation endpoints are unauthenticated (RFC 7662 §2.1 / RFC 7009) #201 (unauthenticated introspection/revocation — same endpoints).