The OAuth 2.0 Authorization Framework: Bearer Token Usage（日本語）

Abstract

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

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6750.

Copyright Notice

Copyright (c) 2012 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.  Authenticated Requests
    2.1.  Authorizationリクエストヘッダフィールド
    2.2.  Formエンコードされたボディパラメータ
    2.3.  URIクエリパラメータ
3.  WWW-Authenticate レスポンスヘッダフィールド
    3.1.  エラーコード
4.  アクセストークンレスポンスの例
5.  Security Considerations
    5.1.  セキュリティ上の脅威
    5.2.  脅威の軽減
    5.3.  推奨事項のまとめ
6.  IANA Considerations
    6.1.  OAuth アクセストークンタイプ登録
        6.1.1.  "Bearer" OAuth アクセストークンタイプ
    6.2.  OAuth 拡張エラー登録
        6.2.1.  "invalid_request" エラー
        6.2.2.  "invalid_token" エラー
        6.2.3.  "insufficient_scope" エラー
7.  References
    7.1.  Normative References
    7.2.  Informative References
    7.3.  翻訳プロジェクト
Appendix A.  Acknowledgements
Appendix B.  翻訳者

1.  はじめに

OAuthは, クライアントがアクセストークンを取得することで, 保護リソースへのアクセスを可能にする. アクセストークンは "The OAuth 2.0 Authorization Framework" [RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) 中で「クライアントに対するアクセス認可の文字列表現」と定義されており, リソース所有者のクレデンシャルを直接利用することではない.

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

この仕様書では Transport Layer Security (TLS) [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) を利用した HTTP/1.1 [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.) 上で, 保護リソースへアクセスするために署名無しトークンを利用する方法を定める. TLSの実装と利用は, 本仕様では必須である; 他の仕様書が他のプロトコルの元での利用について, 本使用を拡張する可能性がある. OAuthの保護リソースへアクセスするために, OAuth 2.0 認可 [RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) フローの 結果得られるアクセストークンを利用するように設計されていることに加え, 本仕様は, 署名なしトークンを利用して, 任意のソースから, 署名付きトークンによって保護されている任意のリソースに対してアクセスすることが可能な一般的なHTTP認可方式を定義する. なおBearer認証スキームは, WWW-AuthenticateおよびAuthorization HTTPヘッダー中でサーバー認証の為に利用されることを想定しているが, プロキシ認証に用いることも禁止はしない.

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) 表記法を元にした. 加えて, 次の規則 (HTTP/1.1 [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.): auth-param および auth-scheme; "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.)記載: URI-reference) に従う.

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

1.2.  用語定義

署名なしトークン (Bearer Token)

セキュリティトークン. トークンを所有する任意のパーティ (持参人 = bearer) は, 「トークンを所有している」という条件を満たしさえすればそのトークンを利用することができる. 署名無しトークンを利用する際, 持参人は, 暗号鍵の所持を証明 (proof-of-posession) するよう要求されない.

他の全ての用語は "The OAuth 2.0 Authorization Framework" [RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) で定義されている通りである.

1.3.  概要

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

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

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

Figure 1 (プロトコルフロー概要) で示されたフロー概要は, クライアント, リソースオーナー, 認可サーバー, リソースサーバー ([RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.)に記載)の間でのやり取りについて記述したものである。 以下のステップはこの文書中で定義される:

(E)

クライアントはリソースサーバに対して保護リソースの要求を行い, アクセストークンを提示することで認証を実施する.

(F)

リソースサーバはアクセストークンの正当性を検証し, 妥当な場合はリクエストに対し応答する.

本文書は, ステップ(D)で返却されるアクセストークンの利用方法について定める.

2.  Authenticated Requests

この章では, リソースの要求において署名無しトークンをリソースサーバに送信する3つの方法を定義する. クライアントは一度のリクエストにおいて, トークンを送信する方法を複数同時に用いてはならない (MUST NOT).

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

HTTP/1.1 [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.) によって定義されるAuthorizationリクエストヘッダフィールド中でアクセストークンを送信する場合, クライアントはBearer認証スキームを用いる.

For example:

  GET /resource HTTP/1.1
  Host: server.example.com
  Authorization: Bearer mF_9.B5f-4.1JqM

このスキームに対する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.) の第2章で定義されるBasicスキームに従う. ここで留意すべきは, Basic同様, [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 1.1 向けに開発された汎用認証フレームワーク[HTTP‑AUTH] (Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Authentication,” October 2012.) とは互換性があるということである. とはいえ, 既存の実装を考慮して, Basic仕様中で概説されている推奨される慣例には従っていない. 持参人クレデンシャルの文法は次のようになる:

  b64token    = 1*( ALPHA / DIGIT /
                    "-" / "." / "_" / "‾" / "+" / "/" ) *"="
  credentials = "Bearer" 1*SP b64token

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

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

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

• HTTPリクエストのエンティティヘッダにContent-Typeヘッダフィールドが含まれており, application/x-www-form-urlencodedにセットされている.
• エンティティボディが HTML 4.01 [W3C.REC‑html401‑19991224] (Raggett, D., Le Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.)によって定義されるapplication/x-www-form-urlencodedコンテントタイプのエンコード要求に従う.
• HTTPリクエストのエンティティボディがシングルパートである.
• エンティティボディ中にエンコードされたコンテンツは全て ASCII[USASCII] (American National Standards Institute, “Coded Character Set -- 7-bit American Standard Code for Information Interchange,” 1986.) 文字列だけで構成されなければならない (MUST).
• リクエストボディが利用できる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=mF_9.B5f-4.1JqM

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

2.3.  URIクエリパラメータ

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

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

  GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1
  Host: server.example.com

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

例:

 https://server.example.com/resource?access_token=mF_9.B5f-4.1JqM&p=q

クライアントはURIクエリパラメータ方式を利用して, "no-store" オプションを含んだCache-Controlヘッダを送信すべきである (SHOULD). これらのリクエストに対するサーバ正常 (2XXステータス) 応答は, "private" オプションを伴うCache-Controlヘッダを含んでいるべきである (SHOULD).

URL中のアクセストークン値がログに記録される可能性が高いことなど, URIを利用した場合はセキュリティレベルが低下 (Section 5 (Security Considerations)参照) するため, アクセストークンをAuthorizationリクエストヘッダかHTTPリクエストエンティティボディ中で送信することが不可能でない限りは, この方式を利用すべきではない (SHOULD NOT). リソースサーバはこの方式をサポートしても良い (MAY).

この方式は現在利用されていることからドキュメントに含まれている. セキュリティ上の重大な不備 (Section 5 (Security Considerations)参照) のため, 利用は非推奨である. また, 予約されたクエリパラメータ名を利用するため, URI名前空間のベストプラクティス ("Architecture of the World Wide Web, Volume One" [W3C.REC‑webarch‑20041215] (Jacobs, I. and N. Walsh, “Architecture of the World Wide Web, Volume One,” December 2004.)) に逆らっていることも理由に挙げられる.

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

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

この仕様により定義される全ての challange は auth-scheme の値に Bearer を用いなければならない (MUST). また, auth-scheme の後ろには1つ以上の auth-param 値を置かなければならない (MUST). この仕様により定義される auth-param 属性は後述する. 同様に, 他の auth-param 属性を用いてよい (MAY).

保護の範囲を表すため, HTTP/1.1 [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.) で記述されている方法で realm 属性が含まれてもよい (MAY). realm 属性は2回以上現れてはならない (MUST NOT).

scope 属性は [RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) の3.3章で定義されている. scope 属性は, 大文字と小文字を区別するスコープ値のスペース区切りリストであり, 要求されたリソースへのアクセスに必要なアクセストークンのスコープを示す. scope の値を一元的に管理する組織は存在せず, 許容される値は認可サーバによって定義される. scope の値の順序は意味を持たない. 場合によっては, 保護リソースを利用するのに十分なスコープを持った新しいアクセストークンを要求するために, scope の値が用いられるかもしれない. scope の値の使用は任意である (OPTIONAL). scope 属性は2回以上現れてはならない (MUST NOT). scope の値はプログラム中で用いられることを目的とし, エンドユーザへ表示することは意図されていない.

scope の値の例を以下に2つ例示する. これらの例は OpenID Connect [OpenID.Messages] (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) および Open Authentication Technology Committee (OATC) の Online Multimedia Authorization Protocol [OMAP] (Huff, J., Schlacht, D., Nadalin, A., Simmons, J., Rosenberg, P., Madsen, P., Ace, T., Rickelton-Abdi, C., and B. Boyer, “Online Multimedia Authorization Protocol: An Industry Standard for Authorized Access to Internet Multimedia Resources,” April 2012.) OAuth 2.0 ユースケースからそれぞれ引用している:

  scope="openid profile email"
  scope="urn:example:channel=HBO&urn:example:rating=G,PG-13"

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

scope 属性の値 ([RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) の Appendix A.4 で定義されている) は, 意図するスコープの値として %x21 / %x23-5B / %x5D-7E の集合およびスコープの値の区切りとして %x20 以外の文字を含んではならない (MUST NOT). error 属性および error_description 属性の値 ([RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) の Appendix A.7 および A.8 で定義されている) は, %x20-21 / %x23-5B / %x5D-7E の集合以外の文字を含んではならない (MUST NOT). error_uri 属性の値 ([RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) の Appendix A.9 で定義されている) は, URI-reference の構文に従わなければならず (MUST), したがって %x21 / %x23-5B / %x5D-7E の集合以外の文字を含んではならない (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.  アクセストークンレスポンスの例

典型的には, 署名無しトークンは OAuth 2.0 [RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) のアクセストークンレスポンスの一部としてクライアントに返される. そのようなレスポンスは以下のようになる:

  HTTP/1.1 200 OK
  Content-Type: application/json;charset=UTF-8
  Cache-Control: no-store
  Pragma: no-cache

  {
    "access_token":"mF_9.B5f-4.1JqM",
    "token_type":"Bearer",
    "expires_in":3600,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
  }

5.  Security Considerations

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

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

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

トークン偽装/改ざん:

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

トークン露見:

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

トークンリダイレクト:

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

トークンリプレイ:

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

5.2.  脅威の軽減

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

このドキュメントでは, エンコード方法やトークンの内容に関しては定義しない. そのため, トークンの整合性を保護するための詳細な手段についての提言は, この文章の範囲外である. トークン整合性保護は, トークンの改変を防ぐのに十分でなければならない(MUST).

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

認可サーバは, TLSを実装しなければならない (MUST). 実装すべきバージョン (場合によっては複数) は, 実装時において広く使用されているバージョン, 既知の脆弱性情報などにより, 時間の経過と共に変化しうる. 本使用が記述された時点においては, TLS version 1.2 [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) が最新バージョンであるが, まだ非常に狭い範囲でしか使用されておらず, 実装ツールキットが容易に入手できない可能性がある. TLS version 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) は, 最も広く使用されているバージョンであり, 広い範囲での相互接続性を提供する.

トークンの露見を防ぐために, 機密性および完全性の保護を提供する暗号スイートと共に TLS [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) を利用し, 機密性保護を行わなければならない(MUST). クライアント-リソースサーバ間と同様に, クライアント-認可サーバ間の通信においても, 機密性および完全性の保護が必要である. この仕様においてはTLSの実装と使用が義務付けられており, それは通信経路上でのトークン漏洩を防ぐための推奨されるアプローチである. クライアントがトークンの内容を覗き見るようなケースを防ぐためには, TLSによる保護に加えて, トークンの暗号化を行う必要がある (MUST). トークン露呈に対するさらなる防衛として, クライアントは, 保護リソースにリクエストを送信する際, 証明書失効リスト (CRL) [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) の確認を含めて, TLSの証明書チェーンを検証しなければならない(MUST).

クッキーは一般的に平文で送信される.したがって, クッキーに含まれる情報は露呈する危険性をもつ. そのため, クッキーを平文で送信できる場合, 署名無しトークンをクッキー内に格納してはならない (MUST NOT). クッキーにおけるセキュリティ上の脅威については, "HTTP State Management Mechanism" [RFC6265] (Barth, A., “HTTP State Management Mechanism,” April 2011.) を参照のこと.

ロードバランサを用いる場合を含むいくつかの場合において, リソースサーバへのTLS接続は, リソースを提供する実際のサーバに到達する以前に, 終端されることがある. これは, TLSコネクションを終端するフロントエンドサーバと実際にリソースを提供するバックエンドサーバ間において, トークンを未保護のままにする. このような場合, フロントエンドサーバとバックエンドサーバ間におけるトークンの機密性を保証するために, 充分な対策を行う必要がある(MUST). トークンの暗号化は, 対策の一つである.

トークンの覗き見と再利用 (トークンリプレイ) への対策として, 以下の手段が推奨される: 第一に, トークンの有効期限は制限されている必要がある (MUST) が, これを実現する一つの方法は, トークン内の保護された部分に, 有効な時間のフィールドを保持しておくことである. 短命 (1時間以下) のトークンを利用することにより, トークンが露呈した場合の影響が軽減されることに留意すべきである. 第二に, クライアントと認可サーバの間及びクライアントとリソースサーバ間の通信においては, 機密性保護を行わなければならない (MUST). 結果として, 通信経路に存在する盗聴者は, トークンの交換を覗き見ることができなくなる. 従って, そのような経路上の攻撃者は, トークンをリプレイすることができない. さらに, クライアントはトークンをリソースサーバに送信する際 "HTTP Over TLS" [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) の3.1項に従い, リソースサーバのアイデンティティを確認しなければならない (MUST). 保護リソースにリクエストを行う際, クライアントはTLSの証明書チェーンを検証しなければならない (MUST) ことに注意すべきである. 未認証かつ未認可なリソースサーバにトークンを送信すること, あるいは証明書チェインの確認に失敗することは, 攻撃者に対して, トークンを盗み, 保護リソースへの認可されていないアクセスを許すことになる.

5.3.  推奨事項のまとめ

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

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

TLS証明書チェインを検証する:

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

Always use TLS (https):

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

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

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

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

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

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

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

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

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

6.  IANA Considerations

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

本仕様は, [RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) で定義される OAuth アクセストークンタイプレジストリーに, 以下のアクセストークンの種類を登録する.

6.1.1.  "Bearer" OAuth アクセストークンタイプ

Type name:

Bearer

Additional Token Endpoint Response Parameters:

(none)

HTTP Authentication Scheme(s):

Bearer

Change controller:

IETF

Specification document(s):

RFC 6750

6.2.  OAuth 拡張エラー登録

本仕様は, [RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) で定義される OAuth 拡張エラーレジストリーに, 以下のエラーの種類を登録する.

6.2.1.  "invalid_request" エラー

Error name:

invalid_request

Error usage location:

Resource access error response

Related protocol extension:

Bearer access token type

Change controller:

IETF

Specification document(s):

RFC 6750

6.2.2.  "invalid_token" エラー

Error name:

invalid_token

Error usage location:

Resource access error response

Related protocol extension:

Bearer access token type

Change controller:

IETF

Specification document(s):

RFC 6750

6.2.3.  "insufficient_scope" エラー

Error name:

insufficient_scope

Error usage location:

Resource access error response

Related protocol extension:

Bearer access token type

Change controller:

IETF

Specification document(s):

RFC 6750

7.  References

7.1. Normative References

7.2. Informative References

7.3. 翻訳プロジェクト

Appendix A.  Acknowledgements

The following people contributed to preliminary versions of this document: Blaine Cook (BT), Brian Eaton (Google), Yaron Y. Goland (Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter), Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and concepts within are a product of the OAuth community, the Web Resource Authorization Profiles (WRAP) community, and the OAuth Working Group. David Recordon created a preliminary version of this specification based upon an early draft of the specification that evolved into OAuth 2.0 [RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.). Michael B. Jones in turn created the first version (00) of this specification using portions of David's preliminary document and edited all subsequent versions.

The OAuth Working Group has dozens of very active contributors who proposed ideas and wording for this document, including Michael Adams, Amanda Anganes, Andrew Arnott, Derek Atkins, Dirk Balfanz, John Bradley, Brian Campbell, Francisco Corella, Leah Culver, Bill de hOra, Breno de Medeiros, Brian Ellin, Stephen Farrell, Igor Faynberg, George Fletcher, Tim Freeman, Evan Gilbert, Yaron Y. Goland, Eran Hammer, Thomas Hardjono, Dick Hardt, Justin Hart, Phil Hunt, John Kemp, Chasen Le Hara, Barry Leiba, Amos Jeffries, Michael B. Jones, Torsten Lodderstedt, Paul Madsen, Eve Maler, James Manger, Laurence Miao, William J. Mills, Chuck Mortimore, Anthony Nadalin, Axel Nennker, Mark Nottingham, David Recordon, Julian Reschke, Rob Richards, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Justin Smith, Christian Stuebner, Jeremy Suriel, Doug Tangren, Paul Tarjan, Hannes Tschofenig, Franklin Tse, Sean Turner, Paul Walker, Shane Weeden, Skylar Woodward, and Zachary Zeltsan.

Appendix B.  翻訳者

本仕様の翻訳は, 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
• Ryo Ito (mixi, Inc.)
• Tatsuya Katsuhara (NRI)
• Yusuke Kondo (Yahoo! Japan)

Authors' Addresses