How do I enforce auth and rate limits across internal and public APIs?

A good way to enforce auth and rate limits across both internal and public APIs is to apply them in layers, with a clear split between:

1. Edge / gateway controls
2. Service-to-service controls
3. App-level authorization
4. Shared policy + observability

1) Put a gateway in front of public APIs

For public APIs, enforce most of the cross-cutting controls at an API gateway or ingress layer:

• Authentication: validate API keys, OAuth2/JWT, mTLS where appropriate
• Authorization: route-level permissions, scopes, tenant checks
• Rate limiting: per IP, per API key, per client, per tenant
• Abuse protections: WAF rules, bot detection, throttling, quotas
• Request validation: schema, size limits, method restrictions

This gives you a single place to protect all public traffic.

2) Treat internal APIs as “private, not trusted”

Internal APIs should still be protected. Don’t assume “inside the network” means safe.

For internal service-to-service traffic, use:

• mTLS for service identity
• Service accounts / workload identity
• JWTs or signed tokens for end-user context propagation when needed
• Policy enforcement at service mesh / gateway / sidecar / library level
• Network policies to restrict who can call whom

Even internal APIs should have:

• authn
• authz
• rate limits
• audit logging

3) Separate authentication from authorization

A clean model is:

• Authentication: who/what is calling?
• Authorization: is that caller allowed to do this action on this resource?

Examples:

• Public user logs in via OAuth/OIDC → gets JWT
• Gateway verifies token
• Backend checks scopes/roles/tenant/resource ownership

For internal services:

• Service identity proves “this is service A”
• Policy says whether service A can call endpoint X
• If user context is forwarded, backend checks both service identity and end-user permissions

4) Use layered rate limits

Use different limits at different levels:

Public-facing limits

• Per IP
• Per API key / client ID
• Per user
• Per tenant
• Per endpoint
• Global burst + sustained quotas

Internal limits

• Per service identity
• Per route
• Per tenant/customer
• Concurrency limits
• Circuit breakers / retries budgets

This prevents one noisy internal service from taking down others.

5) Centralize policy, decentralize enforcement

A common pattern:

• Define policies centrally
• Enforce them close to traffic:
  • gateway/ingress for public APIs
  • sidecars/service mesh for internal APIs
  • app middleware for resource-specific authorization

This balances consistency and performance.

6) Recommended architecture

A practical setup looks like this:

Public client → API Gateway → Auth service / JWT verification → API service

Service A → service mesh mTLS → Service B

At each hop:

• verify identity
• check authorization
• apply rate limits
• log decisions

7) Implementation options

Depending on your stack:

Gateway / ingress

• Kong, Apigee, NGINX, Envoy, AWS API Gateway, Azure APIM, GCP API Gateway

Auth

• OAuth2/OIDC provider: Auth0, Okta, Keycloak, Cognito
• JWT validation at gateway and services
• mTLS for workloads

Internal policy

• Service mesh: Istio, Linkerd, Consul
• Policy engine: OPA / Open Policy Agent, Cedar, custom RBAC/ABAC

Rate limiting

• Redis-backed distributed counters
• Envoy global/local rate limiting
• Token bucket / leaky bucket algorithms

8) Best practices

• Don’t rely only on IP-based auth
• Don’t put sensitive auth decisions only in the frontend
• Validate auth at both edge and service layer for defense in depth
• Make rate limits tenant-aware
• Return clear error codes:
  • 401 unauthenticated
  • 403 unauthorized
  • 429 rate limited
• Log and trace auth/rate-limit decisions with request IDs
• Rotate secrets and keys regularly
• Prefer short-lived tokens

9) A simple policy model

You can think of access control like:

• Public: authenticated via OAuth/API key, limited by client/tenant
• Internal: authenticated by workload identity/mTLS, limited by service identity
• Sensitive endpoints: require both caller identity and user authorization
• High-volume endpoints: stricter per-route limits

10) Good default recommendation

If you want a strong default:

• Use an API gateway for all public traffic
• Use OIDC/JWT for users and mTLS for services
• Enforce authorization in services for resource-level checks
• Add distributed rate limiting keyed by tenant/client/service
• Use a service mesh if you have many internal services

If you want, I can also give you:

1. a reference architecture diagram,
2. a Kubernetes/Istio example, or
3. a concrete implementation in Node/Go/Python.