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.

Typical ingredients:

• Your identity provider (IdP) (Okta, Azure AD, etc.)
• The CDN’s auth features (e.g., token-based site authentication, OIDC integration)

Two flavors are common:

1. Token-based Site Authentication

   • You configure a shared secret/token in the EDS configuration and CDN.
   • The CDN adds an Authorization header for allowed traffic; the EDS origins are configured to require that token.
   • Without the token, direct origin access returns 403.
     This is documented in the EDS Site Authentication and Fastly/CloudFront setup guides, which show how to attach the token on origin requests.

2. OIDC-based Edge Authentication (beta)

   • You configure OpenID Connect (OIDC) against your IdP in a cdn.yaml configuration and deploy via a Config Pipeline.
   • The CDN redirects unauthenticated users to the IdP, validates the ID token, and issues a session token for protected paths.
   • EDS sees only authenticated traffic for those paths; HTML can still be cached safely based on session rules.
     Edge Authentication for Edge Delivery Services is currently available as a beta feature.

Pros

• Strong protection for entire sites or subpaths (intranet, portals, closed user groups)
• 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 (rules, headers, or preflight-style checks)

For most teams, this is the default pattern: protect what needs protecting at the CDN, and let EDS focus on fast HTML and content.

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
• AWS Lambda@Edge or similar

The worker acts as a programmable gate in front of EDS:

1. Intercept incoming requests for protected URLs.

2. If no valid session cookie is present:

   • Redirect the user to your IdP’s login endpoint.
   • Handle the OIDC callback, exchange the auth code for tokens.
   • Set a signed session cookie (containing user or group information).

3. Forward authenticated requests to EDS, optionally:

   • Adding headers that encode user roles/groups for downstream logic.
   • Adjusting cache keys or Cache-Control headers.

Pros

• Very flexible: you can implement 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 (deploying, logging, monitoring edge code).
• Must be careful with caching of authenticated content.
• Requires solid security practices (key rotation, token validation, CSRF, etc.).

Use this when you need custom business logic around auth that your CDN config alone can’t express.

3. Client-Side Gating

In some app-like experiences, you’ll see authentication handled entirely in the browser:

• The EDS HTML is public.
• A JavaScript app handles sign-in (e.g., via OAuth/OIDC) and stores tokens in browser storage.
• Protected data comes from an API that enforces authentication/authorization.

This can work for scenarios where:

• The HTML shell is not sensitive, and only the API data is.
• You’re building a SPA-style dashboard where the main risk is API access, not the page itself.

However, for truly private content (documents, knowledge bases, intranets), client-side gating alone is not enough—users can still view the HTML or call APIs directly.

Pros

• No CDN or edge changes required.
• Fits naturally with SPA frameworks and API-driven UIs.

Cons

• The page itself is still publicly accessible.
• Harder to meet stricter security or compliance requirements.
• More fragile if tokens are exposed in browser storage.

Use this only when you deliberately accept that the page shell is public and only specific APIs are protected.

Choosing an Approach

A practical way to decide:

• Need a gated intranet / portal / partner area?
  Use CDN/edge authentication (token-based Site Authentication or Edge Authentication with OIDC).
• Need complex, custom rules or multi-backend orchestration?
  Add an edge middleware/worker in front of EDS, still enforcing auth before origin.
• 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.

Across all of these, EDS remains responsible for fast, cacheable content, while authentication and authorization are handled at the layers best suited for identity and security.