この仕様は、RFC 6749: The OAuth 2.0 Authorization Framework によって廃止されました。実装者はこの仕様の代わりに RFC 6749 を使用する必要があります。
2009年6月24日
この仕様は、https://oauth.dokyumento.jp/license/core/1.0 で入手可能なOAuth Non-Assertion Covenant and Author's Contribution License For OAuth Specification 1.0 の下で利用可能になった OAuth Core 1.0 仕様から派生しました。OAuth Core 1.0 と OAuth Core 1.0 リビジョン A の間の変更は、Google および Yahoo! によって Open Web Foundation Agreement 0.9 の下でライセンスされています。
OAuth Core 1.0 リビジョン A は、https://oauth.dokyumento.jp/advisories/2009-1 で詳述されているように、OAuth Core 1.0 仕様で特定されたセッション固定攻撃に対処するために作成されました。変更点の完全な一覧は、仕様リポジトリで入手できます。
OAuth プロトコルにより、Webサイトまたはアプリケーション（コンシューマー）は、ユーザーがサービスプロバイダーの認証情報をコンシューマーに開示することなく、API を介して Web サービス（サービスプロバイダー）から保護されたリソースにアクセスできます。より一般的には、OAuth は API 認証のための自由に実装可能な汎用的な方法論を作成します。
ユースケースの例として、印刷サービス printer.example.com (コンシューマー) が、ユーザーが photos.example.net の認証情報を printer.example.com に提供することなく、photos.example.net (サービスプロバイダー) に保存されたプライベート写真にアクセスできるようにすることがあります。
OAuth は、特定のユーザーインターフェースやインタラクションパターンを必要とせず、サービスプロバイダーがユーザーを認証する方法を指定しないため、OpenID のようにコンシューマーが認証資格情報を利用できない場合にプロトコルが最適です。
OAuth は、委任された Web サービス認証の経験と実装を単一のコミュニティ主導のプロトコルに統合することを目指しています。OAuth は、さまざまな Web サイトによって個別に実装されてきた既存のプロトコルとベストプラクティスに基づいて構築されています。大規模および小規模なプロバイダーによってサポートされているオープンスタンダードは、アプリケーション開発者とそれらのアプリケーションのユーザーの両方にとって一貫性があり、信頼できるエクスペリエンスを促進します。
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 レスポンスコード
11. セキュリティに関する考慮事項
11.1. 資格情報とトークンの交換
11.2. PLAINTEXT 署名方式
11.3. リクエストの機密性
11.4. 偽造サーバーによるスプーフィング
11.5. 認証済みコンテンツのプロキシとキャッシュ
11.6. 認証情報の平文での保存
11.7. コンシューマーシークレットの機密性
11.8. フィッシング攻撃
11.9. アクセスリクエストのスコープ設定
11.10. シークレットのエントロピー
11.11. サービス拒否/リソース枯渇攻撃
11.12. 暗号攻撃
11.13. 署名ベース文字列の互換性
11.14. クロスサイトリクエストフォージェリ (CSRF)
11.15. ユーザーインターフェースの不正操作
11.16. 反復認証の自動処理
付録 A. 付録 A - プロトコルの例
付録 A.1. ドキュメントと登録
付録 A.2. リクエストトークンの取得
付録 A.3. ユーザー認証のリクエスト
付録 A.4. アクセストークンの取得
付録 A.5. 保護されたリソースへのアクセス
12. 参考文献
§ 著者のアドレス
このドキュメントにおけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、[RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .) に記載されているように解釈されます。ドメイン名の例では [RFC2606] (Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” .) を使用します。
- サービスプロバイダー
- OAuth を介したアクセスを許可する Web アプリケーション。
- ユーザー
- サービスプロバイダーにアカウントを持つ個人。
- コンシューマー
- OAuth を使用してユーザーに代わってサービスプロバイダーにアクセスする Webサイトまたはアプリケーション。
- 保護されたリソース
- サービスプロバイダーによって制御されるデータで、コンシューマーは認証を通じてアクセスできます。
- コンシューマー開発者
- コンシューマーを実装する個人または組織。
- コンシューマーキー
- コンシューマーがサービスプロバイダーに対して自身を識別するために使用する値。
- コンシューマーシークレット
- コンシューマーがコンシューマーキーの所有権を確立するために使用するシークレット。
- リクエストトークン
- コンシューマーがユーザーから承認を得て、アクセストークンと交換するために使用する値。
- アクセストークン
- コンシューマーがユーザーのサービスプロバイダーの認証情報を使用する代わりに、ユーザーに代わって保護されたリソースへのアクセスを取得するために使用する値。
- トークンシークレット
- コンシューマーが特定のトークンの所有権を確立するために使用するシークレット。
- OAuth プロトコルパラメータ
- 名前がoauth_.
4. ドキュメントと登録
OAuth には、サービスプロバイダーに対するコンシューマー（ユーザーではなく）を認証するコンシューマーキーと一致するコンシューマーシークレットが含まれています。コンシューマー固有の識別により、サービスプロバイダーはコンシューマーへのアクセスレベル（リソースへの無制限アクセスなど）を変化させることができます。
4.1. リクエスト URL
- OAuth は3つのリクエスト URL を定義します。
- リクエストトークン URL
- セクション 6.1 (未認証のリクエストトークンの取得)で説明されている、未認証のリクエストトークンを取得するために使用される URL。
- ユーザー認証 URL
- セクション 6.2 (ユーザー認証の取得)で説明されている、コンシューマーアクセスに対するユーザー認証を取得するために使用される URL。
- アクセストークン URL
セクション 6.3 (アクセストークンの取得)で説明されている、ユーザー認証されたリクエストトークンをアクセストークンと交換するために使用される URL。
http://sp.example.com/authorize
4.2. サービスプロバイダー
サービスプロバイダーの責任は、コンシューマー開発者がコンシューマーキーとコンシューマーシークレットを確立できるようにすることです。これらをプロビジョニングするプロセスと要件は、完全にサービスプロバイダーに依存します。
4.3. コンシューマー
5. パラメータ
すべてのパラメータ名と値は、[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, a transformation format of Unicode and 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,” .)拡張機能を定義します。標準のHTTPを使用します。AuthorizationとWWW-AuthenticateOAuthプロトコルパラメータを渡すためのヘッダー。
サービスプロバイダーは、HTTPを受け入れることを推奨しますAuthorizationヘッダー。コンシューマーは、OAuthのOAuthプロトコルパラメータを送信できる必要がありますAuthorizationヘッダー。
拡張機能認証スキーム（[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 HTTPを返すことにより、拡張機能のサポートを示す場合がありますWWW-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,” .)に従って、このような応答には、追加のHTTPが含まれる場合がありますWWW-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種類のトークンを使用します。
- リクエストトークン
- コンシューマーがユーザーに保護されたリソースへのアクセスを承認するように求めるために使用されます。ユーザーが承認したリクエストトークンはアクセストークンと交換され、一度だけ使用する必要があり、他の目的で使用してはいけません。リクエストトークンの有効期間は限られていることが推奨されます。
- アクセストークン
- コンシューマーがユーザーの代わりに保護されたリソースにアクセスするために使用されます。アクセストークンは、特定の保護されたリソースへのアクセスを制限したり、有効期間を制限したりできます。サービスプロバイダーは、ユーザーがアクセストークンを取り消せるようにする必要があります。保護されたリソースにアクセスするために使用できるのはアクセストークンのみです。
OAuth認証は、次の3つのステップで実行されます。
コンシューマーは、サービスプロバイダーにトークンの発行を要求することにより、未承認のリクエストトークンを取得します。リクエストトークンの唯一の目的は、ユーザーの承認を受け取ることです。アクセストークンを取得するためにのみ使用できます。リクエストトークンプロセスは次のとおりです。
リクエストトークンを取得するために、コンシューマーはHTTPリクエストをサービスプロバイダーのリクエストトークンURLに送信します。サービスプロバイダーのドキュメントでは、このリクエストのHTTPメソッドを指定しており、HTTP POSTが推奨されています。リクエストは署名されている必要があり、次のパラメータが含まれています。
- oauth_consumer_key
- コンシューマーキー。
- oauth_signature_method
- コンシューマーがリクエストに署名するために使用した署名方法。
- oauth_signature
- リクエストの署名 (リクエストの署名)で定義されている署名。
- oauth_timestamp
- Nonceとタイムスタンプ (Nonceとタイムスタンプ)で定義されているとおり。
- oauth_nonce
- Nonceとタイムスタンプ (Nonceとタイムスタンプ)で定義されているとおり。
- oauth_version
- オプション。存在する場合、値は 1.0 である必要があります。サービスプロバイダーは、このパラメータが存在しない場合、プロトコルバージョンを1.0であると想定する必要があります。非1.0値に対するサービスプロバイダーの応答は未定義です。
- oauth_callback
- ユーザー承認の取得 (ユーザー承認の取得)ステップが完了したときに、サービスプロバイダーがユーザーをリダイレクトする絶対URL。コンシューマーがコールバックを受信できない場合、または他の手段でコールバックURLが確立されている場合、パラメータ値はoob(大文字と小文字を区別)に設定して、アウトオブバンド構成を示す必要があります。
- 追加パラメータ
- サービスプロバイダーによって定義された追加パラメータ。
サービスプロバイダーは、署名とコンシューマーキーを検証します。成功した場合、リクエストトークンとトークンシークレットを生成し、サービスプロバイダーレスポンスパラメータ (サービスプロバイダーレスポンスパラメータ)で定義されているように、HTTPレスポンスボディでコンシューマーに返します。サービスプロバイダーは、ユーザー承認の取得 (ユーザー承認の取得)でユーザーが正常にアクセスを許可するまで、リクエストトークンをアクセストークンと交換できないようにする必要があります。
レスポンスには、次のパラメータが含まれます。
- oauth_token
- リクエストトークン。
- oauth_token_secret
- トークンシークレット。
- oauth_callback_confirmed
- 存在する必要があり、trueに設定する必要があります。コンシューマーは、これを使用してサービスプロバイダーがコールバック値を受信したことを確認できます。
- 追加パラメータ
- サービスプロバイダーによって定義された追加パラメータ。
リクエストが検証に失敗した場合、またはその他の理由で拒否された場合、サービスプロバイダーは、HTTPレスポンスコード (HTTPレスポンスコード)で定義されている適切なレスポンスコードで応答する必要があります。サービスプロバイダーは、サービスプロバイダーレスポンスパラメータ (サービスプロバイダーレスポンスパラメータ)で定義されているように、HTTPレスポンスボディでリクエストが拒否された理由に関する詳細を含めることができます。
コンシューマーは、ユーザーが承認するまでリクエストトークンを使用できません。ユーザー承認の取得には、次の手順が含まれます。
コンシューマーがリクエストトークンをアクセストークンと交換できるようにするには、コンシューマーはユーザーをサービスプロバイダーに誘導することにより、ユーザーから承認を得る必要があります。コンシューマーは、次のパラメータを使用して、サービスプロバイダーのユーザー承認URLへのHTTP GETリクエストを作成します。
- oauth_token
- オプション。前のステップで取得したリクエストトークン。サービスプロバイダーは、このパラメータを必須として宣言するか、それなしでユーザー承認URLへのリクエストを受け入れる場合があります。その場合、ユーザーに手動で入力するように求めます。
- 追加パラメータ
- サービスプロバイダーによって定義された追加パラメータ。
リクエストURLが構築されたら、コンシューマーはユーザーのWebブラウザを介してユーザーをURLにリダイレクトします。コンシューマーが自動HTTPリダイレクトを実行できない場合、コンシューマーは、構築されたリクエストURLに手動でアクセスする方法をユーザーに通知する必要があります。
注：サービスプロバイダーがコンシューマーがモバイルデバイスまたはセットトップボックスで実行されていることを認識している場合、サービスプロバイダーは、ユーザー承認URLとリクエストトークンが手動入力に適していることを確認する必要があります。
サービスプロバイダーは、詳細に示すようにユーザーの身元を確認し、同意を求めます。OAuthは、サービスプロバイダーがユーザーを認証する方法を指定していません。ただし、必須の手順のセットを定義します。
コンシューマーキーに基づいてコンシューマーに関する識別情報をユーザーに表示する場合、サービスプロバイダーは、コンシューマーの真の身元を保証できない場合は、ユーザーに通知する必要があります。サービスプロバイダーがユーザーに通知する方法と、身元保証の質は、この仕様の範囲外です。
ユーザーがサービスプロバイダで認証を済ませ、コンシューマへのアクセス許可を与えた後、コンシューマはリクエストトークンが承認され、アクセストークンと交換する準備ができたことを通知される必要があります。ユーザーがアクセスを拒否した場合、コンシューマはリクエストトークンが取り消されたことを通知される場合があります。
アクセスを許可したユーザーが、プロセスを完了するためにコンシューマに戻ってきたユーザーと同一であることを確認するために、サービスプロバイダは検証コードを生成する必要があります。検証コードは、ユーザーを介してコンシューマに渡される、推測不可能な値であり、プロセスを完了するために必要です。
コンシューマがコールバックURLを提供した場合（oauth_callbackセクション6.1.1 (コンシューマがリクエストトークンを取得する)のパラメータを使用するか、その他の手段によって）、サービスプロバイダはそれを使用してHTTPリクエストを構築し、以下のパラメータを追加して、ユーザーのWebブラウザをそのURLにリダイレクトします。
- oauth_token
- ユーザーが承認または拒否したリクエストトークン。
- oauth_verifier
- 検証コード。
コールバックURLには、コンシューマが提供したクエリパラメータを含めることができます。サービスプロバイダは、それらを変更せずに保持し、既存のクエリにOAuthパラメータを追加する必要があります。
コンシューマがコールバックURLを提供しなかった場合、サービスプロバイダは検証コードの値を表示し、認証が完了したことを手動でコンシューマに通知するようにユーザーに指示する必要があります。サービスプロバイダがコンシューマがモバイルデバイスまたはセットトップボックスで実行されていることを認識している場合、サービスプロバイダは検証コードの値が手動入力に適していることを確認する必要があります。
コンシューマは、保護されたリソースにアクセスできるアクセストークンとリクエストトークンを交換します。アクセストークンの取得には、以下の手順が含まれます。
リクエストトークンとトークンシークレットは、アクセストークンとトークンシークレットと交換する必要があります。
アクセストークンを要求するために、コンシューマはサービスプロバイダのアクセストークンURLにHTTPリクエストを送信します。サービスプロバイダのドキュメントでは、このリクエストのHTTPメソッドを指定しており、HTTP POSTが推奨されます。リクエストは、リクエストの署名 (リクエストの署名)に従って署名する必要があり、次のパラメータが含まれます。
- oauth_consumer_key
- コンシューマーキー。
- oauth_token
- 以前に取得したリクエストトークン。
- oauth_signature_method
- コンシューマーがリクエストに署名するために使用した署名方法。
- oauth_signature
- リクエストの署名 (リクエストの署名)で定義されている署名。
- oauth_timestamp
- Nonceとタイムスタンプ (Nonceとタイムスタンプ)で定義されているとおり。
- oauth_nonce
- Nonceとタイムスタンプ (Nonceとタイムスタンプ)で定義されているとおり。
- oauth_version
- オプション。存在する場合、値は 1.0 である必要があります。サービスプロバイダーは、このパラメータが存在しない場合、プロトコルバージョンを1.0であると想定する必要があります。非1.0値に対するサービスプロバイダーの応答は未定義です。
- oauth_verifier
- サービスプロバイダがユーザーをコンシューマへリダイレクトする (サービスプロバイダがユーザーをコンシューマへリダイレクトする)ステップで、サービスプロバイダから受信した検証コード。
すべてのトークン関連情報がユーザーの承認を求める前に存在することを保証するために、アクセストークンを要求する際には、追加のサービスプロバイダ固有のパラメータは許可されていません。
サービスプロバイダは、以下を保証する必要があります。
成功した場合、サービスプロバイダはアクセストークンとトークンシークレットを生成し、サービスプロバイダのレスポンスパラメータ (サービスプロバイダのレスポンスパラメータ)で定義されているように、HTTPレスポンスボディでそれらを返します。アクセストークンとトークンシークレットはコンシューマによって保存され、保護されたリソースリクエストに署名するときに使用されます。レスポンスには次のパラメータが含まれます。
- oauth_token
- アクセストークン。
- oauth_token_secret
- トークンシークレット。
- 追加パラメータ
- サービスプロバイダーによって定義された追加パラメータ。
リクエストが検証に失敗した場合、またはその他の理由で拒否された場合、サービスプロバイダーは、HTTPレスポンスコード (HTTPレスポンスコード)で定義されている適切なレスポンスコードで応答する必要があります。サービスプロバイダーは、サービスプロバイダーレスポンスパラメータ (サービスプロバイダーレスポンスパラメータ)で定義されているように、HTTPレスポンスボディでリクエストが拒否された理由に関する詳細を含めることができます。
アクセストークンとトークンシークレットを正常に受信した後、コンシューマはユーザーに代わって保護されたリソースにアクセスできます。リクエストは、リクエストの署名 (リクエストの署名)に従って署名する必要があり、次のパラメータが含まれます。
- oauth_consumer_key
- コンシューマーキー。
- oauth_token
- アクセストークン。
- oauth_signature_method
- コンシューマーがリクエストに署名するために使用した署名方法。
- oauth_signature
- リクエストの署名 (リクエストの署名)で定義されている署名。
- oauth_timestamp
- Nonceとタイムスタンプ (Nonceとタイムスタンプ)で定義されているとおり。
- oauth_nonce
- Nonceとタイムスタンプ (Nonceとタイムスタンプ)で定義されているとおり。
- oauth_version
- オプション。存在する場合、値は1.0である必要があります。サービスプロバイダーは、このパラメータが存在しない場合、プロトコルバージョンを1.0であると想定する必要があります。非1.0値に対するサービスプロバイダーの応答は未定義です。
- 追加パラメータ
- サービスプロバイダーによって定義された追加パラメータ。
サービスプロバイダによって特に指定がない限り、タイムスタンプは1970年1月1日00:00:00 GMTからの秒数で表されます。タイムスタンプの値は正の整数でなければならず、以前のリクエストで使用されたタイムスタンプ以上でなければなりません。
コンシューマは、そのタイムスタンプを持つすべてのリクエストに対して一意のノンス値を生成する必要があります。ノンスは、各リクエストに対して一意に生成されるランダムな文字列です。ノンスを使用すると、サービスプロバイダはリクエストが以前に作成されたことがないことを検証でき、リクエストが非セキュアチャネル（HTTPなど）を介して行われた場合のリプレイ攻撃を防ぐのに役立ちます。
すべてのトークンリクエストと保護されたリソースリクエストは、コンシューマによって署名され、サービスプロバイダによって検証される必要があります。リクエストに署名する目的は、トークンリクエストまたは保護されたリソースリクエストを行うときに、許可されていない当事者がコンシューマキーとトークンを使用するのを防ぐことです。署名プロセスでは、コンシューマシークレットとトークンシークレットが、リクエストに含まれる検証可能な値にエンコードされます。
OAuthは特定の署名方法を義務付けていません。これは、各実装に独自の要件がある可能性があるためです。プロトコルは3つの署名方法を定義しています。HMAC-SHA1, RSA-SHA1、およびPLAINTEXTただし、サービスプロバイダは独自の方法を実装し、ドキュメント化することができます。特定の方法を推奨することは、この仕様の範囲外です。
コンシューマは、oauth_signature_methodパラメータで署名方法を宣言し、署名を生成し、それをoauth_signatureパラメータに格納します。サービスプロバイダは、各方法で指定されたように署名を検証します。コンシューマ署名を検証するとき、サービスプロバイダは、以前のコンシューマ要求で使用されていないことを確認するために、要求ノンスをチェックする必要があります。
署名プロセスでは、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. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” .)の8.2.1項に従って、コンシューマのRSA秘密鍵を使用して署名されます。ここで、KはコンシューマのRSA秘密鍵であり、Mは署名ベース文字列であり、Sは結果の署名オクテット文字列です。
S = RSASSA-PKCS1-V1_5-SIGN (K, M)
oauth_signatureは、Sまず[RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .)の6.8項に従ってbase64エンコードされ、次にパラメータエンコーディング (パラメータエンコーディング)に従ってURLエンコードされます。
サービスプロバイダは、[RFC3447] (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 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で応答する必要があります。
OAuth仕様では、セクション6.1.2 (サービスプロバイダが未承認リクエストトークンを発行する)およびセクション6.3.2 (サービスプロバイダがアクセストークンを付与する)でサービスプロバイダからコンシューマに送信されるときに、トークンとシークレットを盗聴から保護するメカニズムについて説明していません。サービスプロバイダは、これらの送信がTLSやSSLなどのトランスポート層メカニズムを使用して保護されていることを確認する必要があります。
で使用する場合、PLAINTEXT署名を使用する場合、OAuthプロトコルは、ユーザーの資格情報を盗聴者や中間者攻撃から保護する試みを行いません。PLAINTEXT署名アルゴリズムは、そのような保護を提供するTLSやSSLなどのトランスポート層セキュリティメカニズムと組み合わせてのみ使用することを目的としています。トランスポート層の保護が利用できない場合は、PLAINTEXT署名方式は使用しないでください。
OAuthはリクエストの整合性を検証するメカニズムを提供しますが、リクエストの機密性を保証するものではありません。さらなる予防措置を講じない限り、盗聴者はリクエストコンテンツに完全にアクセスできます。サービスプロバイダは、そのようなリクエストの一部として送信される可能性のあるデータの種類を慎重に検討し、機密性の高いリソースを保護するためにトランスポート層セキュリティメカニズムを採用する必要があります。
OAuthは、サービスプロバイダの信頼性を検証する試みを行いません。悪意のある者がコンシューマのリクエストを傍受し、誤解を招く、または誤った応答を返すことで、これを悪用する可能性があります。サービスプロバイダは、OAuthに基づいてサービスを開発する際にそのような攻撃を考慮し、サービスプロバイダまたはリクエスト応答の信頼性が問題となるリクエストにはトランスポート層セキュリティを要求する必要があります。
HTTP Authorizationスキーム (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 Authorizationスキーム (OAuth HTTP認証スキーム)を使用していないサービスプロバイダは、Cache-Controlヘッダーなどの他のメカニズムを使用して、認証済みコンテンツが保護されていることを確認する必要があります。
コンシューマシークレットとトークンシークレットは、従来の認証システムにおけるパスワードと同じように機能します。PLAINTEXT以外のメソッドで使用される署名を計算するには、サービスプロバイダはこれらのシークレットにプレーンテキスト形式でアクセスできる必要があります。これは、ユーザーの資格情報のハッシュのみを保存する最新のオペレーティングシステムとは対照的です。
攻撃者がこれらのシークレット、またはさらに悪いことに、そのようなすべてのシークレットのサービスプロバイダのデータベースにアクセスした場合、そのユーザーはどのユーザーにも代わってあらゆるアクションを実行できるようになります。したがって、サービスプロバイダがこれらのシークレットを不正アクセスから保護することが重要です。
多くのアプリケーションでは、コンシューマアプリケーションは潜在的に信頼できない当事者の管理下にあります。たとえば、コンシューマが無料で利用できるデスクトップアプリケーションである場合、攻撃者は分析のためにコピーをダウンロードできる可能性があります。このような場合、攻撃者はコンシューマをサービスプロバイダに対して認証するために使用されるコンシューマシークレットを回復できます。
したがって、サービスプロバイダはコンシューマのIDを検証するためにコンシューマシークレットのみを使用しないでください。可能であれば、IPアドレスなどの他の要素も使用する必要があります。
OAuthおよび同様のプロトコルの幅広い展開により、ユーザーはパスワードを入力するように求められるWebサイトにリダイレクトされるという慣行に慣れてしまう可能性があります。ユーザーが資格情報を入力する前にこれらのWebサイトの信頼性を確認することに注意しない場合、攻撃者がこの慣行を悪用してユーザーのパスワードを盗むことが可能になります。
サービスプロバイダは、フィッシング攻撃がもたらすリスクについてユーザーを教育し、ユーザーがサイトの信頼性を簡単に確認できるメカニズムを提供する必要があります。
それ自体で、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がアプリケーションに適切なレベルのセキュリティを提供しているかどうかを検討する際に、これを考慮に入れる必要があります。
署名ベース文字列は、この仕様で定義されている署名方法をサポートするように設計されています。追加の署名方法を設計する場合、署名ベース文字列が使用されるアルゴリズムとの互換性を確保するために評価する必要があります。
署名ベース文字列では、パラメータが送信される順序を保証できません。パラメータの順序が重要で、リクエストの結果に影響を与える場合、署名ベース文字列はリクエストの操作を防ぐことができません。
クロスサイトリクエストフォージェリ（CSRF）は、Webサイトが信頼している、または認証済みのユーザーからHTTPリクエストが送信されるWebベースの攻撃です。OAuth承認に対するCSRF攻撃は、攻撃者がユーザーの同意なしにOAuth保護リソースへの承認を取得することを可能にする可能性があります。サービスプロバイダは、すべてのOAuthエンドポイントでCSRF対策のベストプラクティスを強く検討する必要があります。
コンシューマーによってホストされているOAuthコールバックURLに対するCSRF攻撃も可能です。コンシューマーは、コンシューマーサイトのユーザーがサービスプロバイダとのOAuthネゴシエーションを完了する意図があったことを確認することにより、OAuthコールバックURLに対するCSRF攻撃を防ぐ必要があります。
サービスプロバイダは、UI修正攻撃（「クリックジャッキング」とも呼ばれます）から承認プロセスを保護する必要があります。この記事の執筆時点では、UI修正に対する完全な防御策は利用できません。サービスプロバイダは、次の手法を通じてUI修正攻撃のリスクを軽減できます。
サービスプロバイダは、ユーザーが以前に承認したコンシューマーからの承認リクエスト（セクション6.2（ユーザー承認の取得））を自動的に処理したい場合があります。ユーザーがアクセスを許可するためにサービスプロバイダにリダイレクトされると、サービスプロバイダはユーザーが特定のコンシューマーへのアクセスをすでに許可していることを検出します。サービスプロバイダは、ユーザーに承認を求める代わりに、ユーザーを自動的にプロバイダにリダイレクトします。
コンシューマーシークレットが侵害された場合、自動処理は追加のセキュリティリスクを生み出します。攻撃者は、盗まれたコンシューマーキーとシークレットを使用して、承認リクエストでユーザーをサービスプロバイダにリダイレクトできます。その後、サービスプロバイダは、ユーザーの明示的な承認なしに、または攻撃を認識することなく、ユーザーのデータへのアクセスを許可します。自動承認が実装されていない場合、攻撃者はソーシャルエンジニアリングを使用して、ユーザーにアクセスを承認するよう説得する必要があります。
サービスプロバイダは、自動承認によって取得されたアクセストークンの範囲を制限することにより、自動処理に関連するリスクを軽減できます。明示的なユーザー同意によって取得されたアクセストークンは、影響を受けないままにすることができます。コンシューマーは、コンシューマーシークレットを保護することにより、自動処理に関連するリスクを軽減できます。
この例では、サービスプロバイダphotos.example.netは写真共有Webサイトであり、コンシューマーprinter.example.comは写真印刷Webサイトです。ユーザーであるJaneは、photos.example.netに保存されているプライベート写真vacation.jpgをprinter.example.comで印刷したいと考えています。
Janeがユーザー名とパスワードを使用してphotos.example.netにサインインすると、URLにアクセスして写真にアクセスできますhttp://photos.example.net/photo?file=vacation.jpg。他のユーザーはその写真にアクセスできず、Janeは自分のユーザー名とパスワードをprinter.example.comと共有したくありません。
この例のリクエストでは、パラメータを送信するときにURLクエリメソッドを使用します。これは、例を単純化するために行われたものであり、他のメソッドよりも1つのメソッドを推奨するものとして解釈されるべきではありません。
サービスプロバイダのドキュメントでは、コンシューマーキーとコンシューマーシークレットを登録する方法と、次のURLを宣言する方法について説明します。
- OAuth は3つのリクエスト URL を定義します。
- https://photos.example.net/request_token、HTTP POSTを使用
- セクション 6.1 (未認証のリクエストトークンの取得)で説明されている、未認証のリクエストトークンを取得するために使用される URL。
- http://photos.example.net/authorize、HTTP GETを使用
- セクション 6.2 (ユーザー認証の取得)で説明されている、コンシューマーアクセスに対するユーザー認証を取得するために使用される URL。
- https://photos.example.net/access_token、HTTP POSTを使用
- 写真（保護リソース）URL
- 必要なパラメータを持つhttp://photos.example.net/photofileおよびオプションのパラメータsize
サービスプロバイダは、HMAC-SHA1すべてのリクエストの署名方法をサポートし、PLAINTEXTセキュア（HTTPS）リクエストでのみサポートを宣言します。
コンシューマーprinter.example.comは、photos.example.netとコンシューマーキーとコンシューマーシークレットをすでに確立しており、photos.example.netに保存されている写真の印刷サービスを宣伝しています。コンシューマー登録は
- コンシューマーキー
- dpf43f3p2l4k3l03
- コンシューマーシークレット
- kd94hf93k423kf44
Janeがphotos.example.netに保存されている休暇の写真を印刷したいことをprinter.example.comに通知した後、プリンターのWebサイトは写真にアクセスしようとし、非公開であることを示す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&oauth_callback=http%3A%2F%2Fprinter.example.com%2Frequest_token_ready
サービスプロバイダは署名を確認し、HTTPレスポンスの本文に承認されていないリクエストトークンを返信します
oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03&oauth_callback_confirmed=true
コンシューマーはJaneのブラウザをサービスプロバイダのユーザー承認URLにリダイレクトして、Janeの個人写真へのアクセス許可を取得します。
http://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola
サービスプロバイダはJaneにユーザー名とパスワードを使用してサインインするように求め、成功した場合は、printer.example.comに個人写真へのアクセスを許可することを承認するかどうかを尋ねます。Janeがリクエストを承認すると、サービスプロバイダは検証コードを生成し、彼女をコンシューマーのコールバックURLにリダイレクトします。
http://printer.example.com/request_token_ready?oauth_token=hh5s93j4hdidpola&oauth_verifier=hfdp7dh39dks9884
コンシューマーは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&oauth_verifier=hfdp7dh39dks9884
サービスプロバイダは署名と検証コードを確認し、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 Core ワークグループ | |
| メールアドレス: | spec@oauth.net |