test: verify revoked keys fail gateway auth immediately

[kaizercodes]

Overview

This PR closes the gap where gatewayRoutes.ts consults getTokenRevocationService().isRevoked(apiKeyHash) and DELETE /keys/:id adds the hash, but no end-to-end test proved that a deleted key is rejected on the very next gateway call. It adds that integration coverage and tightens the revocation path so the hash (not plaintext) is what gates authentication.

Related Issue

Changes

🔐 Revocation enforcement

• [MODIFY] src/middleware/gatewayApiKeyAuth.ts

  • Hashes the presented API key with sha256 before consulting the revocation service, so lookups are keyed by hash and never by plaintext.
  • Returns 401 immediately when the hash is revoked, before any upstream dispatch.

• [MODIFY] src/routes/gatewayRoutes.ts

  • Ensures the revocation check runs on the request path prior to proxying, so a revoked key cannot reach the upstream.

• [MODIFY] src/routes/apiKeyRoutes.ts

  • DELETE /keys/:id records the sha256 hash of the key in the revocation service so subsequent gateway calls fail closed.

• [MODIFY] src/services/tokenRevocation.ts

  • Revocation entries are stored and queried by sha256 hash; isRevoked takes the hash, not the raw key.

🧪 Integration coverage

• [MODIFY] tests/integration/keys.test.ts
  • Creates a key via createApiKeyRouter, calls the gateway successfully, deletes the key, then asserts the next gateway call returns 401.
  • Asserts the upstream stub records no request after revocation.
  • Asserts the revocation service entry is keyed by sha256 hash, not plaintext.

Verification Results

npm test -- tests/integration/keys.test.ts src/routes/gatewayRoutes.test.ts
✅ passing

Acceptance Criteria	Status
The call before revocation succeeds	✅ Gateway call with the created key returns success
The call after revocation returns 401	✅ Next gateway call after DELETE /keys/:id returns 401
The upstream stub records no request after revocation	✅ Upstream stub request count unchanged post-revocation
The revocation service entry is keyed by sha256 hash, not plaintext	✅ Asserted against the sha256 of the key, plaintext absent

Security & Failure Modes

• Revocation is checked on every gateway request, so a leaked key stops working on the next call rather than at token expiry.
• Lookups are hash-keyed, so the revocation store never holds plaintext credentials.
• The check runs before upstream dispatch, so a revoked key cannot cause side effects or leak data upstream.
• Fail-closed behavior: a revoked hash short-circuits with 401 and no proxy attempt.

Compatibility

No public API or route shape changes. The revocation service now consistently keys by sha256 hash, matching how gatewayRoutes.ts already called isRevoked(apiKeyHash).

Closes #1318

[drips-wave]

@kaizercodes Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits