Authentication and Edge Delivery Services: Securing Fast Sites

Edge Delivery Services (EDS) sites are public and cache-friendly by default, but many real-world use cases are not: intranets, partner portals, gated documentation, or customer dashboards. The core challenge is getting strong authentication without breaking what EDS is best at—simple architecture, aggressive caching, and very fast responses.

This post walks through the main ways to add authentication around an EDS site, and when to use each.

Where Authentication Lives in an EDS Architecture

An EDS site has two key pieces:

• The .page / .live origins where EDS serves optimized HTML
• A CDN or edge layer (Adobe-managed or BYO Fastly/Cloudflare/Akamai) in front of those origins

Authentication is typically enforced at the CDN or edge tier, not inside EDS itself. The official FAQ explicitly recommends securing access "at the CDN tier" and restricting direct access to the .page and .live origins so content is only reachable through authenticated CDN traffic.
See Frequently Asked Questions

From there, you have three main patterns.

1. Authentication at the CDN / Edge (Recommended)

In this model, the CDN checks whether a user is authenticated before any request reaches the EDS origins.

Two flavors are common:

1. Token-based Site Authentication — configure a shared secret/token in the EDS configuration and CDN. The CDN adds an Authorization header for allowed traffic; without the token, direct origin access returns 403.

2. OIDC-based Edge Authentication (beta) — configure OpenID Connect against your IdP in a cdn.yaml and deploy via a Config Pipeline. The CDN redirects unauthenticated users to the IdP and issues a session token for protected paths.

Pros

• Strong protection for entire sites or subpaths
• Authentication happens before EDS, so .page/.live are never exposed publicly
• Works uniformly across different CDNs; EDS stays simple and cache-focused

Cons

• Requires CDN configuration (and often a config pipeline) plus IdP setup
• Fine-grained, per-resource authorization may need additional logic

2. Authentication in an Edge Middleware / Worker

If you need more custom behavior than your CDN's built-in auth features provide, you can front EDS with an edge middleware such as Fastly Compute@Edge, Cloudflare Workers, or AWS Lambda@Edge.

Pros

• Very flexible: custom login flows, role checks, or tenant routing
• Sensitive tokens stay at the edge, not in the browser
• Can share logic across multiple sites or backends

Cons

• More operational complexity
• Must be careful with caching of authenticated content

3. Client-Side Gating

In some app-like experiences, authentication is handled entirely in the browser. This can work when the HTML shell is not sensitive and only the API data is. However, for truly private content, client-side gating alone is not enough.

Choosing an Approach

• Need a gated intranet / portal / partner area? Use CDN/edge authentication.
• Need complex, custom rules or multi-backend orchestration? Add an edge middleware/worker in front of EDS.
• Building a public app shell with some protected APIs only? Client-side auth can be fine, as long as sensitive content never ships in the HTML.