API Rate Limiting & Authentication
Best Practices 2026

Why Rate Limiting Matters

In 2025, 73% of public APIs experienced some form of abuse—ranging from credential stuffing to runaway automation scripts that burned through millions of tokens in hours. Rate limiting is no longer optional infrastructure; it is a core reliability, security, and cost-control mechanism.

Without rate limiting, a single misconfigured client can exhaust your database connection pool, inflate your cloud bill by orders of magnitude, and deny service to every legitimate user. Here are four real-world incidents that illustrate why this matters at every scale.

Rate Limiting Algorithms Compared

Choosing the right algorithm determines whether your API rejects bursts gracefully or allows them intentionally. Each algorithm trades precision, memory usage, and implementation complexity differently.

Redis-Based Rate Limiting Implementation

Redis is the de facto standard for production rate limiting because it provides sub-millisecond latency, atomic operations via Lua scripts, and native TTL support. Here are the key patterns you need.

Token Bucket — INCR + EXPIRE

// Node.js — Token Bucket via Redis INCR + EXPIRE
async function isAllowed(redis, key, limit, windowSeconds) {
  const current = await redis.incr(key);
  if (current === 1) {
    // First request in window — set TTL
    await redis.expire(key, windowSeconds);
  }
  return current <= limit;
}

// Usage
const allowed = await isAllowed(redis, `rl:${userId}`, 100, 60);
if (!allowed) {
  res.status(429).json({ error: 'Rate limit exceeded', retryAfter: 60 });
  return;
}

Sliding Window Log — ZADD + ZREMRANGEBYSCORE

// Sliding Window Log — stores timestamp per request as sorted set
async function slidingWindowCheck(redis, key, limit, windowMs) {
  const now = Date.now();
  const windowStart = now - windowMs;

  const pipeline = redis.pipeline();
  // Remove timestamps outside the window
  pipeline.zremrangebyscore(key, '-inf', windowStart);
  // Add current request timestamp
  pipeline.zadd(key, now, `${now}-${Math.random()}`);
  // Count requests in window
  pipeline.zcard(key);
  // Set TTL so keys self-clean
  pipeline.expire(key, Math.ceil(windowMs / 1000) + 1);
  const results = await pipeline.exec();

  const requestCount = results[2][1];
  return requestCount <= limit;
}

Atomic Lua Script (Race-Condition Safe)

The INCR + EXPIRE pattern above has a tiny race window between the two commands. Use a Lua script to make the operation fully atomic — Redis executes Lua scripts as a single unit with no interruption.

-- rate_limit.lua — atomic token bucket
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])

local current = redis.call('GET', key)
if current and tonumber(current) >= limit then
  return 0  -- rate limited
end

local new_val = redis.call('INCR', key)
if new_val == 1 then
  redis.call('EXPIRE', key, window)
end
return 1  -- allowed

-- Load and call from Node.js:
-- const result = await redis.eval(luaScript, 1, key, limit, windowSecs);

Using redis-rate-limiter (npm)

import { RateLimiterRedis } from 'rate-limiter-flexible';
import { createClient } from 'redis';

const redisClient = createClient({ url: process.env.REDIS_URL });
await redisClient.connect();

const rateLimiter = new RateLimiterRedis({
  storeClient: redisClient,
  keyPrefix: 'rl',
  points: 100,       // max requests
  duration: 60,      // per 60 seconds
  blockDuration: 30, // block for 30s after limit exceeded
});

// Express middleware
export async function rateLimitMiddleware(req, res, next) {
  try {
    const key = req.user?.id ?? req.ip;
    await rateLimiter.consume(key);
    next();
  } catch (rejRes) {
    const secs = Math.ceil(rejRes.msBeforeNext / 1000);
    res.set('Retry-After', String(secs));
    res.status(429).json({ error: 'Too Many Requests', retryAfter: secs });
  }
}

API Gateway Rate Limiting Solutions

For most teams, the right move is to enforce rate limiting at the gateway layer before requests reach application code. Here is how the major platforms compare.

Kong Rate Limiting Plugin (YAML Config)

# kong.yml — Declarative config for rate limiting plugin
plugins:
  - name: rate-limiting
    config:
      minute: 100          # requests per minute
      hour: 2000           # requests per hour
      policy: redis        # local | cluster | redis
      redis_host: redis.internal
      redis_port: 6379
      redis_timeout: 2000
      limit_by: consumer   # ip | consumer | credential | header | path
      hide_client_headers: false
      fault_tolerant: true # fail open if Redis is down

AWS API Gateway — Usage Plans + Throttling

# AWS CDK — API Gateway Usage Plan with throttling
const plan = api.addUsagePlan('BasicPlan', {
  name: 'Basic',
  throttle: {
    rateLimit: 100,   // requests per second (steady state)
    burstLimit: 200,  // token bucket size (max concurrent burst)
  },
  quota: {
    limit: 10000,         // total requests
    period: Period.MONTH, // per calendar month
  },
});

// Attach an API key to the plan
const key = api.addApiKey('MyApiKey');
plan.addApiKey(key);

// Attach the plan to a stage
plan.addApiStage({ stage: api.deploymentStage });

Cloudflare Rate Limiting

Cloudflare's rule builder lets you create rate limit rules based on IP, User-Agent, ASN, cookie, header value, or request path. Rules fire before the request reaches your origin, making them ideal for DDoS mitigation.

# Cloudflare Rate Limiting Rule (Terraform)
resource "cloudflare_rate_limit" "api" {
  zone_id   = var.zone_id
  threshold = 100
  period    = 60  # seconds

  match {
    request {
      url_pattern = "example.com/api/*"
      schemes     = ["HTTPS"]
      methods     = ["GET", "POST"]
    }
  }

  action {
    mode    = "ban"
    timeout = 300  # ban for 5 minutes
    response {
      content_type = "application/json"
      body         = "{"error":"rate limited"}"
    }
  }
}

API Authentication Methods Compared

Rate limiting works best when paired with strong authentication — you can only enforce fair use if you know who is making the request. Here is how the four major approaches compare across eight dimensions.

JWT Best Practices

JWTs are everywhere — and widely misused. These are the non-negotiable practices for production JWT systems.

// Issuing tokens
const accessToken = jwt.sign(
  { sub: userId, iss: 'api.yourdomain.com', aud: 'app', jti: uuidv4() },
  privateKey,
  { algorithm: 'RS256', expiresIn: '15m' }
);

const refreshToken = jwt.sign(
  { sub: userId, family: familyId, jti: uuidv4() },
  refreshSecret,
  { expiresIn: '7d' }
);

OAuth 2.0 Flows — When to Use Each

OAuth 2.0 defines several grant types optimized for different client environments. Choosing the wrong flow is a common security mistake.

Rate Limit Headers & Client Handling

Well-behaved APIs communicate rate limit state through standard response headers. This lets clients self-throttle before hitting the limit, dramatically reducing unnecessary 429 responses.

Standard Response Headers

HTTP/1.1 200 OK
RateLimit-Limit: 100
RateLimit-Remaining: 47
RateLimit-Reset: 1742600000
Retry-After: 32
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 47
X-RateLimit-Reset: 1742600000

# When rate limited (HTTP 429):
HTTP/1.1 429 Too Many Requests
Retry-After: 32
RateLimit-Policy: 100;w=60;comment="sliding window"
Content-Type: application/json

{
  "error": "too_many_requests",
  "message": "Rate limit exceeded. Retry after 32 seconds.",
  "retryAfter": 32
}

Client-Side 429 Handling — Exponential Backoff with Jitter

// Fetch with exponential backoff + jitter
async function fetchWithRetry(url, options = {}, maxRetries = 5) {
  let attempt = 0;
  while (attempt <= maxRetries) {
    const response = await fetch(url, options);
    if (response.status !== 429) return response;

    const retryAfter = response.headers.get('Retry-After');
    const baseWait = retryAfter
      ? parseInt(retryAfter, 10) * 1000
      : Math.min(1000 * 2 ** attempt, 64000);

    // Add jitter: +/- 20% of base wait to avoid thundering herd
    const jitter = baseWait * 0.2 * (Math.random() - 0.5);
    const waitMs = Math.round(baseWait + jitter);

    console.warn(`429 received. Waiting ${waitMs}ms before retry ${attempt + 1}`);
    await new Promise(resolve => setTimeout(resolve, waitMs));
    attempt++;
  }
  throw new Error(`Max retries exceeded for ${url}`);
}

Security Hardening Techniques

Rate limiting and authentication are the foundation, but production APIs need additional layers. Here are the hardening techniques used at scale.

// HMAC request signing
import crypto from 'crypto';

function signRequest(body, secret) {
  const timestamp = Math.floor(Date.now() / 1000).toString();
  const payload = timestamp + '.' + JSON.stringify(body);
  const sig = crypto.createHmac('sha256', secret).update(payload).digest('hex');
  return { 'X-Timestamp': timestamp, 'X-Signature': `sha256=${sig}` };
}

// Webhook signature validation (Stripe/GitHub pattern)
function validateWebhook(payload, signature, secret) {
  const expected = crypto
    .createHmac('sha256', secret)
    .update(payload, 'utf8')
    .digest('hex');
  const trusted = `sha256=${expected}`;
  // Use timingSafeEqual to prevent timing attacks
  return crypto.timingSafeEqual(
    Buffer.from(signature),
    Buffer.from(trusted)
  );
}

Frequently Asked Questions

Book a Security Architecture Review

Our senior engineers will audit your API authentication, rate limiting configuration, and token handling — and deliver a prioritized remediation plan within 5 business days.