This page provides an overview of signed URLs, which usesignatures to givetime-limited access to a specific Cloud Storage resource. Anyone inpossession of the signed URL can use it while it's active, regardless of whetherthey have a valid account. To learn how to create a signed URL, seeV4 Signing Process with Cloud Storage Tools andV4 Signing Process with Your Own Program. To learn about other ways ofcontrolling access to buckets and objects, seeOverview of Access Control.

Overview

Asigned URL is a URL that provides limited permission and time to make arequest. Signed URLs contain authentication information, including asignature, in their query string, which allows users without credentialsto perform specific actions on a resource.

• When you generate a signed URL, you must specify an account that hassufficient permission to make the request that the signed URL will make.

  • In most cases, the account is aservice account.

  • In cases where you create your own program to generate signed URLs, it'spossible to use a user account, if it has an associatedHMAC key.

After you generate a signed URL, anyone who possesses it can use the signed URLto perform specified actions, such as reading an object, within a specifiedperiod of time.

When should you use a signed URL?

In some scenarios, you might not want to require your users to have their ownaccount in order to access Cloud Storage, but you still want to controlaccess using your application-specific logic. The typical way to address thisuse case is to provide a signed URL to a user, which gives the user read,write, or delete access to that resource for a limited time. You specify anexpiration time when you create the signed URL. Anyone who knows the URL canaccess the resource until the expiration time for the URL is reached or the keyused to sign the URL is rotated.

The most common uses for signed URLs are uploads and downloads, because in suchrequests, object data moves between requesters and Cloud Storage. Inmost other cases, such as copying objects, composing objects, deleting objects,or editing metadata, creating a signed URL and giving it to someone to use is anunnecessary extra step. Instead, you should consider a design in which theentity responsible for creating the signed URL directly makes the desiredrequest to Cloud Storage.

Signed URL example

The following is an example of a signed URL that was created following the V4signing process with service account authentication:

https://storage.googleapis.com/example-bucket/cat.jpeg?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=example%40example-project.iam.gserviceaccount.com%2F20181026%2Fus-central1%2Fstorage%2Fgoog4_request&X-Goog-Date=20181026T181309Z&X-Goog-Expires=900&X-Goog-SignedHeaders=host&X-Goog-Signature=247a2aa45f169edf4d187d54e7cc46e4731b1e6273242c4f4c39a1d2507a0e58706e25e3a85a7dbb891d62afa8496def8e260c1db863d9ace85ff0a184b894b117fe46d1225c82f2aa19efd52cf21d3e2022b3b868dcc1aca2741951ed5bf3bb25a34f5e9316a2841e8ff4c530b22ceaa1c5ce09c7cbb5732631510c20580e61723f5594de3aea497f195456a2ff2bdd0d13bad47289d8611b6f9cfeef0c46c91a455b94e90a66924f722292d21e24d31dcfb38ce0c0f353ffa5a9756fc2a9f2b40bc2113206a81e324fc4fd6823a29163fa845c8ae7eca1fcf6e5bb48b3200983c56c5ca81fffb151cca7402beddfc4a76b133447032ea7abedc098d2eb14a7

This signed URL provided access to read the objectcat.jpeg in the bucketexample-bucket. The query parameters that make this a signed URL are:

• X-Goog-Algorithm: The algorithm used to sign the URL.

• X-Goog-Credential: Information about the credentials used to create thesigned URL.

• X-Goog-Date: The date and time the signed URL became usable, in theISO 8601 basic formatYYYYMMDD'T'HHMMSS'Z'.

• X-Goog-Expires: The length of time the signed URL remained valid, measuredin seconds from the value inX-Goog-Date. In this example the Signed URLexpires in 15 minutes. The longest expiration value is 604800 seconds (7days).

• X-Goog-SignedHeaders: Headers that had to be included as part of any requestthat used the signed URL.

• X-Goog-Signature: The authentication string that allowed requests usingthis signed URL to accesscat.jpeg.

Using signed URLs with resumable uploads

Generally, creating signed URLs forresumable uploads is unnecessary,because after the request toinitiate the upload, subsequentPUTrequests to upload the object data use asession URI, which acts as anauthentication token. This means thatPUT requests don't use any signed URLs.

While you can create and use a signed URL for the initialPOST request toinitiate the upload, in most cases the server can initiate the resumable uploadinstead. The server then sends the session URI to the client to perform theupload. This avoids the complexity of having the server create a signed URL, aswell as the complexity of having the client handle the signed URL and initiatethe resumable upload.

Like signed URLs, a session URI can be used by anyone in possession of it toupload data. Be sure to transmit the session URI over HTTPS when giving it toa client.

Signed URL considerations

When working with signed URLs, keep in mind the following:

• Signed URLs can only be used to access Cloud Storage resources throughXML API endpoints.

• When specifying credentials, it is recommended that you identify your serviceaccount by using its email address; however, use of the service accountID is also supported.

Canonical requests

Signed URLs usecanonical requests as part of the information encoded intheirX-Goog-Signature query string parameter. When youmake a signed URL with Cloud Storage tools, the required canonicalrequest is created and incorporated automatically. However, when youmake a signed URL with your own program, you need to define the canonicalrequest yourself and use it tocreate a signature.

Credential scope

Thecredential scope appears in both the string-to-sign and theX-Goog-Credential query string parameter.

What's next

• Create a signed URL with Cloud Storage tools such as clientlibraries or the Google Cloud CLI.
• Create a signed URL with your own program.
• Learn more aboutCanonical requests.
• Learn more aboutSignatures.