fix(backend): require HTTP message signature on GET /outgoing-payment-grant

[SashaMIT]

Problem

GET /:tenantId/outgoing-payment-grant is wired with exactly two handlers , createOutgoingPaymentGrantTokenIntrospectionMiddleware() and outgoingPaymentRoutes.getGrantSpentAmounts , while every sibling token-protected Open Payments route in the same router (incoming-payments create/list/get/complete, outgoing-payments create/list/get, quotes create/get) pairs its introspection middleware with httpsigMiddleware.

Open Payments binds the access token to the client's key and requires each request to carry an HTTP Message Signature, so possession of the token alone is not supposed to be sufficient. On this endpoint it was: a leaked GNAP access token for outgoing-payment create access could be replayed bearer-style, with no Signature/Signature-Input headers, to read the grant's spent debit and receive amounts , and the endpoint doubles as an oracle confirming a stolen token is still active.

The intended contract is visible in the repo itself: bruno/collections/Rafiki/Open Payments APIs/Outgoing Payment Grant/Get Outgoing Payment Grant.bru calls scripts.addSignatureHeaders() in its pre-request script , clients sign; the server just never verified.

Fix

• Add httpsigMiddleware to the route, matching every sibling route.
• Set ctx.client from the introspection result in createOutgoingPaymentGrantTokenIntrospectionMiddleware (as createTokenIntrospectionMiddleware already does), which httpsigMiddleware needs to resolve the caller's key.
• Introduce SignedGrantContext (GrantContext & HttpSigContext) and type the route with it, so the wiring is checked at compile time.
• Extend the middleware's success-path test to assert ctx.client is populated.

Verification

tsc --noEmit on the backend package is at exact parity with the unpatched baseline (10 pre-existing errors, none in touched files). Jest suites require the Postgres/Redis testcontainers environment, which isn't available here; the middleware success-path test was extended to cover the new ctx.client assignment.

If the omission was deliberate (e.g. the endpoint is considered low-sensitivity), happy to close, but the asymmetry with every sibling route and the repo's own signed client request suggest it was an oversight when the endpoint was added.

[netlify]

✅ Deploy Preview for brilliant-pasca-3e80ec canceled.

Name	Link
🔨 Latest commit	a4a68d4
🔍 Latest deploy log	https://app.netlify.com/projects/brilliant-pasca-3e80ec/deploys/6a7ad543ea3f55000828f8ae

[mkurapov]

Thank you for the contribution, @SashaMIT!
Added minor feedback to tidy up the comments

[mkurapov]

Suggested change

	// httpsigMiddleware resolves the caller's key from ctx.client; set it
	// exactly as createTokenIntrospectionMiddleware does for every sibling
	// route.
	// httpsigMiddleware resolves the caller's key from ctx.client

[mkurapov]

Suggested change

	// Every other token-protected Open Payments route pairs introspection
	// with HTTP message signature verification; possession of the access
	// token alone is not supposed to be sufficient to call this endpoint.

[SashaMIT]

Thanks @mkurapov, applied the comment tidy-ups in the latest commit (shortened the ctx.client notes and removed the route-level rationale comment). Happy to adjust further if anything else stands out.