Signed URLs and Cookie

What are Signed URLs in AWS?

A signed URL is a URL that has a signature. While the URL finds the resource, the signature lets you confirm your authority to access it. Private content is safely sent using signed URLs.

The application verifies the user when they request content and then provides them with a signed URL so they may access the requested content. CloudFront verifies the signed URL's legitimacy when a user asks for access to a resource by comparing it to the policy statement, and it only permits access if the URL is genuine.

The user can download or stream the content using the signed URL. The user often doesn't need further action to access the content because this phase is automatic. For instance, your application sends the signed URL to the browser when a user accesses your content through a web browser. The signed URL is immediately used by the browser to navigate to the file in the CloudFront edge cache without any user interaction.

Content will download successfully if a connection disruption doesn't happen throughout the download duration.

Unless another play event, such as skipping or pausing, is triggered after the timer has expired, CloudFront will let them keep broadcasting.

Using Signed URLs

You have more control over who has access to your content, thanks to the additional information that a signed URL contains, such as an expiration date and time. The further details are contained in a policy statement that is based on either a canned policy or a custom policy. The following two sections describe how canned and custom policies differ from one another.

Creating a Signed URL Using a Canned Policy

To build a signed URL with a canned policy, adhere to the steps listed below.

• If you haven't converted the private key for your key pair from the default. pem format to a format compatible with .NET or Java and you're using either .NET or Java to create signed URLs, do it right away.
• Concatenate the values listed below in the correct order, removing any white space (such as tabs and newline letters) in the process. In the application code, you might need to add escape characters to the string. The string is the data type of all values.
  • Base URL For The File: The basic URL, which includes your query string parameters, if any, is the one you would use to access the file from CloudFront if you weren't utilizing signed URLs.
  • ?: The ? denotes that the basic URL is followed by the query string arguments. If you have no query string parameters of your own, nonetheless include the ?.
  • Query String Parameter: This value is not required. When adding your query string arguments, for instance: color=blue&size=small, include the arguments before the Expires parameter and after the ?. You might need to add your query string parameters after Key-Pair-Id in some situations.
  • Expires: It shows the date and time in Coordinated Universal Time (UTC), and in Unix time format (in seconds).
  • &Signature: A base64-encoded, signed, and hashed variant of the JSON policy declaration.
  • &Key-Pair-Id: It is the ID of the CloudFront public key's associated private key that you are utilizing to create the signature.
• For a signed URL that uses a canned policy, you must take the following actions to create the signature:
  • Make a policy statement.
  • To put your signature on the policy statement, sign it.

Creating a Signed URL Using a Custom Policy

The procedures below must be followed to create a signed URL using a custom policy.

• If you haven't converted the private key for your key pair from the default. pem form to a format compatible with .NET or Java and you're using either .NET or Java to create signed URLs, do it right away.
• Concatenate the values listed below in the correct order, removing any white space (such as tabs and newline letters) in the process. In the application code, you might need to add escape characters to the string. The string is the data type of all values.
  • Base URL For The File: The basic URL, which includes your query string parameters, if any, is the one you would use to access the file from CloudFront if you weren't utilizing signed URLs.
  • ?: The ? denotes that the basic URL is followed by the query string arguments. If you have no query string parameters of your own, nonetheless include the ?.
  • Query String Parameter: This value is not required. When adding your query string arguments, for instance: color=blue&size=small, include the arguments before the Expires parameter and after the ?. You might need to add your query string parameters after Key-Pair-Id in some situations.
  • Policy: Your policy statement in JSON format, with white space removed and base64 encoded. It controls the access that a signed URL grants to a user.
  • &Signature: A base64-encoded, signed, and hashed variant of the JSON policy declaration.
  • &Key-Pair-Id: It is the ID of the CloudFront public key's associated private key that you are utilizing to create the signature.
• For a signed URL that uses a custom policy, you must take the following actions to create the signature:
  • Make a policy statement.
  • To put your signature on the policy statement, sign it.

Code Example for Signed URLs

• Example Policy Statement: for a Signed URL Utilizing a Canned Policy: The file can be accessed by users that use the following sample policy statement in a signed URL up to January 1, 2013 10:00 am UTC:

• Example Policy Statement: Using Many IP Addresses to View One File: The filemay be accessed by users from IP addresses in the range 193.0.2.0/26 until 1st of January, 2013 10:00 am UTC, according to the following example custom policy in a signed URL:

• Example Policy Statement: Using Many IP Addresses to View Many Files: The * wildcard character in the Resource parameter of the following example custom policy denotes the ability to construct signed URLs for any file in the training directory. Until January 1, 2013 10:00 am UTC, users with an IP address in the range 193.0.2.0/25 can access the file:

• Example Policy Statement: Utilizing a Single IP Address to Access All Files Connected to a Key Pair ID: As stated by the * wildcard character in the Resource field, the following sample custom policy enables you to establish signed URLs for any file linked to any distribution. Use of the IP address 192.0.2.14/32 is required. (In CIDR notation, the value 192.0.2.14/32 designates the single IP address 192.0.2.14). Only from Jan 1, 2013 10:00 AM UTC through 2nd of January,2013 10:00 AM UTC are the files accessible:

What is Signed Cookies in AWS?

When a server sends a piece of data with a signature, the browser receives it and stores it on the computer as a signed cookie. In contrast to signed URLs, signed cookies allow access to many files via a single URL. Cookies that have been signed cannot be distributed using the Real-Time Messaging Protocol (RTMP).

If you don't want to alter your URLs or if you want to grant access to several restricted files, such as all the files in a website's subscriber section, CloudFront signed cookies let you manage who may access your content.

Who gets access to the resources is determined by the application. Each of the three HTTP set-cookie headers that the application delivers to the viewer has three name-value pairs, and the browser stores these on the client system. CloudFront checks the signature using the public key when a user requests a file that has been signed with a cookie, ascertains the validity of the request using the policy statement, and then transmits the requested file to the user.

Using Signed Cookies

Setting Signed Cookies Using a Canned Policy

Follow these steps to set a signed cookie using a canned policy.

• If you haven't converted the private key for your key pair from the default.pem format to a format compatible with .NET or Java and you're using either .NET or Java to create signed URLs, do it right away.
• Your application should be configured to deliver three Set-Cookie headers to authorized viewers. Each Set-Cookie header can only have one name-value pair, and a CloudFront signed cookie needs three name-value pairs, thus you need three Set-Cookie headers. CloudFront-Expires, CloudFront-Signature, and CloudFront-Key-Pair-Id are the name-value pairs. Before a user requests a file that you want to restrict access to for the first time, the values must exist on the viewer. Cookie attribute names are case-sensitive.
  • Set-Cookie:
    • Domain: The domain name for the requested file. If you don't specify a Domain attribute, the default value is the domain name in the URL, and it applies only to the specified domain name, not to subdomains. If you specify a Domain attribute, it also applies to subdomains. A leading dot in the domain name (for example, Domain=.example.com) is optional. In addition, if you specify a Domain attribute, the domain name in the URL and the value of the Domain attribute must match.
    • Path: It is the requested file's path. The path in the URL is used as the default value if you don't provide a Path property.
    • Secure: Requires that before sending a request, the viewer secures cookies. To safeguard the cookie attributes from man-in-the-middle attacks, this is necessary.
    • HttpOnly: The viewer must only send the cookie in HTTP or HTTPS requests.
    • CloudFront-Expires: It shows the expiration date and time in Coordinated Universal Time (UTC) and Unix time format (in seconds).
    • CloudFront-Signature: A base64-encoded, signed, and hashed variant of the JSON policy declaration.
    • CloudFront-Key-Pair-Id: The ID of a public key for CloudFront. With the help of the public key ID, CloudFront can verify the signed URL using the appropriate public key.
• For a signed cookie that uses a canned policy, you must take the following actions to create the signature:
  • Make a policy statement.
  • To put your signature on the policy statement, sign it.

Setting Signed Cookies Using a Custom Policy

• If you haven't converted the private key for your key pair from the `default. poem format to a format compatible with .NET or Java and you're using either .NET or Java to create signed URLs, do it right away.
• Program your application to send three Set-Cookie headers to approved viewers. You need three Set-Cookie headers because each Set-Cookie header can contain only one name-value pair, and a CloudFront signed cookie requires three name-value pairs. The name-value pairs are: CloudFront-Policy, CloudFront-Signature, and CloudFront-Key-Pair-Id. The values must be present on the viewer before a user makes the first request for a file that you want to control access to.
  • Set-Cookie:
    • Domain: The domain name for the requested file. If you don't specify a Domain attribute, the default value is the domain name in the URL, and it applies only to the specified domain name, not to subdomains. If you specify a Domain attribute, it also applies to subdomains. A leading dot in the domain name (for example, Domain=.example.com) is optional. In addition, if you specify a Domain attribute, the domain name in the URL and the value of the Domain attribute must match.
    • Path: It is the requested file's path. The path in the URL is used as the default value if you don't provide a Path property.
    • Secure: Requires that before sending a request, the viewer secures cookies.To safeguard the cookie attributes from man-in-the-middle attacks, this is necessary.
    • HttpOnly: The viewer must only send the cookie in HTTP or HTTPS requests.
    • CloudFront-Policy: Your policy statement in JSON format, with white space removed and base64 encoded. It controls the access that a signed cookie grants to a user.
    • CloudFront-Signature: A base64-encoded, signed, and hashed variant of the JSON policy declaration.
    • CloudFront-Key-Pair-Id: The ID of a public key for CloudFront. With the help of the public key ID, CloudFront can verify the signed URL using the appropriate public key.
• For a signed cookie that uses a custom policy, you must take the following actions to create the signature:
  • Make a policy statement.
  • To put your signature on the policy statement, sign it.

Code Example For Signed Cookies

• Example Policy Statement: for a Signed URL Utilizing a Canned Policy: The file can be accessed by users that use the following sample policy statement in a signed URL up to 1st of January, 2013 10:00 am UTC:

• Example Policy Statement: Using Many IP Addresses to View One File: The filemay be accessed by users from IP addresses in the range 193.0.2.0/26 until 1st of January, 2013 10:00 am UTC, according to the following example custom policy in a signed URL:

• Example Policy Statement: Using Many IP Addresses to View Many Files: The * wildcard character in the Resource parameter of the following example custom policy denotes the ability to construct signed URLs for any file in the training directory. Until 1st of January, 2013 10:00 am UTC, users with an IP address in the range 193.0.2.0/25 can access the file:

• Example Policy Statement: Utilizing a Single IP Address to Access All Files Connected to a Key Pair ID: As stated by the * wildcard character in the Resource field, the following sample custom policy enables you to establish signed URLs for any file linked to any distribution. Use of the IP address 192.0.2.14/32 is required. (In CIDR notation, the value 192.0.2.14/32 designates the single IP address 192.0.2.14). Only from the 1st of January, 2013 10:00 AM UTC through the 2nd of January, 2013 10:00 AM UTC are the files accessible:

Choosing Between Signed URLs and Signed Cookies

You can manage who may access your content using CloudFront signed URLs and signed cookies. Consider the following when choosing between signed URLs and signed cookies if you wish to use CloudFront to offer private content.

In the following circumstances, use signed URLs:

• You wish to limit access to specific files, like a download for your application's installation.
• Your users are utilizing a client that doesn't support cookies, such as a unique HTTP client.

In the following circumstances, use signed cookies:

• You wish to give users access to several restricted files, such as all of the HLS files for a video or all of the files in the members-only section of a website.
• You do not wish to alter your existing URLs.