The OAuth 1.0 Protocol
draft-hammer-oauth-10

Abstract

OAuth は、リソースオーナー (別のクライアントやエンドユーザー) に代わって、サーバーリソースにアクセスするための方法を、クライアントに提供するものである。また、リダイレクトを利用することで、エンドユーザーはクライアントにユーザ名やパスワードを共有することなく、サーバーリソースへの第三者アクセスを認可することができる。

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on October 4, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  はじめに
    1.1.  用語定義
    1.2.  例
    1.3.  要求記法および規則
2.  リダイレクション・ベースの認可
    2.1.  テンポラリクレデンシャル
    2.2.  リソースオーナー認可
    2.3.  トークンクレデンシャル
3.  認証済みリクエスト
    3.1.  リクエストの実行
    3.2.  リクエストの妥当性検証
    3.3.  ノンス値とタイムスタンプ
    3.4.  署名
        3.4.1.  シグニチャベースストリング
        3.4.2.  HMAC-SHA1
        3.4.3.  RSA-SHA1
        3.4.4.  PLAINTEXT
    3.5.  パラメータの送信
        3.5.1.  Authorization ヘッダー
        3.5.2.  フォームエンコードボディー
        3.5.3.  リクエスト URI クエリー
    3.6.  パーセントエンコーディング
4.  Security Considerations
    4.1.  RSA-SHA1 署名方式
    4.2.  リクエストの機密性
    4.3.  サーバーのなりすまし
    4.4.  要認証コンテンツに対するプロキシおよびキャッシュ
    4.5.  認証情報のプレインテキストストレージ
    4.6.  クライアントクレデンシャルの秘匿性
    4.7.  フィッシング攻撃
    4.8.  アクセスリクエストのスコープ
    4.9.  認証情報のエントロピー
    4.10.  DoS 攻撃 / リソース枯渇攻撃
    4.11.  SHA-1 攻撃
    4.12.  シグニチャベースストリングの制約
    4.13.  Cross-Site Request Forgery (CSRF)
    4.14.  User Interface Redress
    4.15.  再認可の自動処理
5.  IANA に関する考察
6.  謝辞
Appendix A.  コミュニティ版との違い
Appendix B.  Document History
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Author's Address

1.  はじめに

OAuth は、保護されたリソースに対するアクセス権限を第三者へ委譲する際の共通の問題について、その解決方法を必要としていたさまざまな Web サイトやインターネットサービスの開発者からなるコミュニティから生まれた。その後 OAuth は2007年10月に安定版の version 1.0 となり、2009年9月に改訂され [OAuth Core 1.0 Revision A] (OAuth, OAuth Community., “OAuth Core 1.0 Revision A,” .) となった。

この仕様書では改訂版 [OAuth Core 1.0 Revision A] (OAuth, OAuth Community., “OAuth Core 1.0 Revision A,” .) を OAuth 1.0 として扱い、大幅な文書の明瞭化と同時に改訂後に指摘された誤字修正も行っている。なおこの仕様書の公開をもって、オリジナルの OAuth 仕様の執筆者達の手による OAuth 仕様策定権限は、コミュニティから IETF に移管される。

従来のクライアント・サーバー型認証モデルでは、サーバー上のリソースにアクセスするためにクライアントは自身の認証情報を利用する。分散した Web サービスやクラウドコンピューティングの利用拡大により、ますます多くのサードパーティーアプリケーションがこれらのサーバー上リソースへのアクセス権を必要とすることになる。

OAuth は従来のクライアント・サーバー型認証モデルに加え、3つめの役割「リソースオーナー」を導入する。OAuth モデルでは、クライアント (リソースオーナーではないが、リソースオーナーの代理として振る舞う) は、リソースオーナーが管理しながらもサーバーにホスティングされているリソースへのアクセス権を要求する。サーバーは、リソースオーナーの認可情報と同時に、リクエスト元であるクライアントの身元も検証することができる。

OAuth はクライアントがリソースオーナー (異なるクライアントやエンドユーザーなど) の代理としてサーバーリソースにアクセスする方法を提供する。またエンドユーザーが自身の認証情報 (典型例: ユーザ名およびパスワード) を共有することなしに自身のサーバーリソースへのアクセスを許可する一連のプロセスも提供する。このプロセスではユーザーエージェントのリダイレクトを利用する。

例として、ユーザ (リソースオーナー) がプリントサービス (クライアント) に、自身が写真共有サービス (サーバー) 上に保有するプライベートな写真へのアクセス権を与えることを考える。ここではユーザ名とパスワードはプリントサービスに提示しない。その代わりにユーザは写真共有サービス上で直接認証を行い、写真共有サービスがプリントサービスへの委譲専用のユーザー証明書を発行する。

リソースアクセスのために、クライアントはまずはじめにリソースオーナーから許可を受ける必要がある。この許可情報はトークンと共有鍵の形で示される。トークンがあることでリソースオーナーはクライアントに自身の認証情報を共有する必要がなくなる。リソースオーナーの認証情報と異なり、トークンは限定的な用途でかつ有効期限付きで発行することが可能であり、個別に破棄することができる。

この仕様書は2つの部分からなる。前半部ではエンドユーザーがクライアントにリソースへのアクセス権を認可する際の、リダイレクトベースのユーザーエージェント処理について定義する。後半部では2セットのクレデンシャルを用いて認証済み HTTP [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) リクエストを行う方法を定義する。この2セットのクレデンシャルは、1つはリクエストを行っているクライアントを識別するために用いられ、もう1つはそのリクエストでクライアントが代理となるリソースオーナーを識別するために用いられる。

OAuth を [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) 以外の転送プロトコル上で用いる方法については定義されていない。

1.1.  用語定義

クライアント (client)

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,” June 1999.) 参照)

サーバー (server)

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,” June 1999.) 参照)

保護されたリソース (protected resource)

アクセス制限下にあるリソースで、OAuth 認証済みリクエスト (認証済みリクエスト)を用いて取得可能なもの。

リソースオーナー (resource owner)

サーバーに対して自身の認証情報を用いて認証し、保護されたリソースへのアクセスおよびコントロールを行えるもの。

クレデンシャル (credentials)

ここでいうクレデンシャルとはユニークな識別子と共有鍵のペアを指す。OAuth では「クライアント」「テンポラリ」「トークン」の3種類のクレデンシャルが定義され、リクエストを行うクライアントの識別および認証、認可リクエスト、アクセス権受け渡しの際にそれぞれ用いられる。

トークン (token)

サーバーが発行するユニークな識別子。クライアントは認可要求を行ったもしくは認可を受けたリソースオーナーと、認証済みリクエストを結びつけるためにトークンを利用する。トークンには共有鍵がセットになっており、クライアントはトークン所有権およびリソースオーナーの代理権を証明するために共有鍵を用いる。

オリジナルのコミュニティ仕様書では多少異なる用語が用いられていた。それらはこの仕様書では以下のように表記されている。(左側がオリジナル仕様書)

Consumer

クライアント (client)

Service Provider

サーバー (server)

User

リソースオーナー (resource owner)

Consumer Key and Secret

クライアントクレデンシャル (client credentials)

Request Token and Secret

テンポラリクレデンシャル (temporary credentials)

Access Token and Secret

トークンクレデンシャル (token credentials)

1.2.  例

Jane (リソースオーナー) が写真共有サイト 'photos.example.net' (サーバー) に休暇中の写真 (保護されたリソース) をアップロードしたものとする。彼女は 'printer.example.com' (クライアント) を使って写真を現像したい。通常であれば、Jane は 'photos.example.net' にユーザ名とパスワードを使ってログインするはずである。

しかし、Jane は写真を現像するためとはいえ 'printer.example.com' に対してユーザ名とパスワードを提示したくない。そこで 'printer.example.com' では、ユーザによりよいサービスを提供するため、事前に 'photos.example.net' の提供するクライアントクレデンシャルを取得している。

クライアント識別子

dpf43f3p2l4k3l03

クライアント共有鍵

kd94hf93k423kf44

'printer.example.com' はまた、'photos.example.net' の API ドキュメントに記載された HMAC-SHA1 署名方式を用いたプロトコルエンドポイントを使うよう、アプリケーションを設定済みである。

テンポラリクレデンシャルリクエスト

https://photos.example.net/initiate

リソースオーナー認可URI

https://photos.example.net/authorize

トークンリクエストURI

https://photos.example.net/token

'printer.example.com' が Jane に写真へのアクセス許可を求めるには、まず代理でのリクエストを認識するため、'photos.example.net' に対し、テンポラリクレデンシャルの発行を求めなければならない。これを行うため、クライアントは下記のような HTTPS [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) リクエストをサーバーに送信する。

  POST /initiate HTTP/1.1
  Host: photos.example.net
  Authorization: OAuth realm="Photos",
     oauth_consumer_key="dpf43f3p2l4k3l03",
     oauth_signature_method="HMAC-SHA1",
     oauth_timestamp="137131200",
     oauth_nonce="wIjqoS",
     oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
     oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"

サーバーはリクエストの正当性を確認し、HTTP レスポンスボディ (改行は掲載上の都合による) にテンポラリクレデンシャルを持たせた応答を行う。

  HTTP/1.1 200 OK
  Content-Type: application/x-www-form-urlencoded

  oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03&
  oauth_callback_confirmed=true

クライアントは Jane から彼女のプライベートな写真へのアクセスに関して承認を得るため、彼女のユーザーエージェントをサーバーのリソースオーナー認可エンドポイントにリダイレクトする。

  https://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola

サーバーは Jane にユーザ名とパスワードを使ったログインを要求し、成功した場合は、'printer.example.com' が写真にアクセスしてよいか尋ねる。Jane が承認を行うと、ユーザーエージェントは、先のリクエスト (改行は掲載上の都合による) で提供されたコールバック URI にクライアントをリダイレクトする。

  http://printer.example.com/ready?
  oauth_token=hh5s93j4hdidpola&oauth_verifier=hfdp7dh39dks9884

コールバックリクエストは、Jane の認可プロセス完了をクライアントに通知する。クライアントはその後、テンポラリクレデンシャルを用いて、(安全な TLS チャネル上で) トークンクレデンシャルを要求する。

  POST /token HTTP/1.1
  Host: photos.example.net
  Authorization: OAuth realm="Photos",
     oauth_consumer_key="dpf43f3p2l4k3l03",
     oauth_token="hh5s93j4hdidpola",
     oauth_signature_method="HMAC-SHA1",
     oauth_timestamp="137131201",
     oauth_nonce="walatlh",
     oauth_verifier="hfdp7dh39dks9884",
     oauth_signature="gKgrFCywp7rO0OXSjdot%2FIHF7IU%3D"

サーバーはリクエストの正当性を確認し、HTTP レスポンスボディにトークンクレデンシャルを持たせた応答を行う。

  HTTP/1.1 200 OK
  Content-Type: application/x-www-form-urlencoded

  oauth_token=nnch734d00sl2jdk&oauth_token_secret=pfkkdhi9sl3r4s00

トークンクレデンシャルの取得により、クライアントがプライベートな写真を要求するための準備は整う。

  GET /photos?file=vacation.jpg&size=original HTTP/1.1
  Host: photos.example.net
  Authorization: OAuth realm="Photos",
     oauth_consumer_key="dpf43f3p2l4k3l03",
     oauth_token="nnch734d00sl2jdk",
     oauth_signature_method="HMAC-SHA1",
     oauth_timestamp="137131202",
     oauth_nonce="chapoH",
     oauth_signature="MdpQcU8iPSUjWoN%2FUDMsK2sui9I%3D"

'photos.example.net' サーバーはリクエストの正当性を確認し、要求された写真を返す。'printer.example.com' は Jane の認可の有効期間が終了するか、Jane がアクセスを無効にするまで、同じトークンクレデンシャルを使って、Jane の写真にアクセスし続けることができる。

1.3.  要求記法および規則

用いられる各キーワード「MUST (しなければならない) 」、「MUST NOT (してはならない) 」、「REQUIRED (必須である) 」、「SHALL (するものとする) 」、「SHALL NOT (しないものとする) 」、「SHOULD (すべきである) 」、「SHOULD NOT (すべきではない) 」、「RECOMMENDED (推奨される) 」、「MAY (してもよい) 」、「OPTIONAL (任意である) 」は [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) で述べられている通りに解釈されるべきものである。

2.  リダイレクション・ベースの認可

OAuth はリソースオーナーがクライアントに認可を与える際にトークンを用いる。一般的にトークンクレデンシャルの発行は、リソースオーナーの要求を受けてサーバーが行う。その際、サーバーはトークン発行前にリソースオーナーのアイデンティティを (通常はユーザー名とパスワードを使用して) 認証する。

サーバーがトークンクレデンシャルの提供を行う方法は複数存在する。このセクションでは、HTTP リダイレクションとリソースオーナーのユーザーエージェントを使った、ひとつの方法を定義している。このリダイレクション・ベースの認可方法には、3つのステップがある。

1. クライアントは、サーバーから (識別子と共有鍵の形式で) テンポラリクレデンシャルを取得する。テンポラリクレデンシャルは、認可プロセス中のアクセス要求を識別するために利用される。
2. リソースオーナーは、クライアントからの (テンポラリクレデンシャルによって識別される) アクセス要求をサーバーが許可することについて、承認を行う。
3. クライアントはテンポラリクレデンシャルを用い、サーバーに対してトークンクレデンシャルをリクエストする。これにより、リソースオーナーの保護されたリソースへのアクセスが可能になる。

サーバーは、トークンクレデンシャル発行後、テンポラリクレデンシャルを破棄しなければならない (MUST)。テンポラリクレデンシャルには有効期限を設けることを推奨する (RECOMMENDED)。サーバーは、クライアントに対して発行済のトークンクレデンシャルを、リソースオーナーが破棄できるようにするべきである (SHOULD)。

クライアントがこれらのステップを行えるように、サーバーは以下の3つのエンドポイント URI を知らせる必要がある。

テンポラリクレデンシャルリクエスト

テンポラリクレデンシャルを取得するため、クライアントに用いられるエンドポイント。(Section 2.1 (テンポラリクレデンシャル) 参照)

リソースオーナー認可

認可を与えるため、リソースオーナーがリダイレクトされるエンドポイント。(Section 2.2 (リソースオーナー認可) 参照)

トークンリクエスト

テンポラリクレデンシャルを使ってトークンクレデンシャルを要求するため、クライアントに用いられるエンドポイント。(Section 2.3 (トークンクレデンシャル) 参照)

通達された3つの URI は、クエリー要素を含んでもよい (MAY)。([RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) 3節参照) ただし、エンドポイント利用時に URI に追加されるプロトコルパラメータとの競合を防ぐため、クエリーには oauth_ で始まるパラメータを含んではならない (MUST NOT)。

サーバーが3つのエンドポイントを通達、ドキュメント化する方法は、この仕様の範囲外である。クライアントは、本仕様で未定義な、トークンのサイズや他のサーバーで生成された値について、仮定をすべきではない。プロトコルパラメータは、転送時にエンコードが必要な値を含む場合がある (MAY)。クライアントとサーバーは、値の範囲を仮定してはならない。

2.1.  テンポラリクレデンシャル

クライアントは、テンポラリクレデンシャルリクエストのエンドポイントに、認証済みの (認証済みリクエスト) HTTP POST リクエストを行うことによって、サーバーからテンポラリクレデンシャルを取得する (サーバーが他の HTTP リクエストメソッドを推奨する場合はこの限りではない)。クライアントは、次の必須 (REQUIRED) パラメータをリクエストに加えることにより、(同じメソッドを利用して、他のパラメータに加えることで) リクエスト URI を構成する。

oauth_callback

リソースオーナー認証手順 (Section 2.2 (リソースオーナー認可)) 完了時に、サーバーがリソースオーナーをリダイレクトさせる絶対 URI。もしクライアントがコールバックを受け取ることができない、もしくはコールバック URI が他の手段を介して確立されたなら、このパラメータを使用しないことを示すために oob (大文字小文字を区別) をセットしなければならない (MUST)。

サーバーは、追加パラメータを指定してもよい (MAY)。

クライアントは、クライアントクレデンシャルのみを使用して認証要求を行う。クライアントは、空の oauth_token パラメータをリクエストから省略してもよい (MAY)。またその場合は、トークンシークレットパラメータとして、空文字を使用しなければならない (MUST)。

結果は HTTP レスポンス中にプレーンテキスト形式のクレデンシャルとして返されるため、サーバーは TLS や SSL などのトランスポート層のメカニズム (もしくはそれらに相当するセキュアチャネル) を用いなければならない (MUST)。

たとえば、クライアントは以下のような HTTPS リクエストを行う。

  POST /request_temp_credentials HTTP/1.1
  Host: server.example.com
  Authorization: OAuth realm="Example",
     oauth_consumer_key="jd83jd92dhsh93js",
     oauth_signature_method="PLAINTEXT",
     oauth_callback="http%3A%2F%2Fclient.example.net%2Fcb%3Fx%3D1",
     oauth_signature="ja893SD9%26"

サーバーは、必ずリクエストを検証 (リクエストの妥当性検証)しなければならない (MUST)。リクエストが有効な場合、サーバーはクライアントに (識別子と共有鍵の形式で) テンポラリクレデンシャルを返す。テンポラリクレデンシャルは、ステータスコード 200 (OK) とともに、レスポンスボディーに [W3C.REC‑html40‑19980424] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.0 Specification,” April 1998.) で定義された application/x-www-form-urlencoded 形式で含められる。

レスポンスには次の必須 (REQUIRED) パラメータが含まれる。

oauth_token

テンポラリクレデンシャルの識別子

oauth_token_secret

テンポラリクレデンシャルの共有鍵

oauth_callback_confirmed

必ず存在しなければならない (MUST)、かつ true に設定する。このパラメータは、以前のバージョンと区別するために使用される。

パラメータ名に 'token' が含まれていても、このクレデンシャルはトークンクレデンシャルではないが、次の2つのステップで、トークンクレデンシャルと同様の使い方がされることに注意。

例 (改行は掲載上の都合による)

  HTTP/1.1 200 OK
  Content-Type: application/x-www-form-urlencoded

  oauth_token=hdk48Djdsa&oauth_token_secret=xyz4992k83j47x0b&
  oauth_callback_confirmed=true

2.2.  リソースオーナー認可

クライアントは、サーバーにトークンクレデンシャルを要求する前に、ユーザをサーバーに移動させて要求に対する認可を得なければならない (MUST)。クライアントはリソースオーナー認可エンドポイント URI に以下の必須 (REQUIRED) クエリーパラメータを追加して、リクエスト URI を構成する。

oauth_token

Section 2.1 (テンポラリクレデンシャル)で oauth_token パラメータの値として得られるテンポラリクレデンシャルの識別子。サーバーはこのパラメータを任意とすることもできるが、その場合はリソースオーナーの識別子を示す代替手段を提供しなければならない (MUST)。

サーバーはこの他にもパラメータを指定することもできる (MAY)。

クライアントは、HTTP リダイレクトレスポンスもしくはリソースオーナーのユーザーエージェントがサポートする何らかの代替手段を用いて、リソースオーナーを前述で構成された URI にリダイレクトさせる。このリクエストでは HTTP GET メソッドを用いなければならない (MUST)。

例: クライアントはリソースオーナーのユーザーエージェントをリダイレクトさせ、以下の HTTPS リクエストを実行させる。

  GET /authorize_access?oauth_token=hdk48Djdsa HTTP/1.1
  Host: server.example.com

サーバーの認可リクエストの処理方法については、TLS や SSL などのセキュアチャネルの利用有無とともにこの仕様の範囲外であるが、サーバーはまず最初にリソースオーナーのアイデンティティを検証しなければならない (MUST)。

リソースオーナーに要求されたアクセス権の認可を求める際、サーバーはアクセス権を要求しているクライアントの情報をリソースオーナーに提示するべきである (SHOULD)。その際はクライアント識別子と関連付けられたテンポラリクレデンシャルを利用する。このような情報を表示する際、サーバーはその情報が検証済みかどうか明示するべきである (SHOULD)。

リソースオーナーから認可の可否を受け取った後、コールバック URI が oauth_callback パラメータもしくはその他の方法によって提供されている場合、サーバーはリソースオーナーをそのコールバック URI にリダイレクトさせる。

アクセス権を認可したリソースオーナーが、クライアントに戻されたリソースオーナーと同一であることを確認するため、サーバーは検証コードを生成しなければならない (MUST)。検証コードは推測困難な値であり、リソースオーナーを通じてクライアントに渡され、リソースオーナー認可プロセス完了のために必須となる (REQUIRED)。サーバーはコールバック URI のクエリーパラメータに以下の必須パラメータを追加して、リクエスト URI を構成する。

oauth_token

クライアントから受け取ったテンポラリクレデンシャルの識別子。

oauth_verifier

検証コード。

コールバック URI が既にクエリー要素を含む場合、サーバーは既存のクエリーの後ろに OAuth パラメータを追加しなければならない (MUST)。

例: サーバーはリソースオーナーのユーザーエージェントをリダイレクトさせ、以下の HTTP リクエストを実行させる。

  GET /cb?x=1&oauth_token=hdk48Djdsa&oauth_verifier=473f82d3 HTTP/1.1
  Host: client.example.net

クライアントがコールバック URI を提示しない場合、サーバーは検証コードを表示し、リソースオーナーに対して手動でクライアントに認可処理の完了を伝えるよう指示すべきである (SHOULD)。クライアントが何らかの制約を持つデバイス上で動作していることを把握している場合、サーバーは検証コードを手入力に適した形式で提供すべきである (SHOULD)。

2.3.  トークンクレデンシャル

クライアントは認証済み (認証済みリクエスト) HTTP POST リクエストをトークンリクエストエンドポイントに送信し、サーバーからトークンクレデンシャルを取得する。(サーバーが他の HTTP リクエストメソッドを推奨する場合はこの限りではない) クライアントは (同じフィールドに格納される他プロトコルのパラメータに加え) 以下の必須 (REQUIRED) パラメータをリクエストに追加してリクエスト URI を構成する。

oauth_verifier

前ステップでサーバーから受け取った検証コード。

リクエストを行う際、クライアントはテンポラリクレデンシャル同様クライアントクレデンシャルを用いて認証する。テンポラリクレデンシャルは、認証済みリクエスト中でトークンクレデンシャルの代わりに用いられ、oauth_token パラメータの値として渡される。

リクエスト結果は HTTP レスポンス中のプレーンテキストとして返されるため、サーバーは TLS や SSL などのトランスポート層のメカニズム (もしくはそれらに相当するセキュアチャネル) を用いなければならない (MUST)。

例: クライアントは以下の HTTPS リクエストを行う。

  POST /request_token HTTP/1.1
  Host: server.example.com
  Authorization: OAuth realm="Example",
     oauth_consumer_key="jd83jd92dhsh93js",
     oauth_token="hdk48Djdsa",
     oauth_signature_method="PLAINTEXT",
     oauth_verifier="473f82d3",
     oauth_signature="ja893SD9%26xyz4992k83j47x0b"

サーバーはリクエストの妥当性を検証 (リクエストの妥当性検証)し、リソースオーナーがクライアントにトークンクレデンシャルを提供することを認可していることを確認し、テンポラリクレデンシャルが期限切れおよび使用済みでないことを確認しなければならない (MUST)。サーバーはさらにクライアントから受け取った検証コードも検証しなければならない (MUST)。リクエストが有効で認可済みの場合は、ステータスコード 200 (OK) とともにレスポンスボディーに [W3C.REC‑html40‑19980424] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.0 Specification,” April 1998.) で定義された application/x-www-form-urlencoded 形式でトークンクレデンシャルを含める。

レスポンスは以下の必須 (REQUIRED) パラメータを含む。

oauth_token

トークン識別子

oauth_token_secret

トークン共有鍵

例:

  HTTP/1.1 200 OK
  Content-Type: application/x-www-form-urlencoded

  oauth_token=j49ddk933skd9dks&oauth_token_secret=ll399dj47dskfjdk

サーバーはスコープ、有効期間、およびリソースオーナーが承認したその他の属性を保持し、クライアントが発行済トークンクレデンシャルを用いてリクエストを行う際にそれらの制限を実施しなければならない。

ひとたびトークンクレデンシャルを受け取ると、クライアントはリソースオーナーの代理として、認証済みリクエスト (認証済みリクエスト)により保護されたリソースにアクセスし続けることができる。その際、取得したトークンクレデンシャルとともにクライアントクレデンシャルを用いる。

3.  認証済みリクエスト

クライアントは [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.) で定義されている HTTP 認証メソッドにより、認証済み HTTP リクエストを行うことができる。これらのメソッドを使うクライアントは、クレデンシャル (ユーザ名とパスワード等) を使うことで、保護されたリソースへのアクセスが可能となり、サーバーはその権限の妥当性を検証することができる。代理リクエストとしてこれらのメソッドを利用する場合、クライアントはリソースオーナーの役割を担うものと仮定される必要がある。

OAuth は各リクエストに際し、クライアントを識別するものと、リソースオーナーを識別するもの、2つのクレデンシャルを含むようにデザインされたメソッドを提供する。クライアントは、リソースオーナーの代理として認証済みリクエストを行う前に、まずリソースオーナーによって認可済みのトークンを取得しなければならない。Section 2 (リダイレクション・ベースの認可) は、クライアントがリソースオーナーにより認可されたトークンを取得するひとつの方法である。

クライアントクレデンシャルはユニークな識別子および、識別子に紐付けられた共有鍵、もしくは RSA 鍵ペアの形式をとる。認証済みリクエストを送信するに先立ち、クライアントはサーバーとのクレデンシャルを確立する。ただし、その手順や要件については、本仕様の範囲外のため論じない。実装者は、クライアントの認証情報を使うセキュリティ上の影響をよく考えるべきである。いくつかの懸念点については Section 4.6 (クライアントクレデンシャルの秘匿性) に記載している。

認証済みリクエストを送信するに当たり、サーバーの設定に関する知識が必要となる。OAuth ではリクエスト上でプロトコルパラメータを送信するメソッド (Section 3.5 (パラメータの送信)) と、クライアントがクレデンシャルの所有権を証明するために利用する方法 (Section 3.4 (署名)) が、それぞれ複数存在する。クライアントがこれらの設定を検知する方法については、本仕様の範囲外とする。

3.1.  リクエストの実行

認証済みリクエストには、いくつかのプロトコルパラメータが含まれる。各パラメータ名は oauth_ で始まり、パラメータ名は大文字小文字を区別する。クライアントは、一連のプロトコルパラメータ値を計算し、下記のようにして HTTP リクエストに追加することで、認証済みリクエストを行う。

1. クライアントは下記の (特に指定されていない限り) 必須な (REQUIRED) プロトコルパラメータに、それぞれ値を割り当てる。

   oauth_consumer_key

   クライアントクレデンシャルの識別子部分 (ユーザ名に当たる)。パラメータ名は本仕様の以前のバージョンで使用されていた用語 (Consumer Key) を反映しており、後方互換のためにそのまま使用する。

   oauth_token

   リソースオーナーとリクエストを関連付けるトークン値。リクエストがリソースオーナーと関連付けられていない場合 (トークンが利用できない場合)、パラメータを省略することができる。

   oauth_signature_method

   Section 3.4 (署名) で定義されている、クライアントがリクエストに署名するために使用する署名メソッドの名前。

   oauth_timestamp

   Section 3.3 (ノンス値とタイムスタンプ) で定義されているタイムスタンプ値。署名メソッドとして PLAINTEXT を使用している場合、省略することができる。

   oauth_nonce

   Section 3.3 (ノンス値とタイムスタンプ) で定義されているノンス値。署名メソッドとして PLAINTEXT を使用している場合、省略することができる。

   oauth_version

   オプション (OPTIONAL)。追加する場合、1.0でなければならない。本仕様で定義された認可手順のバージョンを示す。

2. プロトコルパラメータは Section 3.5 (パラメータの送信) に記載された転送メソッドのいずれかを使い、リクエストに追加される。各パラメータはリクエストにつき、二度以上含まれてはならない。
3. クライアントは Section 3.4 (署名) に記載されている通り、oauth_signature パラメータの値を計算し、割り当てる。このパラメータは前のステップと同じ方法で、リクエストに追加する。
4. クライアントが認証済みリクエストをサーバーに送信する。

例えば、下記のような HTTP リクエストを認証付きで実行するとする (c2&a3=2+q はフォームエンコードされたエンティティボディを強調するために使用)

  GET /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
  Host: example.com
  Content-Type: application/x-www-form-urlencoded

  c2&a3=2+q

クライアントはクライアントクレデンシャル、トークンクレデンシャル、現在のタイムスタンプ、ユニークなノンス、署名メソッドとして HMAC-SHA1 を使用することを示し、プロトコルパラメータに値を割り当てる。

  oauth_consumer_key:     9djdj82h48djs9d2
  oauth_token:            kkk9d7dh3k39sjv7
  oauth_signature_method: HMAC-SHA1
  oauth_timestamp:        137131201
  oauth_nonce:            7d8f3e4a

クライアントが OAuth HTTP Authorization ヘッダーフィールドを使って、リクエストにプロトコルパラメータを追加する。

  Authorization: OAuth realm="Example",
                 oauth_consumer_key="9djdj82h48djs9d2",
                 oauth_token="kkk9d7dh3k39sjv7",
                 oauth_signature_method="HMAC-SHA1",
                 oauth_timestamp="137131201",
                 oauth_nonce="7d8f3e4a"

その後 oauth_signature パラメータの値を計算し、リクエストに追加。そして HTTP リクエストをサーバーに送信する。

  GET /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
  Host: example.com
  Content-Type: application/x-www-form-urlencoded
  Authorization: OAuth realm="Example",
                 oauth_consumer_key="9djdj82h48djs9d2",
                 oauth_token="kkk9d7dh3k39sjv7",
                 oauth_signature_method="HMAC-SHA1",
                 oauth_timestamp="137131201",
                 oauth_nonce="7d8f3e4a",
                 oauth_signature="djosJKDKJSD8743243%2Fjdk33klY%3D"

  c2&a3=2+q

3.2.  リクエストの妥当性検証

認証済みリクエストを受け取ったサーバーは、以下のようにその妥当性を検証しなければならない (MUST)。

• リクエスト署名を独自に再計算し (Section 3.4 (署名))、ooauth_signature パラメータとしてクライアントから受け取った値と比較を行う。
• HMAC-SHA1 または RSA-SHA1 署名方式を使用している場合、クライアントから受け取ったノンス値 / タイムスタンプ / トークン (存在する場合のみ) の組合せが以前のリクエストで使用されたものではないことを検証すること。(サーバーはタイムスタンプが古いままのリクエストを拒否してもよい (MAY) (Section 3.3 (ノンス値とタイムスタンプ)))
• トークンが存在する場合、トークンの示すクライアントの認可情報の範囲とステータスを検証すること。(サーバーは トークンの使用を、発行対象となったクライアントのみに制限してもよい (MAY))
• oauth_version パラメータが存在する場合、その値が 1.0 であるか検証すること。

リクエストの妥当性検証に失敗した場合、サーバーは適切な HTTP ステータスコードを返すべきである (SHOULD)。その際、リクエストボディーで詳細なリクエスト拒否理由を通知してもよい (MAY)。

サーバーは、サポート外のパラメータ、サポート外の署名方式、パラメータ不足、重複したプロトコルパラメータを持ったリクエストを受け取った場合、ステータスコード 400 (Bad Request) を返すべきである (SHOULD)。サーバーは、不正なクライアントクレデンシャル、不正または期限切れのトークン、不正または使用済みのノンス値を含むリクエストを受け取った場合、ステータスコード 401 (Unauthorized) を返すべきである (SHOULD)。

3.3.  ノンス値とタイムスタンプ

タイムスタンプは正の整数でなければならない (MUST)。サーバーのドキュメントで規定されていない限り、タイムスタンプは 1970/01/01 00:00:00 GMT を起点にした経過秒数で表される。

ノンス値はクライアントによってユニークに生成されたランダムな文字列である。ノンス値があることでサーバーは、リクエストが過去に実行されていないことの検証や、安全でない通信チャネルを使ってリクエストされた場合の再現攻撃を防ぐことができる。ノンス値は同じタイムスタンプ、クライアントクレデンシャル、トークンの組み合わせを持ったすべてのリクエストに対し、ユニークでなければならない (MUST)。

サーバーは、チェック目的でノンス値を永久に保持しておく必要がないよう、タイムスタンプの古いリクエストを拒否する期間的制限を設けてもよい (MAY)。ただし、この制限はクライアントとサーバーのクロック同期が一定の水準にある前提であることに注意すること。サーバーはクライアントがサーバーのクロックと同期する方法を提供してもよいし (MAY)、別途、信頼の置けるタイムサービスを利用して双方のシステムを同期させてもよい。クロック同期方式の詳細については、この仕様書の範囲外とする。

3.4.  署名

OAuth 認証済みリクエストは、oauth_consumer_key と oauth_token という2つのクレデンシャル情報を持つことができる。サーバーがリクエストの正当性を検証し、認可されていないアクセスを阻止するため、クライアントはクレデンシャルの正当なオーナーであることを証明する必要がある。これはクレデンシャルの共有鍵 (または RSA 鍵) 部分を使用することにより実現される。

OAuth はクライアントがクレデンシャルの正当なオーナーであることを証明する方法として HMAC-SHA、RSA-SHA1、PLAINTEXT の3つを提供する。PLAINTEXT に署名は含まれないが、これらは一般的に署名方式とみなされている。加えて、RSA-SHA1 では、クライアントクレデンシャルにおける共有鍵の代替として、RSA 鍵が利用される。

各実装がそれぞれの要件を保てるよう、OAuth では特定の署名方式を強制しない。サーバーは独自の方式を実装したり、規定することができる。本仕様の範囲外であるため、特定の方式の推奨はしない。実装者はサポートする方式を決定する前に、セキュリティに関する考慮事項 (Security Considerations)を精査するべきである。

クライアントは、どの署名方式を使用するかを oauth_signature_method パラメータを用いて宣言する。生成した署名 (またはそれと等価なもの) は、oauth_signature パラメータに含める。サーバーは各方式で規定されている方法で署名を検証する。

oauth_signature パラメータを除き、署名のプロセスでリクエストやパラメータが変更されることはない。

3.4.1.  シグニチャベースストリング

シグニチャベースストリングは、いくつかの HTTP リクエストの構成要素を、一貫し、かつ再現可能な形で連結した単一の文字列である。この文字列は HMAC-SHA1 および RSA-SHA1 署名方式への入力値となる。

シグニチャベースストリングは HTTP リクエストにおける以下の構成要素を含む。

• HTTP リクエストメソッド (例: GET、POST 等)
• リクエストの HTTP Host ヘッダーで示されるオーソリティ。
• リクエスト URI 中のパスとクエリー要素。
• oauth_signature を除くプロトコルパラメータ。
• リクエストのエンティティボディーに含まれる、Section 3.4.1.3 (リクエストパラメータ) で定義された厳格な制約を満たすパラメータ。

シグニチャベースストリングは HTTP リクエスト全体をカバーするものではない。特に注意すべきは、多くのリクエストにおいて、エンティティボディーや HTTP エンティティヘッダーが含まれないことである。よって、サーバーが SSL や TLS およびその他の防衛策を施さない限り、シグニチャベースストリングに含まれないリクエストコンポーネントの信憑性は検証不可能であることに留意すること。

3.4.1.1.  シグニチャベースストリングの構築

シグニチャベースストリングは以下の HTTP リクエスト要素を順番に連結して構築される。

1. HTTP リクエストメソッド (大文字)。例: HEAD、GET、POST 等。独自の HTTP メソッドを利用する場合は、エンコード (パーセントエンコーディング)しなければならない (MUST)。
2. 文字 & (ASCII code 38)
3. Section 3.4.1.2 (ベースストリング URI) に示されるベースストリング URI をエンコード (パーセントエンコーディング)した文字列。
4. 文字 & (ASCII code 38)
5. Section 3.4.1.3.2 (パラメータのノーマライゼーション) に示されるノーマライズされたリクエストパラメータをエンコード (パーセントエンコーディング)した文字列。

例えば、以下のような HTTP リクエストがあったとする。

  GET /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
  Host: example.com
  Content-Type: application/x-www-form-urlencoded
  Authorization: OAuth realm="Example",
                 oauth_consumer_key="9djdj82h48djs9d2",
                 oauth_token="kkk9d7dh3k39sjv7",
                 oauth_signature_method="HMAC-SHA1",
                 oauth_timestamp="137131201",
                 oauth_nonce="7d8f3e4a",
                 oauth_signature="djosJKDKJSD8743243%2Fjdk33klY%3D"

  c2&a3=2+q

この時、このリクエストに対するシグニチャベースストリングは以下のようになる。(改行は掲載上の都合による)

  GET&http%3A%2F%2Fexample.com%2Frequest&a2%3Dr%2520b%26a3%3D2%2520q%
  26a3%3Da%26b5%3D%253D%25253D%26c%2540%3D%26c2%3D%26oauth_consumer_k
  ey%3D9djdj82h48djs9d2%26oauth_nonce%3D7d8f3e4a%26oauth_signature_me
  thod%3DHMAC-SHA1%26oauth_timestamp%3D137131201%26oauth_token%3Dkkk9
  d7dh3k39sjv7

3.4.1.2.  ベースストリング URI

ベースストリング URI には、リクエスト対象リソースを示す http もしくは https URI を構築した上で、リクエスト URI のスキーマ、オーソリティおよびパス [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) を以下のように含める。

1. スキーマおよびホストは小文字でなければならない (MUST)。
2. ホストとポート番号はリクエスト中の HTTP Host ヘッダーの値と同一でなければならない (MUST)。
3. ポート番号がそのスキーマのデフォルトポートでない場合、必ずポート番号を含めなければならない (MUST)。またデフォルトの場合はポート番号を除外しなければならない (MUST)。特に、HTTP リクエスト [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) の場合にはポート80、HTTPS リクエスト [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) の場合にはポート443を除外しなければならない (MUST)。その他のデフォルト値以外のポート番号は全て含めなければならない (MUST)。

例えば、以下のような HTTP リクエストがあったとする。

  GET /r%20v/X?id=123 HTTP/1.1
  Host: EXAMPLE.COM:80

このときベースストリング URI は次のようになる。 http://example.com/r%20v/X

また以下のような HTTPS リクエストがあったとする。

  GET /?q=1 HTTP/1.1
  Host: www.example.net:8080

この場合のベースストリング URI は次のようになる。 https://www.example.net:8080/

3.4.1.3.  リクエストパラメータ

リクエストパラメータの一貫性と再現性を保証するため、パラメータは集められ、元の形式にデコードされる。その後ソートを行い、元のエンコード方式と異なる場合のある方法でエンコードされ、ひとつの文字列に連結される。

3.4.1.3.1.  Parameter Sources

下記に含まれるパラメータ群は、名前と値のペアのリストにまとめられる。

• [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) 3.4節で定義されている HTTP リクエスト URI のクエリー要素。クエリー要素は application/x-www-form-urlencoded 文字列として名前と値が分割され、[W3C.REC‑html40‑19980424] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.0 Specification,” April 1998.) 17.13.4節で定義された方法でデコードし、名前と値のペアのリストに分解される。
• OAuth HTTP Authorization ヘッダフィールド (Section 3.5.1 (Authorization ヘッダー)) が存在する場合はその値。ヘッダーのコンテンツは realm パラメータを除き、すべて名前と値のペアに分解される。パラメータ値は Section 3.5.1 (Authorization ヘッダー) で定義された方法でデコードされる。
• 以下の条件を満たす場合のみ、HTTP リクエストエンティティボディ。
  • エンティティボディがシングルパートである。
  • エンティティボディが [W3C.REC‑html40‑19980424] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.0 Specification,” April 1998.) で定義されたコンテンツタイプ application/x-www-form-urlencoded のエンコード要件を満たしている。
  • HTTP リクエストエンティティヘッダが application/x-www-form-urlencoded 形式の Content-Type ヘッダーフィールドセットを含む。
  エンティティボディは [W3C.REC‑html40‑19980424] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.0 Specification,” April 1998.) 17.13.4節の方法でデコードされた名前と値のペアのリストに分解される。

oauth_signature パラメータが存在した場合は、それをシグニチャベースストリングから除外しなければならない。明示的にリクエストに含まれたパラメータ以外は、シグニチャベースストリングから除外されなければならない (oauth_version パラメータが省略された場合等)。

例えば下記のような HTTP リクエストの場合

    GET /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
    Host: example.com
    Content-Type: application/x-www-form-urlencoded
    Authorization: OAuth realm="Example",
                   oauth_consumer_key="9djdj82h48djs9d2",
                   oauth_token="kkk9d7dh3k39sjv7",
                   oauth_signature_method="HMAC-SHA1",
                   oauth_timestamp="137131201",
                   oauth_nonce="7d8f3e4a",
                   oauth_signature="djosJKDKJSD8743243%2Fjdk33klY%3D"

    c2&a3=2+q

下記の (デコード済み) パラメータがシグニチャベースストリングに含まれる。

b5 の値は =%3D であり、 == ではないことに注意。c@ と c2 の値は空である。本仕様で定義しているシグニチャベースストリングの構築を目的としたエンコードルールでは、エンコードされたスペース (ASCII コード 32) を表す + 文字 (ASCII コード 43) を除外しているが、これは application/x-www-form-urlencoded でエンコードされた値では広く利用されており、a3 パラメータインスタンスのひとつで示されるように (このリクエストでは a3 は2回登場する)、正しくデコードされなければならない。

3.4.1.3.2.  パラメータのノーマライゼーション

Section 3.4.1.3 (リクエストパラメータ) で集められたパラメータは、以下のようにひとつの文字列にノーマライズされる。

1. まず、各パラメータの名前と値をエンコード (パーセントエンコーディング)する。
2. パラメータはバイト値昇順を使い、名前でソートされる。2つ以上のパラメータが同じ名前を持つ場合、値でソートされる。
3. 各パラメータの名前は = 文字 (ASCII コード 61) をセパレータとして、対応する値と (値が空であっても) 連結される。
4. ソート済みの名前と値のペアは、& 文字 (ASCII コード 38) をセパレータとして、ひとつの文字列に連結される。

例えば前節から引き継いだパラメータは、以下のようにノーマライズされる。

エンコード済み

ソート済み

連結されたペア

その後、これらのパラメータを連結し、単一文字列とする。(改行は掲載上の都合による)

  a2=r%20b&a3=2%20q&a3=a&b5=%3D%253D&c%40=&c2=&oauth_consumer_key=9dj
  dj82h48djs9d2&oauth_nonce=7d8f3e4a&oauth_signature_method=HMAC-SHA1
  &oauth_timestamp=137131201&oauth_token=kkk9d7dh3k39sjv7

3.4.2.  HMAC-SHA1

HMAC-SHA1 署名方式は、[RFC2104] (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” February 1997.) で規定される、HMAC-SHA1 署名アルゴリズムを使用する。

  digest = HMAC-SHA1 (key, text)

HMAC-SHA1 関数の変数は、次のように使用される。

text

シグニチャベースストリング (Section 3.4.1.1 (シグニチャベースストリングの構築) 参照) の値に設定。

key

下記を連結した値に設定。

1. エンコード (パーセントエンコーディング)されたクライアント共有鍵。
2. & (ASCII コード 38) (どちらの共有鍵が空の場合でも含まなければならない (MUST))
3. エンコード (パーセントエンコーディング)済みのトークン共有鍵。

digest

結果のバイト文字列を base64 エンコード ([RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) 6.8節参照) した、oauth_signature プロトコルパラメータを設定。

3.4.3.  RSA-SHA1

RSA-SHA1 署名方式は、[RFC3447] (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.) 8.2節 (別名 : PKCS#1) で規定されている、RSASSA-PKCS1-v1_5 署名アルゴリズムを使用しており、SHA-1 は EMSA-PKCS1-v1_5 のハッシュ化関数として利用される。この方式を使用するために、クライアントは、サーバーに RSA 公開鍵 (この仕様では範囲外) を含むクライアントクレデンシャルを発行してもらわなければならない (MUST)。

シグニチャベースストリングは、[RFC3447] (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.) 8.2.1節に基づき、RSA 秘密鍵を使用して署名される。

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

K

クライアントの RSA 秘密鍵を設定。

M

シグニチャベースストリング (Section 3.4.1.1 (シグニチャベースストリングの構築) 参照) の値に設定。

S

結果のバイト文字列を base64 エンコード ([RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) 6.8節参照) した、oauth_signature プロトコルパラメータを設定。

サーバーは、[RFC3447] (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.) 8.2.2節 に基づき、シグニチャの妥当性を検証する。

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

(n, e)

クライアントの RSA 公開鍵を設定。

M

シグニチャベースストリング (Section 3.4.1.1 (シグニチャベースストリングの構築) 参照) の値に設定。

S

クライアントから受け取った、oauth_signature プロトコルパラメータのバイト文字列を設定。

3.4.4.  PLAINTEXT

PLAINTEXT 方式は、署名アルゴリズムを使用しない。この方式はトランスポート層のメカニズムとして、TLS や SSL (もしくはこれらと同等のセキュアチャネル) を使用しなければならない (MUST)。この方式はシグニチャベースストリングや、oauth_timestamp、oauth_nonce パラメータを使用しない。

oauth_signature プロトコルパラメータは、下記を連結した値に設定する。

1. エンコード (パーセントエンコーディング)済みのクライアント共有鍵
2. & (ASCII コード 38) (どちらの共有鍵が空の場合でも含まなければならない (MUST))
3. エンコード (パーセントエンコーディング)済みのトークン共有鍵

3.5.  パラメータの送信

OAuth 認可リクエストを行う際、プロトコルパラメータおよび oauth_ プレフィックスを含むその他全てのパラメータは、リクエスト中の、以下好ましい順に挙げたいずれか一カ所に含まれる (SHALL)。

1. HTTP Authorization ヘッダーフィールド。(Section 3.5.1 (Authorization ヘッダー) 参照)
2. HTTP リクエストエンティティボディー。(Section 3.5.2 (フォームエンコードボディー) 参照)
3. HTTP リクエスト URI クエリー。（Section 3.5.3 (リクエスト URI クエリー) 参照)

これら3つの方法に加え、プロトコルパラメータをリクエストに含める別の方法が、今後の拡張仕様で定義される場合がある (MAY)。

3.5.1.  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,” June 1999.) で定義される HTTP Authorization ヘッダーフィールドを用いて送信される。その際 auth-scheme 名を OAuth (大文字/小文字を区別) とする。

例:

  Authorization: OAuth realm="Example",
     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"

プロトコルパラメータは以下のように Authorization ヘッダーフィールドに含まれるものとする (SHALL)。

1. パラメータ名と値はパラメータエンコーディング (パーセントエンコーディング)に従いエンコーディングされる。
2. 各パラメータ名の直後には、= (ASCII code 61)、" (ASCII code 34)、パラメータ値 (空白も可 (MAY))、そして " (ASCII code 34) が続く。
3. パラメータは , (ASCII code 44) で区切られる。この際オプションとして [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.) にある "linear whitespace" を用いることもできる (OPTIONAL)。
4. オプションで realm パラメータを追加することができる (OPTIONAL)。([RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.) セクション1.2参照)

サーバーは、クライアントからの保護されたリソースへのリクエストに対して HTTP WWW-Authenticate レスポンスヘッダーフィールドを返すことで、 OAuth auth-scheme をサポートしていることを示すことができる (MAY)。[RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.) にあるように、そのようなレスポンスは HTTP WWW-Authenticate ヘッダーフィールドを含むことができる (MAY)。

例:

  WWW-Authenticate: OAuth realm="http://server.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,” June 1999.) セクション1.2参照)

3.5.2.  フォームエンコードボディー

プロトコルパラーメータは HTTP リクエストエンティティボディーを用いて送信することもできる。ただしその場合は以下の条件を満たす必要がある (REQUIRED)。

• エンティティボディーがシングルパートである。
• エンティティボディーが [W3C.REC‑html40‑19980424] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.0 Specification,” April 1998.) で定義される application/x-www-form-urlencoded コンテントタイプのエンコーディング条件を満たす。
• HTTP リクエストエンティティヘッダーが Content-Type ヘッダーフィールドを含み、その値が application/x-www-form-urlencoded である。

例 (改行は掲載上の都合による)

  oauth_consumer_key=0685bd9184jfhq22&oauth_token=ad180jjd733klr
  u7&oauth_signature_method=HMAC-SHA1&oauth_signature=wOJIO9A2W5
  mFwDgiDvZbTSMK%2FPY%3D&oauth_timestamp=137131200&oauth_nonce=4
  572616e48616d6d65724c61686176&oauth_version=1.0

3.5.3.  リクエスト URI クエリー

プロトコルパラメータは、HTTP リクエスト URI に [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) セクション3で定義されるクエリーパラメータとして付与し、送信することができる。

例 (改行は掲載上の都合による)

  GET /example/path?oauth_consumer_key=0685bd9184jfhq22&
  oauth_token=ad180jjd733klru7&oauth_signature_method=HM
  AC-SHA1&oauth_signature=wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%
  3D&oauth_timestamp=137131200&oauth_nonce=4572616e48616
  d6d65724c61686176&oauth_version=1.0 HTTP/1.1

3.6.  パーセントエンコーディング

既存のパーセントエンコーディング手法では、一貫したシグニチャベースストリングの構成は保証されない。以下に示すパーセントエンコーディング手法は [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) および [W3C.REC‑html40‑19980424] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.0 Specification,” April 1998.) で定義されたパーセントエンコーディング手法を置き換えるために定義されたものではない。この手法はシグニチャベースストリングおよび authorization ヘッダーフィールド (Authorization ヘッダー)のエンコーディングにのみ用いられるものである。

この仕様書では以下のようにパーセントエンコーディング手法を定義する。

1. テキスト値がまだ [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.) で定義される UTF-8 オクテットにエンコードされていない場合は、そのようにエンコードする。人間に利用されないバイナリ値は、この行程をスキップする。
2. 値を以下の [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) で定義されたパーセントエンコーディング手法に従ってエスケープする。
   • [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) のセクション2.3で定義された予約済みでない文字　(アルファベット, 数字, "-", ".", "_", "~")　はエンコードしてはならない (MUST NOT)。
   • その他の文字は全てエンコードしなければならない (MUST)。
   • エンコード文字を示す2文字の16進数値は大文字でなければならない (MUST)。

この手法は application/x-www-form-urlencoded で用いられるエンコード方式とは異なる。(例えばこの手法ではスペースは + ではなく %20 とエンコードされる) この手法は Web デベロップメントフレームワークが提供するパーセントエンコーディングとも異なる可能性がある (MAY)。(異なる文字をエンコードしたり、小文字の16進数文字を使うことなどが想定される)

4.  Security Considerations

[RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.) にあるように、一般的に最大のリスク要因は、プロトコルの本質ではなくそのプロトコルを利用する際のポリシーや手続きにあることが多い。実装者には、このプロトコルがどの程度自らのセキュリティ用件を満たすかを評価することが推奨される。

4.1.  RSA-SHA1 署名方式

RSA-SHA1 署名を用いた認可リクエストでは、トークン共有鍵やクライアント共有鍵は利用されない。そのためこのリクエストは、完全にクライアントが署名生成に使用する秘密鍵の秘匿性に依存する。

4.2.  リクエストの機密性

このプロトコルはリクエストの正当性検証のメカニズムを提供するが、リクエストの機密性は保証されない。その他の予防策が施されていない場合、盗聴者はリクエストコンテンツ全体を傍受することができる。サーバーはリクエスト中で送信されているデータの性質を熟慮し、機密情報を含むリソースを保護するために TLS メカニズムを採用するべきである。

4.3.  サーバーのなりすまし

このプロトコルはサーバーの信憑性を検証するものではない。敵意を持つ第三者がこの点を悪用し、クライアントのリクエストを傍受して改竄もしくは不正なレスポンスを返す可能性がある。サービスプロバイダーはサービス構築時にこのような攻撃を想定し、サーバーやリクエストレスポンスの信憑性が求められるリクエストでは TLS を採用するべきである。

4.4.  要認証コンテンツに対するプロキシおよびキャッシュ

HTTP Authorization スキーム (Authorization ヘッダー)はオプションであるが、[RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) は Authorization および WWW-Authenticate ヘッダーフィールドを元に要認証コンテンツの識別を行う。特にこれらのヘッダーフィールドを用いない場合、プロキシやキャッシュが原因となりリクエストの保護が機能しなくなる可能性がある。

例えば、プライベートな要認証コンテンツは公開アクセスできる形でキャッシュされる可能性がある。HTTP Authorization ヘッダーフィールド (Authorization ヘッダー)を用いないサーバーは、Cache-Control ヘッダーフィールドなどの他の手段を用いて、要認証コンテンツの保護を保証するべきである。

4.5.  認証情報のプレインテキストストレージ

クライアント共有鍵およびトークン共有鍵は、従来の認証システムにおけるパスワードと同様の機能を持つ。RSA-SHA1 以外の方法で使用される署名を計算するには、サーバーがそれらの鍵にプレインテキスト形式でアクセスできなければならない。最近の OS がユーザーの認証情報を不可逆なハッシュでのみ保存するのと比べると、これは対照的である。

もし攻撃者がこれらの鍵のアクセス権、もしくはサーバーの持つすべての鍵データベースへのアクセス権を奪い取った場合、攻撃者はリソースオーナーを装い、あらゆるアクションを起こすことが可能となる。そのため、サーバーはこれらの鍵を権限のない者から厳重に守らなければならない。

4.6.  クライアントクレデンシャルの秘匿性

クライアントアプリケーションが信頼性の低い組織の管理下に置かれるケースは少なくない。例えばクライアントがデスクトップアプリケーションで、ソースコードや実行形式のバイナリが公開されている場合、攻撃者が分析のためにコピーをダウンロードし、クライアントクレデンシャルを見付けてしまう可能性がある。

そういった場合、サーバーはクライアントのアイデンティティを検証する際、クライアントクレデンシャルのみを使うべきではない。可能であれば、IP アドレスのような他の要素も用いるべきである。

4.7.  フィッシング攻撃

本仕様や類似したプロトコルが広く実用化されると、リソースオーナーがパスワードを入力するウェブサイトにリダイレクトされることに慣れてくる可能性がある。これらのウェブサイトの信頼性を注意深く検証せず、リソースオーナーが認証情報を入力してしまうと、リソースオーナーのパスワードが攻撃者に盗まれてしまう可能性もある。

サーバーは、リソースオーナーにフィッシング攻撃のリスクについて情報提供を行い、簡単にウェブサイトの信頼性を検証できる手段を提供すべきである。クライアント開発者はユーザーエージェントとのやりとり (別窓や埋め込み等) におけるセキュリティ上の影響と、エンドユーザーがサーバーウェブサイトの信頼性を検証する能力について考慮すべきである。

4.8.  アクセスリクエストのスコープ

このプロトコルは、それ自体ではクライアントに許可するアクセス権限のスコープを定める方法を提供していない。しかし、ほとんどのアプリケーションは、アクセス権の細分化を必要としている。例えば、サーバーが特定の保護されたリソースへのアクセスを許可しても、他を許可しなかったり、制限のあるアクセス (読み取り専用等) のみ許可したい場合がある。

このプロトコルを実装する際、サーバーは、リソースオーナーがクライアントに対して許可したいアクセスの形式について考慮し、それを実現する機構を提供すべきである。サーバーは、リソースオーナーが自分の許可しようとしているアクセス権と、それがどんなリスクを持っているかについて理解していることを、注意深く確認すべきである。

4.9.  認証情報のエントロピー

トランスポート層のセキュリティプロトコルを使用しない場合、盗聴者は認証済みリクエストとシグニチャにアクセスし、クレデンシャルを暴くためにブルートフォース攻撃を仕掛けられる可能性がある。サーバーは、そのような攻撃に対して、少なくとも有効期間中は共有鍵が暴かれないよう、十分な長さでランダムな共有鍵にすべきである。

例えば、2週間共有鍵を有効にした場合、サーバーは、2週間以内にブルートフォース攻撃が共有鍵を暴くことが不可能であることを確認すべきである。勿論、サーバーは、十分な長さの鍵を用いて対処すべきである。

鍵を生成する Pseudo-Random Number Generator (疑似乱数生成器) が高い品質であることは重要である。ランダムな数列を生成していても、暗号解読やブルートフォース攻撃を容易にするようなパターンや脆弱性を持つ PRNG 実装は多い。実装者はこうした問題の無い安全な PRNG を使用すべきである。

4.10.  DoS 攻撃 / リソース枯渇攻撃

この仕様には、サーバーリソースを枯渇させる攻撃を可能にする特徴が多くある。例えば、サーバーにノンス値が使用済みかを検査するよう要求している。攻撃者が瞬時に多数のノンス値を使用できる場合、それらを検査するのにサーバーはリソースを枯渇させてしまうだろう。更に、リクエストの署名を検証するためにサーバーに高い計算能力を要求している。攻撃者は、不正なリクエストを大量に送る DoS 攻撃でこの計算能力を使い尽くそうとするだろう。

リソース枯渇攻撃は決してこの仕様だけの特有のものではないが、実装者はこの仕様が枯渇攻撃の方法を顕在化させていることに考慮し十分な設計を行うべきである。例えば、エントロピーの不足は、得てして、新たなエントロピーを待つ間に DoS や弱い (推測しやすい) 鍵をもたらすことになる。実装に当たりサーバーは、これらがアプリケーションに深刻なリスクをもたらすことを考慮して十分に設計すべきである。

4.11.  SHA-1 攻撃

HMAC-SHA1 署名方式、RSA-SHA1 署名方式で使用されている SHA-1 はコリジョン攻撃に対して多くの脆弱性を持つことが分かっている。この脆弱性は、HMAC-SHA1 署名方式の利用には影響無いようであるが、RSA-SHA1 署名方式には影響がある。NIST は、電子署名として SHA-1 を用いることを 2010 年までに段階的に廃止していくよう案内している。[NIST SHA‑1 Comments] (Burr, W., “NIST Comments on Cryptanalytic Attacks on SHA-1,” .)

実際のところ、この脆弱性を利用するのは難しく、利用者に重大なリスクをもたらすことはないが、より効率的な攻撃が可能になるかも知れず、サーバーは、SHA-1 が十分なレベルのセキュリティをアプリケーションにもたらすかを考える時、このことを留意しておくべきである。

4.12.  シグニチャベースストリングの制約

シグニチャベースストリングはこの仕様で定義された署名方式をサポートするために設計された。今後署名方式を追加する設計者は、シグニチャベースストリングの互換性、および設計におけるセキュリティ要件を評価すべきである。

多くのリクエストエンティティボディーおよびエンティティヘッダー、パラメータの出現順序などの情報は、シグニチャベースストリングには含まれない。このようにシグニチャベースストリングは HTTP リクエスト全体をカバーするものではないため、サーバーはシグニチャベースストリングに含まれない要素を保護するメカニズムを追加導入すべきである。

4.13.  Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) は HTTP リクエストが信頼されたもしくは認証済みのユーザから送信される Web ベースの攻撃である。認可取得時に攻撃者が CSRF 攻撃をしかけることで、攻撃者はユーザの同意無しに保護されたリソースへの認可を得ることができる。サーバーはすべてのプロトコル認可エンドポイントにおいて、CSRF 対策のベストプラクティスを熟慮するべきである (SHOULD)。

CSRF 攻撃は、クライアントの OAuth コールバック URI においても可能である。クライアントは OAuth コールバック URI で、クライアントサイトにおけるリソースオーナーがサーバーと OAuth 通信を完了させる意思のあることを検証することで、CSRF 攻撃を防ぐべきである。この種の CSRF 攻撃の防御策はこの仕様の範囲外である。

4.14.  User Interface Redress

サーバーは認可プロセスにおける UI Redress 攻撃 ("クリックジャッキング" としても知られる) を防ぐべきである。この仕様執筆時においては、完全な UI redress の対策法は存在しない。サーバーは以下の技術により UI redress のリスクを軽減することができる。

• Javascript によるフレーム解除。
• Javascript によるフレーム解除、および認可ページでブラウザの Javascript を有効にすることを要求。
• ブラウザ固有のフレーム対策技術。
• OAuth token 発行前にパスワード再入力を要求。

4.15.  再認可の自動処理

サーバーは既にリソースオーナーの認可を得たクライアントからの認可リクエスト (Section 2.2 (リソースオーナー認可)) を自動的に処理することを望むかもしれない。リソースオーナーがアクセス承認のためにサーバーにリダイレクトされる時、サーバーはリソースーオーナーが既にそのクライアントからのアクセスを承認していることを検知したとする。その場合サーバーはリソースオーナーに承認を求める代わりに、リソースオーナーを自動的にクライアントにリダイレクトさせる。

クライアントクレデンシャルが漏洩している場合、自動処理はさらなるセキュリティリスクを生み出す。攻撃者は漏洩したクライアントクレデンシャルを使ってリソースオーナーをサーバーにリダイレクトさせ、認可リクエストを行うことができる。そうするとサーバーはリソースオーナーに承認を求めずに、リソースオーナーへのアクセスを承認することになる。もちろん攻撃への注意喚起なども行わない。自動承認が実装されていなければ、攻撃者はリソースオーナーにアクセスを承認させるためにソーシャルエンジニアリングを用いなければならなくなる。

サーバーは自動処理に由来するリスクを軽減するため、自動承認プロセスを通じて発行されるトークンクレデンシャルのスコープを限定することができる。リソースオーナーの同意を得て発行されたトークンクレデンシャルに対して影響を与える必要はない。クライアントはクライアントクレデンシャルを保護することで、自動処理に由来するリスクを軽減することができる。

5.  IANA に関する考察

このメモは IANA へのリクエストを含まない。

6.  謝辞

この仕様は、複数の企業により個別に実装された、既存の独自プロトコルおよびベストプラクティスを元にして作成された、コミュニティ仕様 OAuth Core 1.0 Revision A に、直接的に基づくものである。

コミュニティ仕様は Eran Hammer-Lahav による編集、Mark Atwood、Dirk Balfanz、Darren Bounds、Richard M. Conlan、Blaine Cook、Leah Culver、Breno de Medeiros、Brian Eaton、Kellan Elliott-McCrea、Larry Halff、Eran Hammer-Lahav、Ben Laurie、Chris Messina、John Panzer、Sam Quigley、David Recordon、Eran Sandler、Jonathan Sergent、Todd Sieling、Brian Slesinsky、Andy Smith による著作である。

編集者は、本エディションの公開について、多大な貢献を行った次の人々に感謝する。Lisa Dusseault、Justin Hart、Avshalom Houri、Chris Messina、Mark Nottingham、Tim Polk、Peter Saint-Andre、Joseph Smarr、Paul Walker。

Appendix A.  コミュニティ版との違い

本仕様は、元のコミュニティ仕様 [OAuth Core 1.0 Revision A] (OAuth, OAuth Community., “OAuth Core 1.0 Revision A,” .) が公開されてから発見された、以下の間違いや欠落を修正するための変更点を含む。

• プレインテキストクレデンシャル送信時の TLS/SSL 利用を SHOULD から MUST に変更。この変更によりテンポラリクレデンシャルのリクエスト (テンポラリクレデンシャル)およびトークンクレデンシャルの取得 (トークンクレデンシャル)だけでなく、PLAINTEXT 署名方式の利用が影響を受ける。
• トークン／タイムスタンプ／クライアントの組み合わせごとにユニークになるよう、ノンスの表現を調整。
• タイムスタンプが、前回のリクエストで利用されたものよりも大きいか、同等である必要がある旨を削除。
• PLAINTEXT 署名方式利用時のノンスおよびタイムスタンプパラメータを、オプションに変更。
• 利用される HTTP メソッドが POST 以外の場合の application/x-www-form-urlencoded エンティティボディパラメータを含むシグニチャベースストリングを拡張。また、HTTP メソッドが GET 以外の場合の URI クエリパラメータを拡張。
• 二重エンコードによるエラーを防ぐため、各署名方式の解説に、oauth_signature パラメータにシグニチャ値を挿入する前に、エンコードする旨を追加。
• oauth_token パラメータが空の場合、省略可能とした。
• 空の oauth_token パラメータを使ったテンポラリクレデンシャルのリクエスト送信を許可。
• oauth_ パラメータの追加定義を制限する記述を削除。

Appendix B.  Document History

[[ To be removed by the RFC editor before publication as an RFC. ]]

-10

• Added missing 'oauth_token' in exmaple.
• Changed realm values from URI to string to make them more generic (since the protocol does not define any internal structure for them).

-09

• Added 'with a 200 status code (OK)' in two places.
• Missing comma in example.
• Corrected typos.
• Changed the use of TLS/SSL when sending or receiving plain text credentials to a MUST.
• Clarified text about change control moving from the community to the IETF.

-08

• Adjusted timestamp language to allow use of time servers for clock sync.
• Revised security language for SHA-1 weakness and applicability.
• Added link to the community specification.
• Minor editorial changes.

-07

• Corrected typos.
• Changed examples to use HTTPS in authorization step.
• Clarified the use of 'oauth_' tokens in the three static endpoint URIs.
• Edited abstract and introduction.

-06

• Moved parameter section into client instructions.
• Added more examples in the delegation section, including more complete HTTP responses.
• Removed language about restricting the use of the 'oauth_' prefix.
• Changed the nonce and timestamp parameters to optional when using PLAINTEXT.
• Allowed empty token in temporary credentials requests.

-05

• Replaced the word 'lexicographical' with 'ascending' in sorting instructions.
• Added note that the 'a3' parameter appears twice in the example.
• Made the note about the encoding scheme being different from most common implementations more explicit.
• Moved and cleaned up the example from appendix to introduction. Removed crypto details from the example.

-04

• Corrected typo and other minor editorial changes.
• Added warning about token sizes.
• Clarified that all 'oauth_' parameters must be transmitted using the same method.
• Added explicit requirement to exclude parameters not transmitted in a request in the signature base string (for example oauth_version when omitted).
• Explicitly set OAuth to use HTTP 1.1.
• Rearranged the signature base string section to provide a better narrative of how the HTTP request is normalized. Added the protocol parameters to the examples to better demonstrate how they are incorporated in practice.
• Flipped the document order between authentication and authorization.
• Removed the requirement for timestamps to be equal or greater than previous timestamps.

-03

• Updated draft with changes from OAuth Core 1.0 Revision A to fix a session fixation exploit.
• Small editorial corrections.
• Removed confusing language from 'Denial of Service / Resource Exhaustion Attacks'.
• Added new 'Differences from the Community Edition' appendix.
• Updated acknowledgements section.

-02

• Corrected mistake in parameter sorting order (c%40 comes before c2).
• Added requirement to normalize empty paths as '/'.

-01

• Complete rewrite of the entire specification from scratch. Separated the spec structure into two parts and flipped their order.
• Corrected errors in instructions to encode the signature base string by some methods. The signature value is encoded using the transport rules, not the spec method for encoding.
• Replaced the entire terminology.

-00

• Initial draft based on the OAuth Core 1.0 community specification with the following changes.
• Various changes required to accommodate the strict format requirements of the IETF, such as moving sections around (Security, Contributors, Introduction, etc.), cleaning references, adding IETF specific text, etc.
• Moved the Parameter Encoding sub-section from section 5 (Parameters) to section 9.1 (Signature Base String) to make it clear it only applies to the signature base string.
• Nonce language adjusted to indicate it is unique per token/timestamp/consumer combination.
• Added security language regarding lack of token secrets in RSA-SHA1.
• Fixed the bug in the Normalize Request Parameters section. Removed the GET limitation from the third bullet (query parameters).
• Removed restriction of only signing application/x-www-form-urlencoded in POST requests, allowing the entity-body to be used with all HTTP request methods.

7.  References

7.1. Normative References

7.2. Informative References

Author's Address