Caveats and known issues with Token Authentication
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 does not 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. (We plan to fix this in a later release to limit use to one or the other.)