Secure video playback

You can create Playback IDs for assets and live streams. Playback IDs have two types - public and signed. Public video playback URLs can be watched anywhere, any time, without any restrictions. Signed playback URLs, on the other hand, include JSON Web Token (JWT) that are signed server-side by your application. There are two distinct ways to restrict video playback using signed URLs:

• Expiration time: Viewers can watch videos until the expiration time. All requests past the expiration time are denied.
• Playback Restrictions: Playback Restrictions allow you to implement rules, like a list of allowed websites, for playing videos. Referrer Validation is the only supported Playback Restriction today; Mux plans to add more types of restrictions in the future.

1Create an Asset or Live Stream with a signed playback policy

An asset or live stream can have multiple playback IDs, each with a playback policy that can either be public or signed. The playback policy can be specified when creating a new asset, creating a new live stream, or can be added to an existing asset and live stream.

//POST https://api.mux.com/video/assets

{
  "input": "https://storage.googleapis.com/muxdemofiles/mux-video-intro.mp4",
  "playback_policy": "signed"
}

See Create a playback IDAPI to learn how to add a new playback ID to an existing Asset or Live Stream.

2Create the signing key for your Mux account environment

Signing keys can be managed (created, deleted, listed) either from the dashboard or via the Mux Video API. When creating a new signing key, the API generates a 2048-bit RSA key-pair and returns the private key and a generated key-id. Securely store the private key for signing the token, and Mux stores the public key to validate the signed tokens.

Signing keys are created and deleted independently of assets. You probably only need one signing key active at a time, but you can create multiple to enable key rotation, creating a new key and deleting the old only after any existing signed URLs have expired.

See Create a URL signing keyAPI for full documentation.

//POST https://api.mux.com/video/v1/signing-keys

{
  "data": {
    "private_key": "(base64-encoded PEM file with private key)",
    "id": "(unique signing-key identifier)",
    "created_at": "(UNIX Epoch seconds)”
  }
}

3Create the Playback Restriction for your Mux account environment

Mux supports one type of playback restriction - Referrer Validation. During playback this restriction is applied using a JWT claim, which will be covered in the next two sections.

Create a Playback Restriction

Most commonly, you want all the videos on your Mux account to be watched only on your website https://example.com. To do so, you can create a new Playback Restriction by adding example.com domain as the only allowed domain that can play your videos.

See Playback RestrictionAPI for full documentation.

API Request

//POST https://api.mux.com/video/v1/playback-restrictions

{
  "referrer": {
    "allowed_domains" : [
      "example.com"
	  ],
    "allow_no_referrer" : false
  }
}

API Response

{
  "data": {
    "updated_at": "1634595679",
    "referrer": {
      "allowed_domains": [
        "example.com"
      ],
    },
    "id": "JL88SKXTr7r2t9tovH7SoYS8iLBVsjZ2qTuFS8NGAQY",
    "created_at": "1634595679"
  }
}

Store the id value from the API response above as PLAYBACK_RESTRICTION_ID in your application for later use when generating the signed JWT.

Playback Restriction Syntax

A single Playback Restriction contains list of domains allowed to play your videos. You may allow up to 10 unique domains or sub-domains where your videos will be embedded.

Specify this in the referrer.allowed_domains array using valid dns-style wildcard syntax. For example:

{ "referrer": { "allowed_domains": ["*.example.com", "foo.com"], } }

Choose from the following options:

• To deny video playback requests for all domains, use an empty Array: []
• To allow playback on example.com and all the subdomains of example.com, use the syntax: ["*.example.com", "example.com"]
• Use a single wildcard * entry to allow video playback requests from any domain: ["*"]
• Use a wildcard for one sub-domain level. For instance, video playback will be denied from xyz.foo.example.com when you include ["*.example.com"].

Playback Restriction Considerations

Here are some things to consider when using Playback Restrictions.

• Playback restrictions exist at the environment level. But having a playback restriction created in an environment does not mean all assets are restricted by it. You should apply a given restriction to a playback by referencing it in the token you create for a signed playback ID.

• You can create up to 100 different Playback Restrictions per environment on your Mux account.

• You can use a Playback Restriction ID for playing a single video or group of videos.

• You have a lot of flexibility for associating Playback Restrictions to videos. For instance, you can create one Playback Restriction for each of your clients if your service or application supports multiple clients.

• You can add up to 10 different domains to each Playback Restriction.

• You can restrict playing video on domains added to the Playback Restriction. For instance, if you want multiple partner sites to play a video, you can add the partner site domain to the same Playback Restriction, thereby restricting playback only on those domains.

Reach out to Mux Support if you have a use case that requires more than 100 Playback Restrictions or want to add more than 10 domains per Playback Restriction.

Using Referer HTTP Header for validation

Web browsers send the website address requesting the video in the Referer HTTP header. Mux matches the domains configured in the Playback Restriction, with the domain in the Referer HTTP header. No video is delivered if there is no match.

The Referer HTTP header is only sent by web browsers, while native iOS and Android applications do not send this header. Therefore, Mux cannot perform domain validations on any requests from native iOS and Android applications. For this reason, you can configure the Playback Restrictions to allow or deny all HTTP requests without the Referer HTTP header by setting the allow_no_referrer boolean parameter. You should only set the allow_no_referrer parameter value to true if you are using a native iOS and/or Android applications.

4Generate a JSON Web Token (JWT)

All signed requests have a JWT with the following standard claims:

You can also include the following optional claims depending on the type of request.

The Image (Thumbnails, Animated GIFs, Storyboard and others) API accepts several options to control image selection and transformations. More details on generating JWT for image can be found here.

For Playback IDs that use a public policy, the thumbnail options are supplied as query parameters on the request URL.

For Playback IDs that use a signed policy, the thumbnail options must be specified in the JWT claims when using signed URLs. This ensures that the thumbnail options are not altered, such as changing the timestamp or the dimensions of the thumbnail image. For example, if you uploaded a 4K video and wanted to restrict a thumbnail to a width of 600 pixels and a specific timestamp, then simply include the width and time keys in the JWT claims.

Expiration time

Expiration time should be at least the duration of the Asset or the expected duration of the Live Stream. When the signed URL expires, the URL will no longer be playable, even if playback has already started. Make sure you set the expiration to be sufficiently in the future so that users do not experience an interruption in playback.

Your application should consider cases where the user loads a video, leaves your application, then comes back later at some time in the future and tries to play the video again. You will likely want to detect this behavior and make sure you fetch a new signed URL to make sure playback is able to start.

5Sign the JSON Web Token (JWT)

The steps can be summarized as:

1. Load the private key used for signing
2. Assemble the claims (sub, exp, kid, aud, etc) in a map
3. Encode and sign the JWT using the claims map and private key and the RS256 algorithm.

There are dozens of software libraries for creating & reading JWTs. Whether you’re writing in Go, Elixir, Ruby, or a dozen other languages, don’t fret, there is most likely some JWT library you can rely on.

package main

import (
    "encoding/base64"
    "fmt"
    "log"
    "time"

    "github.com/golang-jwt/jwt/v4"
)

func main() {

    playbackId := "" // Enter your signed playback id here
    keyId      := "" // Enter your signing key id here
    key        := "" // Enter your base64 encoded private key here

    decodedKey, err := base64.StdEncoding.DecodeString(key)
    if err != nil {
        log.Fatalf("Could not base64 decode private key: %v", err)
    }

    signKey, err := jwt.ParseRSAPrivateKeyFromPEM(decodedKey)
    if err != nil {
        log.Fatalf("Could not parse RSA private key: %v", err)
    }

    token := jwt.NewWithClaims(jwt.SigningMethodRS256, jwt.MapClaims{
        "sub": playbackId,
        "aud": "v",
        "exp": time.Now().Add(time.Minute * 15).Unix(),
        "kid": keyId,
    })

    tokenString, err := token.SignedString(signKey)
    if err != nil {
        log.Fatalf("Could not generate token: %v", err)
    }

    fmt.Println(tokenString)
}

6Include the JSON Web Token (JWT) in the media URL

Supply the JWT in the resource URL using the token query parameter. The Mux Video service will inspect and validate the JWT to make sure the request is allowed.

Video URL example:

https://stream.mux.com/{playback-id}.m3u8?token={JWT}

Thumbnail options are supplied as query parameters when using a public policy. When using a signed policy, the thumbnail options must be specified as claims in the JWT following the same naming conventions as with query parameters.

Thumbnail URL example:

https://image.mux.com/{playback-id}/thumbnail.{format}?token={JWT}

Note on query parameters after signing

When you're signing a URL, you're signing the parameters for that URL as well. After the parameters are signed for a playback ID, the resulting signed URL should only contain the token parameter. This is important because leaving the parameters in the URL would both:

• expose more information about the underlying asset than you may want
• result in an incorrect signature since the extraneous parameters would alter the URL.

Example:

Let's say we're taking the following public example and making a signed URL:

• https://image.mux.com/{public_playback_id}/thumbnail.jpg?time=25

Generate a signed URL with {time: 25} in the claims body. Using the helper example we wrote above, this would look like:

• sign(signedPlaybackId, { ...requiredTokenOptions, params: { time: 25 } })

Correct Signed URL:

• https://image.mux.com/{signed_playback_id}/thumbnail.jpg?token={token}

Bad Signed URL:

• https://image.mux.com/{signed_playback_id}/thumbnail.jpg?time=25&token={token}

Including query parameters in the token also applies to playback modifiers like default_subtitles_lang, redundant_streams and roku_trick_play. The JWT claims body must include the extra parameter:

{
  "sub": "{PLAYBACK_ID}",
  "aud": "{AUDIENCE_TYPE}",
  "exp": "{EXPIRATION_TIME}",
  "redundant_streams": true
}

Passing custom parameters to a signed token

With signed URLs, you can pass extra parameters via a custom key in the claims body like the example above.

This may be useful in order to identify bad actors that share signed URLs in an unauthorized way outside of your application. If you find out that a signed URL gets shared then you can decode the parameters and trace it back to the user who shared it. When including extra parameters like this, be sure to respect the following guidelines:

• Do NOT under any circumstances include personally identifiable information (PII) like a name or email address.
• Put your custom parameters nested inside the "custom" key.

{
  "sub": "{PLAYBACK_ID}",
  "aud": "{AUDIENCE_TYPE}",
  "exp": "{EXPIRATION_TIME}",
  "custom": {
    "session_id": "xxxx-123"
  }
}