メニュー
Amazon Simple Storage Service
開発者ガイド (API Version 2006-03-01)

REST リクエストの署名と認証

注記

このトピックでは、署名バージョン 2 を使用してリクエストを認証する方法を説明します。Amazon S3 は現在、最新の署名バージョン 4 をサポートします。この最新の署名バージョンはすべてのリージョンでサポートされており、2014 年 1 月 30 日以降は、新しいリージョンではバージョン 4 の署名のみがサポートされます。詳細については、『Amazon Simple Storage Service API Reference』の「Authenticating Requests (AWS Signature Version 4)」を参照してください。

認証とは、自身のアイデンティティをシステムに証明するプロセスのことをいいます。アイデンティティは、Amazon S3 のアクセスコントロールの判断を行う際に重要です。リクエストの許可または拒否は、リクエスタのアイデンティティに部分的に基づいています。例えば、バケットを作成する権利は、登録開発者用に予約されています。また、バケットにオブジェクトを作成する権利は、対象のバケット所有者用に(デフォルトで)予約されています。開発者としてこれらの権限を実行するリクエストを行うので、そのリクエストを認証することで、自身のアイデンティティをシステムに対して証明する必要があります。このセクションでは、その方法を説明します。

注記

このセクションの内容は HTTP POST には適用されません。詳細については、「POST (AWS 署名バージョン 2) を使用したブラウザベースのアップロード」を参照してください。

Amazon S3 REST API では、キーが設定された HMAC(ハッシュメッセージ認証コード)に基づいたカスタム HTTP スキームが認証に使用されます。リクエストを認証するには、まず、選択されているリクエストの要素を連結し、文字列を作成します。次に、AWS シークレットアクセスキーを使用して、その文字列の HMAC を計算します。正式な呼び名ではありませんが、このプロセスのことを「リクエストへの署名」と呼び、HMAC アルゴリズムの出力を署名と呼びます。これは、このプロセスが実際の署名のセキュリティプロパティを真似ているからです。最後に、このセクションで説明する構文を使用して、この署名をリクエストのパラメーターとして追加します。

システムは、認証済みリクエストを受け取るとき、リクエスト送信者が所有している AWS シークレットアクセスキーを取得し、同様の方法でそのアクセスキーを使用して、受信したメッセージの署名を計算します。そして、計算した署名と、リクエスタから提示された署名を比較します。2 つの署名が一致したら、リクエスタは AWS シークレットアクセスキーにアクセスできると判断されるため、システムはそのキーの発行先となるプリンシパルの権限をサポートします。2 つの署名が一致しない場合、リクエストは中断し、エラーメッセージが返されます。

例 認証された Amazon S3 REST リクエスト

Copy
GET /photos/puppy.jpg HTTP/1.1 Host: johnsmith.s3.amazonaws.com Date: Mon, 26 Mar 2007 19:37:58 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE:frJIUN8DYpKDtOLCwo//yllqDzg=

一時的なセキュリティ認証情報の使用

一時的なセキュリティ認証情報を使用してリクエストに署名する場合は(「リクエストの実行」を参照)、x-amz-security-token ヘッダーを追加して、対応するセキュリティトークンをリクエストに含める必要があります。

AWS Security Token Service API を使用して一時的なセキュリティ認証情報を取得すると、そのレスポンスには、一時的なセキュリティ認証情報とセッショントークンが含まれます。リクエストを Amazon S3 に送信するときに、x-amz-security-token ヘッダーでセッショントークン値を指定します。IAM が提供する AWS Security Token Service API については、『AWS Security Token Service API リファレンス Guide 』の「Action」を参照してください。

認証ヘッダー

Amazon S3 REST API は、標準の HTTP Authorization ヘッダーを使用して、認証情報を渡します。(標準ヘッダーの名前とは異なり、ヘッダーに含まれるのは承認ではなく認証情報です。)Amazon S3 認証スキームにおける認証ヘッダーの形式は次のとおりです。

Copy
Authorization: AWS AWSAccessKeyId:Signature

開発者には、登録時に AWS アクセスキー ID と AWS シークレットアクセスキーが発行されます。リクエストを認証するために、AWSAccessKeyId 要素は、署名の計算に使用されたアクセスキー ID を識別するほか、リクエストを行っている開発者も間接的に識別します。

Signature 要素は、リクエストから選択した要素の RFC 2104HMAC-SHA1 です。したがって、Authorization ヘッダーの Signature 部分はリクエストによって異なります。システムによって計算されたリクエストの署名が、リクエストに含まれる Signature と一致する場合は、リクエスタが AWS シークレットアクセスキーを所有していることになります。その後、リクエストは、キーの発行対象者である開発者のアイデンティティと権限に従って処理されます。

以下は擬似文法で、Authorization リクエストヘッダーの構文例を示しています。 (例中の \n は Unicode のコードポイント U+000A を意味しています。これは通常改行と呼ばれています)。

Copy
Authorization = "AWS" + " " + AWSAccessKeyId + ":" + Signature; Signature = Base64( HMAC-SHA1( YourSecretAccessKeyID, UTF-8-Encoding-Of( StringToSign ) ) ); StringToSign = HTTP-Verb + "\n" + Content-MD5 + "\n" + Content-Type + "\n" + Date + "\n" + CanonicalizedAmzHeaders + CanonicalizedResource; CanonicalizedResource = [ "/" + Bucket ] + <HTTP-Request-URI, from the protocol name up to the query string> + [ subresource, if present. For example "?acl", "?location", "?logging", or "?torrent"]; CanonicalizedAmzHeaders = <described below>

HMAC-SHA1 は、RFC 2104 – Keyed-Hashing for Message Authentication で定義されているアルゴリズムです。このアルゴリズムは、キーとメッセージの 2 つのバイト文字列を入力として取ります。Amazon S3 リクエスト認証については、AWS シークレットアクセスキー(YourSecretAccessKeyID)をキーとして、StringToSign の UTF-8 エンコーディングをメッセージとして使用します。また、HMAC-SHA1 の出力もバイト文字列で、これはダイジェストと呼ばれます。Signature リクエストパラメーターは、このダイジェストをエンコードする Base64 によって作成されます。

署名のためのリクエストの標準化

既に説明したように、システムは認証済みリクエストを受け取るときに、計算されたリクエスト署名と StringToSign のリクエストで指定された署名を比較します。この理由から、署名は、Amazon S3 と同じ方法で計算する必要があります。署名のためにリクエストを承認済み形式にするプロセスは正規化と言います。

CanonicalizedResource 要素の作成

CanonicalizedResource は、リクエストの対象となる Amazon S3 リソースを表します。REST リクエストのこのリソースは次のように作成します。

プロセスを起動

1

空の文字列("")で開始します。

2

HTTP ホストヘッダー(仮想ホスト形式)を使用してバケットが指定されているリクエストについては、バケット名の前に "/" を付けます(例: 「/bucketname」)。パス形式のリクエスト、およびバケットを処理しないリクエストの場合は、何も行いません。仮想ホスト形式のリクエストの詳細については、「バケットの仮想ホスティング」を参照してください。

仮想ホスト形式のリクエスト「https://johnsmith.s3.amazonaws.com/photos/puppy.jpg」の場合、CanonicalizedResource は 「/johnsmith」です。

パス形式のリクエスト「https://s3.amazonaws.com/johnsmith/photos/puppy.jpg」の場合、CanonicalizedResource は「」です。

3

デコードされていない HTTP リクエスト URI のパス部分を追加します(クエリ文字列まで、ただし、その文字列は含みません)。

仮想ホスト形式のリクエスト「https://johnsmith.s3.amazonaws.com/photos/puppy.jpg」の場合、CanonicalizedResource は「/johnsmith/photos/puppy.jpg」です。

パス形式のリクエスト「https://s3.amazonaws.com/johnsmith/photos/puppy.jpg」の場合、CanonicalizedResource は「/johnsmith/photos/puppy.jpg」です。この時点で、CanonicalizedResource は、仮想ホスト形式とパス形式の両方のリクエストで同じです。

GET Service など、バケット宛でないリクエストの場合、「/」を追加します。

4

?versioning?location?acl?torrent?lifecycle?versionid などのサブリソースを処理するリクエストの場合は、サブリソース、そのサブリソースの値(存在する場合)、および疑問符を追加します。複数のサブリソースは、名前のアルファベット順に並べ替えて "&" で区切る必要があります。たとえば、?acl&versionId=value のようにする必要があります。

CanonicalizedResource 要素を作成するときに含める必要があるサブリソースは、acl、lifecycle、location、logging、notification、partNumber、policy、requestPayment、torrent、uploadId、uploads、versionId、versioning、versions、および website です。

レスポンスヘッダー値を上書きするクエリ文字列パラメーターを指定するリクエストの場合は(GET Object を参照)、クエリ文字列パラメーターとそれらの値を追加します。これらのパラメーター値は署名時にエンコードする必要はありませんが、リクエストの実行時にはエンコードする必要があります。GET リクエストのクエリ文字列パラメーターには、response-content-typeresponse-content-languageresponse-expiresresponse-cache-controlresponse-content-dispositionresponse-content-encoding があります。

複数のオブジェクトの Delete リクエストに対して CanonicalizedResource を作成する際には、delete クエリ文字列パラメーターを含める必要があります。

HTTP リクエスト URI の CanonicalizedResource の要素は、URL エンコーディングメタ文字を含め、HTTP リクエストに表示されるとおりに署名する必要があります。

CanonicalizedResource は、HTTP リクエスト URI とは異なる場合があります。特に、リクエストが HTTP Host ヘッダーを使用してバケットを指定する場合、そのバケットは HTTP リクエスト URI に表示されませんが、CanonicalizedResource にもバケットが含まれます。クエリ文字列パラメーターは、リクエスト URI に表示される可能性がありますが、CanonicalizedResource には含まれません。詳細については、「バケットの仮想ホスティング」を参照してください。

CanonicalizedAmzHeaders 要素の作成

StringToSign の CanonicalizedAmzHeaders 部分を作成するには、次の手順に従って、「x-amz-」で始まるすべての HTTP リクエストヘッダーを選択します(大文字と小文字は区別されません)。

CanonicalizedAmzHeaders プロセス

1 各 HTTP ヘッダー名を小文字に変換します。例えば、「X-Amz-Date」は「x-amz-date」に変換します。
2 ヘッダーのコレクションを辞書と同じ順序でヘッダー名ごとに並べ替えます。
3 RFC 2616、セクション 4.2 の説明に従って、同じ名前のヘッダーフィールドを、1 つの「ヘッダー名:コンマ区切り値のリスト」のペアに結合します。その際、値と値の間の空白は削除されます。例えば、2 つのメタデータヘッダー「x-amz-meta-username: fred」および「x-amz-meta-username: barney」が 1 つのヘッダーに結合されると、「x-amz-meta-username: fred,barney」になります。
4 折りたたまれた空白(改行マークを含む)を 1 つのスペースに置き換えて、(RFC 2616、セクション 4.2 で許可されているように)複数行にわたる長いヘッダーを展開します。
5 ヘッダーのコロンの前後の空白を削除します。例えば、ヘッダー「x-amz-meta-username: fred,barney」は「x-amz-meta-username:fred,barney」になります。
6 最後に、改行文字(U+000A)を、結果の一覧の各標準化ヘッダーに追加します。この一覧のすべてのヘッダーを 1 つの文字列に連結することで、CanonicalizedResource 要素を作成します。

位置および指定 HTTP ヘッダーの StringToSign 要素

StringToSign の最初のヘッダー要素(Content-Type、Date、および Content-MD5)は位置を示します。StringToSign には、これらのヘッダーの名前は含まれません。含まれるのはリクエストの値のみです。一方、「x-amz-」要素には名前が付いています。ヘッダーの名前と値は両方とも StringToSign に含まれます。

StringToSign の定義で呼び出される位置ヘッダーがリクエストにない場合は(例えば、Content-Type または Content-MD5 は、PUT リクエストのオプションであり、GET リクエストには無意味です)、空の文字列("")をその位置に代入します。

タイムスタンプの要件

認証済みリクエストには有効なタイムスタンプ(HTTP Date ヘッダーまたは x-amz-date 代替)が必ず必要です。また、認証済みリクエストに含まれるクライアントタイムスタンプは、リクエスト受信時の Amazon S3 システム時間から 15 分以内である必要があります。そうでない場合、リクエストは失敗し、RequestTimeTooSkewed エラーコードが返されます。このように制限することで、攻撃者によって傍受されたリクエストが繰り返される可能性を限定します。傍受に対する保護をさらに強化するには、認証済みリクエストに対して HTTPS 転送を使用します。

注記

リクエスト日の検証の制約は、クエリ文字列認証を使用しない認証済みリクエストにのみ適用されます。詳細については、「クエリ文字列による代替リクエスト認証」を参照してください。

HTTP クライアントライブラリによっては、リクエストの Date ヘッダーを設定する機能が公開されていないことがあります。標準化ヘッダーの「Date」ヘッダーの値を含めることができない場合は、代わりに「x-amz-date」ヘッダーを使用してリクエストのタイムスタンプを設定します。x-amz-date ヘッダーの値は、RFC 2616 形式(http://www.ietf.org/rfc/rfc2616.txt)の 1 つである必要があります。x-amz-date ヘッダーがリクエストに存在する場合は、すべての Date ヘッダーがリクエスト署名の計算時に無視されます。したがって、x-amz-date ヘッダーを含める場合、StringToSign を作成するときは、空の文字列を Date に対して使用します。例については、次のセクションを参照ください。

認証の例

このセクションの例では、次の表の証明書(実際は機能していません)を使用しています。

パラメータ
AWSAccessKeyId AKIAIOSFODNN7EXAMPLE
AWSSecretAccessKey wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

StringToSign の例では、書式設定はそれほど複雑ではありません。\n は Unicode コードポイント U+000A を意味します。これは一般的には改行と呼ばれています。また、例では「+0000」を使用してタイムゾーンを指定しています。代わりに「GMT」を使用してタイムゾーンを指定することもできますが、署名はこの例に示したものとは異なることになります。

例 オブジェクト GET

この例では、johnsmith バケットからオブジェクトを取得します。

リクエスト StringToSign
Copy
GET /photos/puppy.jpg HTTP/1.1 Host: johnsmith.s3.amazonaws.com Date: Tue, 27 Mar 2007 19:36:42 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE: bWq2s1WEIj+Ydj0vQ697zp+IXMU=
Copy
GET\n \n \n Tue, 27 Mar 2007 19:36:42 +0000\n /johnsmith/photos/puppy.jpg

バケット名は CanonicalizedResource には含まれますが、HTTP リクエスト URI には含まれないことに注意してください。 (これはホストヘッダーによって指定されます。)

例 Object PUT

この例では、オブジェクトを johnsmith バケットに配置します。

リクエスト StringToSign
Copy
PUT /photos/puppy.jpg HTTP/1.1 Content-Type: image/jpeg Content-Length: 94328 Host: johnsmith.s3.amazonaws.com Date: Tue, 27 Mar 2007 21:15:45 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE: MyyxeRY7whkBe+bq8fHCL/2kKUg=
Copy
PUT\n \n image/jpeg\n Tue, 27 Mar 2007 21:15:45 +0000\n /johnsmith/photos/puppy.jpg

リクエスト内および StringToSign 内の Content-Type ヘッダーに注意してください。また、Content-MD5 はリクエストにないので、StringToSign では空白のままであることに注意してください。

例 リスト

この例では、johnsmith バケットのコンテンツを表示します。

リクエスト StringToSign
Copy
GET /?prefix=photos&max-keys=50&marker=puppy HTTP/1.1 User-Agent: Mozilla/5.0 Host: johnsmith.s3.amazonaws.com Date: Tue, 27 Mar 2007 19:42:41 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE: htDYFYduRNen8P9ZfE/s9SuKy0U=
Copy
GET\n \n \n Tue, 27 Mar 2007 19:42:41 +0000\n /johnsmith/

CanonicalizedResource の後ろにスラッシュがあること、そしてクエリ文字列パラメーターがないことに注意してください。

例 取得

この例では、「johnsmith」バケットのアクセスコントロールポリシーのサブリソースを取得します。

リクエスト StringToSign
Copy
GET /?acl HTTP/1.1 Host: johnsmith.s3.amazonaws.com Date: Tue, 27 Mar 2007 19:44:46 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE: c2WLPFtWHVgbEmeEG93a4cG37dM=
Copy
GET\n \n \n Tue, 27 Mar 2007 19:44:46 +0000\n /johnsmith/?acl

サブリソースクエリ文字列パラメーターがどのように CanonicalizedResource に挿入されているかに注意してください。

例 Delete

この例では、パス形式および Date 代替を使用して、「johnsmith」バケットからオブジェクトを削除します。

リクエスト StringToSign
Copy
DELETE /johnsmith/photos/puppy.jpg HTTP/1.1 User-Agent: dotnet Host: s3.amazonaws.com Date: Tue, 27 Mar 2007 21:20:27 +0000 x-amz-date: Tue, 27 Mar 2007 21:20:26 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE:lx3byBScXR6KzyMaifNkardMwNk=
Copy
DELETE\n \n \n Tue, 27 Mar 2007 21:20:26 +0000\n /johnsmith/photos/puppy.jpg

代替の「x-amz-date」方式を使用して日付を指定する方法に注意してください(クライアントライブラリにより、日付を設定できない場合など)。このような場合、x-amz-dateDate ヘッダーより優先されます。このため、署名内の日付エントリに x-amz-date ヘッダーの値を含める必要があります。

例 アップロード

この例では、オブジェクトを、メタデータが含まれる CNAME スタイルの仮想ホストバケットにアップロードします。

リクエスト StringToSign
Copy
PUT /db-backup.dat.gz HTTP/1.1 User-Agent: curl/7.15.5 Host: static.johnsmith.net:8080 Date: Tue, 27 Mar 2007 21:06:08 +0000 x-amz-acl: public-read content-type: application/x-download Content-MD5: 4gJE4saaMU4BqNR0kLY+lw== X-Amz-Meta-ReviewedBy: joe@johnsmith.net X-Amz-Meta-ReviewedBy: jane@johnsmith.net X-Amz-Meta-FileChecksum: 0x02661779 X-Amz-Meta-ChecksumAlgorithm: crc32 Content-Disposition: attachment; filename=database.dat Content-Encoding: gzip Content-Length: 5913339 Authorization: AWS AKIAIOSFODNN7EXAMPLE: ilyl83RwaSoYIEdixDQcA4OnAnc=
Copy
PUT\n 4gJE4saaMU4BqNR0kLY+lw==\n application/x-download\n Tue, 27 Mar 2007 21:06:08 +0000\n x-amz-acl:public-read\n x-amz-meta-checksumalgorithm:crc32\n x-amz-meta-filechecksum:0x02661779\n x-amz-meta-reviewedby: joe@johnsmith.net,jane@johnsmith.net\n /static.johnsmith.net/db-backup.dat.gz

「x-amz-」ヘッダーが並べ替えられ、空白を削除されて小文字に変換される様子を観察してください。また、同じ名前を持つ複数のヘッダーが値の区切りとしてカンマを使用して結合されている様子も確認してください。

Content-Type および Content-MD5 HTTP エンティティヘッダーのみが StringToSign に表示されていることに注意してください。もう一方の Content-* エンティティヘッダーは表示されていません。

また、バケット名は CanonicalizedResource には含まれますが、HTTP リクエスト URI には含まれないないことに注意してください(バケットはホストヘッダーによって指定されます)。

例 自分のバケットすべてをリストする

リクエスト StringToSign
Copy
GET / HTTP/1.1 Host: s3.amazonaws.com Date: Wed, 28 Mar 2007 01:29:59 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE:qGdzdERIC03wnaRNKh6OqZehG9s=
Copy
GET\n \n \n Wed, 28 Mar 2007 01:29:59 +0000\n /

例 Unicode キー

リクエスト StringToSign
Copy
GET /dictionary/fran%C3%A7ais/pr%c3%a9f%c3%a8re HTTP/1.1 Host: s3.amazonaws.com Date: Wed, 28 Mar 2007 01:49:49 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE:DNEZGsoieTZ92F3bUfSPQcbGmlM=
Copy
GET\n \n \n Wed, 28 Mar 2007 01:49:49 +0000\n /dictionary/fran%C3%A7ais/pr%c3%a9f%c3%a8re

注記

リクエスト URI から派生した StringToSign の要素は、URI エンコーディングおよび大文字/小文字の設定を含め、文字通りに取得されます。

REST リクエストの署名に関する問題

REST リクエスト認証が失敗すると、システムは、そのリクエストに対して XML エラードキュメントで応答します。このエラードキュメントに含まれる情報は、開発者が問題を診断するのに役立ちます。特に、SignatureDoesNotMatch エラードキュメントの StringToSign 要素を確認すると、システムで使用されているリクエスト標準化が正確にわかります。

ツールキットの中には、知らないヘッダーを通知なしで事前に挿入するものがあります。例えば、PUT の実行中にヘッダー Content-Type が追加されることがあります。この場合、挿入されたヘッダーの値は一定であることがほとんどで、Ethereal、tcpmon などのツールを使用すると、不足しているヘッダーを検出できます。

クエリ文字列による代替リクエスト認証

Authorization HTTP ヘッダーを使用する代わりに、必要な情報をクエリ文字列パラメーターとして渡すことで、特定の種類のリクエストを認証できます。これは、サードパーティのブラウザで、リクエストをプロキシに委任せずに、プライベートの Amazon S3 データに直接アクセスできるようにするときに便利です。これを行うには、「署名付き」のリクエストを作成し、エンドユーザーのブラウザが取得できる URL としてエンコードします。さらに、署名付きのリクエストは、有効期限を指定することで制限できます。

注記

AWS SDK を使用して署名付きの URL を生成する例については、「他ユーザーとのオブジェクトの共有」を参照してください。

署名の作成

クエリ文字列認証済み Amazon S3 REST リクエストの例を次に示します。

Copy
GET /photos/puppy.jpg ?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE&Expires=1141889120&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv4%3D HTTP/1.1 Host: johnsmith.s3.amazonaws.com Date: Mon, 26 Mar 2007 19:37:58 +0000

クエリ文字列リクエスト認証方法には、特別な HTTP ヘッダーは必要ありません。代わりに、必要な認証要素は、クエリ文字列パラメーターとして指定します。

クエリ文字列パラメーター名 値の例 説明
AWSAccessKeyId AKIAIOSFODNN7EXAMPLE 使用する AWS アクセスキー ID。リクエストへの署名に使用する AWS シークレットアクセスキーを指定します。また、リクエストを行う開発者のアイデンティティを間接的に指定します。
Expires 1141889120 署名の有効期限。エポック (1970 年 1 月 1 日の 00:00:00 UTC) からの時間が秒単位で指定されます。この時刻(サーバーの時刻)より後に受信したリクエストは拒否されます。
Signature vjbyPxybdZaNmGa%2ByT272YEAiv4%3D StringToSign の HMAC-SHA1 の Base64 エンコーディングの URL エンコーディング。

クエリ文字列リクエスト認証方法は、通常の方法とは若干異なりますが、Signature リクエストパラメーターおよび StringToSign 要素の形式だけが異なります。クエリ文字列リクエスト認証方法を示す疑似文法を次に示します。

Copy
Signature = URL-Encode( Base64( HMAC-SHA1( YourSecretAccessKeyID, UTF-8-Encoding-Of( StringToSign ) ) ) ); StringToSign = HTTP-VERB + "\n" + Content-MD5 + "\n" + Content-Type + "\n" + Expires + "\n" + CanonicalizedAmzHeaders + CanonicalizedResource;

YourSecretAccessKeyID は、アマゾン ウェブ サービスの開発者としてサインアップするときに、Amazon によって割り当てられる AWS シークレットアクセスキー ID です。Signature が、クエリ文字列内に適切に配置されるために URL エンコードされている点に注目してください。また、HTTP では Date であった位置要素が、StringToSign では Expires に置き換えられていることに注意してください。CanonicalizedAmzHeaders および CanonicalizedResource は同じです。

注記

クエリ文字列認証メソッドでは、署名する文字列を計算する際に、Date または x-amz-date request ヘッダーを使用しません。

例 クエリ文字列リクエスト認証

リクエスト StringToSign
Copy
GET /photos/puppy.jpg?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE& Signature=NpgCjnDzrM%2BWFzoENXmpNDUsSn8%3D& Expires=1175139620 HTTP/1.1 Host: johnsmith.s3.amazonaws.com
Copy
GET\n \n \n 1175139620\n /johnsmith/photos/puppy.jpg

ブラウザが GET リクエストを行うとき、Content-MD5 または Content-Type ヘッダーを提供しないこと、また、x-amz- ヘッダーを設定しないことが前提となっています。したがって、StringToSign のこの部分は空白のままです。

Base64 エンコーディングの使用

HMAC リクエスト署名は、Base64 エンコードされている必要があります。Base64 エンコーディングでは、署名を、リクエストにアタッチできるシンプルな ASCII 文字列に変換します。プラス(+)、スラッシュ(/)、等号(=)などの署名文字列に含めることができる文字は、URI で使用する場合には、エンコードされている必要があります。例えば、認証コードにプラス記号(+)が含まれる場合は、リクエストで %2B としてエンコードします。スラッシュは %2F、等号は %3D でエンコードします。

Base64 エンコーディングの例については、Amazon S3 認証の例 を参照してください。