Authorize access at the
edge with signed URLs and cookies
Another way to help protect your content is to use signed URLs or signed cookies. When privileged or confidential content, such as paid streaming or confidential reports, needs to be delivered to authenticated viewers, you can leverage CloudFront’s signed URLs. Signed URLs validate parameters in the query string or cookies, and allow access only when they are correctly signed with the private key of a pre-registered key pair. You can build an application that authenticates users and shares the signed URLs or cookies to minimize origin authentication efforts, cache the content in CloudFront, and protect against unauthenticated viewer access. Because signed URLs are based on a public-private key pair, content will not be compromised even if the public key is exposed. This provides a better security posture in comparison to shared, key-based token authorization.
To use signed URLs or signed cookies, you need a signer. Each signer that you use to create CloudFront signed URLs or signed cookies must have a public–private key pair. The signer uses its private key to sign the URL or cookies, and CloudFront uses the public key to verify the signature. A signer is either a trusted key group that you create in CloudFront, or an AWS account that contains a CloudFront key pair. We recommend that you use trusted key groups. The way that you create a key pair that depends on whether you use a trusted key group as the signer (recommended), or a CloudFront key pair. We also recommend that you periodically rotate (change) your key pairs for signed URLs and signed cookies.
When a group of URLs, defined by a path pattern, is set to use signed URLs or cookies, CloudFront looks for the required parameters and validates their values on the request of those URLs. These parameters can be in the query string or cookie, where the former takes precedence if both are present. The fields in signed URLs or cookies vary slightly, based on which policy they use. A policy defines conditions which must be matched to access the contents.
There are two types of policies that you can use: a canned policy or a custom policy.
-
A canned policy is the simpler of the two, and allows access if the request is made before the expiration time as a condition and the URL matches the URL pattern as a resource defined in the policy.
-
A custom policy offers more conditions, such as start date time, end date time, and IP address range in Classless Inter-domain Routing (CIDR) form, and allows the wildcard character (*) in the URL (resource) parameter.
When a policy is created, signed URLs can be generated by signing the policy statement with the private key. See code examples in the Amazon CloudFront Developer Guide.
