An API gateway is the front door to the rest of the system. Most of its work is plumbing — request routing, rate limiting, observability hooks — but the security work on top of that plumbing is what determines whether the platform is the kind of system an attacker walks around or the kind they walk through.
The patterns below are the ones that earned their keep on the Web3 wallet platform and the multi-tenant payment platform: protecting third-party keys behind a Lambda proxy, JWT/OIDC verification at the edge, RBAC enforced through Casbin or Keycloak, and outbound IPN callbacks with signing and replay protection.
Third-party keys belong behind a proxy
The first rule of provider integrations is that provider API keys do not live in the client. The interesting case is what "do not live in the client" means in practice. A reverse proxy that terminates TLS and forwards a key as a header is one option; a serverless function that brokers calls and returns only the response body is another.
The proxy approach works well when the gateway already exists. The function approach works well when the gateway is heavier than the work it is doing. On the Web3 wallet platform the third-party provider surface was small enough to justify a Lambda proxy per provider — fewer moving parts than re-routing through the gateway and easier to audit on a per-provider basis.
Either way the contract is the same: the client sees the platform's contract, the platform holds the key, and the provider sees only the server's traffic.
JWT verification belongs at the edge, not in the service
The next reflex is to verify the token in the service that needs it. That is the wrong reflex for two reasons. The first is that every service then has to know the JWKS endpoint, the issuer, the audience, and the algorithm — the same configuration in N places. The second is that "verify at the edge" lets the gateway make authorization decisions (rate limits, route selection, audit metadata) on the verified subject, which is information the service cannot trust unless it re-verifies itself.
A gateway that verifies a token once and forwards the verified claims as headers (subject, tenant, scope) is a gateway that turns token validation into a routing primitive rather than a per-service chore.
RBAC is policy, not middleware
Role-based access control gets bolted on inconsistently. The version that survives contact with production is the version where the policy is data: a policy bundle loaded by the gateway, evaluated per request, and refreshed out of band.
Casbin is a reasonable choice for a service that owns its own authorization decisions; Keycloak (extended with custom SPIs when needed) is the right choice for multi-tenant platforms where authZ has to be tenant-scoped, auditable, and consistent with the platform's identity model. The mistake is to reach for one when the other is the better fit, or — more often — to reach for neither and let access checks drift into the handlers.
Out-of-band policy bundles are the version of this that does not show up in the request path. The gateway hot path performs a lookup, not an evaluation.
Outbound callbacks deserve signatures and replay protection
Inbound security gets all the attention; outbound is where most platforms get compromised. An IPN callback to a merchant endpoint is the platform telling the merchant "this is what we observed". A callback without a signature is a callback anyone can forge; a callback without replay protection is a callback a merchant can be tricked into processing twice.
Two patterns hold up:
- Sign with HMAC over canonicalized payload. The platform signs a stable representation of the payload with a per-merchant secret. The merchant verifies the signature before processing. Rotating the secret is an out-of-band workflow with rollover.
- Replay protection via nonce + timestamp window. Every callback carries a unique nonce and a timestamp; the merchant rejects duplicates and stale messages. The platform stores the nonces it has issued and refuses to re-issue.
Together they turn "trust the network" into "verify the message".
Rate limits are part of the security story
Rate limiting is usually framed as a platform-protection feature (protect yourself from clients). On a payment platform it is also a partner-protection feature (protect partners from runaway integrations). The hard part is keeping the limits consistent across surfaces — the partner's Open API and the platform's internal callers both need to be subject to the same tenant-scoped limits, otherwise one surface becomes a back door around the others.
Observability earns the audit log
Every gateway decision worth making is worth logging. Denied requests, signature failures, replay rejections, RBAC denials — all of these become a story that someone reads the morning after. The story is only useful if it is structured, queryable, and correlated with the request id that the rest of the platform uses.
Logging is not security, but a system that logs its security decisions is a system that recovers from security incidents. A system that does not, is a system that recovers from rumors.
The minimum shape
A hardened API gateway in production has: third-party keys behind a proxy; token verification at the edge with claims forwarded as headers; policy-based RBAC; signed outbound callbacks with replay protection; tenant-scoped rate limits; structured audit logging. The order matters because each layer assumes the one below it. Build them in that order and you can defend the system one capability at a time.