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.
Step 1: Generate the (one-time) access token
- A token name (
token_name): This must be the value,
- Start/end times
- Access control list
- An IP address
- A Key (
key): 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.
- Python: https://github.com/akamai/EdgeAuth-Token-Python
- Java: https://github.com/akamai/EdgeAuth-Token-Java
- Ruby: https://github.com/akamai/EdgeAuth-Token-Ruby
- NodeJS: https://github.com/akamai/EdgeAuth-Token-Node
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.)
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 can affect devices and browsers that don't support cookie use (typically Apple Safari and HLS devices). These users have one of two choices here:
- Your end users can manually enable cookies: In Safari, many end users will need to set . 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.