You can use "cookie-less" Token Auth for HLS
During the Token Auth process, multiple tokens are created and exchanged between the end user and Akamai. We create one of these tokens—a session token—and by default, it's returned to the end user as an HTTP cookie. However, some devices and browsers don't support cookies.
To address this, we offer "cookie-less" token auth via the Token in URI option. Rather than sending the session token as a cookie, the master manifest is modified to embed this token in the URL path of requests for the bit rate manifest and segments. So, once you enable Token in URI, a browser or device only needs to support the following to use Token Auth:
- Support for HLS (An HLS player should support the bare minimum HLS specification.)
- Support fetching of objects via HTTP
- Ensure that Token in URI is "On."
- By default, the HLS Master Manifest
Files field contains various common file names that represent
HLS Master Manifest files. You can add or remove filenames as necessary.
- Filenames can contain alphanumeric and dot characters.
- You can use wildcards in a filename. Use an asterisk to serve as a wildcard to establish a range of filenames.
- Ensure that the filenames you input can be differentiated from the variant manifest files.
Limitations on use
The following limitations apply to the use of the Token in URI functionality:
- HLS streams that do not incorporate a master manifest are not supported. This shouldn't be an issue, due to the nature of an adaptive bitrate stream. These streams already include renditions in different bitrates, resolutions and codecs, and this information is communicated in the master manifest.
- Absolute segment URLs for HLS
segments are not supported. This functionality modifies the master
manifest to embed the session token in the URL of the media playlists. So, the
media/variant playlist must use relative segment URLs. (The session token
cascades down to the segments.) This reduces overall cost, and results in better
performance. However, the URLs for the segments must be relative in the bit rate
manifest file. The following segment types are affected:
- Media segments
- Ad segments
- Media initialization segments for HLS (Those that are indicated via the #EXT-X-MAP tag.)
Generally, this shouldn't be a concern because the bitrate manifest and its corresponding segments are traditionally served from the same origin.
- Multi-CDN is not supported, and other delivery configurations are limited. This is due to the session token that this functionality sets in the URL path of variant playlists and segments. They can't be served from a different Content Delivery Network. They also can't be served from a different Akamai delivery configuration that does not have Token in URI enabled.
- If your manifests have multiple Akamai-served hostnames in their contents, the Encryption key(s) must be the same across each one.