Brightcove's Playback Authorization Service (PAS) offers an extra level of security when using Dynamic Delivery with DRM-protected or HTTP Live Streaming Encryption (HLSe) content.
This feature gives you control over your content playback by requiring a token to authorize playback. A valid JWT token is required to obtain a key, needed to decrypt encrypted HLS, or a license, needed to decrypt DRM-protected content.
If you are not familiar with this feature, see the Overview: DRM with Playback Authorization Service document.
To use Playback Authorization Service, follow these steps:
Create a JSON Web Token
To create a token to use when communicating with Brightcove's Playback API, see the Creating a JSON Web Token (JWT) document.
Configure the player
The token is passed with the playback request. If the token is invalid or expired, access to the content will be restricted. The player must be configured to use the token.
For details about configuring the Brightcove web player, see the Using Playback Authorization Service with Brightcove Player document.
Native Android player
For details about configuring the native player for Android, see the Using Playback Authorization Service with the Native SDKs document.
Native iOS player
For details about configuring the native player for iOS, see the Using Playback Authorization Service with the Native SDKs document.
The following limitations apply to this feature:
- For HLSe (AES-128), the token will be appended to the master manifest request, and will propagate to the encryption key URL. Because these URLs are appended to the master manifest, customers should consider restricting the number of uses to minimize exposure of their content.
- For HLSe (AES-128), players will make mutlitple requests when playing a video, typically one per rendition. The maxu claim needs to be set high enough to account for these requests. You should consider additional claims to minimize the exposure of your content. Switching renditions will request a new license.
- Tracking of the maxu and maxip claims is eventually consistent. This means that if a token using these claims is reused many times in quick succession, it is possible to see that token accepted more times than those claims declare. The tracking becomes consistent within a few seconds and after that window the token will be blocked as expected.