Some content should not be fetchable by anyone holding the URL: paid video, private downloads, personalized documents, API responses per customer. Tokenized delivery — signed URLs and signed cookies — lets the CDN enforce that decision at the edge, cryptographically, without a round trip to your servers on every request. The mechanics differ by provider, but the design questions are identical everywhere.
What signing actually protects
A signed link carries a policy — typically an expiry time, optionally a path scope and client constraints — plus a signature computed with a secret only you and the CDN hold. The edge recomputes the signature, checks the policy, and serves or refuses without consulting your origin. Be clear about the threat model: signing stops link sharing beyond the expiry window, hotlinking, and enumeration of your object space. It does not stop an authorized user from downloading and re-uploading the file — that is DRM territory — and it does not authenticate the user; it authenticates that your application, recently, decided this client could have this object. Your application remains the authorization brain; the edge is the enforcement muscle.
Signed URL or signed cookie?
Sign the URL when access is per-object: one download link, one video manifest, one report. The token travels in the query string, works in any client including curl and native apps, and is the only option where cookies do not flow. Sign a cookie when one grant must cover many objects — a video player fetching thousands of segments, an image-heavy members area — because re-signing every segment URL is either expensive or forces long expiries, while one cookie set at session start covers the whole path prefix cleanly. The classic pairing on CloudFront is exactly this split (signed URLs for single objects, signed cookies for libraries); Akamai’s token authorization and Fastly’s VCL-validated tokens support the same patterns, and most mid-market CDNs offer at least URL tokens. The full support matrix is in our token-auth comparison.
What goes in the token
Every token needs an expiry, and the window should match the content’s life: seconds to a few minutes for a redirect-issued download, hours for a viewing session. Add a path scope so a token for /course-101/ cannot fetch /course-201/ — and prefer prefix scopes over exact paths for segmented media, or every quality-level variant needs its own token. Client binding (embedding the requester’s IP) sounds stronger than it is: mobile clients change addresses mid-session as they move between networks, and corporate egress rotates, so IP-bound tokens generate support tickets in exact proportion to their strictness. Use IP binding only for short-lived, high-value grants, and skip it for anything a phone will play for an hour.
Keys, rotation and clock skew
The signing secret is now critical infrastructure: whoever holds it can mint access to everything it scopes. Store it in your secrets manager, never in client code, and rotate it on a schedule — which requires the CDN side to accept two keys at once. Every serious implementation supports this (CloudFront key groups hold multiple public keys; header-based schemes let you validate against a key list): publish the new key, switch signing to it, and retire the old one only after the longest outstanding token has expired. Rotation without a dual-key window is a synchronized outage. Also allow modest clock skew — start-time conditions a few seconds in the future fail on clients with drifting clocks, so back-date validity slightly and keep expiry the only strict edge.
Caching interplay and rollout
The classic self-inflicted wound: the token rides in the query string, the query string is in the cache key, and every user now misses cache on identical bytes. Configure the CDN to validate the token but exclude it from the cache key — most platforms treat authorization parameters this way once told — and confirm with hit-ratio numbers before and after. Signed cookies dodge the problem entirely, one more argument for them on segmented media; the general discipline is the same as in handling cookies and Vary. Roll out with dual acceptance (unsigned and signed both valid) while clients update, watch 403 rates per path as you enforce, and only then close the unsigned door. And keep serving public content unsigned — tokens on your logo cost cache efficiency and buy nothing. For the wider access design around APIs, see CDN-ing your API.