[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-08-18 UTC。"],[],[],null,["# Signed URLs\n\nThis page provides an overview of signed URLs, which use [signatures](/storage/docs/authentication/signatures) to give\ntime-limited access to a specific Cloud Storage resource. Anyone in\npossession of the signed URL can use it while it's active, regardless of whether\nthey have a valid account. To learn how to create a signed URL, see\n[V4 Signing Process with Cloud Storage Tools](/storage/docs/access-control/signing-urls-with-helpers) and\n[V4 Signing Process with Your Own Program](/storage/docs/access-control/signing-urls-manually). To learn about other ways of\ncontrolling access to buckets and objects, see [Overview of Access Control](/storage/docs/access-control).\n| **Important:** Signed URLs can only be used to access resources in Cloud Storage through [XML API endpoints](/storage/docs/request-endpoints).\n\nOverview\n--------\n\nA *signed URL* is a URL that provides limited permission and time to make a\nrequest. Signed URLs contain authentication information, including a\n[signature](/storage/docs/authentication/signatures), in their query string, which allows users without credentials\nto perform specific actions on a resource.\n\n- When you generate a signed URL, you must specify an account that has\n sufficient permission to make the request that the signed URL will make.\n\n - In most cases, the account is a [service account](/iam/docs/service-accounts).\n\n - In cases where you create your own program to generate signed URLs, it's\n possible to use a user account, if it has an associated [HMAC key](/storage/docs/authentication/hmackeys).\n\nAfter you generate a signed URL, anyone who possesses it can use the signed URL\nto perform specified actions, such as reading an object, within a specified\nperiod of time.\n\n### When should you use a signed URL?\n\nIn some scenarios, you might not want to require your users to have their own\naccount in order to access Cloud Storage, but you still want to control\naccess using your application-specific logic. The typical way to address this\nuse case is to provide a signed URL to a user, which gives the user read,\nwrite, or delete access to that resource for a limited time. You specify an\nexpiration time when you create the signed URL. Anyone who knows the URL can\naccess the resource until the expiration time for the URL is reached or the key\nused to sign the URL is rotated.\n\nThe most common uses for signed URLs are uploads and downloads, because in such\nrequests, object data moves between requesters and Cloud Storage. In\nmost other cases, such as copying objects, composing objects, deleting objects,\nor editing metadata, creating a signed URL and giving it to someone to use is an\nunnecessary extra step. Instead, you should consider a design in which the\nentity responsible for creating the signed URL directly makes the desired\nrequest to Cloud Storage.\n\n### Signed URL example\n\nThe following is an example of a signed URL that was created following the V4\nsigning process with service account authentication: \n\n```\nhttps://storage.googleapis.com/example-bucket/cat.jpeg?X-Goog-Algorithm=\nGOOG4-RSA-SHA256&X-Goog-Credential=example%40example-project.iam.gserviceaccount.com\n%2F20181026%2Fus-central1%2Fstorage%2Fgoog4_request&X-Goog-Date=20181026T18\n1309Z&X-Goog-Expires=900&X-Goog-SignedHeaders=host&X-Goog-Signature=247a2aa45f16\n9edf4d187d54e7cc46e4731b1e6273242c4f4c39a1d2507a0e58706e25e3a85a7dbb891d62afa849\n6def8e260c1db863d9ace85ff0a184b894b117fe46d1225c82f2aa19efd52cf21d3e2022b3b868dc\nc1aca2741951ed5bf3bb25a34f5e9316a2841e8ff4c530b22ceaa1c5ce09c7cbb5732631510c2058\n0e61723f5594de3aea497f195456a2ff2bdd0d13bad47289d8611b6f9cfeef0c46c91a455b94e90a\n66924f722292d21e24d31dcfb38ce0c0f353ffa5a9756fc2a9f2b40bc2113206a81e324fc4fd6823\na29163fa845c8ae7eca1fcf6e5bb48b3200983c56c5ca81fffb151cca7402beddfc4a76b13344703\n2ea7abedc098d2eb14a7\n```\n\nThis signed URL provided access to read the object `cat.jpeg` in the bucket\n`example-bucket`. The query parameters that make this a signed URL are:\n\n- `X-Goog-Algorithm`: The algorithm used to sign the URL.\n\n- `X-Goog-Credential`: Information about the credentials used to create the\n signed URL.\n\n- `X-Goog-Date`: The date and time the signed URL became usable, in the\n [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) basic format `YYYYMMDD'T'HHMMSS'Z'`.\n\n- `X-Goog-Expires`: The length of time the signed URL remained valid, measured\n in seconds from the value in `X-Goog-Date`. In this example the Signed URL\n expires in 15 minutes. The longest expiration value is 604800 seconds (7\n days).\n\n- `X-Goog-SignedHeaders`: Headers that had to be included as part of any request\n that used the signed URL.\n\n- `X-Goog-Signature`: The authentication string that allowed requests using\n this signed URL to access `cat.jpeg`.\n\nUsing signed URLs with resumable uploads\n----------------------------------------\n\nGenerally, creating signed URLs for [resumable uploads](/storage/docs/resumable-uploads) is unnecessary,\nbecause after the request to [initiate the upload](/storage/docs/performing-resumable-uploads#initiate-session), subsequent `PUT`\nrequests to upload the object data use a *session URI* , which acts as an\nauthentication token. This means that `PUT` requests don't use any signed URLs.\n\nWhile you can create and use a signed URL for the initial `POST` request to\ninitiate the upload, in most cases the server can initiate the resumable upload\ninstead. The server then sends the session URI to the client to perform the\nupload. This avoids the complexity of having the server create a signed URL, as\nwell as the complexity of having the client handle the signed URL and initiate\nthe resumable upload.\n\nLike signed URLs, a session URI can be used by anyone in possession of it to\nupload data. Be sure to transmit the session URI over HTTPS when giving it to\na client.\n| **Note:** You might want to use signed URLs with resumable uploads if your server and client are in geographically distant places, because resumable uploads are [pinned to the region of the initial request](/storage/docs/resumable-uploads#upload-performance). Using a signed URL for the initial `POST` request is one way to ensure the upload is initiated from the client's location.\n\nSigned URL considerations\n-------------------------\n\nWhen working with signed URLs, keep in mind the following:\n\n- Signed URLs can only be used to access Cloud Storage resources through\n [XML API endpoints](/storage/docs/request-endpoints).\n\n- When specifying credentials, it is recommended that you identify your service\n account by using its email address; however, use of the service account\n ID is also supported.\n\nCanonical requests\n------------------\n\nSigned URLs use [canonical requests](/storage/docs/authentication/canonical-requests) as part of the information encoded in\ntheir `X-Goog-Signature` query string parameter. When you\n[make a signed URL with Cloud Storage tools](/storage/docs/access-control/signing-urls-with-helpers), the required canonical\nrequest is created and incorporated automatically. However, when you\n[make a signed URL with your own program](/storage/docs/access-control/signing-urls-manually), you need to define the canonical\nrequest yourself and use it to [create a signature](/storage/docs/authentication/creating-signatures).\n\nCredential scope\n----------------\n\nThe [credential scope](/storage/docs/authentication/signatures#credential-scope) appears in both the string-to-sign and the\n`X-Goog-Credential` query string parameter.\n\nWhat's next\n-----------\n\n- [Create a signed URL with Cloud Storage tools](/storage/docs/access-control/signing-urls-with-helpers) such as client libraries or the Google Cloud CLI.\n- [Create a signed URL with your own program](/storage/docs/access-control/signing-urls-manually).\n- Learn more about [Canonical requests](/storage/docs/authentication/canonical-requests).\n- Learn more about [Signatures](/storage/docs/authentication/signatures)."]]
