How the major CDNs implement signed URLs, signed cookies and token authentication — key handling, expiry scope and the migration traps.
Winner depends on your workload.
Winner depends on: whether you want a turnkey scheme with vendor SDKs (CloudFront's signed URLs and cookies, Bunny and the value tier's HMAC tokens), full programmability (Fastly VCL, Cloudflare Workers), or contract-grade token features tied to a media workflow (Akamai). Multi-CDN estates should weight scheme portability above everything.
The same lock, different keyholes
Every scheme here answers one question: how does the edge verify that a request for protected content was authorized by you, without calling your origin? The universal answer is a signature — parameters (path, expiry, sometimes IP or country) hashed with a secret and carried in the URL or a cookie, verified at the POP in microseconds. The differences that bite are operational: where keys live, how rotation works, what the signature may scope, and whether the scheme survives a CDN migration.
| Provider | Mechanism | Operational notes |
|---|---|---|
| Amazon CloudFront | Signed URLs and signed cookies, RSA key pairs in key groups | Canned and custom policies (expiry, start time, IP range); cookies suit whole-site protection, URLs suit single objects |
| Akamai | Token authentication (HMAC), deeply integrated with media delivery | Session tokens for segmented streaming; configured in the property with account-team support |
| Fastly | Token validation implemented in VCL or Compute — a documented pattern, not a boxed feature | Total flexibility (any HMAC scheme you like) at the cost of owning the code and rotation |
| Cloudflare | No universal CDN-plan token toggle: Workers implement HMAC validation; Stream and Images ship native signed URLs; Firewall rules can approximate simple cases | Workers pattern is powerful and portable; product-native tokens stay product-scoped |
| Bunny.net | Built-in token authentication per pull zone, included free | HMAC of path + expiry (+ optional IP); one checkbox and a shared secret |
| KeyCDN / CDN77 / Gcore | Secure-token features in zone settings | Same HMAC family; confirm parameter scope (IP, country, path depth) per provider docs |
URLs or cookies: scope is the decision
A signed URL locks one object — perfect for a download link or a video manifest, awkward for a page pulling five hundred protected assets. Signed cookies invert the trade: one grant covers everything the cookie's policy matches, which is why CloudFront ships both and why its docs steer whole-member-area use cases to cookies. Streaming complicates it further: a signed manifest whose segments are unsigned is an open door, so segment-level token schemes (Akamai's session tokens, or manifest-rewriting on any programmable edge) exist precisely to close it — the enforcement layers we mapped in our token-auth explainer stack on top of, not instead of, this layer.
Boxed scheme or programmable edge
CloudFront and the value tier sell you a finished lock: documented parameters, vendor SDKs to generate signatures, predictable behavior. Fastly and Cloudflare hand you the lock-making machine: HMAC verification in VCL or a Worker is thirty lines, can implement any parameter scheme, and — crucially for multi-CDN estates — can implement the same scheme on two vendors at once, which no boxed feature promises. The cost is custody: your code, your key rotation, your clock-skew grace window, your incident when someone deploys a validator with a hardcoded test key. Boxed schemes fail safer; programmable schemes fail yours.
The traps, from audits
Four recur. Expiry set from client clocks (sign server-side, always, with a small skew allowance). Secrets that never rotate because rotation was never rehearsed — dual-key validation windows exist for this; use a scheme that supports two live keys. Tokens scoped to IP in a CGNAT and mobile world, which silently breaks users whose address changes mid-session — a last-mile reality no signature scheme can fix. And the origin left open: a token at the edge is theater if the origin serves the same paths unauthenticated to anyone who finds its address, which is why edge tokens belong alongside origin locking such as mutual TLS to origin. Lock both doors. Facts verified against provider documentation, July 2026.
Protecting paid content across one CDN — or trying to keep tokens portable across several? The assessment designs the scheme with you.