Token authentication
Token authentication, in video streaming, is an access method in which your backend issues a short-lived signed token that the player must present before a stream will load. The token, usually a JSON Web Token (JWT), names the video it opens and when it expires, and may carry other claims such as a viewer ID. The video service checks the signature and expiry on each request and rejects anything missing, altered or out of date, so entitlement decided in your system is enforced at the stream.
How does token authentication work for video?
The flow has four steps. A signed-in viewer asks your app to play a video. Your backend checks the viewer's rights in its own records: an active subscription, a purchased event, an enrollment or an assigned case. If the answer is yes, it creates a token for that video and signs it with a private key that only your backend holds.
The player receives the playback URL with the token attached. Each request it makes for the manifest and segments carries the token, either in the URL or in a header. The video platform verifies the signature against the matching public key, then checks the claims: right video, not expired.
Nothing about payment or identity moves to the video platform. It only learns that your backend vouched for this request until a given time. That split keeps entitlement logic in the system that bills and supports the viewer, and lets verification run fast at the edge.
What goes inside a video token (JWT)?
A JWT has three parts joined by dots: a header, a payload of claims, and a signature. JWT was standardized in RFC 7519 in May 2015.
The header names the signing algorithm, often RS256, an RSA signature, and a key ID so the verifier knows which public key to use. The payload holds the claims. For video, the important ones are the subject (sub), which on many platforms names the playback ID the token opens, and exp, which RFC 7519 defines as the time after which the token must not be accepted. Many platforms also read an audience claim saying what the token is for, such as video playback or thumbnails.
The signature covers the header and payload together. Changing any claim, such as pointing the token at a different video or pushing the expiry back, breaks it. Claims are readable by anyone, though, so a token should never carry secrets.
Token authentication vs. signed URLs
Both prove that your backend approved a request, and in video they often look alike, because the token is frequently added to the playback URL. The difference is in what is signed and how it is used.
A classic signed URL signs the link itself: the path, an expiry and perhaps a few rules are hashed with a shared secret, and the signature only works for that exact address. Token authentication signs a separate, structured object. The token can name a playback ID rather than a file path, carry several claims, and be reused across every request in a stream, including manifests, segments, thumbnails and storyboards.
That makes tokens easier to work with in adaptive streaming, where one view means hundreds of requests. They also travel well across platforms: the same JWT can go in a URL on the web, a header in a native app and a query parameter on a TV.
What are common token authentication mistakes?
Most token failures are design mistakes rather than broken cryptography, and they tend to surface only after a link leaks or a key is exposed. These come up often in video apps.
- Signing tokens in the browser or mobile app, which ships the private key to every user.
- Expiry set to days or weeks, so a forwarded link outlives the reason it was issued.
- One token reused for every video, instead of a token per playback ID.
- Server clocks that drift, so fresh tokens are rejected as expired or not yet valid.
- No plan for rotating signing keys if one leaks.
- Treating claims as secret, when anyone can decode a JWT payload.
How does FastPix handle token authentication?
FastPix uses signing keys and JWTs for tokenized playback. You create a signing key through the Signing Keys API and keep it in your backend. When a viewer is entitled to a video, your backend signs a JWT for that playback ID with its own expiry. The player sends it with the playback request, and FastPix verifies the signature and expiry before serving the stream. A request without a valid token plays nothing. The same tokens open images: thumbnails, posters and storyboards inherit the playback ID's access policy, so a private video's poster also needs a JWT and cannot expose the content.
Tokens apply at the playback ID, and every asset or live stream can carry one or more playback IDs, each public or signed. Any public ID on the paid episode would open the whole episode, so a free trailer belongs on its own clip with a public ID. For live events, the signed policy on the stream also covers its archived recording, so a pay-per-view match stays gated on replay.
The open-source FastPix Player handles tokens on web, iOS, Android, Flutter, React Native and TV, and any HLS player can pass them too. Video Data then records each view against the viewer ID your app passes, so you can see which accounts watched which titles.
FastPix has no geo-blocking and no IP restriction; any territory or network rule belongs in your backend before it issues a token. Billing follows usage, not tokens issued: encoding per source minute and free on Standard up to 4K, storage per rendition-minute, streaming per minute watched. The free plan includes 10 videos, no card.
By the numbers
- JSON Web Token (JWT) was standardized in RFC 7519, published in May 2015; its optional exp claim sets the time after which a token must not be accepted. (RFC 7519: JSON Web Token (JWT))
