Prevent unauthorized distribution

This page briefly describes the options that Media CDN provides to help prevent unauthorized distribution of your content.

Media CDN supports multiple signed request options to help protect your content from unauthorized distribution. A token is a medium of exchanging signed requests, such as a signed cookie, a URI with query parameters, or a path component. Valid tokens presented by viewers are used to authenticate access to your content. A viewer with an invalid token or a missing token is prevented from accessing your content.

Media CDN offers the following signed request options for client authentication:

• Signatures: Media CDN uses a single signature to help protect content.

• Tokens: Media CDN uses tokens to help protect content. You can choose to use either single-token or dual-token authentication.

  When dual-token authentication is used, Media CDN uses two tokens, a short-duration and a long-duration token, to help protect content.

Signatures let you do full URL signing, including the host and protocol.

Tokens offer the following capabilities:

• Compatibility with non-Google CDNs
• Path-only signing
• Ability to sign more than one header
• Ability to embed arbitrary data and session IDs

We recommend tokens for new integrations. Tokens are required for dual-token authentication.

You can use signed requests and dual-token authentication requests together to help protect your content.

How signed requests work

A signed request uses signatures or tokens to verify that every viewer is authenticated to access content. You can configure Media CDN so that the access is scoped to any of the following:

• Either an exact URI or URI prefix for a limited time
• A specific client
• For signed requests using tokens, up to five paths with wildcards

To use signed requests, you generate keys to sign and verify signatures. You then configure routes, which let you optimize behavior based on the type of content, client attributes, and your freshness requirements. Signed requests can be enforced on a per-route basis, which helps you protect specific endpoints.

Each Media CDN service can use a collection of multiple keys. The collection of keys is also known as a keyset. Keysets let you rotate keys and distribute private keys across your own infrastructure without interruption.

You can configure Media CDN to use either signed requests or tokens to help protect content.

For signed requests using signatures, you can use any of the following formats:

• An exact URI within query parameters: You specify a URLPrefix with the exact URI and append the same query parameters to multiple URIs.
• A URI prefix within query parameters: You specify a URLPrefix with a URI prefix and append the same query parameters to multiple URIs.
• A path component: You specify a path component, which allows relative manifest URIs to inherit the signed URI component.
• A signed cookie: You specify a URI prefix in a cookie, which allows access to any URI to the prefix that you specified.

For more information, see Generate signatures.

For signed requests using tokens, you can place the token in either of the following:

• In a query parameter of your choosing
• In a cookie

For more information, see Generate tokens.

How dual-token authentication works

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

Dual-token authentication uses two tokens to authenticate requests to your content: a short-duration token for playback initiation, and a long-duration token for the remainder of the playback session.

To use dual-token authentication, you configure your application server to issue short-duration tokens to user agents. Then, you configure Media CDN to respond to the short-duration tokens. You can place the token in a query parameter of your choosing, or place the token in a cookie.

Short-duration tokens generated by your application server help protect primary manifests (sometimes called master manifests or mulivariant playlists). The expiration of the signed request is short enough to request a primary manifest, but not to watch all of the content contained within a manifest.

When Media CDN receives a request with an authorized short-duration token, it generates a signed long-duration token. You can use the token in either a single-named query parameter or in a cookie. The long-duration token supports viewing a full-length program. The signed long-duration tokens generated by Media CDN use Ed25519 signatures that are signed with Google-managed keys associated with an EdgeCacheKeyset.

You can customize the expiration time of short- and long-duration tokens. As a best practice, we recommend that you configure the expiration time of short-duration tokens generated on your application server to one minute. You must set the expiration time of long-duration tokens that Media CDN generates to a duration greater than your content length, up to a maximum of one day.

Request flow for dual-token authentication

The following describes the request flow:

1. A viewer requests metadata from your application server for media they want to view. Your application server returns the URI of the primary manifest signed with a short-duration token.

2. Your player application requests the primary manifest from Media CDN. The request includes the short-duration token as a value of a URI query parameter in the single-named query parameter format.

3. Media CDN verifies the short-duration token and the token's signed parameters.

   1. If the token is valid, Media CDN creates a long-duration signature token. Media CDN returns the token either in a Set-Cookie header, or by modifying manifest and segment URIs in the primary manifest to include the token.
   2. If the token isn't valid, Media CDN responds with an HTTP 403 Forbidden response.

4. The player application receives the primary manifest from Media CDN, then requests the media playlist or the media segments referenced in the primary manifest. The request must include the long-duration token, either as a signed cookie or as a URI parameter.

5. Media CDN verifies the long-duration signature token:

   1. If the long-duration token is valid for the specific request, then Media CDN serves the requested content.
   2. If the long-duration token isn't valid (due to either an expired token or an invalid path), then Media CDN responds with an HTTP 403 Forbidden response.

6. The process repeats until media playback ends or the long-duration signature expires.

Supported token formats for dual-token signed requests

Media CDN dual-token signed requests support multiple formats, depending on the token type.

Short-duration signed requests

For short-duration signed requests, Media CDN supports tokens signed with Ed25519 signatures by default. You can also use symmetric-key hash-based message authentication codes (HMACs) for compatibility with existing application code and other CDNs.

To use HMACs, you use Secret Manager to store the HMAC secret. Then you grant access to the Media CDN service account to access the stored secret. As a best practice, we recommend using asymmetric signing with Ed25519 signatures for security and performance.

The Media CDN service account is owned by the Media CDN project, and isn't displayed in your project's list of service accounts. The service account grants access only to Media CDN resources in the projects that you explicitly allow.

The service account has the following format:

[e-mail]

Where PROJECT_NUMBER is your project number.

To activate the service Media CDN service account, create at least one Media CDN resource, such as EdgeCacheOrigin.

Long-duration signed requests

For long-duration signed requests, Media CDN uses Ed25519 signatures that are signed with Google-managed keys associated with an EdgeCacheKeyset.

Media CDN supports a single token format for long-duration tokens, which can be used in either a single-named query parameter for HLS streams, or in a cookie.

Considerations

The following sections discuss items, such as:

• URI limits
• Legacy devices
• Consent and privacy compliance
• Billing

URI limits

Most modern HTTP clients support URIs up to 8000 characters long. However, some legacy or niche devices may have stricter limits. In general, a signed URI adds about 125 characters to the request URI, which includes the following:

• If all field names are used, approximately 67 characters for each field (such as Expires= and KeyName=).
• For the Unix timestamp, 10 characters
• For the KeyName, five characters
• For the base64-encoded Signature value, 43 characters

As a best practice, keep URIs less than 2000 characters long using query parameters as tokens. Shorter URIs prevent devices from sending truncated URIs to Media CDN.

Legacy video streaming devices

Some legacy video streaming devices may not fully support attaching cookies to manifest or media segment requests. If you have devices with known issues handling HTTP cookies, configure Media CDN to use query parameters for signed requests and dual-token exchange.

Consent and privacy compliance

You're solely responsible for any consent and privacy compliance required when using cookies to exchange short-duration tokens. When Media CDN is configured to use dual-token signed requests, Google issues and manages the cookies used for long-duration tokens.

Billing

To learn more about how Secret Manager is billed, see Pricing.

Media CDN fetches for secrets are cached internally, significantly reducing the rate of secret fetches from Secret Manager. The reduced fetches also significantly reduce the rates of accesses that Secret Manager observes and bills you for.

For more information on secret caching in Media CDN, see Keys overview.