To enable Token Authentication ("Token Auth"), you need to apply specific settings in the Segmented Media Protection behavior in your AMD property.

Set up Token Auth

1. Set the Token Authentication slider to On.

2. Set the Encryption Key. Enter a hexadecimal value to serve as a "trusted shared secret." Comprise it of an even number of characters, but don't exceed 32 total characters. For example: "eee7e9157f81b2f6d471bf2c". You can also click the cycle button ( ) to automatically generate a proper value.

3. Make note of this value. You use this value as the Key when generating the token.

4. Don't enable your AMD property on the production network, or test it on staging just yet. Review the optional features you can add to your property, below. Then, you need to generate a token and apply it to your content.

Set Advanced Options (optional)

Click the Show Advanced Options switch button to reveal additional options.

Transition key

This serves as a backup "trusted shared secret." Input one manually or auto-generate one using the cycle button ( ). If the token provided by the end-user request is not valid based on the primary Encryption Key, AMD checks the token using this key. This ensures that users aren't denied access if you're rotating the primary key. (This assumes that you've transitioned to generating your tokens with the Transition Key for some period of time before updating the Encryption key value here.)

Salt

This adds an additional "input" during generation of the token to strengthen security. Manually input a value or auto-generate one using the cycle button ( ). As a best practice, don't override the default value.

Request Headers for Session Token Salt

This allows you to include additional end-user-specific properties to strengthen the relationship between the session token and playback session. These properties are communicated via a salt value that AMD generates using various request headers that you specify here. The following apply to these headers:

• Each header name you specify must consist of alphanumeric characters or hyphens.
• A specified header must exist in player requests for your content to be used in the salt.
• If a header is included in a request and it's not specified here, it's ignored, and it's not used to generate the salt.

Typical values include what's discussed in the table that follows.

📘

Use either Salt or Request Headers for Session Token Salt, but not both. If you do define both, the Salt is used, and what is set for Request Headers for Session Token Salt is ignored.

Salts and Long Token Validation

Token Auth verifies the long token found in an HTTP cookie, even if the current request is for an HLS master manifest. This is because the system can't recognize an .m3u8 file as either a master or variant playlist file. This can result in some corner case issues:

• The long token can be invalidated by a browser update. The HTTP cookie that holds the long token has a time to live (TTL) of 24 hours. If a browser updates between two consecutive playback sessions during this TTL, the long token is invalidated because there's a different string in the User-Agent request header.

• Using "Request Headers for Session Token Salt" can invalidate the long token. If you use this option, you're incorporating request headers that can change frequently between consecutive playback sessions. If this happens, the long token in an HTTP cookie may be invalid.

We've implemented a fix for these cases. When the long token is read from the HTTP cookie and the verification fails, the system falls back to the short token for verification. However, if the long token is read from any other source, and the long token verification fails, the system continues to deny the request with an HTTP 403.

Add Field Carry-Over (optional)

Use these options to enable the security controls and fields you want to be carried over from the access token into the session token. These allow for better access control and analysis.

Review this information to determine if including a field benefits your delivery.

Add "cookie-less" Token Auth for HLS (optional)

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 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

📘

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.

📘

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: