Caveats and known issues with Token Auth

There are some known issues that apply to the use of Token Authentication (TA) with AMD. Review them before adding this functionality to your property.

IssueDescription

Standard token auth requires cookie support

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.

TA doesn't work with Airplay if the initial short token expires

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.

Requests are denied when an Origin is used as a "salt" and a redirect behavior is configured.

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.

The "Salt" option overrides "Request Headers for Session Token Salt" option

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.

You can't use both token auth behaviors in the same rule

You can use Token Auth via the Segmented Media Protection behavior or Auth Token 2.0 Verification, but not both in the same rule. However, you can use them in separate rules that use different Match criteria.