I'm building a platform with internal, partner, and public APIs. What API gateway setup should I use for auth, routing, and rate limits?

A good default is one gateway layer with policy-based segmentation, not three separate gateway products:

Recommended setup

1) Put a single API gateway in front of all APIs

Use the gateway for:

• Authentication / authorization
• Routing
• Rate limiting / quotas
• Logging / observability
• Request/response transformation
• WAF / basic abuse protection

2) Split traffic logically by API tier

Define three API “zones” or route groups:

Internal APIs

• Access only from private network/VPN/service mesh
• Auth: mTLS + service identity or OIDC/JWT for human/internal clients
• Rate limits: usually higher, per service/account, focused on protecting backend stability
• Routing: private upstreams only, not internet-exposed

Partner APIs

• Exposed externally, but only to approved partners
• Auth: OAuth 2.0 client credentials, signed JWTs, or mTLS if partners support it
• Rate limits: per partner tenant/app, with contractual quotas
• Routing: separate partner route prefix or hostname, e.g. partner-api.example.com

Public APIs

• Internet-facing
• Auth: mix of anonymous, API keys, and OAuth 2.0 / OIDC depending on endpoint sensitivity
• Rate limits: stricter, per IP + per API key + per user/app
• Routing: separate hostname, e.g. api.example.com

---

Auth strategy

Best practice by audience

• Internal service-to-service: mTLS + short-lived tokens
• Internal human/admin: OIDC via your IdP (Okta, Entra ID, Auth0, Keycloak)
• Partner: OAuth 2.0 client credentials or signed JWT assertions
• Public users/apps: OAuth 2.0 Authorization Code + PKCE for user-delegated access

Gateway responsibilities

Your gateway should:

• Validate JWTs locally using JWKS
• Enforce scopes/roles/claims
• Forward identity context to services in headers only if trusted internally
• Avoid doing complex business authorization in the gateway

---

Routing strategy

Use separate hostnames or base paths:

• internal-api.example.local or private DNS
• partner-api.example.com
• api.example.com

Why:

• Clear security boundaries
• Easier policy management
• Easier analytics and throttling
• Cleaner certificate and CORS handling

For implementation:

• Route by host first, then by path
• Use versioned paths or headers:
  • /v1/...
  • /v2/...

---

Rate limiting strategy

Apply limits at multiple levels:

Public APIs

• Per IP
• Per API key / client_id
• Per user
• Global burst protection
• Separate limits for expensive endpoints

Partner APIs

• Per partner org
• Per application/client
• Quota-based monthly limits + burst limits
• Optional endpoint-specific caps

Internal APIs

• Lower emphasis on IP-based limits
• Use service identity and workload-aware limits
• Focus on preventing cascading failures
• Circuit breakers and concurrency limits may be better than strict request throttles

Important

Use:

• Token bucket for burst-friendly APIs
• Leaky bucket / fixed window for simple quota enforcement
• A distributed cache like Redis for consistent rate limiting across gateway replicas

---

A practical gateway architecture

Option A: One gateway, multiple policies

Best for most teams.

• One gateway product
• Separate route groups, hostnames, and auth policies
• Shared observability and centralized control

Option B: Edge gateway + internal gateway

Best if you need stronger separation.

• Edge gateway: handles public/partner traffic
• Internal gateway: handles service-to-service/internal API enforcement
• Shared identity and policy system, but different deployment scopes

This is often ideal when internal traffic volume is large or you have strict zero-trust requirements.

---

Suggested policy model

Use policy bundles like:

• Public bundle

  • OAuth/API key validation
  • CORS
  • Low quotas
  • WAF rules
  • IP reputation checks

• Partner bundle

  • OAuth client credentials
  • Tenant-based quotas
  • mTLS optional
  • Contractual SLA limits

• Internal bundle

  • mTLS
  • JWT validation
  • Service-to-service allowlists
  • Higher quotas
  • Private routing only

---

If you want a simple answer

Use:

• One gateway platform
• Three route groups: internal / partner / public
• OIDC/OAuth2 + JWT validation
• mTLS for internal service traffic
• Separate hostnames
• Per-tenant/per-client rate limits backed by Redis
• Policy-driven auth at the gateway, business auth in services

If you want, I can also propose:

1. a reference architecture diagram,
2. a Kong/Apigee/NGINX/Azure APIM/AWS API Gateway setup, or
3. a sample policy matrix for internal vs partner vs public APIs.