The link-sharing problem
A CDN secure token embeds authentication in the URL as query parameters:
Token modes
There are two decisions to make when you configure token auto-refresh for video delivery:- Choose the URL token format supported by your product.
- Choose whether the token is plain or IP-bound.
See the Query String Forwarding documentation for full details.
How auto-refresh works
- The player loads with a signed URL containing a short-lived token (e.g., 60 s).
- A timer fires a few seconds before expiry.
- The player calls your backend and receives a fresh
{ token, expires, url }response. - The
?md5=TOKEN&expires=EXPIRYquery parameters are updated in every outgoing request. - Playback continues without a visible interruption. The viewer’s browser still shows a URL that will expire in seconds — sharing it is pointless.
Choosing a token lifetime
For maximum reliability use long-lived tokens (e.g. more than an hour). For maximum protection use short-lived IP-bound tokens — a shared URL is both nearly expired and locked to the original viewer’s IP. But keep in mind the tradeoff: the shorter the token lifetime, the more sensitive the system becomes to poor network conditions (see Choosing a token lifetime below). The demo usesexpire=60 (60 seconds) to make refresh cycles easy to observe. In production, 60 seconds is very aggressive — use it only if link sharing during live events is a critical threat.
The core tradeoff is: shorter TTL = stronger protection, but less tolerance for slow networks.
On a poor mobile connection, a viewer’s player may take several seconds to fetch a fresh token and download the next media segment before the old token expires. If both operations don’t complete within the token’s lifetime, the CDN rejects the segment request with a 403 and playback will stall or error.
A rule of thumb: set the refresh lead time to at least 20-30% of the token lifetime. For a 300-second token, a lead of 60-90 seconds gives enough runway for the token fetch to complete even on a slow connection before the current token expires.
Architecture for HLS / MPEG-DASH with token auto-refresh
Players such as hls.js and dash.js can work with token auto-refresh, but the player alone is not enough. You need both:- an updated player integration that can request fresh tokens and rewrite playback URLs,
- a backend endpoint that authenticates the viewer and generates new CDN Secure Tokens.
Backend: generating tokens
Backend to generate tokens
Token generation must run on your server — the CDN secret key must never be sent to the browser. Your backend can use any authentication and internal checks before it returns a token: user session, JWT, subscription status, payment status, geo rules, account permissions, purchased event tickets, or any other access logic. After these checks, your backend decides what to return:- a fresh token and expiration time,
- a full signed playback URL,
- or an error if the viewer is not allowed to watch the content.
Demo backend for token API
A working demo endpoint is available for testing and development:https://cdn-token-102748.fastedge.app/. It returns new tokens to all users without authentication, so you can test the player-side refresh flow quickly.
This FastEdge app is bound to the Gcore demo CDN resource and signs tokens for the demo-files-protected.gvideo.io domain only. Use it for testing and integration purposes — it cannot be used with your own CDN resource or content.
Response:
What is Gcore FastEdge?
Gcore FastEdge is a serverless edge-compute platform that runs WebAssembly applications at CDN edge locations worldwide. Apps compile to WASM, start in microseconds with no cold starts, and respond in milliseconds. Billing is per request with no idle cost. For token signing — a stateless, CPU-bound computation — FastEdge is a natural fit: it runs close to the viewer, scales automatically to any load, and requires no dedicated infrastructure to manage.Need user authentication? The demo FastEdge app generates tokens for anyone who calls it — there is no login check. If you need to restrict access to authenticated users only (subscribers, paid accounts, ticket holders), you must implement your own backend endpoint that verifies the user’s session or JWT before generating a token. FastEdge can still be used for that, but the authentication logic must be added to the app. Alternatively, use any backend stack you already have (Node.js, Python, Go, etc.) — the token generation formula is the same regardless of the platform.
FastEdge app source code
The demo endpoint is a Rust WebAssembly application deployed on FastEdge. You can use it as a starting point for your own token API.FastEdge token API source code
FastEdge token API source code
Frontend: player integration
The examples below use the demo API. ReplaceTOKEN_API_URL with your own authenticated backend endpoint before deploying to production.
All approaches share the same core mechanism: a URL rewriter adds or updates the ?md5=TOKEN&expires=EXPIRY query parameters in every outgoing request, and a timer fetches a fresh token a few seconds before expiry.
To give you an idea of how it works, we have prepared a demo app for Gcore Video Player: https://g-core.github.io/gcore-videoplayer-js/example/protected-content.html

- HLS.js + custom URL loader
- Dash.js + custom URL loader
?md5={token}&expires={expiry} query parameters in every outgoing request and a timer fetches a fresh token a few seconds before expiry. Playback is never interrupted.
hls.js
For HLS streams, hls.js with a custom URL-rewriting loader gives seamless, uninterrupted token rotation. This is the recommended approach for most use cases. How it works:TokenRewriteLoaderextends the default hls.js XHR loader. Before every request — master manifest, sub-playlists, media segments — it callsrewriteUrl()to update the?md5=and&expires=query parameters.tokenStateis a plain object shared between the loader and the refresh timer. The loader closure always reads the latest value.- A
setTimeout-based scheduler triggers a refresh ~10 s before expiry and reschedules itself after each successful fetch. - With Query String Forwarding enabled on the CDN resource, the CDN also propagates these parameters from manifest requests to derived segment requests server-side. The custom loader ensures the parameters stay current after each token refresh.
hls.js token auto-refresh example
hls.js token auto-refresh example
dash.js
For DASH (MPEG-DASH) streams, dash.js provides aRequestModifier extension that rewrites every URL before the request is dispatched. The refresh timer is identical to the hls.js approach.
How it works:
- The
RequestModifierextension’smodifyRequest()method is called before every HTTP request — MPD manifest, segment requests, and initialization chunks. - The same
rewriteUrl()function as in the hls.js example sets?md5=and&expires=on every URL. - Enable Query String Forwarding on the CDN resource (
.mpd→.m4s) for DASH segment auth to work.
dash.js token auto-refresh example
dash.js token auto-refresh example
Gcore Video Player
The Gcore Video Player (@gcorevideo/player) can play protected CDN streams by reloading the source URL with a fresh token before each expiry.
For details see the dedicated guide.
Next steps
CDN logs
View CDN requests and status codes to debug token refresh and segment access
Improve video delivery speed
Optimize cache hit ratio and delivery performance for video streaming
Error status codes
Check CDN status code meanings, including authorization and expired-token errors
Create a video CDN resource
Complete setup instructions to create a CDN resource for video streaming