Generate the token and apply it to your content

Along with setting up Token Authentication in Property Manager, you need to perform a few separate steps, including integrating token generation code into your origin infrastructure.

Important: These processes must be performed before enabling your AMD property with Token Authentication on the Production network.

Step 1: Generate the access ("short") token

You need to generate a one-time access token—also referred to as the "short token"—and apply it to media content that uses it. The token is a delimited list of string fields, with an HMAC to prevent tampering with the strings. Each field consists of a value that is verified by AMD when a request is made. Among other things, fields in the token include the following:

  • A token name (token_name/tokenName). Required—This must be the value, hdnts.
  • Start/end times (start_time/startTime, end_time/endTime). Required—Use these to set a time to live for the token.
  • An IP address (ip). Optional—Include this to restrict the token to a specific IP address.
  • A session identifier (session_id/sessionId). Optional—Include this as a unique identifier for a single playback/access session. Create a session identifier using printable ascii characters and ensure that it's no larger than 36 bytes in size.
  • A Key (key). Required—The secret used to generate the token. This is the value you set as the Encryption Key for Token Authentication in the AMD property. (This can also be the Transition Key, if applicable, or the Encryption key + Salt/Request Headers or Transition key + Salt/Request Headers if you've set up these as Advanced Options in the AMD property.)

We offer Token Auth software development kits (SDK), that you can use to generate this token. They are available for multiple programming languages, and they account for all required and optional fields.

See the README section on these pages for details on how to use that SDK.

Step 2: Apply the token

The completed token should be attached as a query string parameter, cookie, or request header, to the URL for the manifest/index file for your target content, using the following format:


The final token might look like the following, if it's included as a query string: (The HMAC in this example was not generated from the token input strings.)<path>/media.m3u8?hdnts=st=1370627194~exp=1370627409~acl=*~hmac=6a10b3f602ffde88c02cd1b89665bfdfdc0fc84c3cf7049752931ad7

Ideally, you should set up your origin server to dynamically generate these tokens for each client request for the content. This way, the IP address (ip) could be included as a parameter, and access to the content would be restricted to that single, authorized user.

Step 3: Ensure query string name disambiguation

Ensure that your content URLs do not use the query string names "hdntl" and "hdnts." We use these names with Token Authentication.

Standard token auth requires cookie support (Apple, HLS)

Token authentication generally requires the use of browser cookies to deliver a signed token as a step in the authorization process. This won't work if devices and browsers don't support cookies. (This is typically the case with Apple Safari and HLS devices). You have one of two choices here:

  • Your end users can manually enable cookies. In Safari, many end users will need to set Preferences > Security > Accept Cookies: Always. With this set, no additional interaction is required, and token authorization will work as designed.
  • You can use "cookie-less" token auth. We offer 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 for the bit rate manifest and segments.