The OAuth 2.0 Authorization Protocol: Bearer Tokens (日本語)
draft-ietf-oauth-v2-bearer-11

Abstract

この仕様書は, OAuth 2.0の保護リソースへアクセスするために, 署名無しトークンをHTTPリクエスト中でどのように利用するか記述したものである. 署名無しトークンを所有する任意のパーティ (持参人) は, 認可済みリソースへアクセスするために署名無しトークンを利用できる (暗号鍵の所有を示す必要はない). 誤った利用を避けるために, 署名無しトークンは保存場所や流通経路での値の露見から守られなければならない (MUST).

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 April 27, 2012.

Copyright Notice

Copyright (c) 2011 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.  Authorizationリクエストヘッダフィールド
    2.2.  Formエンコードされたボディパラメータ
    2.3.  URIクエリパラメータ
3.  WWW-Authenticate レスポンスヘッダフィールド
    3.1.  エラーコード
4.  Security Considerations
    4.1.  セキュリティ上の脅威
    4.2.  脅威の軽減
    4.3.  推奨事項のまとめ
5.  IANAに関する考慮事項
    5.1.  OAuthアクセストークンタイプの登録
        5.1.1.  「署名無し」OAuthアクセストークンタイプ
    5.2.  認証スキームの登録
        5.2.1.  「署名無し」認証スキーム
6.  References
    6.1.  Normative References
    6.2.  Informative References
    6.3.  翻訳プロジェクト
Appendix A.  謝辞
Appendix B.  文書履歴
Appendix C.  翻訳者
§  Authors' Addresses

1.  はじめに

OAuthは, クライアントがアクセストークンを取得することで, 保護リソースへのアクセスを可能にする. アクセストークンは [I‑D.ietf‑oauth‑v2] (Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” September 2011.) 中で「クライアントに対するアクセス認可の文字列表現」と定義されており, リソース所有者のクレデンシャルを直接利用することではない.

トークンはリソース所有者の承認を伴い, 認可サーバによってクライアントに対して発行される. クライアントはアクセストークンを, リソースサーバが持つ保護リソースにアクセスするために利用する. この仕様書では, アクセストークンが署名無しトークンである場合に, 保護リソースを要求する方法を記載する.

この仕様書では HTTP (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] 及び TLS (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] で定義された, TLSを用いたHTTP上でのOAuthで, 署名無しトークンを利用する方法を定める. 他の仕様書がその他の転送プロトコルの元での利用について本仕様を拡張する可能性もある.

1.1.  要求記法および規則

本文書で用いられる各キーワード「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.) で述べられている通りに解釈されるべきものである.

このドキュメントでは[RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.)におけるAugmented Backus-Naur Form (ABNF) 表記法を元にした, [I‑D.ietf‑httpbis‑p1‑messaging] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Reschke, J., and Y. Lafon, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” August 2011.)におけるAugmented Backus-Naur Form (ABNF) 表記法を利用している. 加えて, 次の規則 ([I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Reschke, J., and Y. Lafon, “HTTP/1.1, part 7: Authentication,” August 2011.) 記載: b64token, auth-param および realm; [I‑D.ietf‑httpbis‑p1‑messaging] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Reschke, J., and Y. Lafon, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” August 2011.)記載: quoted-string; [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.)記載: URI-Reference) に従う.

特に記載が無い限り, 全てのプロトコルパラメーター名と値は, 大文字・小文字を区別する.

1.2.  用語定義

署名無しトークン

セキュリティトークン. トークンを所有する任意のパーティ (持参人) は, それを所有する他の任意のパーティーにとって可能ないかなる方法でもトークンを利用することができるという特性を持っている. 署名無しトークンを利用する際, 持参人は, 暗号鍵の所持を証明 (proof-of-posession) するよう要求されない.

他の全ての用語は[I‑D.ietf‑oauth‑v2] (Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” September 2011.)で定義されている通りである.

1.3.  概要

OAuthはリソースオーナーの代わりに保護リソースにアクセスする方法をクライアントに提供する. 一般的なケースにおいて, クライアントが保護リソースにアクセスする前に, クライアントは初めにリソースオーナーの認可を取得し, アクセス認可とアクセストークンを交換しなければならない. アクセストークンは, 与えられた権限の範囲, 期間とその他の属性を示している. クライアントはリソースサーバにアクセストークンを渡すことにより, 保護リソースにアクセスする. いくつかのケースにおいては, クライアントは, 最初にリソースオーナーから認可を得ずに認可サーバからアクセストークンを得るために, 自らのクレデンシャルを認可サーバに直接渡すこともある.

アクセストークンはほかの認証方法 (例: ユーザ名とパスワード, アサーション) をリソースサーバが理解しうる一つのトークンに置き換えるような抽象レイヤーを提供する. この抽象レイヤーは有効期間の短いアクセストークンを発行することを可能にするとともに, リソースサーバーが様々な認証スキームを理解しなくともよいようにする.

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Resource    |
|        |                               |     Owner     |
|        |<-(B)-- Authorization Grant ---|               |
|        |                               +---------------+
|        |
|        |        Authorization Grant &  +---------------+
|        |--(C)--- Client Credentials -->| Authorization |
| Client |                               |     Server    |
|        |<-(D)----- Access Token -------|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(E)----- Access Token ------>|    Resource   |
|        |                               |     Server    |
|        |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

Figure 1 (プロトコルフロー概要) で示されたフロー概要は, OAuth 2.0プロトコルのアーキテクチャの全体を説明したものである. 以下のステップはこの文書中で定義される.

E) クライアントはリソースサーバにアクセストークンを示し, 保護リソースへのリクエストを行う.

F) リソースサーバはアクセストークンの正当性を確認し, 有効な場合はリクエストに対し応答する.

2.  認証されたリクエスト

クライアントは保護されたリソースへの認証されたアクセス要求を行うために署名無しトークンを用いてもよい (MAY). この章では, リソースの要求において署名無しトークンをリソースサーバに送信する3つの方法を定義する. クライアントは一度のリクエストにおいて, トークンを送信する方法を複数同時に用いてはならない (MUST NOT).

2.1.  Authorizationリクエストヘッダフィールド

[I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Reschke, J., and Y. Lafon, “HTTP/1.1, part 7: Authentication,” August 2011.)によって定義されるAuthorizationリクエストヘッダフィールド中でアクセストークンを送信する際, クライアントはBearer認証スキームを用いる.

例:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer vF9dft4qmT

Authorizationヘッダフィールドは[I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Reschke, J., and Y. Lafon, “HTTP/1.1, part 7: Authentication,” August 2011.)により定義されるフレームワークを以下のように用いる:

credentials = "Bearer" 1*SP b64token

クライアントが署名無しトークンを伴う認証されたリクエストを送信する際には, Bearer HTTP認可スキームを用いたAuthorizationリクエストヘッダフィールドを使用すべきである (SHOULD). リソースサーバはこの方法をサポートしなければならない (MUST).

2.2.  Formエンコードされたボディパラメータ

HTTPリクエストのエンティティボディ中でアクセストークンを送信する際, クライアントはaccess_tokenパラメータを用いてアクセストークンをリクエストボディに付加する. クライアントは以下の条件のすべてを満たさない限りこの方法を用いてはならない (MUST NOT):

• HTTPリクエストのエンティティボディがシングルパートである.
• エンティティボディが[W3C.REC‑html401‑19991224] (Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.)によって定義されるapplication/x-www-form-urlencodedコンテントタイプのエンコード要求を満たす.
• HTTPリクエストのエンティティヘッダにapplication/x-www-form-urlencodedにセットされたContent-Typeヘッダフィールドを含む.
• リクエストボディが定義されたセマンティクスを持つHTTPリクエストメソッドである. 特に, これはGETメソッドを用いてはならない (MUST NOT) ことを意味する.

エンティティボディにはリクエストに固有なパラメータを含んでもよい (MAY). この場合, access_tokenパラメータは文字 & (ASCIIコード38) を用いてリクエスト固有なパラメーから適切に分離されなければならない (MUST).

例えば, クライアントは以下のHTTPリクエストをトランスポートレイヤセキュリティを利用して送信する:

POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

access_token=vF9dft4qmT

このapplication/x-www-form-urlencodedを用いる方法は, 関与しているブラウザがAuthorizationリクエストヘッダにアクセスできない場合を除いて使用すべきではない (SHOULD NOT). リソースサーバはこの方法をサポートしてもよい (MAY).

2.3.  URIクエリパラメータ

HTTPリクエストURIの中でアクセストークンを送信する際, クライアントはaccess_tokenパラメータを用いてアクセストークンを[RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.)で定義されているURIクエリコンポーネントに追加する.

たとえば, クライアントは次のようなHTTPリクエストをトランスポートレイヤセキュリティを利用して送信する:

GET /resource?access_token=vF9dft4qmT HTTP/1.1
Host: server.example.com

HTTPリクエストURIはリクエストに特化した他のパラメータを含むことができる. その場合, access_tokenパラメータは & 文字 (ASCII コード 38) を使い, 他のリクエストに特化したパラメータと適切に分離されていなければならない (MUST).

例:

https://server.example.com/resource?x=y&access_token=vF9dft4qmT&p=q

URI方式に関係するセキュリティに関する考慮事項 (Security Considerations)のため, この方法は単に実現可能な方法であるということを除いては利用すべきではない (SHOULD NOT). リソースサーバはこの方式をサポートしても良い (MAY).

3.  WWW-Authenticate レスポンスヘッダフィールド

保護リソースへのリクエストが, 認証クレデンシャルを含んでいない, または保護リソースへアクセスすることができるアクセストークンを含んでいない場合, リソースサーバはHTTP WWW-Authenticate レスポンスヘッダフィールドを含めなければならない (MUST). 同様に, その他の条件下でもリソースサーバはそれをレスポンスに含めてよい (MAY). 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,” June 1999.) により定義されている以下のフレームワークを使用する.

challenge       = "Bearer" [ 1*SP 1#param ]

param           = realm / scope /
                  error / error-desc / error-uri /
                  auth-param

scope           = "scope" "=" DQUOTE scope-val *( SP scope-val ) DQUOTE
scope-val       = 1*scope-val-char
scope-val-char  = %x21 / %x23-5B / %x5D-7E
  ; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII

error           = "error" "=" quoted-string
error-desc      = "error_description" "=" DQUOTE *error-desc-char DQUOTE
error-desc-char = SP / VCHAR
error-uri       = "error_uri" "=" DQUOTE URI-reference DQUOTE

scope 属性は, スペース区切りのスコープ値のリストであり, 要求されたリソースへのアクセスに必要なアクセストークンのスコープを示す. scope 属性は, 2回以上現れてはならない (MUST NOT). scope の値は, プログラム中で用いられることを目的とし, エンドユーザへ表示することは意図されていない.

保護リソースへのリクエストにアクセストークンが含まれているが認証に失敗した場合, リソースサーバはアクセス要求を拒否した理由をクライアントに対して示すために, error 属性を含むべきである (SHOULD). パラメータの値は Section 3.1 (エラーコード) に記載されている. さらに, リソースサーバは, 開発者にとって可読性のある説明を提供するために, error_description 属性を含んでもよい (MAY). なおこの情報はエンドユーザに表示することを想定しない. また, エラーについての可読性のある説明ウェブページを指し示す, 絶対URIで記載されたerror_uri 属性を含んでもよい (MAY). error, error_description, そして error_uri 属性は, 2回以上現れてはならない (MUST NOT).

例えば, 認証されていない場合の保護リソースへのリクエストに対するレスポンスは以下のようになる:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

また, 有効期限の切れたアクセストークンを用いて認証を試みた場合の保護リソースへのリクエストに対するレスポンスは以下のようになる:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                  error="invalid_token",
                  error_description="The access token expired"

3.1.  エラーコード

リクエストが失敗した場合, リソースサーバは適切なHTTPステータスコード (典型的には 400, 401, もしくは 403) を用いて応答し, 下記のうち1つのエラーコードをレスポンスに含める:

invalid_request

リクエストに必要なパラメータが不足している, 対応していないパラメータもしくはパラメータの値が含まれている, 同じパラメータが複数回現れている, 1つのアクセストークンを含むために複数の方法を用いている, もしくはリクエストがその他不正な形式になっている. リソースサーバはHTTPステータスコード400 (Bad Request) の応答を返すべきである (SHOULD).

invalid_token

提供されたアクセストークンが期限切れである, 取り消されている, 不正な値である, もしくはその他の理由により無効である. リソースサーバはHTTPステータスコード401 (Unauthorized) の応答を返すべきである (SHOULD). クライアントは新しいアクセストークンを要求して保護されたリソースへのアクセスを再試行してもよい (MAY).

insufficient_scope

リクエストにはアクセストークンにより提供されるよりも高い権限が必要である. リソースサーバはHTTPステータスコード403 (Forbidden) の応答を返すべき (SHOULD) であり, 保護されたリソースへのアクセスに必要となるスコープを示した scope 属性を含めてもよい (MAY).

リクエストが一切の認証情報を含まない場合 (つまり, 認証が必要であることをクライアントが認識していなかった場合か, 対応していない認証方法をクライアントが試行した場合), リソースサーバはエラーコードやその他のエラー情報を応答に含めるべきではない (SHOULD NOT).

例:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

4.  Security Considerations

本章では, 署名無しトークン利用時におけるトークンの取り扱い方法に関するセキュリティ上の脅威, およびこれらの脅威をどのように軽減するかを記述する.

4.1.  セキュリティ上の脅威

次のリストは何らかのトークン形式を取り扱うプロトコルにおける共通の脅威を表したものである. この脅威リストはNIST Special Publication 800-63 [NIST800‑63] (Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., and E. Nabbus, “NIST Special Publication 800-63-1, INFORMATION SECURITY,” December 2008.)をベースにしたものである. この文書はOAuth 2.0仕様を前提として作成されたものであるため, その仕様や関連文書中に記載されている脅威に関する議論は行わないものとする.

トークン偽装/改ざん:

攻撃者が偽装トークンを生成したり, 既存のトークンの (認証や属性の記述内容といった) コンテンツを改ざんすることで, リソースサーバはクライアントに対して不適切なアクセス権限を許してしまう可能性がある. 例えば, 攻撃者はトークンが妥当である期間を拡張するようにトークンを改ざんするかもしれない. 悪意のあるクライアントは本来見ることができるべきではない情報へのアクセスを得るためにアサーションを改ざんするかもしれない.

トークン露見:

トークンは認証や属性の記述など機微情報を含む可能性がある.

トークンリダイレクト:

攻撃者は, あるリソースサーバで利用することを目的として生成されたトークンを, 別のリソースサーバに対して利用し, 後者が持つリソースにアクセスを試みる.

トークンリプレイ:

攻撃者は過去にリソースサーバで利用済みのトークンの再利用を試みる.

4.2.  脅威の軽減

デジタル署名またはメッセージ認証コード (MAC) を用いてトークンの内容を保護することにより, 多くの脅威は軽減することができる. あるいは, 署名無しトークンはエンコードされた認可情報を直接含むのではなく, 認可情報に対する参照を含むことができる. その参照は, 攻撃者が推測不可能でなければならない (MUST). 参照を用いた場合, 認可情報への参照を解決するために, 認証サーバとトークン発行者の間における追加の通信が必要になることがある. そのような通信の方法は, この仕様では定義されない.

このドキュメントでは, エンコード方法やトークンの内容に関しては定義しない. そのため, トークンの整合性を保護するための詳細に関しての提言は, この文書の範囲外である. トークンが改変されることを防ぐのに十分な程度に, トークンの整合性が保護されているものと仮定する.

トークンリダイレクトへの対策として, トークン内に認可サーバの意図する, 一般的に一つのリソースサーバまたはリソースサーバのリストからなる, トークンの受領者 (観衆) のアイデンティティを含むことが重要である. トークンの利用できる範囲を特定の範囲に制限することも推奨される.

トークンの露見を防ぐために, 機密性保護のための暗号スイートによるTLS (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246]を利用し, 機密性を保護すること. クライアント-リソースサーバ間と同様に, クライアント-認可サーバ間の通信においても, 機密性保護が必要である. この仕様においてはTLSの実装と使用が義務付けられており, それは通信経路上でのトークン漏洩を防ぐための推奨されるアプローチである. クライアントがトークンの内容を覗き見るようなケースを防ぐためには, TLSによる保護に加えて, トークンの暗号化を行う必要がある (MUST).

トークンの覗き見と再利用 (トークンリプレイ) への対策として, 以下の手段が推奨される: 第一に, トークン内の保護された部分に, 有効な時間のフィールドを保持しておき, それによって有効期間を制限しなければならない (MUST). 1時間程度, またはそれ以下の短い期間のみ有効なトークンを使うことが, トークンが漏洩した際のインパクトを減らすことを記す. 第二に, クライアントと認可サーバ間およびクライアントと資源サーバの間の通信における機密性保持は, 例えばTLS等を用いて機密性保持を適用しなければならない (MUST). 結果として, 通信経路に存在する盗聴者は, トークンの交換を覗き見ることができなくなる. 従って, そのような経路上の攻撃者は, トークンをリプレイすることができない. さらに, クライアントはトークンを資源サーバに送信するときに, [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.)に従いサーバのアイデンティティを確認しなければならない (MUST). 保護リソースにリクエストを送信するとき, クライアントがTLS証明書のチェインを確認しなければならない (MUST) ことに注意すべきである. 未認証かつ未認可な資源サーバにトークンを送信すること, あるいは証明書チェインの確認に失敗することは, 攻撃者に対して, トークンを盗み, 保護リソースへの認可されていないアクセスを許すことになる.

4.3.  推奨事項のまとめ

署名無しトークンを保護する

クライアントの実装は, 保護されたリソースへのアクセスを可能とするために署名無しトークンを使う際には, それが意図されていない相手に漏洩していないことを確実にしなければならない (MUST). これは署名無しトークンを用いる際に最も重要なセキュリティに関する考慮事項であり, 後述の詳細な推奨事項すべての基礎となる.

SSL証明書チェインを検証する

クライアントが保護リソースのリクエストを送信する際には, TLS証明書のチェインを検証しなければならない (MUST). これに失敗した場合, さまざまな攻撃に対してトークンが晒されることとなり, 攻撃者に対して意図しないアクセスを許すことになる.

常に TLS (https) を用いる

クライアントが署名無しトークンを用いたリクエストを送信する際には, 常に TLS (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] (https) もしくは同等なトランスポートセキュリティを用いなければならない. これに失敗した場合, 攻撃者に意図しないアクセスを可能とするさまざまな攻撃にトークンが晒されてしまう.

クッキーに署名無しトークンを保存しない

平文で送信されうるクッキーに署名無しトークンを保存する実装を行ってはならない (MUST NOT). (平文での送信はクッキーのデフォルト送信モードである) 署名無しトークンをクッキーに保存する実装では, クロスサイトリクエストフォージェリへの対処をしなければならない (MUST).

有効期間の短い署名無しトークンを発行する

トークンサーバは, 特にブラウザやその他の情報漏洩の起こりやすい環境の中で実行されるクライアントに対してトークンを発行する際には, 有効期間の短い (1時間ないしそれ以下) 署名無しトークンを発行すべきである (SHOULD). 有効期間の短い署名無しトークンを用いることにより, 漏洩した際の影響を減らすことができる.

スコープの設定された署名無しトークンを発行する

トークンサーバは, 1つまたは複数の意図されたリライングパーティによる使用に限定されるよう, オーディエンスの制限を含んだ署名無しトークンを発行すべきである (SHOULD).

署名無しトークンをページURL中で渡さない

署名無しトークンはページURL中で渡されるべきではない (SHOULD NOT). (たとえばクエリ文字列のパラメータとして) 代わりに, 機密性対策の講じられたHTTPメッセージヘッダもしくはメッセージボディ中で渡されるべきである (SHOULD). ブラウザやウェブサーバその他のソフトウェアは, ブラウザの履歴やウェブサーバのログその他のデータ構造において, 適切にURLを保護していないかもしれない. 署名無しトークンがページURLとして渡された場合, 攻撃者は履歴情報やログ, その他の保護されていない場所から盗み取ることができるかもしれない.

5.  IANAに関する考慮事項

5.1.  OAuthアクセストークンタイプの登録

本仕様は, OAuthアクセストークンタイプの登録において, 次のアクセストークンのタイプを登録する.

5.1.1.  「署名無し」OAuthアクセストークンタイプ

タイプ名:

Bearer

トークンエンドポイントで追加となるレスポンスパラメータ:

(無し)

HTTP認証スキーム:

Bearer

変更管理者:

IETF

仕様文書:

[[ 本文書 ]]

5.2.  認証スキームの登録

本仕様は, [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Reschke, J., and Y. Lafon, “HTTP/1.1, part 7: Authentication,” August 2011.)で定義される認証スキーム登録において, 次の認証スキームを登録する.

5.2.1.  「署名無し」認証スキーム

認証スキーム名:

Bearer

仕様書の参照:

[[ 本文書 ]]

備考 (オプション):

(無し)

6.  References

6.1. Normative References

6.2. Informative References

6.3. 翻訳プロジェクト

Appendix A.  謝辞

以下の人々は本文書の前身となる版に対して貢献を行った: Blaine Cook (BT), Brian Eaton (Google), Yaron Y. Goland (Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter), Luke Shepard (Facebook), and Allen Tom (Yahoo!). 本仕様の内容及びコンセプトはOAuthコミュニティ, WRAPコミュニティ, OAuthワーキンググループによって生み出されたものである.

OAuthワーキンググループには本文書のアイデアと文書の記述を提案した多くの貢献者がおり, 以下の人々が含まれる: Michael Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, Brian Campbell, Leah Culver, Bill de hÓra, Brian Ellin, Igor Faynberg, George Fletcher, Tim Freeman, Evan Gilbert, Justin Hart, John Kemp, Eran Hammer-Lahav, Chasen Le Hara, Michael B. Jones, Torsten Lodderstedt, Eve Maler, James Manger, Laurence Miao, Chuck Mortimore, Anthony Nadalin, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Justin Smith, Jeremy Suriel, Christian Stübner, Paul Tarjan, 及び Franklin Tse.

Appendix B.  文書履歴

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

-11

• Replaced uses of <"> with DQUOTE to pass ABNF syntax check.

-10

• Removed the #auth-param option from Authorization header syntax (leaving only the b64token syntax).
• Restricted the scope value character set to %x21 / %x23-5B / %x5D-7E (printable ASCII characters excluding double-quote and backslash). Indicated that scope is intended for programmatic use and is not meant to be displayed to end users.
• Restricted the character set for error_description strings to SP / VCHAR and indicated that they are not meant to be displayed to end users.
• Included more description in the Abstract, since Hannes Tschofenig indicated that the RFC editor would require this.
• Changed "Access Grant" to "Authorization Grant", as was done in the core spec.
• Simplified the introduction to the Authenticated Requests section.

-09

• Incorporated working group last call comments. Specific changes were:
• Use definitions from [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Reschke, J., and Y. Lafon, “HTTP/1.1, part 7: Authentication,” August 2011.) rather than [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.).
• Update credentials definition to conform to [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Reschke, J., and Y. Lafon, “HTTP/1.1, part 7: Authentication,” August 2011.).
• Further clarified that query parameters may occur in any order.
• Specify that error_description is UTF-8 encoded (matching the core specification).
• Registered "Bearer" Authentication Scheme in Authentication Scheme Registry defined by [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Reschke, J., and Y. Lafon, “HTTP/1.1, part 7: Authentication,” August 2011.).
• Updated references to oauth-v2, httpbis-p1-messaging, and httpbis-p7-auth drafts.
• Other wording improvements not introducing normative changes.

-08

• Updated references to oauth-v2 and httpbis drafts.

-07

• Added missing comma in error response example.

-06

• Changed parameter name bearer_token to access_token, per working group consensus.
• Changed HTTP status code for invalid_request error code from HTTP 401 (Unauthorized) back to HTTP 400 (Bad Request), per input from HTTP working group experts.

-05

• Removed OAuth Errors Registry, per design team input.
• Changed HTTP status code for invalid_request error code from HTTP 400 (Bad Request) to HTTP 401 (Unauthorized) to match HTTP usage [[ change pending working group consensus ]].
• Added missing quotation marks in error-uri definition.
• Added note to add language and encoding information to error_description if the core specification does.
• Explicitly reference the Augmented Backus-Naur Form (ABNF) defined in [RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.).
• Use auth-param instead of repeating its definition, which is ( token "=" ( token / quoted-string ) ).
• Clarify security considerations about including an audience restriction in the token and include a recommendation to issue scoped bearer tokens in the summary of recommendations.

-04

• Edits responding to working group last call feedback on -03. Specific edits enumerated below.
• Added Bearer Token definition in Terminology section.
• Changed parameter name oauth_token to bearer_token.
• Added realm parameter to WWW-Authenticate response to comply with [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.).
• Removed "[ RWS 1#auth-param ]" from credentials definition since it did not comply with the ABNF in [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Reschke, J., and Y. Lafon, “HTTP/1.1, part 7: Authentication,” August 2011.).
• Removed restriction that the bearer_token (formerly oauth_token) parameter be the last parameter in the entity-body and the HTTP request URI query.
• Do not require WWW-Authenticate Response in a reply to a malformed request, as an HTTP 400 Bad Request response without a WWW-Authenticate header is likely the right response in some cases of malformed requests.
• Removed OAuth Parameters registry extension.
• Numerous editorial improvements suggested by working group members.

-03

• Restored the WWW-Authenticate response header functionality deleted from the framework specification in draft 12 based upon the specification text from draft 11.
• Augmented the OAuth Parameters registry by adding two additional parameter usage locations: "resource request" and "resource response".
• Registered the "oauth_token" OAuth parameter with usage location "resource request".
• Registered the "error" OAuth parameter.
• Created the OAuth Error registry and registered errors.
• Changed the "OAuth2" OAuth access token type name to "Bearer".

-02

• Incorporated feedback received on draft 01. Most changes were to the security considerations section. No normative changes were made. Specific changes included:
• Changed terminology from "token reuse" to "token capture and replay".
• Removed sentence "Encrypting the token contents is another alternative" from the security considerations since it was redundant and potentially confusing.
• Corrected some references to "resource server" to be "authorization server" in the security considerations.
• Generalized security considerations language about obtaining consent of the resource owner.
• Broadened scope of security considerations description for recommendation "Don't pass bearer tokens in page URLs".
• Removed unused reference to OAuth 1.0.
• Updated reference to framework specification and updated David Recordon's e-mail address.
• Removed security considerations text on authenticating clients.
• Registered the "OAuth2" OAuth access token type and "oauth_token" parameter.

-01

• First public draft, which incorporates feedback received on -00 including enhanced Security Considerations content. This version is intended to accompany OAuth 2.0 draft 11.

-00

• Initial draft based on preliminary version of OAuth 2.0 draft 11.

Appendix C.  翻訳者

本仕様書の翻訳は, OpenIDファウンデーションジャパン (OpenIDファウンデーションジャパン, “OpenIDファウンデーションジャパン,” .) [oidfj] 翻訳・教育ワーキンググループ (OpenIDファウンデーションジャパン, “翻訳・教育ワーキンググループ,” .) [oidfj‑trans]を主体として, 有志のメンバーによって行われました. 質問や修正依頼などについては, Githubレポジトリー (OpenIDファウンデーションジャパン, “Githubレポジトリー,” .) [oidfj‑github] にご連絡ください.

• Boku Kihara (Lepidum)
• Kazuki Shimizu (Lepidum)
• Masaru Kurahayashi (Yahoo! Japan)
• Naohiro Fujie (Itochu Techno Solutions)
• Noboru Kurumai (Fujitsu)
• Nov Matake (Cerego Japan)
• Ryo Ito
• Shunsuke Kouchi (Yahoo! Japan)
• Taizo Matsuoka (Yahoo! Japan)
• Tatsuya Katsuhara (NRI)
• Yusuke Kondo (Yahoo! Japan)
• Yutaka Obuchi (Hitachi Solutions)

Authors' Addresses