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
Note: This only applies to requests for HLS-format media. All other formats use standard, cookie-based Token Auth. However, the Encryption key, and any Advanced Options you apply (Transition key, Salt or Request Headers for Session Token Salt) via Token Authentication settings are common for all formats.

Procedure

  1. Ensure that Token in URI is "On."
  2. 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.
Note: If you don't specify a proper master manifest filename or wildcard equivalent, a request can result in HTTP 403. (If a master manifest is included in a client request that isn't specified here, that request is answered with an HTTP 403.)


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.