OAuth Core 1.0 Revision A 日本語訳

 

 

 

はじめに

 

OAuth は、ウェブサイトやクライアントアプリケーションなど（以降 Consumer と呼ぶ）に対して、ユーザの同意のもと、そのユーザがあるWebサービス（以降 Service Provider と呼ぶ）上に所有する保護されたリソースへ API 経由でアクセスすることを可能にします。この際、ユーザーが Consumer に Service Provider の ID・パスワードを提供することはありません。OAuth は API 向けの自由度が高く汎用的な認証方式です。

 

例えば、あるユーザが、プリントサービス（Consumer）に対して、写真管理サービス（Service Provider）上の自身のプライベートな写真データ（リソース）へのアクセスを許可したいとします。この場合、ユーザーはプリントサービスに写真管理サービスの ID・パスワードを渡すことなく、自分の写真データを渡すことができます。

 

OAuth は特別なユーザーインターフェイスを要求するものではなく、サービスプロバイダに対して認証方法を指定するものでもありません。OpenID のように Consumer がユーザー自身の ID・パスワードを管理しないケースにも適しています。

 

OAuth はウェブサービス上における同意の方法を統一する、コミュニティ主導のプロトコルを目指しています。OAuth は既存の主要なウェブサイトで実装されていた各プロトコルとそれらのベストプラクティスをもとにつくられました。大小さまざまなサービスにサポートされたオープンな共通規格は、開発者・ユーザ双方に一貫した信頼性の高い体験をもたらすでしょう。

 

 

本書について

 

本書は OAuth.net（http://oauth.net/）にて定められている仕様「OAuth Core 1.0 Revision A」（http://oauth.net/core/1.0a）を日本語訳したものです。

 

本書は OAuth Core 1.0 Rev A の仕様を有志が個人的に翻訳したものであり、OAuth.net が正式に翻訳したものではありません。翻訳内容の精度は保証できるものではないため、利用にあたってもあくまで仕様本体を読み解くための参考までにとどめていただくようお願いします。仕様ドキュメントの内容としてはあくまで「OAuth Core 1.0 Revision A」（http://oauth.net/core/1.0a）を"正"としていただき、本書はあくまで理解を助ける参考ドキュメントとご認識ください。

 

将来的によりふさわしい団体、組織、または個人によって日本語訳が出された場合、このページは削除される場合があります。（出来る限り新しいページへのリンクは残すようにします）

 

 

1. 本書のライセンス

 

この仕様は OAuth Core 1.0 の仕様に由来しており、OAuth Core 1.0 の仕様は OAuth Non-Assertion Convenant and Author's Contribution Licence For OAuth Specification 1.0（http://oauth.net/license/core/1.0）に記載されているライセンスに則って利用できます。ただし、OAuth Core 1.0 Revision A への仕様変更についてはこのライセンスではまだカバーされておりません。

 

OAuth Core 1.0 Revision A は session fixation attack の脆弱性を解決する仕様として作られました。

この仕様変更については Google、Yahoo! の両社によって行われ、利用にあたっては OAuth Core 1.0 と同等に扱って良いことを両社と合意しています。

 

 

2. 表記と用法

 

このドキュメント内に記載されている、"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"といった表記は、RFC2119 で規定されている用法に従っています。また、文中の例に利用しているドメインは、RFC26060 で規定されているものに従っています。

 

 

3. 用語定義

 

Service Provider

OAuth 経由でユーザーリソースを提供するウェブアプリケーション

 

User

Service Provider 上にアカウントを持っているエンドユーザー

 

Consumer

User の同意のもと Service Provider の持つユーザーリソースへアクセスする Web サイトもしくはクライアントアプリケーション

 

Protected Resource(s)

Consumer が User の同意のもとアクセスできる Service Provider 上のユーザーリソース

 

Consumer Developer

Consumer の開発者（個人または団体、企業など）

 

Consumer Key

Service Provider 側で識別するための、Consumer の識別子

 

Consumer Secret

Consumer 自身が、その Consumer Key の所有者であることを証明するための秘密鍵

 

Request Token

Consumer が User からリソースへアクセスする同意を得るための値。Access Token と交換される。

 

Access Token

Consumer が User の同意のもと、Service Provider 上のリソースへアクセスする際に利用する値。Service Provider 上の ID・パスワードの代わりに使われる。

 

Token Secret

Consumer が与えられた Token の所有者であることを証明するための秘密鍵

 

OAuth Protocol Palameters

「oauth_」で始まるパラメータの名称

 

 

4. 前提条件

 

OAuth には、Consumer Key と Consumer Secret を使って Service Provider が Consumer の正当性を確認するしくみが含まれています。Consumer を特定、識別することにより、Service Provider は様々なアクセスレベルを Consumer ごとに与えることが可能になります。（たとえばアクセスできる範囲を限定するなど）

 

Consumer Secret が Service Provider と Consumer 以外の第三者に知られ得ないことが確約されない限り、Service Provider は Consumer の正当性を確認する際に Consumer Secret を信頼するべきではありません（SHOULD NOT）。Consumer Secret は空文字列の場合もあります（MAY）。（例えば Consumer を確認する必要がない場合や、Consumer Secret ではなく RSA などの別の方法で Consumer の確認を行う場合など）

 

 

4.1 Request URLs

 

OAuth では３つの Request URL を定義しています

 

Request Token URL

この URL は、Consumer がまだ User に認可されていない Request Token を取得するために使われます。

 

User Authorization URL

この URL は、Consumer が 未認可の Request Token を User に認可させるために使われます。

 

Access Token URL

この URL は、User が認可した Request Token を Access Token と交換するために使われます。

 

これら3つの URL は、scheme、authority、pathを必ず含んでいる必要があり（MUST）、RFC3986 の Section3 に定義されているようなクエリやフラグを含んでいてもかまいません（MAY）。またこれらの URL のクエリには、OAuth プロトコルの Parameter を含んではいけません（MUST NOT）。

 

例：http://sp.example.com/authorize

 

 

4.2 Service Provider

 

Service Provider は責任を持って、Consumer に対して Consumer Key と Consumer Secret を発行する必要があります。またこの発行プロセスと Consumer に要求される条件は、Service Provider 側にすべて任されています。

 

Service Provider の仕様ドキュメントには以下のものが必要です

 

1. Consumer が OAuth リクエストを行う際の Request URLs と、Request Token URL、Access Token URL を利用する際の HTTP メソッド（GET, POSTなど）

2. Service Provider がサポートする署名の方式

3. Service Provider から Token を取得する際に必要な追加パラメータ。Service Provider 独自の Parameter は「oauth_」で始まってはいけません（MUST NOT）

 

 

4.3. Consumer

 

Consumer は Service Provider との間で、利用する Consumer Key と Consumer Secret を取り決める必要があります（MUST）。また、そのために Consumer は Service Provider へ情報を登録し、個別に追加の情報を取得される場合があります。（MAY）

 

 

5. Parameter

 

OAuth Protocol Parameter は、パラメータ名・値ともに大文字、小文字を区別して扱われます。それぞれの OAuth Protocol Parameter は１回のリクエストにつき１つしか含まれないようにしなくてはならず（MUST NOT）、また特に個別の記載がない限りそれぞれの OAuth Protocol Parameter は必須です（REQUIRED）

 

 

5.1 パラメータエンコーディング

 

すべてのパラメータは [RFC3986] の percent-encoding (%xx) で定義されている方式でエスケープされます。[RFC3986] の Section 2.3 にある非予約文字（unreserved character）に含まれていない文字は必ずエンコードされている必要があります（MUST）。一方で非予約文字に含まれる文字についてはエンコードしないようにしてください（MUST NOT）。またエンコードされた16進数の文字は、必ず大文字にしておく必要があります。テキストの名称や値は必ず UTF-8 でエンコードしてから、percent-encoding [RFC3629] を行ってください。

 

 

5.2 Consumer Request Parameter

 

OAuthプロトコルのパラメータは、次の３つのうちいずれかの方式でConsumerからService Providerに対して送信されます。

 

1. 「5.4. OAuth HTTP Authorization Scheme」で定義されている「5.4.1. Authorization header」の中で送信する

2. HTTP POST Requestのbodyに、「content-type of application/x-www-form-urlencoded. 」として送信する

3. URLのクエリ部分に追加して送信する（[RFC3986]section3の定義を参照）

 

これらの定義された方式に加えて、OAuthプロトコルのパラメータを送信する新しい方法が将来的に追加される場合があります。他のリクエストパラメータを送信するための方式は定義されていませんが、OAuth HTTP Authorization Scheme headerを利用しないようにしてください（SHOULD NOT）。

 

 

5.3 Service Provider Response Parameters

 

Response ParametersはService ProviderからConsumerに対して、Tokenとその他の情報を含めてHTTP response bodyで送信されます。これらのParameter名と値は、「5.1. Parameter Encoding」に記載した方式でまずエンコードされ、"&"の文字を使って連結されます。（[RFC3986] Section 2.1. を参照参照）

 

例：oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=xyz4992k83j47x0b

 

 

5.4 OAuth HTTP Authrization Scheme

 

ここでは[RFC2617]の拡張仕様をOAuthがサポートしていることを定義しています。OAuthプロトコルのパラメータの通信には標準的なHTTP AuthorizationとWWW-Authenticate headersを使用します。

 

Service Providerは、HTTP Authorization headerを受け入れるようにしておくべきです（RECOMMNENDED）。ConsumerはOAuth Authorization headerでOAuthプロトコルパラメータを送信することが推奨されています。

 

この認証スキームの拡張仕様（[RFC2617]で定義されている）は、OAuthにおいては大文字、小文字を区別します。

 

 

5.4.1 Authorization Header

 

OAuthプロトコルパラメータは、以下のようなAuthorization Headerで送信されます。

 

1. Parameter名と値は「5.1. Parameter Encoding」に記載されている方式でエンコーディングされます。

2. それぞれのParameterにおいて、Parameter名の後に「=」（ASCII code 61）、「"」（ASCII code 34）、「パラメータの値」（空白の場合もあります）、「"」（ASCII code 34）、と続きます。

3. パラメータ同士は「,」（ASCII code 44）で区切るか、もしくは[RFC2617]にあるように空白で区切ってもかまいません。

4. [RFC2617]Section 1.2. にあるように、realm parameterが含まれていても問題はありません（OPTIONAL）

 

例：

 

                Authorization: OAuth realm="http://sp.example.com/",
                oauth_consumer_key="0685bd9184jfhq22",
                oauth_token="ad180jjd733klru7",
                oauth_signature_method="HMAC-SHA1",
                oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
                oauth_timestamp="137131200",
                oauth_nonce="4572616e48616d6d65724c61686176",
                oauth_version="1.0"

 

 

5.4.2 WWW-Authenticate Header

 

保護されているリソースに対してConsumerがRequestした際のResponseとして、WWW-Authenticate HeaderをサポートしていることをService Providerが明示しても差し支えありません。

 

 

例：

                WWW-Authenticate: OAuth realm="http://sp.example.com/"

 

[RFC2617] Section 1.2. に記載されているように、realm parameterが保護されたrealmを示しています。

 

 

6. Authenticating with OAuth

 

OAuthの認証プロセスでは、End Userが同意することにより、End User自身のクレデンシャル（ID、パスワードなど）をConsumerに渡すことなく、保護されたリソースへのアクセス権限のみを委譲できます。OAuthはEnd Userのクレデンシャルの代わりに、Service Providerによって生成されたTokenを利用し、Service Providerの保護されたリソースへ対してアクセス要求をする際に、クレデンシャルの代わりにそれらのTokenを利用します。

 

このプロセスで使われるTokenには以下の２種類があります。

 

Request Token

 

Request TokenはConsumerがUserへ、保護されたリソースにアクセスする際の同意を得るために利用します。Userが同意したRequest TokenはAccess Tokenに交換できるようになります。ここでは１度だけ交換することができ（MUST）、またRequest Tokenは他のいかなる目的にも利用されるべきではありません（MUST NOT）。また、

Request Tokenには有効期限を設定することを推奨します（RECOMMENDED）

 

Access Token

 

Access Tokenは、ConsumerがUserになり代わってUserの保護されたリソースへアクセスする際に利用します。Access Tokenを使って保護されたリソースへアクセスする場合、Service Providerはアクセス権限を制限するようにしていてもかまいませんし（MAY）、有効期限を設定してもかまいません（MAY）。

またService ProviderはEnd UserがAccess Tokenを無効化できるような手段を準備しておくべきで（SHOULD）、かつ保護されたリソースに対してはAccess Tokenのみを利用してアクセスできるようにしておくべきです（SHOULD）。

 

 

OAuth Authenticationは以下の３ステップがあります。

 

1. ConsumerがUserが未同意のRequest Tokenを取得する

2. UserがRequest Tokenを同意（認可）する

3. ConsumerはRequest TokenとAccess Tokenを交換する

 

 

6.1 未同意のRequest Tokenを取得する

 

ConsumerはService Providerへ未同意のRequest Tokenを発行するように依頼します。Request Tokenの唯一の目的は、Access Tokenを取得するためにUserの同意を得ることです。Request Tokenを使った処理は以下のようになります。

 

 

6.1.1 ConsumerがRequest Tokenを取得する

 

Request Tokenを取得するには、ConsumerはService ProviderのRequest Token URLに対してHTTP Requestを送ります。Service Providerのドキュメントには、Requestを送る際のHTTPメソッドが指定されるべきで、原則的にはHTTP POSTが推奨されます（RECOMMENDED）。またこのRequestには必ず署名がされている必要があり、以下のパラメータが必須です。

 

- oauth_consumer key

Consumer key

 

- oauth_signature_method

ConsumerがRequestに署名する際の署名方式

 

- oauth_signature

ConsumerがRequestに行った署名

 

- oauth_timestamp

「8. Nonceとタイムスタンプ」の項目で定義されたタイムスタンプ

 

- oauth_nonce

「8. Nonceとタイムスタンプ」の項目で定義されたNonce

 

- oauth_version

オプション。このParameterの値が含まれる場合は必ず「1.0」である必要があります（MUST）。値が含まれない場合は、Service Provider側がOAuth Core 1.0であると想定しなくてはなりません（MUST）。Service ProviderがOAuth Core 1.0以外である場合の値は、現在の仕様ではまだ定義されていません

 

- oauth_callback

Userの同意を得たあとにService ProviderがUserをリダイレクトする先のURLです。 Consumerはcallbackされない、またはなんらかの理由によってcallback URLが確率されない場合、このParameterの値には「oob」を入れる必要があります（MUST）。「oob」はout of band configurationのことを示しています。また、値を入れる際には大文字、小文字が区別されるため注意してください。

 

- Additional parameters

追加のパラメータ。個別にService Providerによって定義されます

 

 

6.1.2 Service Providerが未同意のRequest Tokenを発行する

 

Service Providerは、Requestに含まれる署名とConsumer Keyを確認します。これが正しく確認できた場合は、「5.3 Service Provider Response Parameters」で定義されている方式で、Request TokenとToken SecretをHTTP response bodyに含めてConsumerに返します。Service ProviderはUserが同意しない限り、Request TokenとAccess Tokenを交換しないようにしておく必要があります（MUST）。

 

Service ProviderからのResponseには以下のParameterが含まれます。

 

- oauth_token

Request Tokenそのものです

 

- oauth_token_secret

Token Secretです

 

- oauth_callback_confirmed

常に「true」をセットしてください。Service Provider側でcallbackの値がすでに確認済みであることを、Consumer側で知るために利用します。

 

- Additional parameters

追加のパラメータ。個別にService Providerによって定義されます

 

Requestが正しく確認できていなかったり、または他の何らかの理由によって失敗した場合、Service Providerは「10. HTTP Response Codes」で定義されている通りに、適切なHTTP Responseを返すべきです（SHOULD）。

 

Service Providerは「5.3 Service Provider Response Parameters」で定められているとおり、なぜRequestが失敗したのかの詳細をHTTP response bodyに含めて返してもかまいません（MAY）

 

 

6.2 Userの同意を得る

 

Consumerは、Userによって同意を得るまではRequest Tokenを使うことはできません。同意を得るまでの流れは以下のとおりです。

 

 

6.2.1 ConsumerがUserをService Providerへ遷移させる

 

Request TokenをAccess Tokenに変換するためにはUserの同意が必要であり、そのためにConsumerはUserをService Providerへ遷移させる必要があります（MUST）。ConsumerはService ProviderのUser Authentication URLに対して、以下のParameterを含めたHTTP GET requestを送ります。

 

- oauth_token

オプション。前のステップで取得したRequest Token。Service Providerはこの値を必須とすることもでき（REQUIRED）、値が無い場合でもUser自身に直接手動で入力させる方法を取ることもできます。

 

- Additional Parameters

追加のパラメータ。個別にService Providerによって定義されます

 

request URLが作成されると、ConsumerはUserをブラウザ上でそのURLへリダイレクトします。

Consumerが自動的にHTTP redirectionを行えない場合、ConsumerはUserに対して、手動でrequest URLへアクセスするように案内することもできます。

 

Note: Consumerのアプリケーションが携帯端末、セットアップボックス上で動作していることを、Service Providerがあらかじめ知っている場合は、User Authorization URLやRequest Tokenを手動入力に適したものにするべきです（SHOULD）。

 

 

6.2.2 Service ProviderはUserを認証し、同意を得る

 

Service ProviderはUserを認証して、同意をする必要があります。OAuthの仕様上、Service Providerは特定の認証方式に縛られていませんが、以下のことに従ってください。

 

- Service ProviderはUserに同意を得る前にそのUserを認証しておく必要があります（MUST）。Userがまだ認証をしていない場合は認証画面を出してもかまいません（MAY）

 

- Service Providerは、ConsumerがUserの保護されたリソースにアクセスしようとしていることをUserに表示します。その際には、どの期間保護されたリソースにアクセスができるかの情報も明示します。この情報にはService Provider固有の情報を含んでもかまいません（MAY）

 

- Service ProviderがConsumerに対して、Userの代わりに保護されたリソースへのアクセスすることについては、Userが同意、または非同意のどちらも選択できるようにしておく必要があります（MUST）。Userが非同意を選択した場合、Service ProviderはConsumerに対してアクセス権限を付与してはいけません（MUST NOT）

 

同意の際に、Consumer Keyなどの識別子を利用してConsumer自身の情報を明示する場合は、Service ProviderはそのConsumerが本当に信頼できるものであるかは保証できないことを明示する必要があります（MUST）。Service ProviderがConsumerの信頼性を保証することについてはこの仕様の範囲外です。

 

 

6.2.3 Service ProviderはUserをConsumerへ遷移させる

 

Request Tokenに同意を行ったUserと同じUserが処理を終えてConsumerに戻ってきたことを確認するためService Providerは確認用コード（同意の処理を完了するために必要になる、User経由でConsumerに渡される推測不能な値）を生成する必要があります（MUST）。  Consumerがcallback URLを指定してきている場合（「6.1.1. ConsumerがRequest Tokenを取得する」で説明されているoauth_callback parameterのこと）、Service ProviderはHTTP request URLを作成し、Userをcallback URLの値で指定されているURLに、以下のParameterをつけたうえでWebブラウザ上で遷移させます。 

 

<oauth_token>

Userが同意、もしくは非同意したRequest Token

 

<oauth_verifier>

確認用コード

 

このcallback URLにはConsumerによって付与されたクエリパラメータを含んでもかまいません（MAY）。Service Providerはそのパラメータを変更せず、OAuth parametersに含むようにしなくてはなりません（MUST）。

 

Consumerがcallback URLを指定してこない場合、Service Providerは確認用コードを表示し（SHOULD）、User自身が手動でConsumerへ通知して同意の処理を完了するよう指示します。もしService ProviderがConsumerのサービスが携帯端末やset-top box上で提供されていることをあらかじめ知っている場合には、確認用コードは手動で入力するのに適切な値にしておくべきです（SHOULD）

 

 

6.3 Access Tokenの取得

 

Consumerは保護されたリソースへアクセスできるAccess TokenをRequest Tokenと交換することで取得します。Access Tokenを取得するステップは以下のとおりです。

 

 

6.3.1 ConsumerがAccess Tokenを要求する

 

Request TokenとToken Secretは、Access TokenとToken Secretと交換されなくてはいけません（MUST）

 

ConsumerはService ProviderのAccess Token URLに対して、HTTP requestを作成します。Service ProviderのドキュメントにはそのrequestのHTTPメソッドに関する説明があり、原則的にはHTTP POSTを推奨します（RECOMMENDED）。Requestは「9. Signing Requests」に記載されている方法で署名されている必要があり、次のパラメータを含みます。

 

- oauth_consumer_key

Consumer Keyのことです

 

- oauth_token

以前に取得したRequest Token

 

- oauth_signing_method

Consumerがrequestに署名する方式

 

- oauth_signature

「9. Signing Requests」で説明されている署名

 

- oauth_timestamp

「8. Nonceとタイムスタンプ」で説明されているタイムスタンプ

 

- oauth_nonse

「8. Nonceとタイムスタンプ」で説明されているNonce

 

- oauth_version

オプション。このパラメータの値が含まれる場合は、必ず「1.0」である必要があります（MUST）。値が含まれない場合は、Service Provider側がOAuth Core 1.0であると想定しなくてはなりません（MUST）。Service ProviderがOAuth Core 1.0以外である場合の値は、現在の仕様ではまだ定義されていません

 

-oauth_verifier

Service ProviderがUserをConsumerへ遷移させる際に利用する、Service Providerから受け取った確認用コード。

 

Access Tokenのrequestを送る際には、Service Provider固有の追加パラメータを付与してはいけません。これはTokenに関する情報はUserの同意前にすべて明示されておくようにするためです。

 

 

6.3.2 Service ProviderがAccess Tokenを発行する

 

Service Providerは以下の確認を行う必要があります。

 

- requestの署名が正しく確認できたか

- Request TokenがすでにAccess Tokenと交換されたものでないか

- Request TokenがConsumer Keyと合ってるいるか

- Consumerから受け取った確認用コードが正しく確認できたか

 

これらの確認ができれば、Service ProviderはAccess TokenとToken Secretを作成し、「5.3 Service Provider Response Parameters」で説明されている方法で、HTTP response bodyに含めてConsumerに返します。Access TokenとToken SecretはConsumer側に保管され、Userの保護されたリソースへアクセスする際に利用されます。このresponseには以下のパラメータが含まれます。

 

- oauth_token

Access Token

 

- oauth_token_secret

Token Secret

 

- Additional parameters

追加のパラメータ。個別にService Providerによって定義されます

 

Requestが正しく確認できなかったり、または他の何らかの理由によって失敗した場合、Service Providerは「10. HTTP Response Codes」で定義されているとおりに、適切なHTTP Responseを返すべきです（SHOULD）。

 

Service Providerは「5.3 Service Provider Response Parameters」で定められている通り、なぜRequestが失敗したのかの詳細をHTTP response bodyに含めて返してもかまいません（MAY）

 

 

7. 保護されたリソースへのアクセス

 

Access TokenとToken Secretの取得に成功した後、ConsumerはUserに代わって保護されたリソースへアクセスできるようになります。

 

また、このRequestは「9. Singing Requests」にしたがって必ず署名がされている必要があり（MUST）、以下のParameterを含みます。

 

- oauth_consumer_key

Consumer Keyのことです

 

- oauth_token

Access Token

 

- oauth_signature_method

Consumerがrequestに署名する方式

 

- oauth_signature

「9. Singing Requests」で説明されている署名

 

- oauth_timestamp

「8. Nonceとタイムスタンプ」で説明されているタイムスタンプ

 

- oauth_nonce

「8. Nonceとタイムスタンプ」で説明されているNonce

 

- oauth_version

オプション。このパラメータの値が含まれる場合は、必ず「1.0」である必要があります（MUST）。値が含まれない場合は、Service Provider側がOAuth Core 1.0であると想定しなくてはなりません（MUST）。Service ProviderがOAuth Core 1.0以外である場合の値は、現在の仕様ではまだ定義されていません

- Additional parameters

追加のパラメータ。個別にService Providerによって定義されます

 

 

8. Nonceとタイムスタンプ

 

Service Providerが特に指定しない限り、タイムスタンプは1970年１月１日00時00分00秒からの経過秒数で表現されます。タイムスタンプの値は必ず正の整数である必要があり（MUST）、それ以前のrequestのタイムスタンプと同じ、または大きな値である必要があります（MUST).

 

Consumerは、すべてのrequestとその署名に対してNonceを生成するべきです（SHALL）。Nonceはランダムな文字列で、それぞれのrequestに対してユニークになるように生成します。Service ProviderはNonceを使うことにより、そのrequestが以前にすでに処理されたものであるかを判別することができ、HTTPなどのセキュアでないチャンネル上でのリプレイアタックを防ぐのに役立ちます。

 

 

9. Requestの署名

 

Consumerは、すべてのToken Request、保護されたリソースへのrequestに署名をつけ、Service Providerにその署名が正しいかを確認してもらう必要があります（MUST）。requestに署名をする目的は、Service Providerに利用を認められていない開発者が、Token requestや保護されたリソースへのrequestを作成して送信することを防ぐことにあります。署名の際にConsumer Secret、Token Secretは正しく確認できるような値でエンコードされ、requestのなかに含む必要があります。

 

個々の状況により署名方式は変わる場合があるため、OAuthでは特定の署名方式までは定義しません。プロトコルではHMAC-SHA1、RSA-SHA1、プレーンテキストの３つの署名方式を定義していますが、Service Providerは固有の署名方式で実装することができます。特定の署名方式を推奨することは仕様の範囲外とします。

 

Consumerはoauth_signature_method parameterで使用する署名方式を宣言し、署名を作成して、そしてoauth_signature parameterにそれを格納します。Service Providerはそれぞれ宣言された署名方式に沿ってその署名を確認します。Service Providerは署名を確認する際にnonceをチェックして、以前に同じrequestが来ていなかったかを確認すべきです（SHOULD）

 

署名確認の際には、oauth_signature_parameterを除いて、requestのparameter_nameや値を変更してはなりません（MUST NOT）。

 

 

9.1 Signature Base String

 

Signature Base Stringは、一連のrequestの要素を復元できるひとつの文字列です。この文字列はハッシュ化または署名アルゴリズムの入力値として使います。Signature Base Stringを生成する標準的な例として、HMAC-SHA1による署名アルゴリズムを説明します。Signature Base Stringを作成する際には、「5.1 Parameter Encoding」での説明内容にしたがってエンコードされている必要があります。

 

 

9.1.1 Request Parameterの正規化

 

request parameterは収集された後にソートされ、さらに連結されて文字列として正規化されます。

 

- OAuth HTTP Authorization headerのrealm parameterを除いたparameterである

- parameterはHTTP POSTのrequest bodyに含まれる（application/x-www-form-urlencodedのcontent-typeのもの）

- HTTP GET parameterは、URLのクエリ部分に追加される（[RFC3986]の規定に準拠）

 

oauth_signature parameterは除外されている必要があります（MUST）

 

parameterは次の流れで正規化されます

 

1. parameterはparameter nameでソートされます。parameter nameはアルファベット順で並び、parameter nameが同じ文字列の場合は、その値にしたがってアルファベット順にソートします。たとえば、

 

a=1, c=hi%20there, f=25, f=50, f=a, z=p, z=t

 

2. parameterはソートされた後、ひとつの文字列に連結されます。それぞれのparameterにおいて、parameter nameとその値の間は「=」（ASCII code 61)で区切られ、それは値の中身がの場合でも同様です。parameter nameと値のセットそれぞれについては、「&」（ASCII code 38）によって区切られます。具体的には下記のようになります。

 

a=1&c=hi520there&f=25&f=50&f=a=&z=p&z=t

 

 

9.1.2 Request URLの生成

 

Signature Base Stringはrequest absolute URLを含み、特定のエンドポイントと署名を結びつけます。Signature Base Stringで使われるURLは、scheme、authority、pathを含む必要があり（MUST）、[RFC3986]section3の規定に従ってクエリやフラグメントを除く必要があります（MUST）

 

もしabsolute request URLが、Service Providerで利用できない場合（Consumerでは常に利用できるが）、使用されているschemeとHTTP host header、HTTP request URLから作成することができます。もしHost headerが利用出来ない場合、Service Providerはドキュメントなどに指定したホスト名をConsumerとの通信に使うべきです（SHOULD）

 

Service Providerは、URLの正規化の曖昧さを取り除くため、Signature Base Stringで使われるURLの形式をドキュメントに記載するべきです（SHOULD）。特に指定がない場合、URL schemeとauthorityは小文字で、かつポート番号を含んでいる必要があります（MUST）。ただし、そこではhttpデフォルトのポート番号80と、httpsデフォルトのポート番号443に限っては含まないようにする必要があります（MUST）。

 

例としては以下のようなrequestの場合、

 

          HTTP://Example.com80/resource?id=123

 

Signature Base Stringは下記のようになります。

 

http://example.com/resource

 

 

9.1.3 Request 要素を連結する

 

requestの要素を連結する場合、以下の各要素を連結する必要があります（MUST）。各要素は「5.1 Parameter Encoding」での説明にしたがってエンコードされており、要素の中身が空の場合でもそれぞれの要素の間は「&」（ASCII code 38）で区切らなくてはなりません。

 

 

1. requestに使われたHTTP request method。値は大文字である必要があります（MUST）。例としては、HEAD、GET、POSTなどがあります。

 

2. 「9.1.2 Construct Request URL」で説明されているrequest URL

 

3. 「9.1.1 Normalize Request Parameters」で説明されている正規化されたrequest parameters string

 

9.2 HMAC-SHA1

 

HMAC-SHA1は、[RFC2104]で規定されている署名アルゴリズムを使う署名方式です。この規定でSignature Base Stringはテキストで、keyはConsumer SecretとToken Secretを連結した値（それぞれ「5.1 Parameter Encoding」で説明された方式で最初にエンコードをする）となり、これらは「&」（ASCII code 38）によって区切られます。（値が空の場合でも）

 

 

9.2.1. 署名の生成

 

oauth_signatureは、整数で計算した10進数の文字列です。はじめに[RFC2045]section6.8で規定されているbase64エンコードによりエンコードを行い、その後「5.1 Parameter Encoding」に記載されている方式でエンコードします。

 

9.2.2 署名の確認

 

Service Providerはまず自身で新しく10進数でrequestの署名を作成し、Consumerから渡された署名を「5.1 Parameter Encoding」で説明された方式でURLデコードを行い、次に[RFC2045]section 6.8で規定されている方式に従ってbase64デコードを行ったものと一致するかを比較します。この署名はConsumerから渡されるrequest parameterと、Service Providerが保存しているConsumer SecretとToken Secretから生成されます

 

 

9.3 RSA-SHA1

 

RSA-SHA1は、[RFC3447]section8.2で規定されているRSASSA-PKCS1-v1_5 署名アルゴリズムに従って利用され、EMSA-PKCS1-v1_5のハッシュ化にSHA-1を利用します。これはConsumerからService Providerに対して、RSA公開鍵が確実な方法で提供されていることを前提とし、その提供方法についてはこの仕様の範囲外とします。

 

 

9.3.1 署名の生成

 

Signature Base Stringは、[RFC3447]section 8.2.1の規定に従って、ConsumerのRSA秘密鍵によって署名されます。「K」にはConsumerのRSA秘密鍵、「M」にはSignature Base String、「S」には署名の検証結果が10進数で入ります。

 

          S = RSASSA-PKCS1-V1_5-SIGN(K,M)

 

まずはじめにoauth_signatureを[RFC2045]section 6.8の規定に従ってbase64エンコードし、それから「5.1 Parameter Encoding」で説明されているURLエンコードを行った後、「S」にセットします。

 

 

9.3.2 署名の確認

 

Service Providerは[RFC3447]section 8.2.2の規定に従って署名を確認します。「(n,e)」にはConsumerのRSA公開鍵、「M」にはSignature Base String、「S」にはoauth_signature valueの文字列が10進数で入ります。

 

          RSASSA-PKCS1-V1_5-VERIFY((n,e),M,S)

 

 

9.4 PLAINTEXT

 

PLAINTEXTでの署名方式を利用する場合は、セキュリティ的に保護されていないためHTTPSなどのセキュアなチャンネルを利用するべきです（SHOULD）。これはSignature Base Stringではありません。

 

9.4.1 署名の生成

 

oauth_signatureはConsumer SecretとToken Secretの値をエンコードして連結したものです。「&」（ASCII code 38）によって連結され、値が空の場合も連結されます。ここで得られた結果はさらにもう一度エンコードする必要があります（MUST）。

 

以下の例では、Consumer Secretの値が「djr9rjt0jd78jf88」であり、３つの異なるToken Secretを使う場合にoauth_signatureの値がどのようになるかを表しています。

 

     jjd999tj88uiths3:

           oauth_signature=djr9rjt0jd78jf88%26jjd999tj88uiths3

     jjd99$tj88uiths3:

           oauth_signature=djr9rjt0jd78jf88%26jjd99%2524tj88uiths3

     Empty:

           oauth_signature=djr9rjt0jd78jf88%26

 

 

9.4.2 署名の確認

 

Service ProviderはConsumer SecretとToken Secretから署名を取り出し、Service Provider側で保存している署名と一致するかを確認します。

 

 

10. HTTP Response Codes

 

ここでの内容はRequest TokenとAccess Tokenに対して適用されます。Service Providerは原則的に、[RFC2616]section 10で規定されている内容に従ってresponse codeを利用するべきです（SHOULD）。

Service ProviderがConsumerのリクエストを拒否する場合は、HTTP 400 Bad RequestまたはHTTP 401 Unauthorizedを返すべきです（SHOULD）

 

• HTTP 400 Bad Request
  • Unsupported parameter
  • Unsupported signature method
  • Missing required parameter
  • Duplicated OAuth Protocol Parameter
• HTTP 401 Unauthorized
  • Invalid Consumer Key
  • Invalid / expired Token
  • Invalid signature
  • Invalid / used nonce

 

※11.は省略

 

 

原典はOAuth Core 1.0 Revision A（oauth.net）

 

http://oauth.net/core/1.0a