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.
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:
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
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.
Updated over 1 year ago