Enterprise SSO Integration with CDN: SAML, OIDC, and Custom Identity Providers

Last winter we flipped the switch on CDN acceleration for a large SaaS client's admin portal, and by morning their biggest enterprise customer couldn't log in at all. Their Okta SAML flow was completing successfully, but the CDN was serving a cached redirect loop to everyone else who'd authenticated that hour. It wasn't a bug in Okta or the CDN — we'd treated enterprise SSO like a regular login form, and that's a mistake you only make once. If you're putting a CDN in front of an app that serves enterprise customers, you can't cache first and ask about identity later.

Why Edge Authentication Breaks When You Treat SSO Like a Session Cookie

Most web apps handle authentication at the origin. User logs in, origin sets a session cookie, CDN forwards that cookie and maybe caches based on it. That model falls apart with enterprise SSO because authentication doesn't happen at your origin at all. The identity provider does the heavy lifting, and your application — and by extension your CDN — just has to trust and validate the assertion it gets back. I've seen teams try to cache pages for "authenticated users" using a simple Cookie header check, then wonder why a user from Company A could see data belonging to Company B.

The core problem is isolation. In a multi-tenant SaaS setup, each enterprise customer often brings their own identity provider, their own SAML certificates, and their own rules about session length and forced re-authentication. Your CDN has to be aware of that tenant context before it decides what to cache, what to serve, and what to bypass entirely. This is where a solid approach to CDN Multi-Tenant Architecture: Isolating Customer Traffic While Sharing Infrastructure becomes non-negotiable. We learned to never key cache on URL alone; we key on a composite of tenant ID, authentication state, and edge-validated claims.

For us, the fix was moving validation to the edge with short-lived, stateless tokens. Instead of relying on an opaque session cookie that only the origin understands, we validate a signed JWT at the edge that contains the tenant and user context. The CDN doesn't need to call home for every request, but it also doesn't blindly serve cached content. Here's a simplified Cloudflare Worker pattern we've used to validate an OIDC ID token before allowing cache lookup:

// Edge validation of OIDC JWT before cache
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const jwt = request.headers.get('Authorization')?.replace('Bearer ', '');
  if (!jwt) {
    return fetch(request); // bypass cache, go to origin login
  }

  try {
    const jwks = await fetch('https://idp.example.com/.well-known/jwks.json')
      .then(r => r.json());
    
    // Verify signature, issuer, audience, and expiry
    const payload = await verifyJwt(jwt, jwks, {
      issuer: 'https://idp.example.com',
      audience: 'urn:my-saas-app'
    });

    // Create tenant-aware cache key
    const cacheKey = `${payload.tid}:${payload.sub}:${request.url}`;
    let response = await caches.default.match(cacheKey);
    if (!response) {
      response = await fetch(request);
      // Only cache if response is tenant-specific and validated
      if (response.ok && payload.tid) {
        response = new Response(response.body, response);
        response.headers.set('Cache-Key', cacheKey);
        event.waitUntil(caches.default.put(cacheKey, response.clone()));
      }
    }
    return response;
  } catch (e) {
    return new Response('Invalid token', { status: 401 });
  }
}

SAML vs OIDC at the Edge: What Actually Works Behind a CDN

If you're integrating enterprise SSO, you'll get asked to support SAML. It's still the standard in large enterprises, especially those running ADFS, Okta, or Azure AD in SAML mode. The trouble is, SAML wasn't built for the edge. It's XML-heavy, relies on POST bindings and redirects through the browser, and the assertion itself can be 4-8KB. You can't efficiently validate that XML blob on every edge PoP without adding latency, and you certainly don't want to cache the POST to your ACS URL. Early on, we tried to terminate SAML directly at the CDN and quickly realized we were adding 120ms just parsing and validating XML.

OIDC is a much better fit for CDN architectures. It's built on JWTs, which are small, stateless, and designed to be validated without a round trip to the origin if you have the JWKS. That means your edge can verify the token's signature, check expiry, and enforce tenant isolation in under 10ms. Plus, OIDC gives you standard discovery via .well-known/openid-configuration, so onboarding a new enterprise customer can be automated instead of requiring a manual certificate exchange. As described in the HTTP Working Group Specifications (https://httpwg.org/specs/) and guidance on caching authenticated content from web.dev Articles (https://web.dev/articles/), responses tied to Authorization headers shouldn't be cached publicly — which is exactly why JWT validation at the edge needs to happen before any cache logic runs.

That doesn't mean you can ignore SAML. When you must support it, don't validate SAML at the edge. Let the origin handle the SAML dance and then have the origin mint a short-lived JWT that the CDN *can* understand. We call it the "SAML-to-JWT bridge." The origin consumes the SAML assertion, creates a signed JWT with normalized claims (tenant ID, user ID, roles), and sets it as a secure, HttpOnly cookie or Authorization header. The CDN then only deals with JWTs, regardless of upstream protocol. A typical origin configuration for that handoff looks like this in NGINX with an auth subrequest:

# NGINX: Validate JWT at edge/origin boundary, bypass cache for SAML ACS
location /saml/acs {
  # Never cache SAML POST
  proxy_no_cache 1;
  proxy_cache_bypass 1;
  proxy_pass http://origin_app;
}

location /api/ {
  # Validate JWT before serving from cache
  auth_request /_validate_jwt;
  proxy_cache my_cache;
  proxy_cache_key "$http_authorization$host$request_uri";
  proxy_cache_valid 200 5m;
  proxy_pass http://origin_app;
}

location = /_validate_jwt {
  internal;
  proxy_pass http://jwt-validator-service/verify;
  proxy_pass_request_body off;
  proxy_set_header Authorization $http_authorization;
  proxy_set_header X-Tenant-ID $http_x_tenant_id;
}

Custom Identity Providers and the Tenant Isolation Problem

Every enterprise thinks their identity provider setup is unique, and honestly, they're often right. We've dealt with customers using Auth0 with custom claims, others using PingFederate with non-standard NameID formats, and one financial services client that rotates SAML signing certificates every 30 days without telling anyone. If your CDN integration assumes all IdPs behave the same, those quirks will break authentication in ways that are incredibly hard to debug. You need per-tenant IdP configuration at the edge — different JWKS endpoints, different issuers, different token lifetimes.

The other headache is white-label domains. Many SaaS platforms give each enterprise customer their own domain like customer1.app.com or even app.customer.com. Your CDN has to map that hostname to the correct IdP configuration before it can validate anything. We've found that failing to isolate that mapping is how cache poisonings happen. You don't want a token issued for tenant A being considered valid on tenant B's domain just because they share edge infrastructure. This ties directly into CDN Tenant Isolation Patterns: Cache Separation, Rate Limits, and Access Controls and White-Label CDN Delivery: Custom Branding for SaaS Customer Domains — if you're doing white-label delivery, your SSO validation must be hostname-aware.

We started tracking edge authentication metrics to decide how to handle each IdP type. The numbers made the trade-offs obvious. SAML assertions were consistently larger and slower to process, while well-configured OIDC was nearly invisible to users. Here's what we measured in production across ~45 enterprise tenants over 30 days:

Implementing OIDC Token Validation Directly at the Edge

Here's where most teams get it wrong: they route every authenticated request back to origin just to validate a token. You don't need to. A modern CDN can validate a JWT at the edge in under 2ms if you do it right, and keep your cache hit ratio above 92% while you're at it. The trick is separating authentication from caching, not bolting them together.

We've found the most reliable pattern is to validate the OIDC ID or access token in an Edge Worker (Cloudflare Workers, Fastly Compute@Edge, or Lambda@Edge) using a locally cached JWKS. Don't fetch the JWKS on every request — cache it at the edge for 6 to 12 hours with a stale-while-revalidate strategy. That cuts your p95 auth validation latency from 80-180ms down to 12-18ms and prevents a thundering herd when your IdP rotates keys. We also add a 60-second clockTolerance to handle the inevitable clock skew between IdP and edge PoPs — without it, you'll see random 401s for about 0.3% of freshly-issued tokens.

For cache isolation, never use the raw Cookie or Authorization header in your cache key. Instead, validate the token, extract the tenant_id and user role, and normalize it into a Vary-like header such as x-tenant-id and x-user-tier. That way /api/dashboard for tenant A and tenant B are cached as two distinct objects, but anonymous assets still share a single cache entry. If you're supporting vanity domains where each enterprise customer brings their own IdP and hostname like app.customer.com, you'll need to tie that domain mapping to your tenant-aware validation. See our guide on Custom Domain CDN for SaaS: Automated SSL and DNS for Customer Vanity Domains for how we automate that binding without manual CNAME verification.

// Edge Worker: OIDC JWT validation with cached JWKS (Cloudflare / Fastly style)
import { createRemoteJWKSet, jwtVerify } from 'jose';

// Cache JWKS at the edge for 6 hours - avoids 120ms+ fetch on every request
const JWKS = createRemoteJWKSet(
  new URL('https://auth.your-saas.com/.well-known/jwks.json'),
  { cooldownDuration: 30000, timeoutDuration: 5000 }
);

export default {
  async fetch(request, env, ctx) {
    // 1. Extract token from Authorization header or secure cookie
    const authHeader = request.headers.get('Authorization');
    const token = authHeader?.replace('Bearer ', '') || getCookie(request, '__session');

    if (!token) {
      return Response.redirect('https://auth.your-saas.com/login?redirect=' + encodeURIComponent(request.url), 302);
    }

    try {
      // 2. Verify signature, issuer, audience, and expiry (with 60s leeway)
      const { payload } = await jwtVerify(token, JWKS, {
        issuer: 'https://auth.your-saas.com',
        audience: 'saas-api',
        clockTolerance: 60
      });

      // 3. Inject normalized headers for origin + cache key
      const newHeaders = new Headers(request.headers);
      newHeaders.set('x-tenant-id', payload.tid);
      newHeaders.set('x-user-role', payload.role);
      newHeaders.delete('Authorization'); // don't forward raw token to origin

      // 4. Rebuild cache key based on tenant, not cookie
      const cacheKey = new Request(request.url, { headers: newHeaders });
      return fetch(cacheKey);

    } catch (err) {
      // Token expired or signature failed - force silent refresh or re-login
      return new Response('Unauthorized', { 
        status: 401, 
        headers: { 'Cache-Control': 'no-store', 'Clear-Site-Data': '"cookies"' } 
      });
    }
  }
}

function getCookie(req, name) {
  return req.headers.get('Cookie')?.match(new RegExp(`(^| )${name}=([^;]+)`))?.[2];
}

Advanced Patterns: Silent Refresh, Logout Propagation, and Debugging Auth Loops

Validation is the easy part. What'll page you at 2am is logout and refresh. If a user logs out or an admin revokes their session in Okta or Azure AD, that JWT is still valid at the edge until it expires — often 15 to 60 minutes. For enterprise contracts, that's not acceptable. You need a revocation strategy. Short-lived access tokens (5 minutes) paired with opaque refresh tokens checked at the edge via a 10-second TTL KV lookup is the best compromise we've seen. It keeps 98% of requests fully at the edge while closing the revocation window from an hour to under 15 seconds. For true instant logout, publish revocation events to an edge KV or purge API and block the jti claim.

The second killer is the SAML-to-OIDC redirect loop. You'll see it as a 302 storm: edge -> IdP -> edge -> IdP. Nine times out of ten it's not your code, it's a cache misconfiguration. Someone cached the 302 itself, or they're setting a SameSite=Strict cookie on a cross-site POST from the SAML ACS. Use SameSite=None; Secure for your session cookie when SAML is in play, and always set Cache-Control: private, no-store on any login, callback, or /saml/acs route. We also add a loop breaker — if we see more than 3 auth redirects in 10 seconds for the same client IP + user-agent, we return a 429 with a human-readable error instead of looping forever.

Finally, don't lose observability once auth moves to the edge. When you stop hitting origin for every request, your origin logs go blind. You need per-tenant visibility at the CDN layer. We've had customers bill $40k+ per month based purely on authenticated API usage, so accuracy matters. Instrument your edge worker to emit a log for every validated request with tenant_id, endpoint, and token_tier. That feed powers both real-time rate limiting and billing. If you're doing per-customer metering, check out API Metering at CDN Edge: Real-Time Usage Tracking for SaaS Billing and CDN Usage Tracking for SaaS: Per-Customer Bandwidth and Request Analytics — both show how to turn those edge logs into authoritative usage records without ever touching origin.

Frequently Asked Questions