すべてのプロダクト
Search
ドキュメントセンター

:権限付与ヘッダーにV1署名を含める

最終更新日:Mar 12, 2024

Object Storage Service (OSS) では、HTTP Authorizationヘッダーを使用することが、認証情報を提供する最も一般的な方法です。 POSTリクエストとクエリパラメーターを使用して署名されたリクエストを除き、すべてのOSS操作で認証にAuthorizationリクエストヘッダーが使用されます。 このトピックでは、V1署名アルゴリズムを使用してAuthorizationヘッダーに署名を含める方法について説明します。

重要

より良いセキュリティを提供するV4署名アルゴリズムを使用することを推奨します。 詳細については、「AuthorizationヘッダーにV4署名を含める (推奨) 」をご参照ください。

OSS SDKを使用したV1シグネチャの自動実装

OSS SDKには、OSS署名V1の実装が含まれています。 OSS SDKを使用する場合、署名を使用するために追加の操作を実行する必要はありません。 特定のプログラミング言語の署名実装の詳細については、そのプログラミング言語のOSS SDKのコードをご参照ください。 次の表に、さまざまなプログラミング言語でOSS SDKを使用する場合に、V1署名アルゴリズムを使用してリクエストに署名するために使用されるサンプルコードへの参照を示します。

SDK

サンプルコード

Java

OSSV1Signer.java

PHP

SignerV1.php

Node.js

client.js

Browser.js

Python

auth.py

. ネット

OssRequestSigner.cs

Android

OSSUtils.java

Go

v1.go

iOS

OSSModel.m

C++

SignerV1.cc

C

oss_auth.c

Ruby

util.rb

承認ヘッダーの計算

計算方法

許可="OSS" + AccessKeyId + ":" + 署名
署名=base64(hmac-sha1(AccessKeySecret、
            VERB + "\n"
            + Content-MD5 + "\n" 
            + Content-Type + "\n" 
            + Date + "\n" 
            + CanonicalizedOSSHeaders
            + CanonicalizedResource) 

パラメーター

パラメーター

データ型

必須

説明

AccessKeyId

String

必須

LTAI4FixJvEPgvZ6g5cC ****

OSSへのアクセスに使用されるAccessKey ID。

AccessKeySecret

String

必須

Q0YehC6ZyugWfjod5y8Rcqrc1y ****

OSSへのアクセスに使用されるAccessKeyシークレット。

VERB

列挙

PUT

HTTPリクエストのメソッド (PUT、GET、POST、HEAD、DELETE、OPTIONSなど) 。

\n

String

任意

\n

ラインフィード。

コンテンツ-MD5

String

任意

eB5eJF1ptWaXm4bijSPyxw==

要求されたコンテンツのMD5ハッシュ。 メッセージの内容 (ヘッダーなし) を計算して、128ビットの数値であるMD5ハッシュを取得します。 この数値は、Content-MD5値を生成するためにBase64でエンコードされます。 詳細については、「RFC 2616 Content-MD5」をご参照ください。

リクエストヘッダーは、メッセージの有効性を確認するために使用できます。 メッセージコンテンツは、受信されたメッセージコンテンツが送信されたコンテンツと同じである場合に有効である。 このパラメーターは空白のままも可能です。

Content-MD5の値の計算方法の詳細については、「コンテンツの計算-MD5」をご参照ください。

コンテンツタイプ

String

任意

application/octet-stream

リクエストコンテンツのタイプ。 このパラメーターは空白のままも可能です。

説明

署名を計算するときにContent-Typeを設定しない場合は、後で署名を使用してオブジェクトをアップロードするときにこのパラメーターを設定する必要はありません。

日付

String

必須

11月22日日曜日2015 08:16:38 GMT

操作が実行された時刻。 このパラメーターの値はUTCでなければなりません。 このパラメーターは空白のままにできません。 パラメーターの値は、リクエストのDateヘッダーまたはx-oss-dateヘッダーから計算されます。 2つのヘッダーが同時に存在する場合、x-oss-dateが優先されます。

重要

リクエストのDateヘッダーで指定された時間と、リクエストが受信されたサーバーの時間の差が15分を超える場合、OSSはリクエストを拒否し、HTTPステータスコード403を返します。

CanonicalizedOSSHeaders

String

任意

x-oss-meta-a:a\nx-oss-meta-b:b\nx-oss-meta-c:c\n

先頭にx-oss- を付け、アルファベット順に並べたHTTPヘッダー。 このパラメーターは空白のままも可能です。

  • CanonicalizedOSSHeadersが空の場合、ヘッダーの末尾に \n区切り文字を追加する必要はありません。

  • CanonicalizedOSSHeadersにヘッダーが1つしか含まれていない場合は、ヘッダーの末尾に \n区切り文字を追加する必要があります。 例: x-oss-meta-a\n

  • CanonicalizedOSSHeadersに複数のヘッダーが含まれている場合は、各ヘッダーの末尾に \n区切り文字を追加する必要があります。 例: x-oss-meta-a:a\nx-oss-meta-b:b\nx-oss-meta-c:c\n

CanonicalizedOSSHeadersの作成方法の詳細については、「CanonicalizedOSSHeadersの作成」をご参照ください。

CanonicalizedResource

String

必須

examplebucket

アクセスするOSSリソース。 このパラメーターは空白のままにできません。

CanonicalizedResourceの作成方法の詳細については、「CanonicalizedResourceの作成」をご参照ください。

  • 例1 (すべてのパラメータを含む)

    リクエスト

    計算式:

    署名文字列

    PUT /nelson HTTP/1.0 Content-MD5: eB5eJF1ptWaXm4bijSPyxw== Content-Type: text/html日付: 2022年12月28日水曜日10:27:41 GMTホスト: examplebucket.oss-cn-hangzhou.aliyuncs.com x-oss-meta-著者: alice x-oss-meta-magic: abracadabra

    署名=base64(hmac-sha1(AccessKeySecret,VERB + "\n" + Content-MD5 + "\n" + コンテンツタイプ + "\n" + 日付 + "\n" + CanonicalizedOSSHeaders + CanonicalizedResource))

    PUT\n eB5eJF1ptWaXm4bijSPyxw =\ n text/html\n水曜日、2022 12月28日10:27:41 GMT\n x-oss-meta-magic:abracadabra\nx-oss-meta-著者: alice\n/examplebucket/nelson

    AccessKey IDがLTAI4FixJvEPgvZ6g5cC **** で、AccessKeyシークレットがQ0YehC6ZyugWfjod5y8Rcqrc1y **** の場合、次のPythonコードを実行して署名を計算できます。

    hmacのインポート
    hashlibのインポート
    インポートbase64
    
    h = hmac.new("Q0YehC6ZyugWfjod5y8Rcqrc1y ****".encode('utf-8 '),
                 "PUT\nODBGOERFMDMzQTczRUY3NUE3NzA5QzdFNUYzMDQxNEM\ntext/html\nWed、2022年12月28日10:27:41 GMT\nx-oss-meta-magic:abracadabra\nx-oss-meta-author:alice\n/oss-example/nelson".encode('utf-8 ') 、hashlib.sha1)
    signature = base64.encodebytes(h.digest())
    プリント (署名) 

    計算された署名はJ9Nl3b xdEKNQGWFhhZpjSLm **** です。 次の例は、Authorizationヘッダーを含む最終的なリクエストを示しています。

    PUT /nelson HTTP/1.0
    権限付与: OSS LTAI4FixJvEPgvZ6g5cC ****:J9Nl3b + xdEKNQGWFhhZpjSLm ****
    Content-Md5: eB5eJF1ptWaXm4bijSPyxw==
    コンテンツタイプ: text/html
    日付: 12月28日水2022 10:27:41 GMT
    ホスト: oss-example.oss-cn-hangzhou.aliyuncs.com
    x-oss-meta-author: alice
    x-oss-meta-magic: abracadabra 
  • 例2 (オプションのパラメーターContent-MD5とContent-Typeを除く)

    リクエスト

    計算式:

    署名文字列

    PUT /nelson HTTP/1.0日付: 2022 12月28日水曜日09:56:32 GMTホスト: examplebucket.oss-cn-hangzhou.aliyuncs.com x-oss-meta-著者: alice x-oss-meta-magic: abracadabra

    署名=base64(hmac-sha1(AccessKeySecret,VERB + "\n" + "\n" + Date + "\n" + CanonicalizedOSSHeaders + CanonicalizedResource))

    PUT\n\n\n水曜日、2022 12月28日09:56:32 GMT\n x-oss-meta-magic:abracadabra\nx-oss-meta-著者: alice\n/examplebucket/nelson

    AccessKey IDがLTAI5t7h6SgiLSganP2m **** で、AccessKeyシークレットがKZo149BD9GLPNiDIEmdQ7dyNKG **** の場合、次のPythonコードを実行して署名を計算できます。

    hmacのインポート
    hashlibのインポート
    インポートbase64
    
    h = hmac.new("KZo149BD9GLPNiDIEmdQ7dyNKG ****".encode('utf-8 '),
                 "PUT\n\n\nWed, 28 Dec 2022 09:56:32 GMT\nx-oss-meta-magic:abracadabra\nx-oss-meta-author:alice\n/oss-example/nelson".encode('utf-8 ') 、hashlib.sha1)
    signature = base64.encodebytes(h.digest())
    プリント (署名) 

    計算された署名はMhb1MkIfOlZTnBXZE5Hleb/2 **** です。 次の例は、Authorizationヘッダーを含む最終的なリクエストを示しています。

    PUT /nelson HTTP/1.0
    承認: OSS LTAI5t7h6SgiLSganP2m ****:Mhb1MkIfOlZTnBXZE5Hleb/2 ****
    日付: 12月28日水2022 09:56:32 GMT
    ホスト: oss-example.oss-cn-hangzhou.aliyuncs.com
    x-oss-meta-author: alice
    x-oss-meta-magic: abracadabra 

追加情報

  • インポートされたAccessKey IDが存在しないか、有効化されていない場合、403 ForbiddenはエラーコードInvalidAccessKeyIdと共に返されます。 インポートされたAccessKey IDが有効化されているが、OSSがリクエストで署名エラーが発生したと判断した場合、暗号化を検証するために、403 Forbiddenがレスポンスで正しい署名文字列とともに返されます。 応答に基づいて、署名文字列が正しいかどうかを確認できます。

    レスポンス例:

    <?xml version="1.0" ?>
    <エラー>
     <Code>
         SignatureDoesNotMatch
     </Code>
     <Message>
         The request signature we calculated does not match the signature you provided. Check your key and signing method.
     </Message>
     <StringToSignBytes>
         47 45 54 0a 0a 0a 57 65 64 2c 20 31 31 20 4d 61 79 20 32 30 31 31 20 30 37 3a 35 39 3a 32 35 20 47 4d 54 0a 2f 75 73 72 65 61 6c 74 65 73 74 3f 61 63 6c
     </StringToSignBytes>
     <RequestId>
         1E446260FF9B ****
     </RequestId>
     <HostId>
         oss-cn-hangzhou.aliyuncs。***
     </HostId>
     <SignatureProvided>
         y5H7yzPsA/tP4+0tH1HHvPEwUv8=
     </SignatureProvided>
     <StringToSign>
         GET
    5月11日水曜日2011 07:59:25 GMT
    /examplebucket?acl
     </StringToSign>
     <OSSAccessKeyId>
         AKIAIVAKMSMOY7VO ****
     </OSSAccessKeyId>
    </エラー> 
  • リクエストのAuthorization値の形式が無効な場合、400 Bad requestはエラーコードInvalidArgumentと共に返されます。

  • すべてのOSSリクエストの日付と時刻は、HTTP/1.1で指定されたUTCである必要があります。 日付は次の形式です。

    date1 = 2DIGIT SP月SP 4DIGIT; 日月年 (例: 02 Jun 1982)
    説明

    前の日付形式では、dayは2桁を使用します。 したがって、Jun 22 Jun 1982、および2-Jun-1982はすべて無効な日付形式です。

    • 署名付きリクエストでDateヘッダーが指定されていないか、無効な形式の場合、403 ForbiddenはエラーコードAccessDeniedと共に返されます。

    • リクエストのDateヘッダーで指定された時間と、リクエストが受信されたサーバーの時間の差が15分を超える場合、403 ForbiddenはエラーコードRequestTimeTooSkewedと共に返されます。

CanonicalizedOSSHeadersの作成

先頭にx-oss- が付いたすべてのHTTPヘッダーは、CanonicalizedOSSHeadersと呼ばれます。 CanonicalizedOSSHeadersを作成するには、次の手順を実行します。

  1. 先頭にx-oss- が付いたすべてのHTTPリクエストヘッダーの名前を小文字に変換します。 たとえば、X-OSS-Meta-Name: TaoBaox-oss-meta-name: TaoBaoに変換します。

  2. Security Token Service (STS) から取得した一時的なアクセス資格情報を使用してリクエストを送信する場合、取得したsecurity-token値をx-oss-security-token:security-token形式で署名文字列に追加する必要があります。

    説明

    STSの設定方法の詳細については、「STSが提供する一時的な資格情報を使用してOSSにアクセスする」をご参照ください。 AssumeRole操作を呼び出すか、さまざまなプログラミング言語のSTS SDKを使用して、一時的なアクセス資格情報を取得できます。 一時的なアクセス資格情報には、セキュリティトークンと一時的なAccessKeyペアが含まれます。 AccessKey ペアは、AccessKey ID と AccessKey Secret で構成されます。

  3. すべてのHTTPリクエストヘッダーをアルファベット順に並べ替えます。

  4. 各ヘッダーとヘッダー値の間の区切り文字の両側のスペースをすべて削除します。 たとえば、x-oss-meta-name: TaoBaox-oss-meta-name: TaoBaoに変換します。

  5. CanonicalizedOSSHeadersを作成するには、すべてのヘッダーを \nの区切り文字で区切ります。

CanonicalizedResourceの作成

リクエストに必要なOSSリソースは、CanonicalizedResourceと呼ばれます。 CanonicalizedResourceを構築するには、次の操作を実行します。

  • リソースにバケットとオブジェクトが含まれている場合は、CanonicalizedResourceを /BucketName/ObjectNameに設定します。

  • リソースにバケットが含まれている場合は、CanonicalizedResourceを /BucketName/ に設定します。

  • リソースにバケットまたはオブジェクトが含まれていない場合は、CanonicalizedResourceをスラッシュ (/) に設定します。

  • リソースにサブリソースが含まれている場合は、すべてのサブリソースをアルファベット順に並べ替え、アンパサンド (&) で区切ります。 疑問符 (?) とサブリソース文字列をCanonicalizedResource文字列の末尾に追加します。 作成されたCanonicalizedResourceの形式は /BucketName/ObjectName?acl&uploadId=UploadIdです。

    OSSは、次のタイプのサブリソースをサポートしています。

    • acl、uploads、location、cors、logging、website、referer、lifecycle、delete、append、tagging、objectMeta、uploadId、partNumber、security-token、position、img、style、styleName、replicationProgress、replicationLocation、cname、bucketInfo、comp、qos、live、status、status、およびcallback-var。 詳細については、「PutBucket」および「PutObject」をご参照ください。

      重要

      リソース識別子は大文字と小文字を区別します。

    • Response-content-type、response-content-language、response-expires、response-cache-control、response-content-disposition、response-content-encodingなどの応答ヘッダーフィールド。 詳しくは、「GetObject」をご参照ください。

    • x-oss-processなどのIMG実装モード。 詳細については、「概要」をご参照ください。

    • x-oss-ac-source-ip、x-oss-ac-subnet-mask、x-oss-ac-vpc-id、x-oss-ac-forward-allowなど、x-oss-ac-* で始まるアクセス制御フィールド。 詳細については、「署名V1を使用した署名付きURLの作成」をご参照ください。

      説明

      x-oss-ac-source-ipを含むCanonicalizedResourceを使用して署名を生成した後、リクエストのクエリパラメーターからx-oss-ac-source-ipを削除して、IPアドレスのリークを防ぎます。

署名計算ルール

  • 署名の計算に使用される署名文字列は、UTF-8でエンコードする必要があります。 漢字を含む署名文字列は、UTF-8でエンコードする必要があります。 エンコードされた署名文字列は、AccessKeySecretパラメーターとともに使用され、最終的な署名文字列が計算されます。

  • RFC 2104で指定されているHMAC-SHA1メソッドを使用して、署名を計算します。 このメソッドでは、KeyはAccessKeyシークレットを示します。

  • Content-TypeContent-MD5は、リクエストに指定されないままにすることができます。 ただし、OSSがリクエストの署名を検証する必要があり、これら2つのヘッダーの値が空の場合は、空の値を改行 (\n) に置き換えます。

  • x-oss- というプレフィックスが付いた非標準HTTPヘッダーを署名文字列に追加する必要があります。 その他の非標準HTTPヘッダーはOSSによって無視されます。 たとえば、次の署名例のx-oss-meta-magicヘッダーを署名文字列に含める必要があります。

    説明

    署名文字列の先頭にx-oss- が付いているヘッダーは、次の規則に従う必要があり

    • ヘッダーの名前は小文字でなければなりません。

    • ヘッダーはアルファベット順に並べ替える必要があります。

    • 各ヘッダー名と値を区切るコロン (:) の前後にスペースがありません。

    • 各ヘッダーの後にラインフィード (\n) が続きます。 ヘッダーを指定しない場合は、CanonicalizedOSSHeadersを空のままにします。

Content-MD5の計算

次の例では、文字列 "123456789" を使用して、リクエストコンテンツのContent-MD5値を計算する方法を示します。

  • 正しい計算

    1. 文字列のMD5ハッシュを計算します。これは128ビットのバイナリ配列です。

    2. Base64で (32ビット文字列の代わりに) バイナリ配列をエンコードします。

    次のPythonコードは、Content-MD5値の計算方法の例を示しています。

    >>> インポートbase64、hashlib
    >>> hash = hashlib.md5()
    >>> hash.update("0123456789") // Python 3を使用する場合は、この行をhash.update(b "0123456789") に変更します。 
    >>> base64.b64encode(hash.digest())
    'eB5eJF1ptWaXm4bijSPyxw==' 

    hash.digest() を呼び出して、128ビットのバイナリ配列を計算します。

    >>> hash.digest()
    'x\x1e ^$]i\xb5f\x97\x9b\x86\xe2\x8d#\xf2\xc7' 
  • 不正計算

    説明

    一般的な不正操作は、計算された32ビット文字列をBase64でエンコードしてContent-MD5値を取得することです。

    # hash.hexdigest() を呼び出して、32ビットの平文文字列を取得します。 
    >>> hash.hexdigest()
    '781e5e245d69b566979b86e28d23f2c7'
    # 次のコードは、Base64で誤ったMD5ハッシュをエンコードした結果の例を示しています。>>> base64.b64encode(hash.hexdigest())
    'NzgxZTVlMjQ1ZDY5YjU2Njk3OWI4NmUyOGQyM2YyYzc='