Problem
The middleware never verifies JWT signatures in-process. Both transports parse
tokens with ParseUnverified:
auth/middleware/middleware.go:276 (Fiber)auth/middleware/middlewareGRPC.go:211 (gRPC)
Claims (type, owner, sub) are read straight from an unverified token and
used to build the authz subject (middleware.go:296-314). All trust rests on the
external auth service reachable via the POST to /v1/authorize
(middleware.go:338). There is no JWKS support anywhere in the module — no
config key is read for it; the capability is simply absent.
Impact
A consumer with no in-process signature check has zero defense-in-depth: if the
authz call is misrouted, MITM'd, or served by a compromised/substituted endpoint,
a forged-but-well-formed token flows through claim extraction unchallenged. The
library cannot independently establish that the bearer token is authentic.
Proposal
Add opt-in JWKS verification, backward-compatible (off by default):
- Config field on
AuthClient (e.g. JWKSAddress) + env (e.g. AUTH_JWKS_ADDRESS).
- When set, fetch+cache the key set and verify signature/
exp/iss/aud
before claim extraction, on both Fiber and gRPC paths.
- When unset, preserve current behavior exactly.
Downstream context
midaz pins lib-auth/v2 v2.8.0 (upstream-only, never forked). Downstream cannot
add signature verification without wrapping the middleware, which defeats the
shared-library contract. A library-level opt-in keeps the verification logic in
one audited place.
Problem
The middleware never verifies JWT signatures in-process. Both transports parse
tokens with
ParseUnverified:auth/middleware/middleware.go:276(Fiber)auth/middleware/middlewareGRPC.go:211(gRPC)Claims (
type,owner,sub) are read straight from an unverified token andused to build the authz subject (
middleware.go:296-314). All trust rests on theexternal auth service reachable via the POST to
/v1/authorize(
middleware.go:338). There is no JWKS support anywhere in the module — noconfig key is read for it; the capability is simply absent.
Impact
A consumer with no in-process signature check has zero defense-in-depth: if the
authz call is misrouted, MITM'd, or served by a compromised/substituted endpoint,
a forged-but-well-formed token flows through claim extraction unchallenged. The
library cannot independently establish that the bearer token is authentic.
Proposal
Add opt-in JWKS verification, backward-compatible (off by default):
AuthClient(e.g.JWKSAddress) + env (e.g.AUTH_JWKS_ADDRESS).exp/iss/audbefore claim extraction, on both Fiber and gRPC paths.
Downstream context
midaz pins
lib-auth/v2v2.8.0 (upstream-only, never forked). Downstream cannotadd signature verification without wrapping the middleware, which defeats the
shared-library contract. A library-level opt-in keeps the verification logic in
one audited place.