← Engineering · Case studies API economy · Case study

Secure API access & governance

Authentication and rate limiting enforced at the gateway, with a governance review that decides visibility, PII, and access before an API is ever built.

Overview

Authentication was handled differently in every service, there was no consistent rate limiting, and it was unclear which APIs exposed PII or should be public. The goal was access that is secure by design at the edge, and a governance gate that answers the hard questions before build.

Auth is enforced at the gateway: initially JWTs issued via an Auth Proxy for coarse-grained decisions, with fine-grained authorization left to the service — a transitional model on the path to OAuth2 and OpenID Connect.

The challenge

Authentication implemented inconsistently across services
No rate limiting, leaving services exposed to abuse and overload
Unclear which endpoints exposed PII or should be public, partner, or private
Security was considered too late — after the API was built

Our approach

Centralised authentication at the gateway using JWTs (via the Auth Proxy) for coarse-grained access, with fine-grained authorization in the service
Planned the transition to industry-standard OAuth 2.0 and OpenID Connect
Enabled rate-limiting and request-validation plugins to protect services and curb abuse
Segmented exposure into public, partner, and private workspaces
Ran a governance review of the domain model, C4 context, and API specification before build — addressing expected volume, endpoint visibility, PII, and access

Results & business impact

Authentication is consistent and enforced at the edge
Services are protected by rate limiting and request validation
Public, partner, and private exposure is a deliberate, reviewed decision
PII and security questions are answered before code, not after an incident

Tools & technology

API Gateway JWT OAuth 2.0 OpenID Connect Rate limiting Request validation Governance review Public/Partner/Private PII