この仕様は、OAuth Core 1.0 Revision A によって2009年6月24日に廃止されました。これは、セッション固定攻撃に対処するためです。 OAuth Core 1.0 Revision A 仕様は、提案されている IETF ドラフト draft-hammer-oauth によって廃止されつつあります。 このドラフトは現在、RFCとして公開される前に IESG の承認を保留中です。
実装者は、この仕様の代わりに RFC 6749: OAuth 2.0 認可フレームワーク を使用する必要があります。.
2007年12月4日
OAuth プロトコルは、ウェブサイトまたはアプリケーション（コンシューマー）が、ユーザーがサービスプロバイダーの資格情報をコンシューマーに開示することなく、APIを介してウェブサービス（サービスプロバイダー）から保護されたリソースにアクセスできるようにします。 より一般的に言えば、OAuth は、API 認証のための自由に実装可能な汎用的な方法論を作成します。
使用例としては、印刷サービス printer.example.com（コンシューマー）が、ユーザーが printer.example.com に photos.example.net の資格情報を提供することなく、photos.example.net（サービスプロバイダー）に保存されているプライベート写真にアクセスできるようにすることが挙げられます。
OAuth は、特定のユーザーインターフェースまたはインタラクションパターンを必要とせず、サービスプロバイダーがユーザーを認証する方法も指定しないため、OpenID のように認証資格情報がコンシューマーで利用できない場合にプロトコルが最適です。
OAuth は、委任された Web サービス認証のエクスペリエンスと実装を、単一のコミュニティ主導のプロトコルに統合することを目指しています。 OAuth は、さまざまな Web サイトによって個別に実装されてきた既存のプロトコルとベストプラクティスに基づいています。 大手プロバイダーと小規模プロバイダーの両方によってサポートされているオープンスタンダードは、アプリケーション開発者とそれらのアプリケーションのユーザーの両方に一貫した信頼できるエクスペリエンスを促進します。
この仕様は、https://oauth.dokyumento.jp/license/core/1.0 で入手可能なOAuth 非主張契約およびOAuth 仕様 1.0 の著者貢献ライセンスに基づいて利用可能です。著作権は、http://creativecommons.org/licenses/by-sa/3.0 で入手可能なクリエイティブ・コモンズ 表示 - 継承 3.0 ライセンスの条項に基づいてライセンスされています。
1. 著者
2. 表記と規則
3. 定義
4. ドキュメントと登録
4.1. リクエスト URL
4.2. サービスプロバイダー
4.3. コンシューマー
5. パラメータ
5.1. パラメータエンコーディング
5.2. コンシューマーリクエストパラメータ
5.3. サービスプロバイダーレスポンスパラメータ
5.4. OAuth HTTP 認証スキーム
6. OAuth を使用した認証
6.1. 未承認のリクエストトークンの取得
6.2. ユーザー承認の取得
6.3. アクセストークンの取得
7. 保護されたリソースへのアクセス
8. ナンスとタイムスタンプ
9. リクエストへの署名
9.1. 署名ベース文字列
9.2. HMAC-SHA1
9.3. RSA-SHA1
9.4. PLAINTEXT
10. HTTPレスポンスコード
付録 A. 付録 A - プロトコルの例
付録 A.1. ドキュメントと登録
付録 A.2. リクエストトークンの取得
付録 A.3. ユーザー承認のリクエスト
付録 A.4. アクセストークンの取得
付録 A.5. 保護されたリソースへのアクセス
付録 B. セキュリティに関する考慮事項
付録 B.1. 資格情報とトークン交換
付録 B.2. PLAINTEXT 署名方法
付録 B.3. リクエストの機密性
付録 B.4. 偽のサーバーによるスプーフィング
付録 B.5. 認証済みコンテンツのプロキシとキャッシング
付録 B.6. 資格情報のプレーンテキストストレージ
付録 B.7. コンシューマーシークレットの秘密性
付録 B.8. フィッシング攻撃
付録 B.9. アクセスリクエストのスコープ
付録 B.10. シークレットのエントロピー
付録 B.11. サービス拒否/リソース枯渇攻撃
付録 B.12. 暗号攻撃
付録 B.13. 署名ベース文字列の互換性
11. 参考文献
§ 著者のアドレス
このドキュメントにおけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、[RFC2119] (Bradner, B., “RFC で使用する要求レベルを示すキーワード,” .) に記載されているように解釈されるものとします。ドメイン名の例では、[RFC2606] (Eastlake, D. and A. Panitz, “予約済みトップレベル DNS 名,” .) を使用しています。
- サービスプロバイダー
- OAuth を介したアクセスを許可する Web アプリケーション。
- ユーザー
- サービスプロバイダーにアカウントを持つ個人。
- コンシューマー
- OAuth を使用してユーザーの代わりにサービスプロバイダーにアクセスする Web サイトまたはアプリケーション。
- 保護されたリソース
- 認証を通じてコンシューマーがアクセスできる、サービスプロバイダーによって制御されるデータ。
- コンシューマー開発者
- コンシューマーを実装する個人または組織。
- コンシューマーキー
- コンシューマーがサービスプロバイダーに自身を識別するために使用する値。
- コンシューマーシークレット
- コンシューマーがコンシューマーキーの所有権を確立するために使用する秘密。
- リクエストトークン
- コンシューマーがユーザーから承認を取得し、アクセストークンと交換するために使用する値。
- アクセストークン
- コンシューマーがユーザーのサービスプロバイダーの資格情報の代わりに使用して、ユーザーの代わりに保護されたリソースにアクセスするために使用する値。
- トークンシークレット
- コンシューマーが特定のトークンの所有権を確立するために使用する秘密。
- OAuth プロトコルパラメータ
- で始まる名前のパラメータoauth_.
OAuth には、コンシューマー（ユーザーではなく）をサービスプロバイダーに対して認証するコンシューマーキーと一致するコンシューマーシークレットが含まれています。 コンシューマー固有の識別により、サービスプロバイダーはコンシューマーへのアクセスレベル（リソースへのスロットリングされていないアクセスなど）を変化させることができます。
サービスプロバイダーは、コンシューマーシークレットがコンシューマーとサービスプロバイダー以外の誰もアクセスできないことがわかっていない限り、コンシューマーシークレットをコンシューマーのIDを検証する方法として依存すべきではありません。 コンシューマーシークレットは、空の文字列である場合があります（たとえば、コンシューマーの検証が必要ない場合、またはRSAなどの他の手段で検証が達成された場合）。
OAuth は、3つのリクエスト URL を定義します。
- リクエストトークン URL
- セクション 6.1 (未承認のリクエストトークンの取得) に記載されている、未承認のリクエストトークンを取得するために使用される URL。
- ユーザー承認 URL
- セクション 6.2 (ユーザー承認の取得) に記載されている、コンシューマーアクセスに対するユーザー承認を取得するために使用される URL。
- アクセストークン URL
- セクション 6.3 (アクセストークンの取得) に記載されている、ユーザー承認済みリクエストトークンをアクセストークンと交換するために使用される URL。
3つの URL は、スキーム、権限、およびパスを含める必要があり、[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) セクション 3 で定義されているように、クエリとフラグメントを含めることができます。リクエスト URL クエリには、OAuth プロトコルパラメータを含めてはいけません。 たとえば
http://sp.example.com/authorize
サービスプロバイダーの責任は、コンシューマー開発者がコンシューマーキーとコンシューマーシークレットを確立できるようにすることです。 これらをプロビジョニングするプロセスと要件は、サービスプロバイダーに完全に委ねられます。
サービスプロバイダーのドキュメントには、次のものが含まれています。
コンシューマー開発者は、サービスプロバイダーとコンシューマーキーとコンシューマーシークレットを確立する必要があります。 コンシューマー開発者は、登録時にサービスプロバイダーに追加情報を提供するよう要求される場合もあります。
OAuth プロトコルパラメータの名前と値は大文字と小文字が区別されます。 各 OAuth プロトコルパラメータは、リクエストごとに複数回出現してはならず、特に明記されていない限り必須です。
すべてのパラメータ名と値は、[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) パーセントエンコーディング（%xx）メカニズムを使用してエスケープされます。予約されていない文字セットに含まれない文字（[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) セクション 2.3）はエンコードする必要があります。予約されていない文字セット内の文字はエンコードしないでください。 エンコーディングの16進文字は大文字である必要があります。 テキストの名前と値は、[RFC3629] (Yergeau, F., “UTF-8, Unicode および ISO 10646 の変換形式,” .) に従ってパーセントエンコードする前に、UTF-8オクテットとしてエンコードする必要があります。
unreserved = ALPHA, DIGIT, '-', '.', '_', '~'
OAuthプロトコルパラメータは、優先度の高い順に、以下の3つの方法のいずれかでコンシューマからサービスプロバイダに送信されます。
これらの定義された方法に加えて、将来の拡張では、OAuthプロトコルパラメータを送信するための代替方法が記述される場合があります。他のリクエストパラメータを送信する方法は未定義のままですが、OAuth HTTP Authorization Scheme (OAuth HTTP Authorization Scheme)ヘッダーを使用すべきではありません。
レスポンスパラメータは、トークンやその他の情報をコンシューマに返すために、サービスプロバイダによってHTTPレスポンスボディで送信されます。パラメータ名と値は、まずパラメータエンコーディング (パラメータエンコーディング)に従ってエンコードされ、[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)の2.1項で定義されているように、「&」文字（ASCIIコード38）で連結されます。例:
oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=xyz4992k83j47x0b
このセクションでは、OAuthをサポートするための[RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .)拡張機能を定義します。標準のHTTPAuthorizationとWWW-Authenticateヘッダーを使用してOAuthプロトコルパラメータを渡します。
サービスプロバイダは、HTTPAuthorizationヘッダーを受け入れることが推奨されます。コンシューマは、OAuthAuthorizationヘッダーでOAuthプロトコルパラメータを送信できる必要があります。
拡張認証スキーム（[RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .)で定義されているように）はOAuthであり、大文字と小文字は区別されません。
OAuthプロトコルパラメータは、Authorizationヘッダーで次のように送信されます。
例:
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"
サービスプロバイダは、保護されたリソースに対するコンシューマのリクエストに応じて、OAuth HTTPWWW-Authenticateヘッダーを返すことで、拡張機能のサポートを示すことができます。[RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .)に従って、このようなレスポンスには、追加のHTTPWWW-Authenticateヘッダーを含めることができます。
例:
WWW-Authenticate: OAuth realm="http://sp.example.com/"
realmパラメータは、[RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .)の1.2項に従って保護領域を定義します。
OAuth認証は、ユーザーが自分の認証情報をコンシューマと共有することなく、保護されたリソースへのアクセスを許可するプロセスです。OAuthは、保護されたリソースリクエストでユーザーの認証情報の代わりにサービスプロバイダによって生成されたトークンを使用します。このプロセスでは、2種類のトークンを使用します。
- リクエストトークン
- ユーザーが保護されたリソースへのアクセスを承認するように要求するためにコンシューマによって使用されます。ユーザーによって承認されたリクエストトークンはアクセストークンと交換され、1回のみ使用する必要があり、他の目的で使用してはなりません。リクエストトークンの有効期間を制限することが推奨されます。
- アクセストークン
- ユーザーに代わって保護されたリソースにアクセスするためにコンシューマによって使用されます。アクセストークンは、特定の保護されたリソースへのアクセスを制限したり、有効期間を制限したりできます。サービスプロバイダは、ユーザーがアクセストークンを取り消すことができるようにする必要があります。保護されたリソースにアクセスするには、アクセストークンのみを使用する必要があります。
OAuth認証は、次の3つのステップで実行されます。
コンシューマは、サービスプロバイダにトークンを発行するように依頼することで、未承認のリクエストトークンを取得します。リクエストトークンの唯一の目的は、ユーザーの承認を受け取ることだけであり、アクセストークンを取得するためにのみ使用できます。リクエストトークンのプロセスは次のとおりです。
リクエストトークンを取得するために、コンシューマはHTTPリクエストをサービスプロバイダのリクエストトークンURLに送信します。サービスプロバイダのドキュメントでは、このリクエストのHTTPメソッドが指定されており、HTTP POSTが推奨されます。リクエストは署名され、次のパラメータが含まれている必要があります。
- oauth_consumer_key
- コンシューマキー。
- oauth_signature_method
- コンシューマがリクエストの署名に使用した署名メソッド。
- oauth_signature
- リクエストの署名 (リクエストの署名)で定義されている署名。
- oauth_timestamp
- ナンスとタイムスタンプ (ナンスとタイムスタンプ)で定義されているとおり。
- oauth_nonce
- ナンスとタイムスタンプ (ナンスとタイムスタンプ)で定義されているとおり。
- oauth_version
- オプション。存在する場合は、値は 1.0 である必要があります。サービスプロバイダは、このパラメータが存在しない場合は、プロトコルのバージョンが1.0であると想定する必要があります。サービスプロバイダの1.0以外の値への応答は未定義のままです。
- 追加パラメータ
- サービスプロバイダによって定義された追加パラメータ。
サービスプロバイダは、署名とコンシューマキーを検証します。成功すると、リクエストトークンとトークンシークレットを生成し、サービスプロバイダのレスポンスパラメータ (サービスプロバイダのレスポンスパラメータ)で定義されているように、HTTPレスポンスボディでコンシューマに返します。サービスプロバイダは、ユーザー承認の取得 (ユーザー承認の取得)でユーザーが正常にアクセスを許可するまで、リクエストトークンがアクセストークンと交換できないようにする必要があります。
レスポンスには次のパラメータが含まれます。
- oauth_token
- リクエストトークン。
- oauth_token_secret
- トークンシークレット。
- 追加パラメータ
- サービスプロバイダによって定義された追加パラメータ。
リクエストが検証に失敗した場合、または他の理由で拒否された場合、サービスプロバイダはHTTPレスポンスコード (HTTPレスポンスコード)で定義されているように、適切なレスポンスコードで応答する必要があります。サービスプロバイダは、リクエストが拒否された理由に関する詳細をサービスプロバイダのレスポンスパラメータ (サービスプロバイダのレスポンスパラメータ)で定義されているように、HTTPレスポンスボディに含めることができます。
コンシューマは、ユーザーによって承認されるまでリクエストトークンを使用できません。ユーザー承認の取得には、次のステップが含まれます。
コンシューマがリクエストトークンをアクセストークンと交換できるようにするには、コンシューマはユーザーをサービスプロバイダに誘導して、ユーザーから承認を得る必要があります。コンシューマは、次のパラメータを使用して、サービスプロバイダのユーザー承認URLへのHTTP GETリクエストを構築します。
- oauth_token
- オプション。前のステップで取得したリクエストトークン。サービスプロバイダは、このパラメータを必須として宣言するか、パラメータなしでユーザー承認URLへのリクエストを受け入れることができます。この場合、ユーザーに手動で入力するように促します。
- oauth_callback
- オプション。コンシューマは、ユーザー承認の取得 (ユーザー承認の取得)が完了したときに、サービスプロバイダがユーザーをコンシューマにリダイレクトするために使用するURLを指定できます。
- 追加パラメータ
- サービスプロバイダによって定義された追加パラメータ。
リクエストURLが構築されると、コンシューマはユーザーのWebブラウザを介してユーザーをURLにリダイレクトします。コンシューマが自動HTTPリダイレクトを実行できない場合、コンシューマは構築されたリクエストURLに手動で移動する方法をユーザーに通知する必要があります。
注：サービスプロバイダがコンシューマがモバイルデバイスまたはセットトップボックスで実行されていることを認識している場合、サービスプロバイダはユーザー承認URLとリクエストトークンが手動入力に適していることを確認する必要があります。
サービスプロバイダは、詳細に示されているように、ユーザーの身元を確認し、同意を求めます。OAuthは、サービスプロバイダがユーザーを認証する方法を指定しません。ただし、必須のステップのセットを定義します。
コンシューマーキーに基づいてコンシューマーに関する識別情報をユーザーに表示する際、サービスプロバイダーは、コンシューマーの真の身元を保証できない場合は、その旨をユーザーに通知しなければなりません。サービスプロバイダーがユーザーに通知する方法と、身元保証の質は、この仕様の範囲外です。
ユーザーがサービスプロバイダーで認証を行い、コンシューマーアクセスを許可すると、リクエストトークンが承認され、アクセストークンと交換できる状態になったことをコンシューマーに通知する必要があります。ユーザーがアクセスを拒否した場合、リクエストトークンが取り消されたことをコンシューマーに通知してもかまいません。
コンシューマーがコールバックURLをoauth_callback(コンシューマーがユーザーをサービスプロバイダーに誘導する (コンシューマーがユーザーをサービスプロバイダーに誘導する)で説明されているように) に提供した場合、サービスプロバイダーはHTTP GETリクエストURLを構築し、次のパラメーターを使用してユーザーのWebブラウザーをそのURLにリダイレクトします。
- oauth_token
- ユーザーが承認または拒否したリクエストトークン。
コールバックURLには、コンシューマーが提供したクエリパラメーターを含めることができます。サービスプロバイダーは、それらを変更せずに保持し、既存のクエリにoauth_tokenパラメーターを追加する必要があります。
コールバックURLが提供されなかった場合、サービスプロバイダーは、認証が完了したことをユーザーに手動でコンシューマーに通知するように指示します。
コンシューマーは、リクエストトークンを、保護されたリソースにアクセスできるアクセストークンと交換します。アクセストークンの取得には、次のステップが含まれます。
リクエストトークンとトークンシークレットは、アクセストークンとトークンシークレットと交換する必要があります。
アクセストークンをリクエストするために、コンシューマーはサービスプロバイダーのアクセストークンURLにHTTPリクエストを送信します。サービスプロバイダーのドキュメントでは、このリクエストのHTTPメソッドを指定しており、HTTP POSTが推奨されています。リクエストは、リクエストの署名 (リクエストの署名)に従って署名する必要があり、次のパラメーターが含まれます。
- oauth_consumer_key
- コンシューマキー。
- oauth_token
- 以前に取得したリクエストトークン。
- oauth_signature_method
- コンシューマがリクエストの署名に使用した署名メソッド。
- oauth_signature
- リクエストの署名 (リクエストの署名)で定義されている署名。
- oauth_timestamp
- ナンスとタイムスタンプ (ナンスとタイムスタンプ)で定義されているとおり。
- oauth_nonce
- ナンスとタイムスタンプ (ナンスとタイムスタンプ)で定義されているとおり。
- oauth_version
- オプション。存在する場合は、値は 1.0 である必要があります。サービスプロバイダは、このパラメータが存在しない場合は、プロトコルのバージョンが1.0であると想定する必要があります。サービスプロバイダの1.0以外の値への応答は未定義のままです。
すべてのトークン関連情報がユーザーの承認を求める前に存在するように、アクセストークンをリクエストする際には、追加のサービスプロバイダー固有のパラメーターは許可されません。
サービスプロバイダーは、次のことを確認する必要があります。
成功した場合、サービスプロバイダーはアクセストークンとトークンシークレットを生成し、サービスプロバイダーの応答パラメーター (サービスプロバイダーの応答パラメーター)で定義されているように、HTTP応答ボディでそれらを返します。アクセストークンとトークンシークレットはコンシューマーによって保存され、保護されたリソースリクエストに署名するときに使用されます。応答には、次のパラメーターが含まれます。
- oauth_token
- アクセストークン。
- oauth_token_secret
- トークンシークレット。
- 追加パラメータ
- サービスプロバイダによって定義された追加パラメータ。
リクエストが検証に失敗した場合、または他の理由で拒否された場合、サービスプロバイダはHTTPレスポンスコード (HTTPレスポンスコード)で定義されているように、適切なレスポンスコードで応答する必要があります。サービスプロバイダは、リクエストが拒否された理由に関する詳細をサービスプロバイダのレスポンスパラメータ (サービスプロバイダのレスポンスパラメータ)で定義されているように、HTTPレスポンスボディに含めることができます。
アクセストークンとトークンシークレットを正常に受信した後、コンシューマーはユーザーに代わって保護されたリソースにアクセスできます。リクエストは、リクエストの署名 (リクエストの署名)に従って署名する必要があり、次のパラメーターが含まれます。
- oauth_consumer_key
- コンシューマキー。
- oauth_token
- アクセストークン。
- oauth_signature_method
- コンシューマがリクエストの署名に使用した署名メソッド。
- oauth_signature
- リクエストの署名 (リクエストの署名)で定義されている署名。
- oauth_timestamp
- ナンスとタイムスタンプ (ナンスとタイムスタンプ)で定義されているとおり。
- oauth_nonce
- ナンスとタイムスタンプ (ナンスとタイムスタンプ)で定義されているとおり。
- oauth_version
- オプション。存在する場合は、値は1.0である必要があります。サービスプロバイダは、このパラメータが存在しない場合は、プロトコルのバージョンが1.0であると想定する必要があります。サービスプロバイダの1.0以外の値への応答は未定義のままです。
- 追加パラメータ
- サービスプロバイダによって定義された追加パラメータ。
サービスプロバイダーによって特に指定されていない限り、タイムスタンプは、1970年1月1日00:00:00 GMTからの秒数で表されます。タイムスタンプの値は正の整数でなければならず、以前のリクエストで使用されたタイムスタンプ以上でなければなりません。
コンシューマーは、そのタイムスタンプを持つすべてのリクエストに対して一意であるNonce値を生成する必要があります。nonceは、リクエストごとに一意に生成されるランダムな文字列です。nonceを使用すると、サービスプロバイダーは、リクエストが以前に送信されたことがないことを検証でき、リクエストが安全でないチャネル（HTTPなど）を介して送信された場合にリプレイ攻撃を防ぐのに役立ちます。
すべてのトークンリクエストと保護されたリソースリクエストは、コンシューマーによって署名され、サービスプロバイダーによって検証される必要があります。リクエストに署名する目的は、トークンリクエストまたは保護されたリソースリクエストを行う際に、不正な当事者がコンシューマーキーとトークンを使用するのを防ぐことです。署名プロセスは、コンシューマーシークレットとトークンシークレットを、リクエストに含まれる検証可能な値にエンコードします。
OAuthは特定の署名方法を義務付けていません。これは、各実装に固有の要件がある可能性があるためです。プロトコルは3つの署名方法を定義します。HMAC-SHA1, RSA-SHA1、およびPLAINTEXT、ただし、サービスプロバイダーは独自の方法を実装および文書化してもかまいません。特定の方法を推奨することは、この仕様の範囲外です。
コンシューマーは、oauth_signature_methodパラメーターで署名方法を宣言し、署名を生成して、oauth_signatureパラメーターに保存します。サービスプロバイダーは、各メソッドで指定されているように署名を検証します。コンシューマー署名を検証する場合、サービスプロバイダーは、以前のコンシューマーリクエストで使用されていないことを確認するために、リクエストnonceをチェックする必要があります。
署名プロセスでは、oauth_signatureパラメーターを除き、リクエストパラメーターの名前または値を変更してはなりません。
署名ベース文字列は、リクエスト要素を単一の文字列に一貫して再現可能に連結したものです。文字列は、ハッシュアルゴリズムまたは署名アルゴリズムの入力として使用されます。HMAC-SHA1署名方法は、署名アルゴリズムを使用して署名を生成するための署名ベース文字列の使用例と標準の両方を提供します。署名ベース文字列を作成する前に、すべてのリクエストパラメーターをパラメーターエンコーディング (パラメーターエンコーディング)で説明されているようにエンコードする必要があります。
リクエストパラメーターを収集し、ソートして、正規化された文字列に連結します
パラメーターはoauth_signature除外する必要があります。
パラメーターは、次のように単一の文字列に正規化されます。
a=1, c=hi%20there, f=25, f=50, f=a, z=p, z=t
a=1&c=hi%20there&f=25&f=50&f=a&z=p&z=t
署名ベース文字列には、署名を特定のエンドポイントに関連付けるリクエストの絶対URLが含まれます。署名ベース文字列で使用されるURLには、スキーム、権限、およびパスが含まれている必要があり、[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)セクション3で定義されているように、クエリとフラグメントを除外する必要があります。
絶対リクエストURLがサービスプロバイダーで利用できない場合（常にコンシューマーで利用可能）、使用されているスキーム、HTTPHostヘッダー、および相対HTTPリクエストURLを組み合わせることで構築できます。Hostヘッダーが利用できない場合、サービスプロバイダーは、ドキュメントまたはその他の手段でコンシューマーに伝達されたホスト名を使用する必要があります。
サービスプロバイダーは、URLの正規化によるあいまいさを回避するために、署名ベース文字列で使用されるURLの形式を文書化する必要があります。特に指定がない限り、URLスキームと権限は小文字で、ポート番号を含める必要があります。httpデフォルトポート80およびhttpsデフォルトポート443は除外する必要があります。
たとえば、リクエスト
HTTP://Example.com:80/resource?id=123
署名ベース文字列には、次のように含まれています
http://example.com/resource
次の項目は、単一の文字列に順番に連結する必要があります。各項目は、空の場合でも、エンコード (パラメーターエンコーディング)され、「&」文字（ASCIIコード38）で区切られます。
署名ベース文字列の例については、付録A.5.1 (署名ベース文字列の生成)を参照してください。
パラメーターはHMAC-SHA1署名方法は、[RFC2104] (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” .)で定義されているHMAC-SHA1署名アルゴリズムを使用します。ここで、署名ベース文字列はテキストであり、キーは、コンシューマーシークレットとトークンシークレットの連結された値（それぞれパラメーターエンコーディング (パラメーターエンコーディング)に従って最初にエンコード）であり、「&」文字（ASCIIコード38）で区切られます。空の場合でも同様です。
oauth_signatureは、計算されたダイジェストオクテット文字列に設定され、最初に[RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .)セクション6.8に従ってbase64でエンコードされ、次にパラメーターエンコーディング (パラメーターエンコーディング)に従ってURLエンコードされます。
サービスプロバイダーは、新しいリクエスト署名オクテット文字列を生成し、コンシューマーによって提供された署名と比較することでリクエストを検証します。最初にパラメーターエンコーディング (パラメーターエンコーディング)に従ってURLデコードし、次に[RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .)セクション6.8に従ってbase64デコードします。署名は、コンシューマーが提供したリクエストパラメーターと、サービスプロバイダーによって保存されたコンシューマーシークレットおよびトークンシークレットを使用して生成されます。
パラメーターはRSA-SHA1署名メソッドは、[RFC3447] (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” .)セクション8.2（PKCS#1としてより一般的に知られている）で定義されているRSASSA-PKCS1-v1_5署名アルゴリズムを、EMSA-PKCS1-v1_5のハッシュ関数としてSHA-1を使用して使用します。コンシューマーが、この仕様の範囲外の方法で、検証済みの方法でRSA公開鍵をサービスプロバイダーに提供していると想定されています。
署名ベース文字列は、[RFC3447] (Jonsson, J. と B. Kaliski, “公開鍵暗号標準 (PKCS) #1: RSA暗号; 仕様バージョン 2.1,” .) のセクション 8.2.1 に従って、コンシューマーの RSA 秘密鍵を使用して署名されます。ここで、Kは、コンシューマーの RSA 秘密鍵、Mは、署名ベース文字列、そしてSは、結果の署名オクテット文字列です。
S = RSASSA-PKCS1-V1_5-SIGN (K, M)
oauth_signatureは、次のように設定されます。Sまず、[RFC2045] (Freed, N. と N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .) のセクション 6.8 に従って base64 エンコードされ、次に パラメータエンコード (パラメータエンコード) に従って URL エンコードされます。
サービスプロバイダーは、[RFC3447] (Jonsson, J. と B. Kaliski, “公開鍵暗号標準 (PKCS) #1: RSA暗号; 仕様バージョン 2.1,” .) のセクション 8.2.2 に従って署名を検証します。ここで、(n, e)は、コンシューマーの RSA 公開鍵、Mは、署名ベース文字列、そしてSは、oauth_signature値のオクテット文字列表現です。
RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S)
パラメーターはPLAINTEXTメソッドは、セキュリティ保護を提供せず、HTTPSのようなセキュアなチャネルでのみ使用する必要があります。署名ベース文字列は使用しません。
oauth_signatureは、コンシューマーシークレットとトークンシークレットのエンコードされた値を連結し、それらを「&」文字（ASCIIコード38）で区切ったものに設定されます。どちらかのシークレットが空の場合でも同様です。結果は再度エンコードする必要があります。
これらの例は、oauth_signatureコンシューマーシークレットdjr9rjt0jd78jf88および 3 つの異なるトークンシークレット
- jjd999tj88uiths3
- oauth_signature=djr9rjt0jd78jf88%26jjd999tj88uiths3
- jjd99$tj88uiths3
- oauth_signature=djr9rjt0jd78jf88%26jjd99%2524tj88uiths3
- 空
- oauth_signature=djr9rjt0jd78jf88%26
サービスプロバイダーは、署名値をコンシューマーシークレットとトークンシークレットに分解し、それらがローカルに保存されたシークレットと一致することを確認することによってリクエストを検証します。
このセクションは、リクエストトークンおよびアクセストークンリクエストにのみ適用されます。一般的に、サービスプロバイダーは、[RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” .) のセクション 10 で定義されているレスポンスコードを使用する必要があります。サービスプロバイダーがコンシューマーリクエストを拒否する場合は、HTTP 400 Bad Request または HTTP 401 Unauthorized で応答する必要があります。
この例では、サービスプロバイダー photos.example.net は写真共有ウェブサイトであり、コンシューマー printer.example.com は写真印刷ウェブサイトです。ユーザーの Jane は、photos.example.net に保存されているプライベート写真vacation.jpgを printer.example.com で印刷したいと考えています。
Jane が自分のユーザー名とパスワードを使用して photos.example.net にサインインすると、URLhttp://photos.example.net/photo?file=vacation.jpgにアクセスして写真にアクセスできます。他のユーザーはその写真にアクセスできず、Jane は自分のユーザー名とパスワードを printer.example.com と共有したくありません。
この例のリクエストでは、パラメータを送信する際に URL クエリメソッドを使用します。これは例を簡単にするためであり、他のメソッドよりも特定のメソッドを推奨していると解釈しないでください。
サービスプロバイダーのドキュメントでは、コンシューマーキーとコンシューマーシークレットを登録する方法について説明しており、次の URL を宣言しています。
- リクエストトークン URL
- https://photos.example.net/request_token, HTTP POST を使用
- ユーザー承認 URL
- http://photos.example.net/authorize, HTTP GET を使用
- アクセストークン URL
- https://photos.example.net/access_token, HTTP POST を使用
- 写真（保護されたリソース）URL
- http://photos.example.net/photo 必要なパラメータfileおよびオプションのパラメータsize
サービスプロバイダーは、すべてのリクエストに対してHMAC-SHA1署名メソッド、およびPLAINTEXTセキュア（HTTPS）リクエストでのみサポートを宣言します。
コンシューマー printer.example.com はすでに photos.example.net でコンシューマーキーとコンシューマーシークレットを確立しており、photos.example.net に保存されている写真の印刷サービスを宣伝しています。コンシューマー登録は
- コンシューマーキー
- dpf43f3p2l4k3l03
- コンシューマーシークレット
- kd94hf93k423kf44
Jane が photos.example.net に保存されている休暇写真を印刷したいことを printer.example.com に伝えた後、プリンターのウェブサイトは写真にアクセスしようとして、プライベートであることを示す HTTP 401 Unauthorized を受信します。サービスプロバイダーは、応答に次のヘッダーを含めます。
WWW-Authenticate: OAuth realm="http://photos.example.net/"
コンシューマーは、次の HTTP POST リクエストをサービスプロバイダーに送信します。
https://photos.example.net/request_token?oauth_consumer_key=dpf43f3p2l4k3l03&oauth_signature_method=PLAINTEXT&oauth_signature=kd94hf93k423kf44%26&oauth_timestamp=1191242090&oauth_nonce=hsu94j3884jdopsl&oauth_version=1.0
サービスプロバイダーは署名を確認し、HTTP レスポンスの本文に未承認のリクエストトークンで応答します。
oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03
コンシューマーは、Jane のブラウザーをサービスプロバイダーのユーザー承認 URL にリダイレクトして、Jane がプライベート写真へのアクセスを承認してもらいます。
http://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola&oauth_callback=http%3A%2F%2Fprinter.example.com%2Frequest_token_ready
サービスプロバイダーは、Jane にユーザー名とパスワードを使用してサインインするように求め、成功した場合、printer.example.com にプライベート写真へのアクセスを許可することを承認するかどうかを尋ねます。Jane がリクエストを承認した場合、サービスプロバイダーは彼女をコンシューマーのコールバック URL にリダイレクトします。
http://printer.example.com/request_token_ready?oauth_token=hh5s93j4hdidpola
コンシューマーは、Jane がリクエストトークンを承認したことを知ったので、サービスプロバイダーにアクセストークンと交換するように要求します。
https://photos.example.net/access_token?oauth_consumer_key=dpf43f3p2l4k3l03&oauth_token=hh5s93j4hdidpola&oauth_signature_method=PLAINTEXT&oauth_signature=kd94hf93k423kf44%26hdhd0244k9j7ao03&oauth_timestamp=1191242092&oauth_nonce=dji430splmx33448&oauth_version=1.0
サービスプロバイダーは署名を確認し、HTTP レスポンスの本文にアクセストークンで応答します。
oauth_token=nnch734d00sl2jdk&oauth_token_secret=pfkkdhi9sl3r4s00
コンシューマーは、プライベート写真をリクエストする準備が整いました。写真の URL はセキュアではない (HTTP) ため、HMAC-SHA1.
署名を生成するには、まず署名ベース文字列を生成する必要があります。リクエストには、次のパラメータ (oauth_signatureを除く) が含まれており、これらは順序付けられ、正規化された文字列に連結されます。
- oauth_consumer_key
- dpf43f3p2l4k3l03
- oauth_token
- nnch734d00sl2jdk
- oauth_signature_method
- HMAC-SHA1
- oauth_timestamp
- 1191242096
- oauth_nonce
- kllo9940pd9333jh
- oauth_version
- 1.0
- file
- vacation.jpg
- size
- original
次の入力は、署名ベース文字列を生成するために使用されます。
署名ベース文字列は
GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal
HMAC-SHA1 は次のものを生成します。ダイジェストbase64 エンコードされた文字列としての値（署名ベース文字列をテキストとkd94hf93k423kf44&pfkkdhi9sl3r4s00として使用します）。キー):
tR3+Ty81lMeYAr/Fid0kMTYa/WM=
すべてをまとめると、写真に対するコンシューマーのリクエストは次のようになります。
http://photos.example.net/photos?file=vacation.jpg&size=original
Authorization: OAuth realm="http://photos.example.net/",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_token="nnch734d00sl2jdk",
oauth_signature_method="HMAC-SHA1",
oauth_signature="tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D",
oauth_timestamp="1191242096",
oauth_nonce="kllo9940pd9333jh",
oauth_version="1.0"
また、クエリパラメータを使用する場合は次のようになります。
http://photos.example.net/photos?file=vacation.jpg&size=original&oauth_consumer_key=dpf43f3p2l4k3l03&oauth_token=nnch734d00sl2jdk&oauth_signature_method=HMAC-SHA1&oauth_signature=tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D&oauth_timestamp=1191242096&oauth_nonce=kllo9940pd9333jh&oauth_version=1.0
photos.example.net は署名を確認し、要求された写真で応答します。
OAuth 仕様では、セクション 6.1.2 (サービスプロバイダーは未承認のリクエストトークンを発行します) および セクション 6.3.2 (サービスプロバイダーはアクセストークンを付与します) で、サービスプロバイダーからコンシューマーに送信される際に、トークンとシークレットを盗聴者から保護するためのメカニズムについては説明していません。サービスプロバイダーは、これらの伝送が TLS や SSL などのトランスポート層メカニズムを使用して保護されていることを確認する必要があります。
と併用した場合、PLAINTEXT署名を使用すると、OAuth プロトコルは、ユーザー認証情報を盗聴者や中間者攻撃から保護しようとしません。PLAINTEXT署名アルゴリズムは、そのような保護を提供する TLS や SSL などのトランスポート層セキュリティメカニズムと組み合わせてのみ使用することを意図しています。トランスポート層保護が利用できない場合、PLAINTEXT署名メソッドは使用すべきではありません。
OAuth は、リクエストの整合性を検証するためのメカニズムを提供しますが、リクエストの機密性を保証するものではありません。さらに予防措置を講じない限り、盗聴者はリクエストの内容に完全にアクセスできます。サービスプロバイダーは、このようなリクエストの一部として送信される可能性のあるデータの種類を慎重に検討し、機密性の高いリソースを保護するためにトランスポート層セキュリティメカニズムを採用する必要があります。
OAuth は、サービスプロバイダーの信頼性を検証しようとしません。悪意のある第三者は、コンシューマーのリクエストを傍受し、誤解を招くような、または誤った応答を返すことで、これを利用する可能性があります。サービスプロバイダーは、OAuth に基づくサービスを開発する際に、このような攻撃を検討し、サービスプロバイダーの信頼性またはリクエスト応答が問題となるすべてのリクエストにトランスポート層セキュリティを要求する必要があります。
HTTP 認証スキーム (OAuth HTTP 認証スキーム) はオプションです。ただし、[RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” .) はAuthorizationとWWW-Authenticateヘッダーに依存して、保護できるように認証されたコンテンツを区別しています。特に、プロキシとキャッシュは、これらのヘッダーを使用していないリクエストを適切に保護できない場合があります。
たとえば、プライベートな認証済みコンテンツは、公開アクセス可能なキャッシュに保存（したがって取得可能）される場合があります。HTTP 認証スキーム (OAuth HTTP 認証スキーム) を使用していないサービスプロバイダーは、認証済みコンテンツが保護されるように、Cache-Controlヘッダーなどの他のメカニズムを使用するように注意する必要があります。
コンシューマーシークレットとトークンシークレットは、従来の認証システムでパスワードが機能するのと同じように機能します。非PLAINTEXTメソッドで使用される署名を計算するためには、サービスプロバイダーはこれらのシークレットにプレーンテキスト形式でアクセスできる必要があります。これは、たとえば、ユーザー認証情報の一方向ハッシュのみを保存する最新のオペレーティングシステムとは対照的です。
攻撃者がこれらのシークレットにアクセスした場合、またはさらに悪いことに、すべてのそのようなシークレットのサービスプロバイダーのデータベースにアクセスした場合、その人物はすべてのユーザーに代わって任意のアクションを実行できるようになります。したがって、サービスプロバイダーがこれらのシークレットを不正アクセスから保護することが重要です。
多くのアプリケーションでは、コンシューマーアプリケーションは、潜在的に信頼できない当事者の管理下に置かれることになります。たとえば、コンシューマーが自由に利用できるデスクトップアプリケーションである場合、攻撃者は分析のためにコピーをダウンロードできる可能性があります。このような場合、攻撃者は、サービスプロバイダーに対するコンシューマーの認証に使用されるコンシューマーシークレットを回復できるようになります。
したがって、サービスプロバイダーは、コンシューマーシークレットのみを使用してコンシューマーのIDを確認すべきではありません。可能な場合は、IPアドレスなどの他の要素も使用する必要があります。
OAuthや類似のプロトコルが広く普及すると、ユーザーはパスワードを入力するためにウェブサイトにリダイレクトされることに慣れてしまう可能性があります。ユーザーが認証情報を入力する前にこれらのウェブサイトの真正性を慎重に確認しない場合、攻撃者がこの慣習を悪用してユーザーのパスワードを盗むことが可能になります。
サービスプロバイダーは、フィッシング攻撃がもたらすリスクについてユーザーを啓発するよう努めるべきであり、ユーザーがサイトの真正性を簡単に確認できるメカニズムを提供する必要があります。
OAuth自体は、コンシューマーに付与されるアクセス権のスコープを設定するためのメソッドを提供していません。コンシューマーは、保護されたリソースにアクセスできるか、またはできないかのどちらかです。しかし、多くのアプリケーションでは、より詳細なアクセス権が必要になります。たとえば、サービスプロバイダーは、一部の保護されたリソースへのアクセスは許可するが、他のリソースへのアクセスは許可しない、またはそれらの保護されたリソースへのアクセスを限定的な（読み取り専用アクセスなど）アクセスのみ許可できるようにしたい場合があります。
OAuthを実装する場合、サービスプロバイダーは、ユーザーがコンシューマーに付与したいと考える可能性のあるアクセス権の種類を考慮し、それを行うためのメカニズムを提供する必要があります。また、サービスプロバイダーは、ユーザーが付与しているアクセス権と、それに伴うリスクを理解していることを確認するように注意する必要があります。
トランスポート層のセキュリティプロトコルを使用しない限り、盗聴者はOAuthリクエストと署名に完全にアクセスできるため、コンシューマーが使用した認証情報を回復するためのオフラインでのブルートフォース攻撃を仕掛けることができます。サービスプロバイダーは、トークンシークレットとコンシューマーシークレットを、少なくともシークレットが有効な期間中はこのような攻撃に耐えられるだけの長さとランダムさを持つように慎重に割り当てる必要があります。
たとえば、トークンシークレットが2週間有効な場合、サービスプロバイダーは、2週間以内にトークンシークレットを回復するブルートフォース攻撃を実行できないようにする必要があります。もちろん、サービスプロバイダーは用心深く、合理的な範囲で最も長いシークレットを使用するように強く推奨されます。
これらの秘密鍵を生成するために使用される擬似乱数生成器（PRNG）が十分に高品質であることも同様に重要です。多くのPRNG実装では、ランダムに見える可能性のある数のシーケンスを生成しますが、暗号解析やブルートフォース攻撃を容易にするパターンやその他の脆弱性を示しています。実装者は、これらの問題を回避するために、暗号学的に安全なPRNGを使用するように注意する必要があります。
OAuthプロトコルには、サービスプロバイダーに対するリソース枯渇攻撃を可能にする可能性のある多くの機能があります。たとえば、サービスプロバイダーが上記のように推奨されているようにトークンシークレットにかなりの量のエントロピーを含める場合、攻撃者はサービスプロバイダーからリクエストトークンを繰り返し取得することにより、サービスプロバイダーのエントロピープールを非常に迅速に枯渇させることができます。
同様に、OAuthではサービスプロバイダーが使用済みのナンスを追跡する必要があります。攻撃者が多くのナンスを迅速に使用できる場合、それらを追跡するために必要なリソースが利用可能な容量を使い果たす可能性があります。また、OAuthでは、サービスプロバイダーが受信リクエストの署名を検証するために、コストのかかる計算を実行する必要がある場合があります。攻撃者はこれを悪用して、サービスプロバイダーに大量の無効なリクエストを送信することにより、サービス拒否攻撃を実行する可能性があります。
リソース枯渇攻撃は、決してOAuth特有のものではありません。ただし、OAuthの実装者は、OAuthがさらす攻撃の追加の手段を慎重に検討し、それに応じて実装を設計する必要があります。たとえば、エントロピー枯渇は通常、システムが新しいエントロピーを待機している間の完全なサービス拒否、または弱い（推測しやすい）秘密鍵のいずれかをもたらします。OAuthを実装する際、サービスプロバイダーは、どちらがアプリケーションにとってより深刻なリスクをもたらすかを検討し、それに応じて設計する必要があります。
署名で使用されるハッシュアルゴリズムであるSHA-1には、HMAC-SHA1示されているように (De Canniere, C. and C. Rechberger, “Finding SHA-1 Characteristics: General Results and Applications,” .) [SHA1]、衝突攻撃に対する耐性を大幅に低下させるいくつかの暗号学的脆弱性があることが判明しています。実際には、これらの脆弱性を悪用することは難しく、それ自体ではOAuthのユーザーに重大なリスクをもたらすものではありません。ただし、より効率的な攻撃を可能にする可能性があり、NISTは、発表しています (National Institute of Standards and Technolog, NIST., “NIST Brief Comments on Recent Cryptanalytic Attacks on Secure Hashing Functions and the Continued Security Provided by SHA-1,” .) [NIST]、2010年までにSHA-1の使用を段階的に廃止すると述べています。サービスプロバイダーは、SHA-1がアプリケーションに適切なレベルのセキュリティを提供するかどうかを検討する際に、これを考慮に入れる必要があります。
署名ベース文字列は、この仕様で定義されている署名メソッドをサポートするように設計されています。追加の署名メソッドを設計する場合、署名ベース文字列が使用されるアルゴリズムとの互換性を確保するために評価する必要があります。
署名ベース文字列は、パラメータが送信される順序を保証できません。パラメータの順序が重要であり、リクエストの結果に影響を与える場合、署名ベース文字列はリクエストの操作から保護しません。
| OAuth Core Workgroup | |
| Email: | spec@oauth.net |