File: internal/controller/well_known_controller.go (lines 68, 69)
Project: tinyauth
Severity: BUG • Confidence: high • Slug: other-misleading-metadata
Finding
The OpenID configuration response sets RequestParameterSupported: true and RequestObjectSigningAlgValuesSupported: ["none"], but the AuthorizeRequest struct in internal/service/oidc_service.go has no Request field and the Authorize handler in internal/controller/oidc_controller.go never parses a JWT request object. Clients following discovery will believe they can send a request= parameter (and that unsigned alg:none is acceptable), but tinyauth silently ignores it and proceeds with the URL/JSON params. Today this is just misleading metadata, but if request-object handling is added later without revisiting these fields the server would default to accepting unsigned request objects — exactly the OIDC alg-confusion attack class. RS256 (which the IDP signs ID tokens with) is also notably absent from RequestObjectSigningAlgValuesSupported.
Recommendation
Either implement request-object parsing properly or set RequestParameterSupported: false and remove the ["none"] entry from RequestObjectSigningAlgValuesSupported (or omit the field entirely). When adding request-object support, never honor alg: none; require RS256/ES256/PS256.
Revalidation
Verdict: true-positive
Confirmed: AuthorizeRequest (oidc_service.go:104-113) has no Request field, and the Authorize handler (oidc_controller.go:120-208) parses only the JSON body into that struct — the SERVER never decodes a JWT request parameter. However, commit 18c8413 deliberately added the metadata AND a frontend decoder (frontend/src/lib/hooks/oidc.ts:19-39) that decodes the request=<JWT> query param client-side, REQUIRES alg: none, and merges the JWT claims into the URL params posted to /authorize. So the system as a whole 'supports' unsigned request objects, but only by trusting the browser to do the JOSE parsing. The advertised request_object_signing_alg_values_supported: ["none"] accurately reflects current behavior, but the broader concerns the finding raises are valid: (a) no signature verification means a malicious page/extension could substitute a forged request object — though the URL params would have been equally manipulable, so the impact is null vs. status quo; (b) if a future commit adds server-side request-object parsing, the existing metadata could anchor it to alg:none and produce an alg-confusion vulnerability — exactly the OIDC class. Today's status is misleading metadata + footgun, not exploitable. Correctly classified BUG.
File:
internal/controller/well_known_controller.go(lines 68, 69)Project: tinyauth
Severity: BUG • Confidence: high • Slug:
other-misleading-metadataFinding
The OpenID configuration response sets RequestParameterSupported: true and RequestObjectSigningAlgValuesSupported: ["none"], but the AuthorizeRequest struct in internal/service/oidc_service.go has no Request field and the Authorize handler in internal/controller/oidc_controller.go never parses a JWT request object. Clients following discovery will believe they can send a
request=parameter (and that unsignedalg:noneis acceptable), but tinyauth silently ignores it and proceeds with the URL/JSON params. Today this is just misleading metadata, but if request-object handling is added later without revisiting these fields the server would default to accepting unsigned request objects — exactly the OIDC alg-confusion attack class. RS256 (which the IDP signs ID tokens with) is also notably absent from RequestObjectSigningAlgValuesSupported.Recommendation
Either implement request-object parsing properly or set RequestParameterSupported: false and remove the ["none"] entry from RequestObjectSigningAlgValuesSupported (or omit the field entirely). When adding request-object support, never honor
alg: none; require RS256/ES256/PS256.Revalidation
Verdict: true-positive
Confirmed:
AuthorizeRequest(oidc_service.go:104-113) has noRequestfield, and the Authorize handler (oidc_controller.go:120-208) parses only the JSON body into that struct — the SERVER never decodes a JWTrequestparameter. However, commit 18c8413 deliberately added the metadata AND a frontend decoder (frontend/src/lib/hooks/oidc.ts:19-39) that decodes therequest=<JWT>query param client-side, REQUIRESalg: none, and merges the JWT claims into the URL params posted to /authorize. So the system as a whole 'supports' unsigned request objects, but only by trusting the browser to do the JOSE parsing. The advertisedrequest_object_signing_alg_values_supported: ["none"]accurately reflects current behavior, but the broader concerns the finding raises are valid: (a) no signature verification means a malicious page/extension could substitute a forged request object — though the URL params would have been equally manipulable, so the impact is null vs. status quo; (b) if a future commit adds server-side request-object parsing, the existing metadata could anchor it to alg:none and produce an alg-confusion vulnerability — exactly the OIDC class. Today's status is misleading metadata + footgun, not exploitable. Correctly classified BUG.