Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 6750 Microsoft
カテゴリ: 標準化過程 D. Hardt
ISSN: 2070-1721 Independent
2012年10月
OAuth 2.0 認可フレームワーク: ベアラー・トークンの利用
概要
この仕様は、OAuth 2.0 によって保護されたリソースにアクセスする
ために、HTTPリクエストでベアラー・トークンを使用する方法を
説明します。ベアラー・トークンを所持している任意の当事者
（「ベアラー」）は、（暗号鍵の所持を証明することなく）
それを使用して関連リソースへのアクセスを取得できます。
不正使用を防ぐため、ベアラー・トークンは保存時および
転送時に開示から保護される必要があります。
このメモの位置づけ
これはインターネット標準化過程の文書です。
この文書は Internet Engineering Task Force (IETF) の成果物です。
これは IETF コミュニティの合意を表しています。公開レビューを受け、
Internet Engineering Steering Group (IESG) によって公開が承認されて
います。インターネット標準に関する詳細情報は
RFC 5741 の Section 2 で入手できます。
この文書の現在の状態、正誤表、およびフィードバックの提供方法に
関する情報は、
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.
Jones & Hardt 標準化過程 [ページ 1]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
目次
1. はじめに ....................................................2
1.1. 表記上の規約 .............................................3
1.2. 用語 ....................................................3
1.3. 概要 ....................................................3
2. 認証済みリクエスト ..........................................4
2.1. Authorizationリクエスト・ヘッダー・フィールド .............5
2.2. フォーム符号化された本文パラメーター ......................5
2.3. URIクエリー・パラメーター ................................6
3. WWW-Authenticateレスポンス・ヘッダー・フィールド ..............7
3.1. エラー・コード ...........................................9
4. アクセス・トークン・レスポンスの例 ..........................10
5. セキュリティに関する考慮事項 ................................10
5.1. セキュリティ上の脅威 ....................................10
5.2. 脅威の軽減 ..............................................11
5.3. 推奨事項の要約 ..........................................13
6. IANAに関する考慮事項 ........................................14
6.1. OAuthアクセス・トークン型の登録 ..........................14
6.1.1. "Bearer" OAuthアクセス・トークン型 ...............14
6.2. OAuth拡張エラー登録 ......................................14
6.2.1. "invalid_request" エラー値 .......................14
6.2.2. "invalid_token" エラー値 .........................15
6.2.3. "insufficient_scope" エラー値 ....................15
7. 参考文献 ....................................................15
7.1. 規範的参考文献 ..........................................15
7.2. 参考情報 ................................................17
Appendix A. 謝辞 ..............................................18
1. はじめに
OAuthは、リソース所有者の資格情報を直接使用するのではなく、
「OAuth 2.0 認可フレームワーク」[RFC6749] で
「クライアントに発行されたアクセス認可を表す文字列」として
定義されるアクセス・トークンを取得することにより、クライアントが
保護リソースにアクセスできるようにします。
トークンは、リソース所有者の承認を得て、認可サーバーによって
クライアントに発行されます。クライアントはアクセス・トークンを使用して、
リソース・サーバーがホストする保護リソースにアクセスします。この仕様は、
OAuthアクセス・トークンがベアラー・トークンである場合に、
保護リソース・リクエストを行う方法を説明します。
この仕様は、保護リソースにアクセスするために、Transport Layer
Security (TLS) [RFC5246] を使用して HTTP/1.1
[RFC2616] 上でベアラー・トークンを使用する方法を定義します。
TLSは、この仕様とともに実装および使用することが必須です。
他の仕様は、他のプロトコルで使用するためにこの仕様を拡張できます。
OAuth 2.0認可 [RFC6749] フローの結果として得られるアクセス・トークンを
Jones & Hardt 標準化過程 [ページ 2]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
使用してOAuth保護リソースにアクセスするために設計されていますが、
この仕様は実際には、任意の発行元からのベアラー・トークンを使用して、
それらのベアラー・トークンによって保護された任意のリソースに
アクセスできる、一般的なHTTP認可方式を定義しています。
Bearer認証スキームは主に、WWW-AuthenticateおよびAuthorization
HTTPヘッダーを使用したサーバー認証を意図していますが、
プロキシ認証での使用を妨げるものではありません。
1.1. 表記上の規約
この文書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
および "OPTIONAL" は、「RFCで要求レベルを示すために使用する
キーワード」[RFC2119] で説明されているように解釈されます。
この文書は、[RFC5234] の Augmented Backus-Naur Form (ABNF)
記法を使用します。さらに、HTTP/1.1 [RFC2617] から次の
ルールを含みます: auth-param および auth-scheme。また、
「Uniform Resource Identifier (URI): Generic Syntax」[RFC3986]
から URI-reference を含みます。
特に記載がない限り、すべてのプロトコル・パラメーター名および値は
大文字と小文字を区別します。
1.2. 用語
Bearer Token
トークンを所持している任意の当事者（「ベアラー」）が、
そのトークンを所持している他の任意の当事者と同じ方法で
使用できるという性質を持つセキュリティ・トークン。
ベアラー・トークンの使用では、ベアラーが暗号鍵素材の所持
（proof-of-possession）を証明する必要はありません。
その他のすべての用語は、「OAuth 2.0 認可フレームワーク」
[RFC6749] で定義されるとおりです。
1.3. 概要
OAuthは、クライアントがリソース所有者に代わって保護リソースに
アクセスするための方法を提供します。一般的な場合、クライアントが
保護リソースにアクセスできるようになる前に、まずリソース所有者から
認可グラントを取得し、次にその認可グラントをアクセス・トークンと
交換しなければなりません。アクセス・トークンは、認可グラントによって
付与されたグラントのスコープ、期間、およびその他の属性を表します。
クライアントは、アクセス・トークンをリソース・サーバーに提示することで
保護リソースにアクセスします。場合によっては、クライアントが
リソース所有者から認可グラントをまず取得することなく、自身の資格情報を
認可サーバーに直接提示してアクセス・トークンを取得できます。
Jones & Hardt 標準化過程 [ページ 3]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
アクセス・トークンは抽象化を提供し、異なる認可構成要素
（例: ユーザー名とパスワード、アサーション）を、リソース・サーバーが
理解する単一のトークンに置き換えます。この抽象化により、
短期間有効なアクセス・トークンを発行できるだけでなく、
リソース・サーバーが幅広い認証スキームを理解する必要もなくなります。
+--------+ +---------------+
| |--(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 ---| |
+--------+ +---------------+
図1: 抽象プロトコル・フロー
図1に示す抽象OAuth 2.0フローは、クライアント、リソース所有者、
認可サーバー、およびリソース・サーバー（[RFC6749] で説明）間の
相互作用を説明しています。この文書では、次の2つのステップを
規定します。
(E) クライアントはリソース・サーバーに保護リソースを要求し、
アクセス・トークンを提示することによって認証します。
(F) リソース・サーバーはアクセス・トークンを検証し、有効であれば、
リクエストに応答します。
この文書は、ステップ (D) で返されるアクセス・トークンにも
意味上の要求事項を課します。
2. 認証済みリクエスト
このセクションでは、リソース・サーバーへのリソース・リクエストで
ベアラー・アクセス・トークンを送信する3つの方法を定義します。
クライアントは、各リクエストでトークンを送信するために複数の方法を
使用してはなりません（MUST NOT）。
Jones & Hardt 標準化過程 [ページ 4]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
2.1. Authorizationリクエスト・ヘッダー・フィールド
HTTP/1.1 [RFC2617] で定義される "Authorization" リクエスト・ヘッダー・
フィールドでアクセス・トークンを送信する場合、クライアントは
"Bearer" 認証スキームを使用してアクセス・トークンを送信します。
例:
GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM
このスキームにおける "Authorization" ヘッダー・フィールドの構文は、
[RFC2617] の Section 2 で定義される Basic スキームの使用法に
従います。Basicと同様に、[RFC2617] の Section 1.2 で定義される
汎用構文には適合しませんが、HTTP 1.1 [HTTP-AUTH] 用に開発中の
一般的な認証フレームワークとは互換性があります。ただし、既存の
展開を反映するため、そこで概説されている推奨プラクティスには
従いません。Bearer資格情報の構文は次のとおりです。
b64token = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token
クライアントは、"Bearer" HTTP認可スキームとともに "Authorization"
リクエスト・ヘッダー・フィールドを使用して、ベアラー・トークンにより
認証済みリクエストを行うべきです（SHOULD）。リソース・サーバーは
この方法をサポートしなければなりません（MUST）。
2.2. フォーム符号化された本文パラメーター
HTTPリクエストのエンティティ本文でアクセス・トークンを送信する場合、
クライアントは "access_token" パラメーターを使用してアクセス・トークンを
リクエスト本文に追加します。クライアントは、次のすべての条件が
満たされていない限り、この方法を使用してはなりません（MUST NOT）。
o HTTPリクエストのエンティティ・ヘッダーには、"Content-Type"
ヘッダー・フィールドが "application/x-www-form-urlencoded" に
設定されて含まれている。
o エンティティ本文は、HTML 4.01
[W3C.REC-html401-19991224] で定義される
"application/x-www-form-urlencoded" コンテンツ型の符号化要件に従う。
o HTTPリクエストのエンティティ本文は単一パートである。
Jones & Hardt 標準化過程 [ページ 5]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
o エンティティ本文で符号化される内容は、完全にASCII
[USASCII] 文字で構成されなければならない（MUST）。
o 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でアクセス・トークンを送信する場合、クライアントは
「Uniform Resource Identifier (URI): Generic Syntax」[RFC3986] で
定義されるリクエストURIのクエリー構成要素に、"access_token"
パラメーターを使用してアクセス・トークンを追加します。
たとえば、クライアントはトランスポート層セキュリティを使用して、
次のHTTPリクエストを行います。
GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1
Host: server.example.com
HTTPリクエストURIのクエリーには、他のリクエスト固有パラメーターを
含めることができます。その場合、"access_token" パラメーターは、
"&" 文字（ASCIIコード38）を使用して、リクエスト固有パラメーターから
適切に分離されなければなりません（MUST）。
Jones & Hardt 標準化過程 [ページ 6]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
例:
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）。
URI方式に関連するセキュリティ上の弱点（Section 5 参照）、
とりわけアクセス・トークンを含むURLがログに記録される可能性が高いことから、
"Authorization" リクエスト・ヘッダー・フィールドまたはHTTPリクエストの
エンティティ本文でアクセス・トークンを転送することが不可能でない限り、
この方式を使用すべきではありません（SHOULD NOT）。リソース・サーバーは
この方法をサポートしてもかまいません（MAY）。
この方式は現在の使用状況を文書化するために含められています。
セキュリティ上の欠点（Section 5 参照）のため、
その使用は推奨されません。また、「Architecture of the World Wide Web,
Volume One」[W3C.REC-webarch-20041215] によるURI名前空間の
ベスト・プラクティスに反して、予約済みのクエリー・パラメーター名を
使用するためでもあります。
3. WWW-Authenticateレスポンス・ヘッダー・フィールド
保護リソース・リクエストが認証資格情報を含んでいない場合、または
保護リソースへのアクセスを可能にするアクセス・トークンを含んでいない
場合、リソース・サーバーはHTTP "WWW-Authenticate" レスポンス・
ヘッダー・フィールドを含めなければなりません（MUST）。その他の条件への
応答としてこれを含めてもかまいません（MAY）。"WWW-Authenticate"
ヘッダー・フィールドは、HTTP/1.1 [RFC2617] で定義される
フレームワークを使用します。
この仕様で定義されるすべてのチャレンジは、auth-scheme値 "Bearer" を
使用しなければなりません（MUST）。このスキームの後には、1つ以上の
auth-param値が続かなければなりません（MUST）。この仕様で使用または
定義されるauth-param属性は次のとおりです。その他のauth-param属性も
使用できます（MAY）。
"realm" 属性は、HTTP/1.1 [RFC2617] で説明される方法で
保護の範囲を示すために含めることができます（MAY）。"realm" 属性は
複数回出現してはなりません（MUST NOT）。
"scope" 属性は、[RFC6749] の Section 3.3 で定義されます。
"scope" 属性は、要求されたリソースにアクセスするためにアクセス・
トークンに必要なスコープを示す、大文字と小文字を区別するスコープ値の
空白区切りリストです。"scope" 値は実装定義であり、それらに対する
集中登録簿はありません。許可される値は認可サーバーによって定義されます。
"scope" 値の順序には意味がありません。場合によっては、"scope" 値は
Jones & Hardt 標準化過程 [ページ 7]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
保護リソースを利用するのに十分なアクセス範囲を持つ新しいアクセス・
トークンを要求するときに使用されます。"scope" 属性の使用は任意です
（OPTIONAL）。"scope" 属性は複数回出現してはなりません（MUST NOT）。
"scope" 値はプログラムでの使用を意図しており、エンドユーザーに
表示することを目的としていません。
以下に2つのスコープ値の例を示します。これらはそれぞれ、OpenID
Connect [OpenID.Messages] および Open Authentication Technology
Committee (OATC) Online Multimedia Authorization Protocol [OMAP]
の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）。これはエンドユーザーに表示することを目的と
していません。また、エラーを説明する人間が読めるWebページを識別する
絶対URIを持つ "error_uri" 属性を含めてもかまいません（MAY）。
"error", "error_description", および "error_uri" 属性は
複数回出現してはなりません（MUST NOT）。
"scope" 属性の値（[RFC6749] の Appendix A.4 で規定）は、
スコープ値を表す %x21 / %x23-5B / %x5D-7E、およびスコープ値間の
区切りとしての %x20 の集合外の文字を含んではなりません（MUST NOT）。
"error" および "error_description" 属性の値（[RFC6749] の
Appendixes A.7 および A.8 で規定）は、%x20-21 / %x23-5B / %x5D-7E
の集合外の文字を含んではなりません（MUST NOT）。"error_uri" 属性の
値（[RFC6749] の Appendix A.9 で規定）は、URI-reference構文に
適合しなければならず、したがって %x21 / %x23-5B / %x5D-7E の
集合外の文字を含んではなりません（MUST NOT）。
たとえば、認証なしの保護リソース・リクエストに対するレスポンスでは:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
Jones & Hardt 標準化過程 [ページ 8]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
また、期限切れのアクセス・トークンを使用した認証試行を伴う
保護リソース・リクエストに対するレスポンスでは:
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, または 405）を使用して応答し、
レスポンスに次のいずれかのエラー・コードを含めます。
invalid_request
リクエストに必須パラメーターが欠落している、サポートされていない
パラメーターまたはパラメーター値を含んでいる、同じパラメーターを
繰り返している、アクセス・トークンを含めるために複数の方法を
使用している、またはその他の形式不正がある。リソース・サーバーは
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"
Jones & Hardt 標準化過程 [ページ 9]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
4. アクセス・トークン・レスポンスの例
通常、ベアラー・トークンはOAuth 2.0 [RFC6749] アクセス・
トークン・レスポンスの一部としてクライアントに返されます。
そのようなレスポンスの例は次のとおりです。
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. セキュリティに関する考慮事項
このセクションでは、ベアラー・トークンを使用する際のトークン処理に
関する関連するセキュリティ上の脅威を説明し、これらの脅威を軽減する
方法を説明します。
5.1. セキュリティ上の脅威
次の一覧は、何らかの形式のトークンを利用するプロトコルに対する
いくつかの一般的な脅威を示しています。この脅威一覧は、NIST Special
Publication 800-63 [NIST800-63] に基づいています。この文書は
OAuth 2.0認可仕様 [RFC6749] に基づいているため、そこや関連文書で
説明されている脅威についての議論は除外します。
トークンの生成/変更: 攻撃者は偽のトークンを生成したり、既存の
トークンの内容（認証文や属性文など）を変更したりして、
リソース・サーバーがクライアントに不適切なアクセスを許可するように
する可能性があります。たとえば、攻撃者はトークンを変更して
有効期間を延長する可能性があります。また、悪意のあるクライアントは、
閲覧できるべきでない情報へのアクセスを得るためにアサーションを
変更する可能性があります。
トークンの開示: トークンには、機密情報を含む認証文および属性文が
含まれている可能性があります。
Jones & Hardt 標準化過程 [ページ 10]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
トークンのリダイレクト: 攻撃者は、あるリソース・サーバーによる利用の
ために生成されたトークンを使用して、そのトークンが自分宛てであると
誤って信じている別のリソース・サーバーへのアクセスを得ます。
トークンのリプレイ: 攻撃者は、そのリソース・サーバーで過去に
すでに使用されたトークンを使用しようとします。
5.2. 脅威の軽減
トークンの内容をデジタル署名またはMessage Authentication Code (MAC)で
保護することにより、広範な脅威を軽減できます。あるいは、
ベアラー・トークンは、認可情報を直接符号化するのではなく、
認可情報への参照を含むことができます。そのような参照は、攻撃者が
推測することが不可能でなければなりません（MUST）。参照を使用する場合、
参照を認可情報に解決するために、サーバーとトークン発行者との間で
追加の相互作用が必要になることがあります。そのような相互作用の仕組みは
この仕様では定義しません。
この文書はトークンの符号化または内容を規定しません。したがって、
トークン完全性保護を保証する手段に関する詳細な推奨事項は、この文書の
範囲外です。トークン完全性保護は、トークンの変更を防ぐのに十分で
なければなりません（MUST）。
トークンのリダイレクトに対処するためには、認可サーバーがトークンに
意図された受信者（オーディエンス）の識別子、通常は単一のリソース・
サーバー（またはリソース・サーバーのリスト）を含めることが重要です。
トークンの使用を特定のスコープに制限することも推奨されます
（RECOMMENDED）。
認可サーバーはTLSを実装しなければなりません（MUST）。どのバージョンを
実装すべきかは、時間とともに変化し、実装時点での普及状況および既知の
セキュリティ脆弱性に依存します。執筆時点では、TLSバージョン1.2
[RFC5246] が最新バージョンですが、実際の展開は非常に限られており、
実装ツールキットで容易に利用できない可能性があります。TLSバージョン1.0
[RFC2246] は最も広く展開されているバージョンであり、最も広い
相互運用性を提供します。
トークンの開示を防ぐため、機密性および完全性保護を提供する暗号スイート
を用いたTLS [RFC5246] により、機密性保護を適用しなければなりません
（MUST）。これには、クライアントと認可サーバー間の通信相互作用、
およびクライアントとリソース・サーバー間の相互作用の両方が、
機密性および完全性保護を利用することが必要です。TLSはこの仕様と
ともに実装および使用することが必須であるため、通信チャネルを介した
トークン開示を防ぐための推奨される方法です。クライアントがトークンの
Jones & Hardt 標準化過程 [ページ 11]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
内容を観察できないようにされている場合には、TLS保護の使用に加えて
トークン暗号化を適用しなければなりません（MUST）。トークン開示に対する
さらなる防御として、クライアントは保護リソースにリクエストを行う際に、
Certificate Revocation List (CRL) [RFC5280] の確認を含め、
TLS証明書チェーンを検証しなければなりません（MUST）。
Cookieは通常、平文で送信されます。したがって、その中に含まれる情報は
開示の危険にさらされます。そのため、ベアラー・トークンは、平文で
送信され得るCookieに保存してはなりません（MUST NOT）。Cookieに関する
セキュリティ上の考慮事項については、「HTTP State Management Mechanism」
[RFC6265] を参照してください。
ロードバランサーを利用するものを含む一部の展開では、リソース・
サーバーへのTLS接続が、リソースを提供する実際のサーバーより前で
終端されます。これにより、TLS接続が終端されるフロントエンド・サーバーと、
リソースを提供するバックエンド・サーバーとの間で、トークンが保護されない
ままになる可能性があります。そのような展開では、フロントエンドと
バックエンドのサーバー間でトークンの機密性を確保するために、十分な措置を
講じなければなりません（MUST）。トークンの暗号化は、そのような可能な
措置の1つです。
トークンの捕捉とリプレイに対処するために、次の推奨事項を示します。
第一に、トークンの存続期間は制限されなければなりません（MUST）。
これを実現する一つの手段は、トークンの保護部分の中に有効期限フィールドを
入れることです。短寿命（一時間以下）のトークンを使用すると、
それらが漏えいした場合の影響が低減されることに注意してください。
第二に、クライアントと認可サーバー間、およびクライアントとリソース・
サーバー間の交換に対して、機密性保護を適用しなければなりません
（MUST）。その結果、通信経路上の盗聴者はトークン交換を観察できません。
したがって、そのような経路上の攻撃者はトークンをリプレイできません。
さらに、トークンをリソース・サーバーに提示する際、クライアントは
「HTTP Over TLS」[RFC2818] の Section 3.1 に従って、そのリソース・
サーバーの身元を検証しなければなりません（MUST）。これらのリクエストを
保護リソースに行う際、クライアントはTLS証明書チェーンを検証しなければ
ならないことに注意してください（MUST）。認証および認可されていない
リソース・サーバーにトークンを提示したり、証明書チェーンの検証に
失敗したりすると、攻撃者がトークンを盗み、保護リソースへの
不正アクセスを得ることを許してしまいます。
Jones & Hardt 標準化過程 [ページ 12]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
5.3. 推奨事項の要約
ベアラー・トークンを保護する: クライアント実装は、ベアラー・トークンが
意図しない当事者に漏えいしないようにしなければなりません（MUST）。
そのような当事者は、保護リソースへのアクセスを得るためにそれらを
使用できるためです。これはベアラー・トークンを使用する際の主要な
セキュリティ上の考慮事項であり、以下に続くすべてのより具体的な
推奨事項の基礎となります。
TLS証明書チェーンを検証する: クライアントは保護リソースにリクエストを
行う際に、TLS証明書チェーンを検証しなければなりません（MUST）。
これを怠ると、DNSハイジャック攻撃によってトークンが盗まれ、
意図しないアクセスを得られる可能性があります。
常にTLS (https) を使用する: クライアントは、ベアラー・トークンを用いて
リクエストを行う際、常にTLS [RFC5246] (https) または同等の
トランスポート・セキュリティを使用しなければなりません（MUST）。
これを怠ると、トークンは多数の攻撃にさらされ、攻撃者に意図しない
アクセスを与える可能性があります。
ベアラー・トークンをCookieに保存しない: 実装は、平文で送信され得る
Cookie（Cookieの既定の送信モード）内にベアラー・トークンを
保存してはなりません（MUST NOT）。ベアラー・トークンをCookieに
保存する実装は、クロスサイト・リクエスト・フォージェリに対する
予防措置を講じなければなりません（MUST）。
短寿命のベアラー・トークンを発行する: トークン・サーバーは、特に
Webブラウザー内で実行されるクライアントや、情報漏えいが発生する
可能性のあるその他の環境に対してトークンを発行する場合、短寿命
（一時間以下）のベアラー・トークンを発行すべきです（SHOULD）。
短寿命のベアラー・トークンを使用することで、それらが漏えいした場合の
影響を低減できます。
スコープ付きベアラー・トークンを発行する: トークン・サーバーは、
意図された依拠当事者または依拠当事者の集合に使用を限定する、
オーディエンス制限を含むベアラー・トークンを発行すべきです
（SHOULD）。
ページURLでベアラー・トークンを渡さない: ベアラー・トークンは、
ページURL（たとえばクエリー文字列パラメーター）で渡すべきでは
ありません（SHOULD NOT）。代わりに、ベアラー・トークンは、
機密性措置が講じられるHTTPメッセージ・ヘッダーまたはメッセージ本文で
渡すべきです（SHOULD）。ブラウザー、Webサーバー、およびその他の
ソフトウェアは、ブラウザー履歴、Webサーバー・ログ、およびその他の
データ構造内のURLを十分に保護しない可能性があります。ベアラー・
トークンがページURLで渡される場合、攻撃者は履歴データ、ログ、または
その他の保護されていない場所からそれらを盗むことができる可能性があります。
Jones & Hardt 標準化過程 [ページ 13]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
6. IANAに関する考慮事項
6.1. OAuthアクセス・トークン型の登録
この仕様は、[RFC6749] で定義されるOAuth Access Token Types登録簿に、
次のアクセス・トークン型を登録します。
6.1.1. "Bearer" OAuthアクセス・トークン型
型名:
Bearer
追加のトークン・エンドポイント・レスポンス・パラメーター:
（なし）
HTTP認証スキーム:
Bearer
変更管理者:
IETF
仕様文書:
RFC 6750
6.2. OAuth拡張エラー登録
この仕様は、[RFC6749] で定義されるOAuth Extensions Error登録簿に、
次のエラー値を登録します。
6.2.1. "invalid_request" エラー値
エラー名:
invalid_request
エラー使用場所:
リソース・アクセス・エラー・レスポンス
関連プロトコル拡張:
Bearerアクセス・トークン型
変更管理者:
IETF
仕様文書:
RFC 6750
Jones & Hardt 標準化過程 [ページ 14]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
6.2.2. "invalid_token" エラー値
エラー名:
invalid_token
エラー使用場所:
リソース・アクセス・エラー・レスポンス
関連プロトコル拡張:
Bearerアクセス・トークン型
変更管理者:
IETF
仕様文書:
RFC 6750
6.2.3. "insufficient_scope" エラー値
エラー名:
insufficient_scope
エラー使用場所:
リソース・アクセス・エラー・レスポンス
関連プロトコル拡張:
Bearerアクセス・トークン型
変更管理者:
IETF
仕様文書:
RFC 6750
7. 参考文献
7.1. 規範的参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997年3月.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, 1999年1月.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, 1999年6月.
Jones & Hardt 標準化過程 [ページ 15]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
S., Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, 1999年6月.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2000年5月.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, 2005年1月.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, 2008年1月.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
2008年8月.
[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", RFC 5280, 2008年5月.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
2011年4月.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, 2012年10月.
[USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
[W3C.REC-html401-19991224]
Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium
Recommendation REC-html401-19991224, 1999年12月,
<http://www.w3.org/TR/1999/REC-html401-19991224>.
[W3C.REC-webarch-20041215]
Jacobs, I. and N. Walsh, "Architecture of the World Wide
Web, Volume One", World Wide Web Consortium
Recommendation REC-webarch-20041215, 2004年12月,
<http://www.w3.org/TR/2004/REC-webarch-20041215>.
Jones & Hardt 標準化過程 [ページ 16]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
7.2. 参考情報
[HTTP-AUTH] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", Work
in Progress, 2012年10月.
[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", 2011年12月,
<http://csrc.nist.gov/publications/>.
[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", 2012年4月,
<http://www.oatc.us/Standards/Download.aspx>.
[OpenID.Messages]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B.,
Mortimore, C., and E. Jay, "OpenID Connect Messages
1.0", 2012年6月, <http://openid.net/specs/
openid-connect-messages-1_0.html>.
Jones & Hardt 標準化過程 [ページ 17]
RFC 6750 OAuth 2.0 ベアラー・トークンの利用 2012年10月
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コミュニティ、
Web Resource Authorization Profiles (WRAP) コミュニティ、および
OAuth Working Groupの成果です。David Recordonは、OAuth 2.0
[RFC6749] へと発展した仕様の初期ドラフトに基づき、この仕様の
予備版を作成しました。Michael B. Jonesはその後、Davidの予備文書の
一部を使用してこの仕様の最初の版（00）を作成し、その後のすべての版を
編集しました。
OAuth Working Groupには、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 を含む、非常に活発な貢献者が数十名おり、
この文書のアイデアおよび文言を提案しました。
著者の住所
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
URI: http://self-issued.info/
Dick Hardt
Independent
EMail: dick.hardt@gmail.com
URI: http://dickhardt.org/
Jones & Hardt 標準化過程 [ページ 18]