Summary
The standard OAuth endpoints — /oauth2/token, /oauth2/token/introspect, /oauth2/token/revoke — are currently served through Huma. Huma generates request schemas with additionalProperties: false, which causes spec-noncompliant behavior on these endpoints (see linked issues for the resulting 422-on-unknown-param and token-reflection bugs). We should move these endpoints to plain chi handlers.
Rationale
Huma earns its keep elsewhere in the stack via OpenAPI generation and client codegen. On the OAuth surface specifically, that value is close to zero:
- These endpoints are discovered through AS/OP metadata (
/.well-known/oauth-authorization-server, /.well-known/openid-configuration), not through our OpenAPI document.
- Any compliant OAuth client already knows their request/response shapes from the RFCs (6749, 7662, 7009) — generated clients add nothing.
Meanwhile Huma's strict-schema validation actively works against RFC 6749 §3.1, which requires servers to ignore unrecognized request parameters. (Huma 2 can be told to ignore unknown fields per-struct or globally, which would patch the symptom — but on these endpoints the framework provides no offsetting benefit.)
There is already local precedent for the plain-chi approach: /oauth2/token/verify is a bare chi handler (internal/handler/auth_verify.go), not a Huma operation.
Scope
- Re-implement
/oauth2/token, /oauth2/token/introspect, /oauth2/token/revoke as plain chi handlers with manual form/JSON parsing.
- Preserve the existing form-compat behavior (accept both
application/x-www-form-urlencoded and JSON).
- Ignore unrecognized parameters per RFC 6749 §3.1.
- Closes the underlying cause of the unknown-param 422 and the reflected-token error-body leak (linked).
References
- RFC 6749 §3.1 — servers MUST ignore unrecognized request parameters
- RFC 7662 (introspection), RFC 7009 (revocation)
Reported by Andrii Deinega via WIMSE WG review of ZeroID.
Summary
The standard OAuth endpoints —
/oauth2/token,/oauth2/token/introspect,/oauth2/token/revoke— are currently served through Huma. Huma generates request schemas withadditionalProperties: false, which causes spec-noncompliant behavior on these endpoints (see linked issues for the resulting 422-on-unknown-param and token-reflection bugs). We should move these endpoints to plain chi handlers.Rationale
Huma earns its keep elsewhere in the stack via OpenAPI generation and client codegen. On the OAuth surface specifically, that value is close to zero:
/.well-known/oauth-authorization-server,/.well-known/openid-configuration), not through our OpenAPI document.Meanwhile Huma's strict-schema validation actively works against RFC 6749 §3.1, which requires servers to ignore unrecognized request parameters. (Huma 2 can be told to ignore unknown fields per-struct or globally, which would patch the symptom — but on these endpoints the framework provides no offsetting benefit.)
There is already local precedent for the plain-chi approach:
/oauth2/token/verifyis a bare chi handler (internal/handler/auth_verify.go), not a Huma operation.Scope
/oauth2/token,/oauth2/token/introspect,/oauth2/token/revokeas plain chi handlers with manual form/JSON parsing.application/x-www-form-urlencodedand JSON).References
Reported by Andrii Deinega via WIMSE WG review of ZeroID.