Caveats and known issues with Token Authentication

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.

When playback is started on an iOS device, and then "Airplayed" to an AppleTV (or vice-versa, midstream), playback fails if the initial short token has expired. It's also important to note that the X-Playback-Session-ID header is also changed during Airplay. You need to manage short token expiry to accommodate Airplay/Casting if this scenario applies in your environment.

If you have a redirect behavior or Site Failover defined in your AMD property configuration, a request can be denied when the Origin is used in the "salt" value for the TA token. This happens when the URL used for the redirect does not use the same host as the original request. To support the CORS behavior for "privacy-sensitive-contexts," the browser sets the Origin to "Null" for the first redirect to follow, and then sets the original "Origin" for subsequent requests.

When configuring Advanced Options for Token Auth, you can define values for both the Salt and Request Headers for Session Token Salt options. If you do, only the Salt is used.

To avoid confusion, only use one of these options. (We plan to fix this in a later release to limit use to one or the other.)