TOC 
Network Working GroupE. Hammer-Lahav, Ed.
Internet-DraftYahoo!
Obsoletes: 5849 (if approved)D. Recordon
Intended status: Standards TrackFacebook
Expires: March 25, 2012D. Hardt
 Microsoft
 September 22, 2011


The OAuth 2.0 Authorization Protocol
draft-ietf-oauth-v2-22

Abstract

OAuth 2.0 は, サードパーティーアプリケーションがHTTPで提供されるサービスとリソースオーナー間に同意の調整を行うか, もしくはサードパーティーアプリケーション自身のためにアクセスすることを自ら許可することによって, サービスへの限定されたアクセス権を得ることを可能にする認可プロトコルである. 本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである.

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 March 25, 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.  認可グラント
        1.3.1.  認可コード
        1.3.2.  インプリシット (暗黙の)
        1.3.3.  リソースオーナーパスワードクレデンシャル
        1.3.4.  クライアントクレデンシャル
    1.4.  アクセストークン
    1.5.  リフレッシュトークン
    1.6.  表記規約
2.  クライアント登録
    2.1.  クライアントタイプ
    2.2.  クライアント識別子
    2.3.  クライアント認証
        2.3.1.  クライアントパスワード
        2.3.2.  その他の認証方式
    2.4.  未登録クライアント
3.  プロトコルエンドポイント
    3.1.  認可エンドポイント
        3.1.1.  レスポンスタイプ
        3.1.2.  リダイレクトエンドポイント
    3.2.  トークンエンドポイント
        3.2.1.  クライアント認証
    3.3.  アクセストークンスコープ
4.  認可の取得
    4.1.  認可コード
        4.1.1.  認可リクエスト
        4.1.2.  認可レスポンス
        4.1.3.  アクセストークンリクエスト
        4.1.4.  アクセストークンレスポンス
    4.2.  インプリシットグラント
        4.2.1.  認可リクエスト
        4.2.2.  アクセストークンレスポンス
    4.3.  リソースオーナーパスワードクレデンシャル
        4.3.1.  認可リクエストとレスポンス
        4.3.2.  アクセストークンリクエスト
        4.3.3.  アクセストークンレスポンス
    4.4.  クライアントクレデンシャル
        4.4.1.  認可リクエストとレスポンス
        4.4.2.  アクセストークンリクエスト
        4.4.3.  アクセストークンレスポンス
    4.5.  拡張
5.  アクセストークンの発行
    5.1.  成功レスポンス
    5.2.  エラーレスポンス
6.  アクセストークンの更新
7.  保護されたリソースへのアクセス
    7.1.  アクセストークンタイプ
8.  仕様の拡張性
    8.1.  アクセストークンタイプの定義
    8.2.  新たなエンドポイントパラメーターの定義
    8.3.  新たな認可グラントタイプの定義
    8.4.  新たな認可エンドポイントレスポンスタイプの定義
    8.5.  追加のエラーコードの定義
9.  ネイティブアプリケーション
10.  Security Considerations
    10.1.  クライアント認証
    10.2.  クライアント偽装
    10.3.  アクセストークン
    10.4.  リフレッシュトークン
    10.5.  認可コード
    10.6.  認可コードリダイレクトURIの操作
    10.7.  リソースオーナーパスワードクレデンシャル
    10.8.  リクエストの機密性
    10.9.  エンドポイントの真正性
    10.10.  クレデンシャルゲッシングアタック
    10.11.  フィッシングアタック
    10.12.  クロスサイトリクエストフォージェリ
    10.13.  クリックジャッキング
    10.14.  コードインジェクションとインプットバリデーション
    10.15.  オープンリダイレクタ
11.  IANA Considerations
    11.1.  OAuth アクセストークンタイプレジストリー
        11.1.1.  レジストリーテンプレート
    11.2.  OAuth パラメーターレジストリー
        11.2.1.  レジストリーテンプレート
        11.2.2.  初期レジストリーコンテンツ
    11.3.  OAuth 認可エンドポイントレスポンスタイプレジストリー
        11.3.1.  レジストリーテンプレート
        11.3.2.  初期レジストリーコンテンツ
    11.4.  OAuth拡張エラーレジストリー
        11.4.1.  レジストリーテンプレート
12.  Acknowledgements
Appendix A.  Editor's Notes
Appendix B.  翻訳者
13.  References
    13.1.  Normative References
    13.2.  Informative References
    13.3.  翻訳プロジェクト
§  Authors' Addresses



 TOC 

1.  はじめに

従来のクライアントサーバー型の認証モデルでは, クライアントはリソースオーナーのクレデンシャルを使ってサーバーに対して認証を行いサーバー上の保護されたリソースにアクセスする. つまり, サードパーティーアプリケーションに保護されたリソースへのアクセス権を与えるには, リソースオーナーは自身のクレデンシャルをサードパーティーと共有する必要がある. これはいくつかの問題と制限をもたらす.

OAuthは, クライアントとリソースオーナーの役割を分けることで, これらの問題の解決に取り組む. OAuthでは, クライアントは, リソースオーナーのコントロール下にありリソースサーバーによってホストされているリソースへのアクセス権を要求する. そしてリソースオーナーのクレデンシャルそのものとは別のクレデンシャルを取得する.

クライアントは, 保護されたリソースにアクセスする為にリソースオーナーのクレデンシャルを使う代わりに, アクセストークン (ある特定のスコープ, 期間およびその他の属性と紐付けられた文字列) を取得する. アクセストークンはリソースオーナーの同意をもって認可サーバーからサードパーティークライアントへ発行される. クライアントはアクセストークンを用いてリソースサーバーがホストしている保護されたリソースにアクセスする.

例えば, あるユーザー (リソースオーナー) が, 印刷サービス (クライアント) に対して, 写真共有サービス上 (リソースサーバー) に保管されている彼女の保護された写真へのアクセス権を与えることを考える. 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.) での利用を想定して設計されている. HTTP以外の通信プロトコルでのOAuth利用については未定義である.


 TOC 

1.1.  ロール

OAuthは以下4つのロールを定義する.

リソースオーナー
保護されたリソースへのアクセスを許可するエンティティー. (例：エンドユーザー)
リソースサーバー
保護されたリソースをホストし, アクセストークンを用いた保護されたリソースへのリクエストを受理してレスポンスを返すことのできるサーバー.
クライアント
リソースオーナーの認可を得て, リソースオーナーの代理として保護されたリソースに対するリクエストを行うアプリケーション.
認可サーバー
リソースオーナーの認証とリソースオーナーからの認可取得が成功した後, アクセストークンをクライアントに発行するサーバー.

認可サーバーとリソースサーバー間のやりとりについては本仕様書の範囲外である. 認可サーバーはリソースサーバーと同一のサーバーでも異なるサーバーでもよい. 単一の認可サーバーが複数のリソースサーバーにアクセス可能なアクセストークンを発行してもよい.


 TOC 

1.2.  プロトコルフロー



  +--------+                               +---------------+
  |        |--(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: プロトコルフローの概要 

Figure 1 (プロトコルフローの概要)で示されたフロー概要は, 4つのロール間での相互作用と以下のステップについて記載している.

(A)
クライアントはリソースオーナーに対して認可を要求する. その際 (図のように) リソースオーナーに直接認可要求を行うことも出来るが, 認可サーバーを経由して間接的に行うことがのぞましい.
(B)
クライアントは, リソースオーナーの認可を表すクレデンシャルとして認可グラントを受け取る. 認可グラントは本仕様で定義される4つのグラントタイプの内の1つ, または拡張されたグラントタイプで発行される. どの認可グラントタイプを用いるかは, クライアントの利用する認可リクエストの方式と認可サーバーがサポートするグラントタイプに依存する.
(C)
クライアントは認可サーバーに対して自身を認証し, 認可グラントを提示することで, アクセストークンを要求する.
(D)
認可サーバーはクライアント認証と認可グラントの正当性を確認し, 正当であればアクセストークンを発行する.
(E)
クライアントはリソースサーバーの保護されたリソースへリクエストを行い, 発行されたアクセストークンにより認証を行う.
(F)
リソースサーバーはアクセストークンの正当性を確認し, 正当であればリクエストを受け入れる.


 TOC 

1.3.  認可グラント

認可グラントは, リソースオーナーの (保護されたリソースへのアクセスを行うことに対する) 認可を示し, クライアントがアクセストークンを取得する際に用いられる. 本仕様では認可コード, インプリシット, リソースオーナーパスワードクレデンシャル, クライアントクレデンシャルの4つのグラントタイプを定義しており, 拡張仕様によってタイプを追加することもできる.


 TOC 

1.3.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.) に定義されたユーザーエージェントを経由して) リソースオーナーを認可サーバーへリダイレクトさせ, リソースオーナーがリダイレクトして戻ってきた際に認可コードを取得する.

リソースオーナーを認可コードとともにリダイレクト経由でクライアントに戻す前に, 認可サーバーはリソースオーナーを認証し認可を得る. これによりリソースオーナーは認可サーバーによってのみ認証され, リソースオーナーのクレデンシャルはクライアントへ共有されない.

認可コードは, クライアントを認証する機会を提供したり, リソースオーナーのユーザーエージェントを経由せずリソースオーナーを含む第三者に露出することなしにアクセストークンをクライアントに直接伝搬できるなど, いくつかの点で重要なセキュリティ的なメリットを提供する.


 TOC 

1.3.2.  インプリシット (暗黙の)

インプリシットグラントはJavaScriptの様なスクリプト言語を使用して, ブラウザで実行されるクライアントに最適化され, 認可コードフローを単純化したものである. インプリシットフローでは, クライアントは (リソースオーナー認可の結果) 認可コードの代わりに直接アクセストークンを受け取る. このグラントタイプは (認可コードのような, 後にアクセストークンを取得する際に用いられる) 仲介のクレデンシャルを利用しないため, インプリシット (訳注: implicit = 暗黙の) と呼ばれる.

インプリシットグラントを発行する時, 認可サーバーはクライアントを認証しない. ただし, クライアントにアクセストークンを渡す際に使用されたリダイレクトURIをもとに, クライアントの身元が検証可能なこともある. アクセストークンはリソースオーナー, もしくはリソースオーナーのユーザーエージェントにアクセスすることで他のアプリケーションに晒されるかもしれない.

アクセストークンを得るのに必要な往復の回数を減らせるため, インプリシットグラントは (ブラウザにおけるアプリケーションとして実行されたクライアントなど) いくつかのクライアントで反応性と効率性を高める. しかしながら, 特に認可コードグラントタイプが利用可能である場合, インプリシットグラントを用いた場合の利便性はセキュリティー面の影響とトレードオフの関係にあることを考慮すべきである.


 TOC 

1.3.3.  リソースオーナーパスワードクレデンシャル

リソースオーナーパスワードクレデンシャル (例えばユーザー名とパスワード) を直接アクセストークンを得るための認可グラントとして使用することも出来る. このクレデンシャルは, リソースオーナーとクライアント (例えばデバイスOSや非常に特権のあるアプリケーション) の間で高い信頼があり, (認可コードのような) 他の認可グラントタイプが利用できない場合のみ使用されるべきである.

このグラントタイプでは, クライアントがリソースオーナークレデンシャルへ直接アクセスすることになるが, リソースオーナークレデンシャルは1回のリクエストにのみ使用され, アクセストークンに交換される. このグラントタイプでは, クレデンシャルを寿命の長いアクセストークンやリフレッシュトークンと交換することにより, クライアントがリソースオーナークレデンシャルを将来的に使用する目的で格納しておく必要がなくなる.


 TOC 

1.3.4.  クライアントクレデンシャル

認可範囲がクライアントの管理下の保護されたリソースもしくはあらかじめ認可サーバーとの間で調整済の保護されたリソースに制限されている場合は, 認可グラントとしてクライアントクレデンシャル (もしくは他のクライアント認証形式) が使用できる. クライアントがクライアント自身のために行動している (またはクライアントがリソースオーナー) か, クライアントがあらかじめ認可サーバーとの間で調整済の保護されたリソースアクセスを求めている場合, クライアントクレデンシャルが認可グラントとして使用される.


 TOC 

1.4.  アクセストークン

アクセストークンは保護されたリソースにアクセスするために使用されるクレデンシャルである. アクセストークンはクライアントに対して発行される認可を表す文字列である. この文字列は通常クライアントからみるとランダムな文字列になっている. トークンはアクセス範囲とアクセス期間を表し, それらはリソースのオーナーによって許可され, リソースサーバーと認可サーバーによって適用される.

トークンは認可情報を取り出すための識別子を表したり, 検証可能な方法でそれ自身に認可情報を含んでもよい (データと署名を含むトークン文字列など). クライアントがトークンを使用するために, 本仕様で定めていない追加の認証クレデンシャルが要求されることもある.

アクセストークンによって, 様々な認可要素 (例えばユーザー名やパスワード) をリソースサーバーが解釈できる単体のトークンに置き換えるような抽象化レイヤーが提供される. この抽象化は, これらの認可要素を取得するための認可グラントよりも制限の強いアクセストークンの発行を可能とするだけではなく, 広範囲の認証方式をリソースサーバーが解釈する必要性がなくなる.

アクセストークンはリソースサーバーのセキュリティ要件に基づいて異なるフォーマット, 構成, および利用方法を持つことができる (暗号の特性). アクセストークンの属性と保護されたリソースにアクセスするための方法は本仕様に定めるところではなく, 付録の仕様書によって定義されている.


 TOC 

1.5.  リフレッシュトークン

リフレッシュトークンはアクセストークンを取得するために使用されるクレデンシャルである. リフレッシュトークンは認可サーバーによってクライアントに対して発行され, 現在のアクセストークンが無効化されたあるいは期限切れの際に新しいアクセストークンを取得するため, または同一あるいは狭い範囲で追加のアクセストークンを取得するために利用される (アクセストークンはリソースオーナーによって認可されるよりも有効期限は短く, 権限が少なくてもよい). リフレッシュトークンの発行はオプションである. 認可サーバーがリフレッシュトークンを発行する場合, アクセストークン発行の際にリフレッシュトークンも含まれる.

リフレッシュトークンはリソースオーナーによってクライアントに付与される認可を表す文字列である. この文字列は通常クライアントからみるとランダムな文字列になっている. そのトークンは認可情報を取り出すための識別子を意味してもよい. アクセストークンとは異なり, リフレッシュトークンは認可サーバーでのみ使用されるものであり, リソースサーバーに送信されることはない. 



  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+
 Figure 2: 期限切れのアクセストークンのリフレッシュ 

Figure 2 (期限切れのアクセストークンのリフレッシュ) のフローは以下の通りである.

(A)
クライアントは認可サーバーで認証して認可グラントを提示することによって, アクセストークンの要求をする.
(B)
認可サーバーはクライアントを認証して認可グラントを確認し, 有効である場合はアクセストークンとリフレッシュトークンを発行する.
(C)
クライアントはアクセストークンを提示してリソースサーバー上の保護されたリソースに対してリクエストを行う.
(D)
リソースサーバーはアクセストークンの正当性を確認し, 有効な場合はリクエストを処理する.
(E)
ステップ (C) と (D) はアクセストークンの有効期限が切れるまで繰り返される. クライアントがアクセストークンの期限切れを検知した場合, ステップ (G) にスキップし, そうでなければ保護されたリソースへのリクエストを続ける.
(F)
アクセストークンが有効でないとき, リソースサーバーはエラーを返し, トークンが無効なことを伝える.
(G)
クライアントは, 認可サーバーで認証してリフレッシュトークンを提示することによって, 新しいアクセストークンを要求する. クライアント認証の必要条件はクライアントタイプと認可サーバーのポリシーに基づいている.
(H)
認可サーバーはクライアントを認証しリフレッシュトークンの正当性を確認し, 正当であれば新しいアクセストークン (と必要に応じてリフレッシュトークン) を発行する.


 TOC 

1.6.  表記規約

本仕様書で用いられる各キーワード「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) 表記法を使用している. [RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.).

特定のセキュリティ関連の用語は [RFC4949] (Shirey, R., “Internet Security Glossary, Version 2,” August 2007.) で定義された意味で理解されるべきである. これらの用語には, 「攻撃 (attack)」, 「認証 (authentication)」, 「認可 (authorization)」, 「証明書 (certificate)」, 「機密性 (confidentiality)」, 「クレデンシャル (credential)」, 「暗号化 (encryption)」, 「アイデンティティ (identity)」, 「記号 (sign)」, 「署名 (signature)」, 「信頼 (trust)」, 「正当性の確認 (validate)」, 「検証 (verify)」などがあるが, これらだけに限定はされない.

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


 TOC 

2.  クライアント登録

OAuth プロトコルフローを開始する前に, クライアントは認可サーバーに登録する. クライアントが認可サーバーに登録する方法は本仕様での範囲外であるが, 通常エンドユーザーとの対話を伴うHTML登録フォームを持つ.

クライアントの登録は, クライアントと認可サーバー間の直接的なやりとりを必須としない. 認可サーバーでサポートされている場合, 必要なクライアントのプロパティー (例えばリダイレクトURIやクライアントタイプ) を取得し信頼を確立する他の方法を用いて登録を行うことができる. 例えば, クライアント自身もしくはサードパーティーが発行したアサーションを使用したり, 認可サーバーが信頼できるチャネルを使用してクライアントのディスカバリーを行うことで, 登録を行うことができる.

クライアントを登録する場合, クライアント開発者は：


 TOC 

2.1.  クライアントタイプ

認可サーバーと安全に認証する能力 (クライアントクレデンシャルの機密性を維持できる能力など) に基づいて, OAuthは二つのクライアントタイプを定義している.

コンフィデンシャル
クレデンシャルの機密性を維持することができるクライアント (例えば, クライアントクレデンシャルへのアクセスが制限されたセキュアサーバー上に実装されたクライアント), または他の手段を使用したセキュアなクライアント認証ができるクライアント.
パブリック
クレデンシャルの機密性を維持することができず (例えばインストールされたネイティブアプリケーションやブラウザベースのWebアプリケーションのようにリソースオーナーのデバイス上で実行するクライアント), かつ他の手段を使用したセキュアなクライアント認証もできないクライアント.

クライアントタイプは, 認可サーバーが定めるセキュア認証の定義とクライアントクレデンシャルの許容公開レベルに基づいて決定される.

本仕様は次のクライアントプロファイルに基づいて設計されている,

Webアプリケーション
Webアプリケーションは, Webサーバー上で実行されているコンフィデンシャルクライアントである. リソースオーナーは, リソースオーナーのデバイス上のユーザーエージェントにレンダリングされたHTMLユーザーインターフェイスを通してクライアントにアクセスする. クライアントに発行されたアクセストークンと同様にクライアントクレデンシャルはWebサーバー上に保存され, リソースオーナーによって公開されたりアクセス可能な状態にならない.
ユーザーエージェントベースアプリケーション
ユーザーエージェントベースアプリケーションは, クライアントコードがWebサーバーからダウンロードされリソースオーナーのデバイス上のユーザーエージェント (例えばWebブラウザ) 内で実行されるパブリッククライアントである. プロトコルのデータとクレデンシャルはリソースオーナーに簡単にアクセス (かつ多くの場合は見ること) できる. このようなアプリケーションはユーザーエージェント内にあるので, 認可を要求する時ユーザーエージェントの能力をシームレスに使用することができる.
ネイティブアプリケーション
ネイティブアプリケーションは, リソースオーナーのデバイス上にインストールされ, 実行されるパブリッククライアントである. リソースオーナーはプロトコルのデータとクレデンシャルにアクセス可能である. アプリケーションに含まれるいかなるクライアント認証用のクレデンシャルも, 抽出可能であると想定される. 一方, アクセストークンやリフレッシュトークンといった動的に発行されたクレデンシャルは許容できるレベルの保護が得られる. 少なくとも, これらのクレデンシャルはアプリケーションと対話できる悪意のあるサーバーから保護されている. プラットフォームによっては, これらのクレデンシャルは同じデバイス上に存在する他のアプリケーションからも保護されているであろう.


 TOC 

2.2.  クライアント識別子

認可サーバーは登録済みのクライアントにクライアント識別子 (クライアントが提供した登録情報を表すユニーク文字列) を発行する. クライアント識別子はシークレットと異なりリソースオーナーに露出されるため, その情報のみでクライアント認証を行ってはならない (MUST NOT).


 TOC 

2.3.  クライアント認証

クライアントタイプがコンフィデンシャルである場合, クライアントと認可サーバーは, 認可サーバーのセキュリティ要求を満たすクライアント認証方式を確立する. 認可サーバーは自身のセキュリティ要求さえ満たせば, どのような方式のクライアント認証に対応してもよい (MAY).

コンフィデンシャルクライアントには, 通常は認可サーバーでの認証に使われるクライアントクレデンシャルのセットが発行 (もしくは確立) される. 例) パスワード, 公開鍵／秘密鍵のペア

認可サーバーはクライアントタイプを仮定したり, クライアントとその開発者との信頼確立せずに提供されたタイプ情報に対応すべきではない (SHOULD NOT). 認可サーバーはパブリッククライアントとクライアント認証によって信頼確立してもよい (MAY). しかし, 認可サーバーはクライアントを識別する目的で, パブリッククライアントを信頼してはならない (MUST NOT).

クライアントは1回のリクエストにおいて二つ以上の認証方式を利用してはならない (MUST NOT).


 TOC 

2.3.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.) で定義されている HTTP Basic 認証スキームを使用してもよい (MAY). この場合, クライアント識別子がユーザー名, クライアントパスワードがパスワードとして利用される.

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


  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

認可サーバーは以下のパラメーターを用いて, リクエストボディーにクライアントクレデンシャルを含めてもよい (MAY).

client_id
必須 (REQUIRED). Section 2.2 (クライアント識別子) に示されるクライアント登録時に発行されたクライアント識別子.
client_secret
必須 (REQUIRED). クライアントのシークレット. 空の場合は省略してもよい (MAY).

2つのパラメーターを使ってクライアントクレデンシャルをリクエストボディーに含めることは推奨されていない (NOT RECOMMENDED). この方法は HTTP Basic 認証スキーム (もしくは他のパスワードベースのHTTP認証スキーム) が直接利用できないクライアントに限定すべきある.

例：ボディパラメーターを使ってアクセストークンを更新 (Section 6 (アクセストークンの更新)) する場合 (改行は掲載上の都合による) 


  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded;charset=UTF-8

  grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
  &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

この認証方式ではトークンエンドポイントへのリクエストに平文のクレデンシャルが含まれることになるので, 認可サーバーはトークンエンドポイントでTLSの使用を必須としなければならない (MUST).

クライアント認証方式にパスワードが含まれるので, 認可サーバーはクライアント認証を行うすべてのエンドポイントでブルートフォースアタック対策を行わなくてはならない (MUST).


 TOC 

2.3.2.  その他の認証方式

認可サーバーは, セキュリティ要件に適合する適切なHTTP認証スキームをサポートすべきである (MAY). 他の認証方式を利用する際には, 認可サーバーはクライアント識別子 (つまり登録されたクライアント) と認証スキームのマッピングを明確にしなければならない (MUST).


 TOC 

2.4.  未登録クライアント

本仕様は, 未登録のクライアントの利用を排除するものではない. しなしながら, そのようなクライアントの利用は本仕様のスコープ外であり, さらなるセキュリティー面の分析と相互運用性への影響度評価が必要である.


 TOC 

3.  プロトコルエンドポイント

認可プロセスは2つのエンドポイント (HTTP リソース) を利用する:

すべてのグラントタイプが両方のエンドポイントを使用するわけではない. 拡張されたグラントタイプは必要に応じて追加のエンドポイントを定義してもよい (MAY).


 TOC 

3.1.  認可エンドポイント

認可エンドポイントは, リソースオーナーとのインタラクションを通じて認可を得るために使用される. 認可サーバーは, まずリソースオーナーのアイデンティティを確認しなければならない (MUST). 認可サーバーが用いるリソースオーナーの認証方法 (ユーザー名とパスワードによるログイン, セッションクッキー) については, 本仕様の定めるところではない.

クライアントの認可エンドポイントURLの取得は本仕様の定めるところではないが, そのURLは一般的にサービスドキュメントで提供される.

エンドポイントURIは application/x-www-form-urlencoded ([W3C.REC‑html401‑19991224] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.)) でフォーマットされたクエリーコンポーネント ([RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) セクション3.4) を含んでもよい (MAY). クエリーパラメーターを追加する際, ここで指定されたクエリーコンポーネントは維持すること (MUST). エンドポイントURIはフラグメントコンポーネントを含んではいけない (MUST NOT).

認可エンドポイントへのリクエストはユーザー認証と (HTTPレスポンスによる) 平文クレデンシャルの転送を伴うため, 認可エンドポイントにリクエストを送信する際, 認可サーバーはトランスポート層でのセキュリティ機構を用いらなければならない (MUST). 認可サーバーはTLS 1.0 ([RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.)) をサポートしなければならず (MUST), TLS 1.2 ([RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.)) および将来の代替方式をサポートすべきであり (SHOULD), セキュリティ要件に合わせた追加のトランスポート層メカニズムをサポートしてもよい (MAY).

認可サーバーは認可エンドポイントでHTTP GET メソッドをサポートしなければならず (MUST), 同様に POST メソッドをサポートしてもよい (MAY).

パラメーターの値がない場合は, パラメーター自体が省略されているものとして扱わなければならない (MUST). 認可サーバーは認められていないリクエストパラメーターを無視すべきである (SHOULD). リクエストおよびレスポンスパラメーターは重複を許さない (MUST NOT).


 TOC 

3.1.1.  レスポンスタイプ

認可エンドポイントは認可コードグラントタイプとインプリシットタイプのフローで使用される. クライアントは以下に示すパラメーターを利用した希望するタイプの認可サーバーに情報を送る.

response_type
必須 (REQUIRED). レスポンスタイプの値は Section 4.1.1 (認可リクエスト) で後述する認可コードをリクエストするための code あるいは, Section 4.2.1 (認可リクエスト) で後述するアクセストークン (インプリシットグラント) をリクエストする token あるいは, Section 8.4 (新たな認可エンドポイントレスポンスタイプの定義) で後述する登録されている拡張された値のいずれかでなければならない (MUST). レスポンスタイプに1つ以上の空白文字 (%x20) が含まれている場合, 空白区切りの一覧として解釈すること. なお値の順序は問題としない (a b と b a は同じである).

認可リクエストで response_type を見つけられない場合, 認可サーバーは Section 4.1.2.1 (エラーレスポンス) で述べるエラーレスポンスを返すべきである (SHOULD).


 TOC 

3.1.2.  リダイレクトエンドポイント

リソースオーナーとのやりとりが完了した後, 認可サーバーはリソースオーナーのユーザーエージェントをクライアントへ誘導する. 認可サーバーはユーザーエージェントをクライアント登録プロセス中, もしくは認可リクエスト時に認可サーバーに事前に確立されたクライアントのリダイレクトエンドポイントへリダイレクトする.

リダイレクトURIは [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) セクション4.3で定義されているように絶対URIでなければいけない (MUST). エンドポイントURIは application/x-www-form-urlencoded ([W3C.REC‑html401‑19991224] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.)) でフォーマットされたクエリーコンポーネント ([RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) セクション3.4) を含んでもよい (MAY). クエリーパラメーターを追加する際, ここで指定されたクエリーコンポーネントは維持すること (MUST). エンドポイントURIはフラグメントコンポーネントを含んではいけない (MUST NOT).


 TOC 

3.1.2.1.  エンドポイントリクエストの機密性

もしリダイレクトリクエストが (リソースオーナーのユーザーエージェントとクライアントの間で) オープンなネットワークにわたって認可コードやアクセストークンの通信が生じるなら, クライアントはトランスポート層でのセキュリティメカニズムの使用を求めるべきである (SHOULD).

トランスポート層のセキュリティの欠如はクライアントとアクセス認証された保護リソース上で深刻な影響を及ぼす. トランスポート層のセキュリティを使用することは, 認可プロセスがクライアントによってエンドユーザー認証の委譲された形式で使用される場合特に重要である (例えばサードパーティーサインインサービス).


 TOC 

3.1.2.2.  登録要件

認可エンドポイントを使用する前に認可サーバーはリダイレクトURIを登録することをクライアントすべてに要求するべきである (SHOULD). 以下のクライアントはリダイレクトURIの登録を要求しなければいけない (MUST).

認可サーバーは完全なリダイレクトURIの提供をクライアントに要求するべきである (SHOULD). (クライアントはリクエスト毎のカスタマイズを得るため state リクエストパラメーターを使用できる (MAY)) 認可サーバーはクライアントに複数のリダイレクトURIの登録を許可するべきである (MAY). 完全なリダイレクトURIの登録を要求することが可能出ないなら, 認可サーバーはURIスキーム, 権限, パス (認可要求の時, リダイレクトURIのクエリーコンポーネントのみ動的に変更を許可する) の登録を要求するべきである (SHOULD).


 TOC 

3.1.2.3.  動的設定

リダイレクトURIが複数登録されていた場合, リダイレクトURIの一部のみ登録されていた場合, もしくはリダイレクトURIが登録されていなかった場合, クライアントは redirect_uri リクエストパラメーターを使用して認可リクエストでリダイレクトURIを含まなければいけない (MUST).

リダイレクトURIが認可リクエストに含まれていた時, いくつかのリダイレクトURIが登録されていた場合[RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.)セクション6に示すとおり登録されているリダイレクトURI (もしくはURIコンポーネント) の内の少なくとも一つに対して受け取った値と比較し一致しなければいけない. もしクライアントの登録にフルのリダイレクトURIが含まれていた場合, 認可サーバーは [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) セクション6.2.1.で定義されているように単純な文字列比較を使用し二つのURIを比較しなければいけない (MUST).

認可サーバーがリダイレクトURIのクエリーコンポーネントの動的変更をクライアントに許可するなら, 攻撃者がSection 10.15 (オープンリダイレクタ)に示すとおりリダイレクトエンドポイントの乱用できないことによってクライアントはクエリーコンポーネントの操作を保証しなければいけない.


 TOC 

3.1.2.4.  無効なエンドポイント

認可リクエストがリダイレクトURIの欠落, 無効, もしくは不一致のため検証失敗なら, 認可サーバーはエラーをリソースオーナーに知らせるべきである (SHOULD). そして無効なリダイレクトURIにユーザーエージェントを自動でリダイレクトしてはいけない (MUST NOT).

認可サーバーは認可エンドポイントをオープンリダイレクタとして使われることから防ぐために登録されていない, もしくは信頼できないURIにユーザーエージェントをリダイレクトするべきでない (SHOULD NOT).


 TOC 

3.1.2.5.  エンドポイントコンテント

クライアントのエンドポイントへのリダイレクトリクエストは通常ユーザーエージェントによって処理されたHTMLドキュメントを返される. HTMLレスポンスがリダイレクトリクエストの結果直接提供するなら, HTMLドキュメントに含まれるスクリプトがにリダイレクトURIとそれに含まれるクレデンシャルへのフルアクセスが実行する.

クライアントはURIからクレデンシャルを抽出し削除するのに使用される独自のスクリプトが最初に実行されることを確認せず, リダイレクトエンドポイントのレスポンスに信頼できないサードパーティーのスクリプトを含んではいけない (MUST NOT) (例えばサードパーティーのアクセス解析, ソーシャルプラグイン, 広告ネットワーク).

クライアントはリダイレクトエンドポイントのレスポンスにサードパーティースクリプトを含めるべきではない (SHOULD NOT). 代わりにそのURIからクレデンシャルを抽出し, URIのクレデンシャルなしで別のエンドポイントへ再びユーザーエージェントをリダイレクトするべきである.


 TOC 

3.2.  トークンエンドポイント

トークンエンドポイントは認可グラントもしくはリフレッシュトークンを提示することでクライアントがアクセストークンを取得するための利用される トークンエンドポイントはインプリシットグラントタイプを除くすべてのグラントタイプで利用される (アクセストークンは直接発行されるため).

クライアントがトークンエンドポイントの所在を取得する方法については本仕様の範囲外であるが, 通常はサービス文書中に記載されている.

エンドポイントURIは application/x-www-form-urlencoded ([W3C.REC‑html401‑19991224] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.)) でフォーマットされたクエリーコンポーネント ([RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) セクション3.4) を含んでもよい (MAY). クエリーパラメーターを追加する際, ここで指定されたクエリーコンポーネントは維持すること (MUST). エンドポイントURIはフラグメントコンポーネントを含んではいけない (MUST NOT).

トークンエンドポイントへのリクエストが平文で (HTTPリクエストおよびレスポンスにて) 転送することになるため, 認可サーバーはトークンエンドポイントへリクエストを送信する際にTLSの仕組みを利用しなくてはならない (MUST). 認可サーバーはTLS 1.0 ([RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.)) をサポートしなくてはならない (MUST). 認可サーバーはTLS 1.2 ([RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.)) とその後継のプロトコルもサポートするべきである (SHOULD). また, 認可サーバーは自身のセキュリティ要件を満たす追加のトランスポート層の仕組みをサポートしてもよい (MAY).

クライアントはアクセストークンリクエストを送信する際に, HTTP POST メソッドを使用しなければならない (MUST).

空の値で送信されたパラメーターは省略されたものとして扱われなければならない (MUST). 認可サーバーは未知のリクエストパラメーターは無視するべきである (SHOULD). リクエストおよびレスポンスパラメーターは重複を許さない (MUST NOT).


 TOC 

3.2.1.  クライアント認証

クライアントクレデンシャルまたは他の認証方法を利用可能なコンフィデンシャルクライアントは, Section 2.3 (クライアント認証) に従ってトークンエンドポイントへのリクエスト時に認可サーバーとの間で認証を行わなければならない (MUST). クライアント認証には以下の目的がある.

トークンエンドポイントにリクエストを送信する場合, クライアントパスワードが発行されていないパブリッククライアントは, 自分自身を識別するために client_id リクエストパラメーターを使用してもよい (MAY).

パブリッククライアントに対してトークンエンドポイントへの未認証アクセスを許可したりリフレッシュトークンを発行する際は, セキュリティ面への影響を考慮すること (MUST).


 TOC 

3.3.  アクセストークンスコープ

認可エンドポイントおよびトークンエンドポイントでは, クライアントは scope リクエストパラメーターを用いて要求するアクセス範囲を明示することができる. 同様に, 認可サーバーは発行されたアクセストークンの範囲をクライアントに通知するために scope レスポンスパラメーターを使用する.

スコープパラメーターの値は大文字と小文字を区別する文字列で, スペース区切りのリストで示される. 文字列は認可サーバーによって定義されている. 値が複数のスペース区切りの文字列を含んでいる場合, その順序に意味は無く, それぞれのアクセス範囲の合計が要求されるスコープになる.

認可サーバーは, 認可サーバーのポリシーまたはリソースオーナーの指示に基づいて, クライアントに要求されたスコープの一部もしくはすべてを無視してもよい (MAY). 発行されたアクセストークンのスコープがクライアントから要求されたものと異なる場合, 認可サーバーは実際に許可されたスコープをクライアントに通知するため, scope レスポンスパラメーターを含めるべきである (SHOULD).


 TOC 

4.  認可の取得

アクセストークンを要求するため, まずクライアントはリソースオーナーから認可を取得する. 認可は, クライアントがアクセストークンを要求するのに使用する認可グラントの形式で表現される. OAuthでは, 4つのグラントタイプ (認可コード, インプリシット, リソースオーナーパスワードクレデンシャル, クライアントクレデンシャル) を定義している. また, 拡張仕様によって新たなグラントタイプを追加することも可能である.


 TOC 

4.1.  認可コード

認可コードグラントタイプは, アクセストークンとリフレッシュトークの両方を取得するために用いられ, コンフィデンシャルクライアントに最適化されている. このグラントタイプではリダイレクトベースのフローが利用されるため, クライアントはリソースオーナーのユーザーエージェント (通常はWebブラウザ) と対話し, 認可サーバーによる (リダイレクトを通した) リクエストを受け付けることが出来なくてはいけない. 



  +----------+
  | resource |
  |   owner  |
  |          |
  +----------+
       ^
       |
      (B)
  +----|-----+          Client Identifier      +---------------+
  |         -+----(A)-- & Redirection URI ---->|               |
  |  User-   |                                 | Authorization |
  |  Agent  -+----(B)-- User authenticates --->|     Server    |
  |          |                                 |               |
  |         -+----(C)-- Authorization Code ---<|               |
  +-|----|---+                                 +---------------+
    |    |                                         ^      v
   (A)  (C)                                        |      |
    |    |                                         |      |
    ^    v                                         |      |
  +---------+                                      |      |
  |         |>---(D)-- Authorization Code ---------'      |
  |  Client |          & Redirection URI                  |
  |         |                                             |
  |         |<---(E)----- Access Token -------------------'
  +---------+       (w/ Optional Refresh Token)
 Figure 3: 認可コード処理フロー 

Figure 3 (認可コード処理フロー) のフローは以下の通りである.

(A)
クライアントがリソースオーナーのユーザーエージェントを認可エンドポイントに送ることで, フローが開始する. このときクライアントは, クライアント識別子, リクエストスコープ, ローカルステート, および認可サーバーがアクセス許可取得後にユーザーエージェントを戻すリダイレクトURIをリクエストに含める.
(B)
認可サーバーは (ユーザーエージェントを通して) リソースオーナーを認証し, リソースオーナーにアクセス要求の許可/拒否をたずねる.
(C)
リソースオーナーがアクセスを許可した場合, 認可サーバーは予め与えられていた (リクエストもしくはクライアント登録時に指定される) リダイレクトURIを用いて, ユーザーエージェントをリダイレクトさせてクライアントに戻す. リダイレクトURIには, 認可コード, クライアントから事前に送られたローカルステートが含まれる.
(D)
クライアントは前のステップで取得した認可コードを認可サーバーのトークンエンドポイントに送ることでアクセストークンを要求する. このとき, クライアントは認可サーバーとの間で認証を行う. またクライアントは認可コード取得時に使用したリダイレクトURIを検証のためリクエストに含める.
(E)
認可サーバーはクライアントを認証し, 認可コードを検証し, 受け取ったリダイレクトURIがステップ (C) で使用したURIと同一であることを確かめる. その結果, 正当である場合, 認可サーバーはアクセストークンと任意でリフレッシュトークンを返却する.


 TOC 

4.1.1.  認可リクエスト

クライアントは, [W3C.REC‑html401‑19991224] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) で規定された application/x-www-form-urlencoded フォーマットを用いて認可エンドポイントURIへのクエリーとして, 次のパラメーターを付与する.

response_type
必須 (REQUIRED). 値は必ず code にしなければならない (MUST).
client_id
必須 (REQUIRED). 詳細は Section 2.2 (クライアント識別子) を参照のこと.
redirect_uri
任意 (OPTIONAL). 詳細は Section 3.1.2 (リダイレクトエンドポイント) を参照のこと.
scope
任意 (OPTIONAL). 詳細は Section 3.3 (アクセストークンスコープ) を参照のこと.
state
推奨 (RECOMMENDED). リクエストとコールバックの間で状態を維持するために使用するランダムな値. 認可サーバーはリダイレクトによってクライアントに処理を戻す際にこの値を付与する. このパラメーターは Section 10.12 (クロスサイトリクエストフォージェリ) に記載されているクロスサイトリクエストフォージェリを防ぐために用いられるべきである (SHOULD).

クライアントは, HTTPリダイレクトまたはユーザーエージェントを介したその他の利用可能な手段によって, リソースオーナーを構築されたURIに送る.

例えば, クライアントはユーザーエージェントに次のHTTPリクエストをTLSを用いて実行させる (改行は掲載上の都合による). 


  GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
      &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
  Host: server.example.com

認可サーバーは必要なリクエストパラメーターがすべて揃っていて, かつ正当であることを検証する. リクエストが正当であれば, 認可サーバーはリソースオーナーを認証し, (リソースオーナーに確認することによって, または他の手段によって承認を確立することによって) 認可の判定を得る.

判定が成立すると, 認可サーバーはHTTPリダイレクトレスポンスまたはユーザーエージェントを介したその他の利用可能な手段を用いて, 与えられたリダイレクトURIにユーザーエージェントを送る.


 TOC 

4.1.2.  認可レスポンス

リソースオーナーがアクセスリクエストを許可した場合, 認可サーバーは認可コードを発行し, application/x-www-form-urlencoded フォーマットを用いてリダイレクトURIのクエリーコンポーネントに次のパラメーターを付与してクライアントに送る.

code
必須 (REQUIRED). 認可コードは認可サーバーによって許可される. 漏洩のリスクを軽減するため, 認可コードは発行されてから短期間で無効にしなければならない (MUST). 認可コードの有効期限は最大でも10分を推奨する (RECOMMENDED). クライアントは2回以上認可コードを使用してはならない (MUST NOT). もし認可コードが2回以上使用された場合は, 認可サーバーはリクエストを拒否しなければならず (MUST), この認可コードを基に発行されたこれまでのすべてのトークンを無効化すべきである (SHOULD). 認可コードはクライアント識別子とリダイレクトURIに紐づく.
state
クライアントからの認可リクエストに state パラメーターが含まれていた場合は必須 (REQUIRED). クライアントから受け取った値をそのまま返す.

例えば, 認可サーバーは次のようなHTTPレスポンスをユーザーエージェントに返し, ユーザーエージェントをリダイレクトさせる. 


  HTTP/1.1 302 Found
  Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
            &state=xyz

クライアントは認識できないレスポンスパラメーターを無視すべきである (SHOULD). 認可コードの文字列長は本仕様では定義しない. クライアントはコード値のサイズについてなんらかの仮定をすべきではない. 認可サーバーは自身が発行するあらゆる値のサイズについてドキュメントに明記すべきである.


 TOC 

4.1.2.1.  エラーレスポンス

リクエストが, リダイレクトURIの欠落 / 不正 / ミスマッチによって失敗した場合, もしくはクライアント識別子が不正な場合は, 認可サーバーはリソースオーナーにエラーを通知すべきである (SHOULD). 不正なリダイレクトURIに対してユーザーエージェントを自動的にリダイレクトさせてはならない (MUST NOT).

リソースオーナーがアクセス要求を拒否した場合, もしくはリダイレクトURIの欠落 / 不正以外でリクエストが失敗した場合は, 認可サーバーは application/x-www-form-urlencoded フォーマットを用いてリダイレクトURIのクエリーコンポーネントに次のようなパラメーターを付与してクライアントに返却する.

error
必須 (REQUIRED). 次のエラーコードの中の1つ:
invalid_request
リクエストに必要なパラメーターが含まれていない. サポート外のパラメーターが付与されていた場合や, その他不正な形式であった場合もこれに含まれる.
unauthorized_client
クライアントは現在の方法で認可コードを取得することを認可されていない.
access_denied
リソースオーナーまたは認可サーバーがリクエストを拒否した
unsupported_response_type
認可サーバーは現在の方法による認可コード取得をサポートしていない.
invalid_scope
リクエストスコープが不正, 未知, もしくはその他の不当な形式である.
server_error
認可サーバーがリクエストの処理ができないような予期しない状況に遭遇した.
temporarily_unavailable
認可サーバーが一時的な過負荷やメンテナンスによってリクエストを扱うことが出来ない.
error_description
任意 (OPTIONAL). クライアント開発者が発生したエラーを理解する際の手助けとなる, UTF-8エンコードされた可読性のある追加情報.
error_uri
任意 (OPTIONAL). クライアント開発者が発生したエラーに関する追加の情報を得ることができるWebページのURI.
state
もし正当な state パラメーターがクライアントからの認可リクエストに含めれている場合は必須 (REQUIRED). クライアントから受け取った値をそのまま返す.

例えば, 認可サーバーは次のようなHTTPレスポンスをユーザーエージェントに返し, ユーザーエージェントをリダイレクトさせる. 


  HTTP/1.1 302 Found
  Location: https://client.example.com/cb?error=access_denied&state=xyz

 TOC 

4.1.3.  アクセストークンリクエスト

クライアントはトークンエンドポイントに対して, 次のようなパラメーターを付与してリクエストを送信する. パラメーターはHTTPリクエストのエンティティーボディに application/x-www-form-urlencoded フォーマットで含める.

grant_type
必須 (REQUIRED). 値は authorization_code でなければならない (MUST).
code
必須 (REQUIRED). 認可サーバーから受け取った認可コード.
redirect_uri
Section 4.1.1 (認可リクエスト) で示す認可リクエストに, redirect_uri パラメーターが含まれていた場合は必須 (REQUIRED). その値をそのまま付与しなくてはいけない (MUST).

クライアントタイプがコンフィデンシャルである場合, あるいはクライアントクレデンシャルが発行された (もしくはその他の認証が要求された) クライアントは, Section 3.2.1 (クライアント認証) に示すとおり認可サーバーにより認証されなければならない (MUST).

例えば, クライアントは次のようなHTTPリクエストをTLSを用いて送信する (改行は掲載上の都合による). 


  POST /token HTTP/1.1
  Host: server.example.com
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  Content-Type: application/x-www-form-urlencoded;charset=UTF-8

  grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
  &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

認可サーバーは以下に従わなければならない (MUST):


 TOC 

4.1.4.  アクセストークンレスポンス

アクセストークンリクエストが正当かつ認可された場合, 認可サーバーは Section 5.1 (成功レスポンス) に示すとおりアクセストークンと任意でリフレッシュトークンを発行する. もしリクエストが失敗もしくは不正だった場合, 認可サーバーは Section 5.2 (エラーレスポンス) に示すとおりエラーレスポンスを返却する.

成功レスポンス例を以下に示す. 


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

  {
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"example",
    "expires_in":3600,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "example_parameter":"example_value"
  }

 TOC 

4.2.  インプリシットグラント

インプリシットグラントタイプは, アクセストークンを取得するために用いられ (リフレッシュトークンの発行はサポートされない), 特定のリダイレクトURIを利用することが既知であるパブリッククライアントに最適化されている. これらのクライアントは, 通常JavaScriptなどのスクリプト言語を使用してブラウザ上に実装される.

このグラントタイプではリダイレクトベースのフローが利用されるため, クライアントはリソースオーナーのユーザーエージェント (通常はWebブラウザ) と対話し, 認可サーバーによる (リダイレクトを通した) リクエストを受け付けることが出来なくてはいけない.

認可取得とアクセストークン取得のリクエストが分離されている認可コードグラントタイプと異なり, クライアントは認可リクエストの結果としてアクセストークンを受け取る.

インプリシットグラントタイプではクライアント認証は行わず, リソースオーナーの介在とリダイレクトURIの事前登録に頼っている. アクセストークンはリダイレクトURI中にエンコードされるため, リソースオーナーとデバイス上のその他のアプリケーションに漏えいするかもしれない. 



  +----------+
  | Resource |
  |  Owner   |
  |          |
  +----------+
       ^
       |
      (B)
  +----|-----+          Client Identifier     +---------------+
  |         -+----(A)-- & Redirection URI --->|               |
  |  User-   |                                | Authorization |
  |  Agent  -|----(B)-- User authenticates -->|     Server    |
  |          |                                |               |
  |          |<---(C)--- Redirection URI ----<|               |
  |          |          with Access Token     +---------------+
  |          |            in Fragment
  |          |                                +---------------+
  |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
  |          |          without Fragment      |     Client    |
  |          |                                |    Resource   |
  |     (F)  |<---(E)------- Script ---------<|               |
  |          |                                +---------------+
  +-|--------+
    |    |
   (A)  (G) Access Token
    |    |
    ^    v
  +---------+
  |         |
  |  Client |
  |         |
  +---------+
 Figure 4: インプリシットグラントフロー 

Figure 4 (インプリシットグラントフロー) のフローは以下の通りである.

(A)
クライアントがリソースオーナーのユーザーエージェントを認可エンドポイントに送ることで, フローが開始する. このときクライアントは, クライアント識別子, リクエストスコープ, ローカルステート, および認可サーバーがアクセス許可取得後にユーザーエージェントを戻すリダイレクトURIをリクエストに含める.
(B)
認可サーバーは (ユーザーエージェントを通して) リソースオーナーを認証し, リソースオーナーにアクセス要求の許可/拒否をたずねる.
(C)
リソースオーナーがアクセスを許可した場合, 認可サーバーは予め与えられていたリダイレクトURIを用いて, ユーザーエージェントをリダイレクトさせてクライアントに戻す. リダイレクトURIには, アクセストークンが含まれる.
(D)
ユーザーエージェントは, リダイレクトの指示に従い, Web上にホストされたクライアントリソースにリクエストを送信する (このときフラグメントは送信されない). ユーザーエージェントはフラグメントの情報をローカルに保持する.
(E)
Webでホストされたクライアントリソースにアクセスすると, Webページ (通常, 埋め込みのスクリプトが含まれるHTMLドキュメント) が返される. そのWebページでは, ユーザーエージェントによって保持されているフラグメントを含む完全なリダイレクトURLにアクセスし, フラグメントに含まれているアクセストークン (とその他のパラメーター) を取り出すことができる.
(F)
ユーザーエージェントは上記Webページに含まれるスクリプトをローカルに実行し, アクセストークンを取り出してクライアントに渡す.


 TOC 

4.2.1.  認可リクエスト

クライアントは, application/x-www-form-urlencoded フォーマットを用いて認可エンドポイントURIへのクエリーとして, 次のパラメーターを付与する.

response_type
必須 (REQUIRED). 値は必ず token にしなければならない (MUST).
client_id
必須 (REQUIRED). 詳細は Section 2.2 (クライアント識別子) を参照のこと.
redirect_uri
任意 (OPTIONAL). 詳細は Section 3.1.2 (リダイレクトエンドポイント) を参照のこと.
scope
任意 (OPTIONAL). 詳細は Section 3.3 (アクセストークンスコープ) を参照のこと.
state
推奨 (RECOMMENDED). リクエストとコールバックの間で状態を維持するために使用するランダムな値. 認可サーバーはリダイレクトによってクライアントに処理を戻す際にこの値を付与する. このパラメーターは Section 10.12 (クロスサイトリクエストフォージェリ) に記載されているクロスサイトリクエストフォージェリを防ぐために用いられるべきである (SHOULD).

クライアントは, HTTPリダイレクトまたはユーザーエージェントを介したその他の利用可能な手段によって, リソースオーナーを構築されたURIに送る.

例えば, クライアントはユーザーエージェントに次のHTTPリクエストをTLSを用いて実行させる (改行は掲載上の都合による). 


  GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
      &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
  Host: server.example.com

認可サーバーは, 必要なリクエストパラメーターがすべて揃っていて, かつ正当であることを検証する. 認可サーバーは, アクセストークンを返すリダイレクトURIが Section 3.1.2 (リダイレクトエンドポイント) に述べるように事前登録されたリダイレクトURIと一致することを検証しなければならない (MUST).

リクエストが正当なものであれば, 認可サーバーはリソースオーナーを認証し, (リソースオーナーに確認することによって, または他の手段によって承認を確立することによって) 認可の判定を得る.

判定が成立すると, 認可サーバーはHTTPリダイレクトレスポンスまたはユーザーエージェントを介したその他の利用可能な手段を用いて, 与えられたリダイレクトURIにユーザーエージェントを送る.


 TOC 

4.2.2.  アクセストークンレスポンス

リソースオーナーがアクセスリクエストを許可した場合, 認可サーバーはアクセストークンを発行し, application/x-www-form-urlencoded フォーマットを用いてリダイレクトURIのフラグメントコンポーネントに次のパラメーターを付与してクライアントに送る.

access_token
必須 (REQUIRED). 認可サーバーによって発行されたアクセストークン.
token_type
必須 (REQUIRED). 詳細は Section 7.1 (アクセストークンタイプ) を参照のこと. 大文字・小文字は区別しない.
expires_in
任意 (OPTIONAL). アクセストークンの有効期間を秒で表したもの. 例えばこの値が 3600 であれば, そのアクセストークンは発行から1時間後に期限切れとなる.
scope
任意 (OPTIONAL). 詳細は Section 3.3 (アクセストークンスコープ) を参照のこと.
state
クライアントの認可リクエストに state が含まれていた場合は必須 (REQUIRED). クライアントから受け取った値をそのまま返す.

認可サーバーはリフレッシュトークンを発行してはならない (MUST NOT).

例えば, 認可サーバーは次のようなHTTPレスポンスをユーザーエージェントに返し, ユーザーエージェントをリダイレクトさせる (改行は掲載上の都合による). 


  HTTP/1.1 302 Found
  Location: http://example.com/rd#access_token=2YotnFZFEjr1zCsicMWpAA
            &state=xyz&token_type=example&expires_in=3600

開発者は, いくつかのHTTPクライアント実装が, HTTP Location レスポンスヘッダーフィールドをサポートしないことに注意するべきである. このようなクライアントは3xxリダイレクトレスポンス以外でクライアントを向け直すための方法が必要になるだろう. 例えば, リダイレクトURI先にリンクするような"続行"ボタンを含むHTMLページを返却するなどである.

クライアントは認識できないレスポンスパラメーターを無視すべきである (SHOULD). アクセストークンの文字列長は本仕様では定義しない. クライアントは値のサイズについてなんらかの仮定をすべきではない. 認可サーバーは自身が発行するあらゆる値のサイズについてドキュメントに明記すべきである.


 TOC 

4.2.2.1.  エラーレスポンス

リクエストが, リダイレクトURIの欠落 / 不正 / ミスマッチによって失敗した場合, もしくはクライアント識別子が不正な場合は, 認可サーバーはリソースオーナーにエラーを通知すべきである (SHOULD). 不正なリダイレクトURIに対してユーザーエージェントを自動的にリダイレクトさせてはならない (MUST NOT).

リソースオーナーがアクセス要求を拒否した場合, もしくはリダイレクトURIの欠落 / 不正以外でリクエストが失敗した場合は, 認可サーバーは application/x-www-form-urlencoded フォーマットを用いてリダイレクトURIのフラグメントコンポーネントに次のようなパラメーターを付与してクライアントに返却する.

error
必須 (REQUIRED). 次のエラーコードの中の1つ:
invalid_request
リクエストに必要なパラメーターが含まれていない. サポート外のパラメーターが付与されていた場合や, その他不正な形式であった場合もこれに含まれる.
unauthorized_client
クライアントは現在の方法でアクセストークンを取得することを認可されていない.
access_denied
リソースオーナーまたは認可サーバーがリクエストを拒否した.
unsupported_response_type
認可サーバーは現在の方法によるアクセストークン取得をサポートしていない.
invalid_scope
リクエストスコープが不正, 未知, もしくはその他の不当な形式である.
server_error
認可サーバーがリクエストの処理ができないような予期しない状況に遭遇した.
temporarily_unavailable
認可サーバーが一時的な過負荷やメンテナンスによってリクエストを扱うことが出来ない.
error_description
任意 (OPTIONAL). クライアント開発者が発生したエラーを理解する際の手助けとなる, UTF-8エンコードされた可読性のある追加情報.
error_uri
任意 (OPTIONAL). クライアント開発者が発生したエラーに関する追加の情報を得ることができるWebページのURI.
state
もし正当な state パラメーターがクライアントからの認可リクエストに含めれている場合は必須 (REQUIRED). クライアントから受け取った値をそのまま返す.

例えば, 認可サーバーは次のようなHTTPレスポンスをユーザーエージェントに返却する. 


  HTTP/1.1 302 Found
  Location: https://client.example.com/cb#error=access_denied&state=xyz

 TOC 

4.3.  リソースオーナーパスワードクレデンシャル

リソースオーナーパスワードクレデンシャルグラントタイプは, リソースオーナーがクライアントと信頼関係にある場合, 例えばリソースオーナーの所有するデバイスOSや特別許可されたアプリケーションなどに適している. 認可サーバーはこのグラントタイプを有効にする際は特に注意するべきである. また他のフローが利用できない場合にのみ許可するべきである.

このグラントタイプは, リソースオーナーのクレデンシャル (通常は対話型入力フォームにて取得するユーザー名とパスワード) を取得できるクライアントに適している. また, 保存済みのクレデンシャルをアクセストークンへ変換できるため, Basic認証やDigest認証のような直接的な認証スキームを利用している既存のクライアントをOAuthへ移行する際にも利用できる. 



  +----------+
  | Resource |
  |  Owner   |
  |          |
  +----------+
       v
       |    Resource Owner
      (A) Password Credentials
       |
       v
  +---------+                                  +---------------+
  |         |>--(B)---- Resource Owner ------->|               |
  |         |         Password Credentials     | Authorization |
  | Client  |                                  |     Server    |
  |         |<--(C)---- Access Token ---------<|               |
  |         |    (w/ Optional Refresh Token)   |               |
  +---------+                                  +---------------+
 Figure 5: リソースオーナーパスワードクレデンシャルフロー 

Figure 5 (リソースオーナーパスワードクレデンシャルフロー) のフローは以下の通りである.

(A)
リソースオーナーはクライアントにユーザー名とパスワードを提供する.
(B)
クライアントは認可サーバーのトークンエンドポイントにリソースオーナーから取得したクレデンシャルを含めることでアクセストークンを要求する. リクエストを生成する際に, クライアントは認可サーバーによって認証される.
(C)
認可サーバーはクライアントを認証し, リソースオーナーのクレデンシャルを検証する. もし有効であればアクセストークンを発行する.


 TOC 

4.3.1.  認可リクエストとレスポンス

クライアントがリソースオーナーのクレデンシャルを取得する方法は, 本仕様の範囲外である. クライアントはアクセストークン取得直後にクレデンシャルを破棄しなければならない (MUST).


 TOC 

4.3.2.  アクセストークンリクエスト

クライアントは, 下記のパラメーターを application/x-www-form-urlencoded フォーマットでHTTPリクエストボディーに含め, リクエストを構築する.

grant_type
必須 (REQUIRED). 値には password を指定しなければならない (MUST).
username
必須 (REQUIRED). UTF-8エンコードされたリソースオーナーのユーザーネーム.
password
必須 (REQUIRED). UTF-8エンコードされたリソースオーナーのパスワード.
scope
任意 (OPTIONAL). 詳細は Section 3.3 (アクセストークンスコープ) を参照のこと.

クライアントタイプがコンフィデンシャルである場合, あるいはクライアントクレデンシャルが発行された (もしくはその他の認証が要求された) クライアントは, Section 3.2.1 (クライアント認証) に示すとおり認可サーバーにより認証されなければならない (MUST).

例えば, クライアントは以下のHTTPリクエストをセキュリティ保護されたトランスポート層から送信する (改行は掲載上の都合による). 


  POST /token HTTP/1.1
  Host: server.example.com
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  Content-Type: application/x-www-form-urlencoded;charset=UTF-8

  grant_type=password&username=johndoe&password=A3ddj3w

認可サーバーは次のことを実施しなければならない (MUST):

このアクセストークンリクエストにはリソースオーナーのパスワードが含まれるため, 認可サーバーはブルートフォース攻撃からこのエンドポイントを保護しなければならない (MUST).


 TOC 

4.3.3.  アクセストークンレスポンス

アクセストークンリクエストが正当かつ認可された場合, 認可サーバーは Section 5.1 (成功レスポンス) に示すとおりアクセストークンと任意でリフレッシュトークンを発行する. クライアント認証に失敗, もしくはリクエストが不正であった場合, 認可サーバーは Section 5.2 (エラーレスポンス) に示すとおりエラーレスポンスを返却する.

成功レスポンス例を以下に示す. 


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

  {
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"example",
    "expires_in":3600,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "example_parameter":"example_value"
  }

 TOC 

4.4.  クライアントクレデンシャル

クライアント自身のコントロール下にある保護リソースまたは認可サーバーとの間で調整済みの保護リソースにアクセスする場合, クライアントはクライアントクレデンシャル (あるいはサポートされているその他の認証方式) のみでアクセストークンをリクエストすることができる.

コンフィデンシャルクライアントのみが, クライアントクレデンシャルグラントタイプを利用できる (MUST). 



  +---------+                                  +---------------+
  |         |                                  |               |
  |         |>--(A)- Client Authentication --->| Authorization |
  | Client  |                                  |     Server    |
  |         |<--(B)---- Access Token ---------<|               |
  |         |                                  |               |
  +---------+                                  +---------------+
 Figure 6: クライアントクレデンシャルフロー 

Figure 6 (クライアントクレデンシャルフロー) のフローは以下の通りである.

(A)
クライアントは自身の認証情報を含めてトークンエンドポイントにアクセストークンリクエストを送る.
(B)
認可サーバーはクライアントを認証し, 認証に成功すればアクセストークンを発行する.


 TOC 

4.4.1.  認可リクエストとレスポンス

クライアント認証が認可グラントとして利用されるため, 追加の認可リクエストは必要ない.


 TOC 

4.4.2.  アクセストークンリクエスト

クライアントは, HTTPリクエストボディーに application/x-www-form-urlencoded フォーマットで下記のパラメーターを追加し, トークンエンドポイントにリクエストを送る.

grant_type
必須 (REQUIRED). client_credentials を指定しなければならない (MUST).
scope
任意 (OPTIONAL). 詳細は Section 3.3 (アクセストークンスコープ) を参照のこと.

クライアントは認可サーバーに対して認証を行わなければならない (MUST). 詳細は Section 3.2.1 (クライアント認証) を参照のこと.

例えば, クライアントは以下のHTTPリクエストをセキュリティ保護されたトランスポート層から送信する (改行は掲載上の都合による). 


  POST /token HTTP/1.1
  Host: server.example.com
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  Content-Type: application/x-www-form-urlencoded;charset=UTF-8

  grant_type=client_credentials

認可サーバーはクライアントを認証しなければならない (MUST).


 TOC 

4.4.3.  アクセストークンレスポンス

アクセストークンリクエストが正当かつ認可された場合, 認可サーバーは Section 5.1 (成功レスポンス) に示すとおりアクセストークンを発行する. リフレッシュトークンは含むべきでない (SHOULD NOT). クライアント認証に失敗, もしくはリクエストが不正であった場合, 認可サーバーは Section 5.2 (エラーレスポンス) に示すとおりエラーレスポンスを返す.

成功レスポンス例を以下に示す. 


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

  {
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"example",
    "expires_in":3600,
    "example_parameter":"example_value"
  }

 TOC 

4.5.  拡張

クライアントはトークンエンドポイントの grant_type パラメーターの値に (認可サーバーによって定義された) 絶対URIを指定し, 追加の必須パラメーターを付与することによって, 拡張グラントタイプを利用できる.

例えば, [I‑D.ietf‑oauth‑saml2‑bearer] (Mortimore, C., “SAML 2.0 Bearer Assertion Profiles for OAuth 2.0,” August 2011.) で定義されているSAML 2.0アサーショングラントタイプを利用してアクセストークンを要求するために, クライアントはTLSを用いて次のようなHTTPリクエストを行う. (改行は掲載上の都合による) 


  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded;charset=UTF-8

  grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-
  bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU
  [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-

アクセストークンリクエストが正当かつ認可されている場合, 認可サーバーは Section 5.1 (成功レスポンス) に示すとおりアクセストークンとオプションでリフレッシュトークンを発行する. クライアント認証に失敗, もしくはリクエストが不正であった場合, 認可サーバーは Section 5.2 (エラーレスポンス) に示すとおりエラーレスポンスを返す.


 TOC 

5.  アクセストークンの発行

アクセストークンリクエストが正当であり認可済であれば, 認可サーバーは Section 5.1 (成功レスポンス) に述べる形式でアクセストークン (および任意でリフレッシュトークン) を発行する. クライアント認証に失敗, もしくはリクエストが不正であった場合, 認可サーバーは Section 5.2 (エラーレスポンス) に述べる形式でエラーレスポンスを返す.


 TOC 

5.1.  成功レスポンス

認可サーバーはアクセストークン (および任意でリフレッシュトークン) を発行する. このレスポンスはエンティティーボディーに以下のパラメーターを含み, HTTP ステータスコード 200 (OK) で返される.

access_token
必須 (REQUIRED). 認可サーバーが発行するアクセストークン.
token_type
必須 (REQUIRED). トークンのタイプ. 値は大文字・小文字を区別しない. 詳細は Section 7.1 (アクセストークンタイプ) を参照のこと.
expires_in
任意 (OPTIONAL). アクセストークンの有効期間を表す秒数. 例えばこの値が 3600 であれば, そのアクセストークンは発行から1時間後に期限切れとなる.
refresh_token
任意 (OPTIONAL). リフレッシュトークン. 同じ認可グラントを用いて新しいアクセストークンを取得するのに利用される. 詳細は Section 6 (アクセストークンの更新) を参照のこと.
scope
任意 (OPTIONAL). アクセストークンのスコープ. 詳細は Section 3.3 (アクセストークンスコープ) を参照のこと.

これらのパラメーターは, [RFC4627] (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) で定義されているメディアタイプ application/json 形式で, HTTPレスポンスボディーに含まれる. JSONへのシリアライゼーションは, 各パラメーターをJSONオブジェクトの最上位要素とする形式で行う. パラメーター名と文字列値はJSON文字列, 数値はJSON数値となる. パラメーターの順序は問わず, 多様であり得る.

認可サーバーは, トークン, クレデンシャル, その他センシティブな情報を含むいかなる HTTP レスポンスにおいても, Cache-Control ([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.)) ヘッダーに no-store を, Pragma ([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.)) ヘッダーに no-cache を指定しなければならない (MUST).

例: 


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

  {
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"example",
    "expires_in":3600,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "example_parameter":"example_value"
  }

クライアントは認識できないレスポンスパラメーターを無視するべきである (SHOULD). トークンや認可サーバーから受けとるその他の値のサイズは定義しない. クライアントは値のサイズについてなんらかの仮定をすべきではない. 認可サーバーは自身が発行するあらゆる値のサイズについてドキュメントに明記すべきである.


 TOC 

5.2.  エラーレスポンス

認可サーバーはHTTP ステータスコード 400 (Bad Request) を返す. このレスポンスには以下のパラメーターが含まれる.

error
必須 (REQUIRED). 以下のエラーコードより1つを設定する.
invalid_request
リクエストに必要なパラメーターが含まれていない, サポートされないパラメーター値が含まれている, パラメーターが重複している, 複数のクレデンシャルが含まれている, クライアント認証のための複数のメカニズムが利用されている, もしくは異常値が設定されている.
invalid_client
クライアント認証に失敗した (例: 未知のクライアントである, クライアント認証情報が含まれていない, サポートされない認証方式が利用されている). 認可サーバーはHTTP認証スキームがサポートされていないことを示すためにHTTP ステータスコード 401 (Unauthorized) を返してもよい (MAY). もしクライアントが Authorization リクエストヘッダー経由で認証を試みた場合, 認可サーバーはHTTP ステータスコード 401 (Unauthorized) と共に, WWW-Authenticate レスポンスヘッダーにクライアントが利用すべき認証スキームを含めなければならない (MUST).
invalid_grant
提供された認可グラント (例えば認可コード, リソースオーナークレデンシャル, クライアントクレデンシャル) が不正, 有効期限切れ, 失効している, 認可リクエストで用いられたリダイレクト先URIとマッチしていない, 他のクライアントに対して発行されたものである.
unauthorized_client
認証されたクライアントが当該のグラントタイプを利用する様に認可されていない.
unsupported_grant_type
グラントタイプが認可サーバーによってサポートされていない.
invalid_scope
要求されたスコープが不正, 未知, 異常, リソースオーナーによって与えられた範囲を超えている.
error_description
任意 (OPTIONAL). クライアント開発者が発生したエラーを理解する際の手助けとなる, UTF-8エンコードされた可読性のある追加情報.
error_uri
任意 (OPTIONAL). クライアント開発者が発生したエラーに関する追加の情報を得ることができるWebページのURI.

これらのパラメーターは, [RFC4627] (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) で定義されているメディアタイプ application/json 形式で, HTTPレスポンスボディーに含まれる. JSONへのシリアライゼーションは, 各パラメーターをJSONオブジェクトの最上位要素とする形式で行う. パラメーター名と文字列値はJSON文字列, 数値はJSON数値となる. パラメーターの順序は問わず, 多様であり得る.

例: 


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

  {
    "error":"invalid_request"
  }

 TOC 

6.  アクセストークンの更新

認可サーバーがクライアントにリフレッシュトークンを発行していれば, クライアントはトークンエンドポイントに更新リクエストを送ることができる. 以下のパラメーターが application/x-www-form-urlencoded 形式でHTTPリクエストエンティティーボディーに加えられる.

grant_type
必須 (REQUIRED). 値には refresh_token がセットされなければならない (MUST).
refresh_token
必須 (REQUIRED). クライアントに発行されたリフレッシュトークン.
scope
任意 (OPTIONAL). アクセス要求のスコープ. 詳細は Section 3.3 (アクセストークンスコープ) を参照のこと. 要求されたスコープはリソースオーナーがもともと許可していない値を含んではならない (MUST NOT). もし指定されなかった場合は, もともと許可された値が用いられる.

リフレッシュトークンは, 一般的に有効期間の長い追加のアクセストークンを要求するためのクレデンシャルであるため, 発行されたクライアントと紐づく. クライアントタイプがコンフィデンシャルである場合, あるいはクライアントクレデンシャルが発行された (もしくはその他の認証が要求された) クライアントは, Section 3.2.1 (クライアント認証) に示すとおり認可サーバーにより認証されなければならない (MUST).

例えば, クライアントはTLSを用いて次のようなHTTPリクエストを送信する (改行は掲載上の都合による). 


  POST /token HTTP/1.1
  Host: server.example.com
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  Content-Type: application/x-www-form-urlencoded;charset=UTF-8

  grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

認可サーバーは次のことを実施しなければならない (MUST):

リクエストが有効で認可されている場合, 認可サーバーはアクセストークンを発行する. レスポンスの詳細は Section 5.1 (成功レスポンス) を参照のこと. リクエストの検証に失敗もしくはリクエストが無効な場合, 認可サーバーはエラーレスポンスを返す. エラーレスポンスの詳細は Section 5.2 (エラーレスポンス) を参照のこと.

認可サーバーは新しいリフレッシュトークンを返してもよい (MAY). その場合, クライアントは古いリフレッシュトークンを破棄し, 新しいリフレッシュトークンに取り替えなければならない (MUST). 認可サーバーは新しいリフレッシュトークンを発行した後, 古いリフレッシュトークンを無効化してもよい (MAY). 新しいリフレッシュトークンが発行された時, リフレッシュトークンのスコープはクライアントによってリクエストに含まれたリフレッシュトークンのスコープと同一でなければならない (MUST).


 TOC 

7.  保護されたリソースへのアクセス

クライアントはリソースサーバー上の保護されたリソースにアクセストークンを用いてアクセスする. リソースサーバーはアクセストークンの検証を行い, 有効期間が切れていないこと, 要求されているリソースがスコープ範囲内であることを確認しなければならない (MUST). アクセストークンを検証する具体的な方法 (およびエラーレスポンス) は本仕様の対象外だが, 一般的に検証はリソースサーバーと認可サーバーで協調して実行される.

クライアントがリソースサーバーの認証を受けるためにどのようにアクセストークンを用いるかは, リソースサーバーから払い出されたアクセストークンのタイプに依存する. 一般的には, アクセストークンタイプの仕様に定義される認証スキームに従ってHTTPの 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.) が利用される.


 TOC 

7.1.  アクセストークンタイプ

アクセストークンタイプは, タイプ特有の属性とともに, クライアントが保護されたリソースにリクエストする際アクセストークンを適切に用いるために必要な情報を提供する. クライアントはトークンタイプが想定外のものであるとき, または信頼できない時にはそのアクセストークンを利用するべきではない (MUST NOT).

例えば, [I‑D.ietf‑oauth‑v2‑bearer] (Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Protocol: Bearer Tokens,” July 2011.) に定義される bearer トークンタイプでは, 単にリクエストにアクセストークンを含めるだけでよい. 


  GET /resource/1 HTTP/1.1
  Host: example.com
  Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw

一方, [I‑D.ietf‑oauth‑v2‑http‑mac] (Hammer-Lahav, E., Barth, A., and B. Adida, “HTTP Authentication: MAC Access Authentication,” May 2011.) に定義される mac トークンタイプでは, アクセストークンと共にMACキーを発行する. このMACキーはHTTPリクエストの一部分を署名するのに利用される. 


  GET /resource/1 HTTP/1.1
  Host: example.com
  Authorization: MAC id="h480djs93hd8",
                     nonce="274312:dj83hs9s",
                     mac="kDZvddkndxvhGRXZhvuDjEWhGeE="

尚, 上記はあくまで参考例であり, 開発者は利用前に [I‑D.ietf‑oauth‑v2‑bearer] (Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Protocol: Bearer Tokens,” July 2011.) や [I‑D.ietf‑oauth‑v2‑http‑mac] (Hammer-Lahav, E., Barth, A., and B. Adida, “HTTP Authentication: MAC Access Authentication,” May 2011.) を参照することが推奨される.

各アクセストークンタイプ定義は, access_token レスポンスパラメーターとともにクライアントへ送付される追加属性 (もしあれば) を指定する. また, 保護されたリソースへのリクエストにアクセストークンを含めるために利用されるHTTP認証方式も定義する.


 TOC 

8.  仕様の拡張性


 TOC 

8.1.  アクセストークンタイプの定義

アクセストークンタイプを定義する方法は, Section 11.1 (OAuth アクセストークンタイプレジストリー) に示す手順でアクセストークンタイプレジストリーへの登録を行う方法と, 重複しない絶対 URI をタイプ名として用いる方法の2通りが存在する.

URI をタイプ名として用いるトークンタイプは, ベンダー固有の実装に限定されるべきであり (SHOULD), 広く一般に適用されるものではない. またこれらのトークンタイプは, それが用いられるリソースサーバーの実装詳細に固有のものである.

上記以外のすべてのトークンタイプは, レジストリーへの登録が必須である (MUST). タイプ名は type-name ABNF に従わなければならない (MUST). またトークンタイプが新しい HTTP 認証スキームを定義する場合, そのタイプ名には ([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 認証スキームと同一のものを用いるべきである (SHOULD). なおトークンタイプ example は, 例示のために予約済である. 


  type-name  = 1*name-char
  name-char   = "-" / "." / "_" / DIGIT / ALPHA

 TOC 

8.2.  新たなエンドポイントパラメーターの定義

認可エンドポイントおよびトークンエンドポイントで用いられる新たなリクエストないしレスポンスパラメーターは, Section 11.2 (OAuth パラメーターレジストリー) に示す手順に従って定義され, パラメーターレジストリーに登録される.

パラメーター名は param-name ABNF に従わなければならず (MUST), パラメーター値は (ABNF や既存パラメーターのシンタックスを参照するなどの方法で) 明確に定義する必要がある (MUST). 


  param-name  = 1*name-char
  name-char   = "-" / "." / "_" / DIGIT / ALPHA

ベンダー固有の未登録拡張パラメーターは, 広く一般には適用されず, それが用いられる認可サーバーの実装詳細に固有のものである. これらの拡張パラメーターには, その他の登録済みの値と衝突しないようなベンダー固有のプレフィックスを用いるべきである (SHOULD). (例: パラメーター名を 'companyname_' で始める)


 TOC 

8.3.  新たな認可グラントタイプの定義

新たな認可グラントタイプは grant_type パラメーター値として用いる重複の無い絶対 URI を用いることで定義される. 拡張グラントタイプを用いるために新たなトークンエンドポイントパラメーターが必要な場合は, それらのパラメーターを Section 11.2 (OAuth パラメーターレジストリー) に述べるように OAuth パラメーターレジストリーに登録する必要がある (MUST).


 TOC 

8.4.  新たな認可エンドポイントレスポンスタイプの定義

認可エンドポイントで利用される新しいレスポンスタイプは認可エンドポイントレスポンスタイプレジストリーに Section 11.3 (OAuth 認可エンドポイントレスポンスタイプレジストリー) の手順で定義され登録される. レスポンスタイプ名は response-type ABNF に従って定義する必要がある (MUST). 


  response-type  = response-name *( SP response-name )
  response-name  = 1*response-char
  response-char  = "_" / DIGIT / ALPHA

レスポンスタイプが一つ以上の空白文字 (%x20) を含む場合, それは空白で区切られた順不同の値のリストとして扱われる. 値の順番は一通りだけ登録でき, 同じ値の組の順番を変えた他のすべての組み合わせを網羅する.

例えば, 本仕様ではレスポンスタイプ token code を定義しないが, 拡張仕様として token code レスポンスタイプを定義し登録することは可能である. 一旦登録されると同じ組み合わせは code token としては登録することはできないが, 両方の値は同じレスポンスタイプを示すために使うことが出来る.


 TOC 

8.5.  追加のエラーコードの定義

プロトコルの拡張 (例えば, アクセストークンタイプ, 拡張パラメーター, 拡張グラントタイプ) が認可コードグラントエラーレスポンス (Section 4.1.2.1 (エラーレスポンス)), インプリシットグラントエラーレスポンス (Section 4.2.2.1 (エラーレスポンス)), トークンエラーレスポンス (Section 5.2 (エラーレスポンス)) と一緒に使われる追加のエラーコードを必要とする場合, そのようなエラーコードを定義してもよい (MAY).

拡張エラーコードは登録されたアクセストークンタイプ, エンドポイントパラメーター, 拡張グラントタイプと共に利用する場合は (Section 11.4 (OAuth拡張エラーレジストリー) の手順に従って) 登録されなければならない (MUST). 登録されていない拡張と共に利用するエラーコードは登録してもよい (MAY).

エラーコードは error-code ABNF に従う必要があり (MUST), 可能な場合は識別名をプレフィックスとして付与するべきである (SHOULD). 例えば, 不正な値が拡張パラメーター example に設定されたことを示すエラーは example_invalid と命名されるべきである. 


  error-code   = ALPHA *error-char
  error-char   = "-" / "." / "_" / DIGIT / ALPHA

 TOC 

9.  ネイティブアプリケーション

ネイティブアプリケーションはリソースオーナーの端末にインストールされ, 実行されるクライアントである (例えば, デスクトップアプリケーション, ネイティブモバイルアプリケーション). ネイティブアプリケーションではセキュリティ, プラットフォーム性能と全体的なエンドユーザー体験に関する特別な考慮を必要とするかもしれない (MAY).

認可エンドポイントはクライアントとリソースオーナーのユーザーエージェントによるインタラクションを要求する. ネイティブアプリケーションは外部のユーザーエージェントを起動もしくはアプリケーション内にユーザーエージェントを埋め込むことができる.

外部のユーザーエージェントか埋め込みのユーザーエージェントかを選択するとき, 開発者は以下のことを考慮すべきである.

インプリシットグラントタイプと認可コードグラントタイプを選択するとき, 以下について考慮すべきである.


 TOC 

10.  Security Considerations

柔軟で拡張可能なフレームワークであるため, OAuthでセキュリティに関して配慮すべき点は多くの因子によって決まる. 以下のセクションでは実装者に Section 2.1 (クライアントタイプ) にある, Webアプリケーション, ユーザーエージェントベースのアプリケーション, ネイティブアプリケーションの3つのクライアントプロファイルにフォーカスを当てたセキュリティーガイドラインを提供する.

より包括的なOAuthのセキュリティーモデルとその分析は, プロトコルデザインの背景と共に [I‑D.ietf‑oauth‑v2‑threatmodel] (Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” July 2011.) で提供される.


 TOC 

10.1.  クライアント認証

認可サーバーはクライアント認証の目的でWebアプリケーションとの間でクレデンシャルを確立する. 認可サーバーはクライアントパスワードより強度の高い認証手段を検討することが推奨される. Webアプリケーションはクライアントパスワードやその他のクレデンシャルの機密性を保持しなければならない (MUST).

認可サーバーはクライアント認証の目的でネイティブアプリケーションやユーザーエージェントベースのアプリケーションにパスワードやその他のクレデンシャルを発行するべきではない (MUST NOT). 認可サーバーは特定デバイス上に特定の方法でインストールされたネイティブアプリケーションに対しては, クライアントパスワード, もしくはその他のクレデンシャルを発行してもよい (MAY).

クライアント認証が不可能な時には, 認可サーバーはクライアントのアイデンティティ検証のために他の手段を採用すべきである (SHOULD). 例えば, クライアントのリダイレクトURIの登録要求やリソース所有者によるアイデンティティ確認が考えられる. 有効なリダイレクトURIは, それ単体でエンドユーザーの認可時にクライアントのアイデンティティを証明するには至らないが, エンドユーザーの認可取得後に偽のクライアントにクレデンシャルを配布するのを回避するのに利用することができる.

認可サーバーは認証されていないクライアントとの通信によるセキュリティ上の影響を考慮しなけれならない. そして, そのようなクライアントに対するリフレッシュトークンなどの他のクレデンシャルの開示を制限するための措置をとらなければならない.


 TOC 

10.2.  クライアント偽装

もし正当なクライアントがクライアントクレデンシャルを秘匿に保てない場合, 悪意あるクライアントがそのクライアントになりすまし, 保護されたリソースへのアクセスを取得することができる.

認可サーバーはクライアントが認証可能である場合は, 常にクライアント認証を実行しなければならない (MUST). クライアントが本質的に認証不可能な場合は, 認可サーバーは認可レスポンス時に用いられる全リダイレクト URI の登録を要求しなければならず (MUST), また上記のような悪意あるクライアントからリソースオーナーを保護する何らかの方策を取るべきである (SHOULD). そのような方策の例としては, リソースオーナー自身がクライアントの身元を確認するように認可サーバーが促すことなどが考えられる.

認可サーバーは明示的にリソースオーナーに認証を要求し, クライアントと要求される認可スコープおよび有効期間についての情報を提供するべきである (SHOULD). その時点でのクライアントのコンテキスト内の情報を評価し, リクエストの認可/拒否を行うことは, リソースオーナー自身の判断にゆだねられる.

認可サーバーは, クライアント認証やその他の判断基準によって, リクエストが同一のクライアントから送られておりクライアント偽装が行われていないことを確認できない限り, 二度目以降の認可リクエストを (リソースオーナーの能動的なインタラクション無しに) 自動的に処理すべきではない (SHOULD NOT).


 TOC 

10.3.  アクセストークン

アクセストークン (およびあらゆるトークンタイプ固有属性) は, 通信経路・ストレージ上ともに機密に保たれなければならない (MUST). またそれらの情報は, 認可サーバー, アクセストークンが通用するリソースサーバー, およびアクセストークンを発行されたクライアントの間でのみ共有される (MUST).

インプリシットグラントを利用する場合, アクセストークンは URI フラグメント経由で送信されるため, 認可対象外の何者かに漏洩する可能性がある.

認可サーバーは, 認可対象外の何者かがトークンの有効性を保持したままアクセストークンを生成・変更したり, トークンの生成方法を推測したりできないことを保証しなければならない (MUST).

クライアントは, 必要最小限のスコープおよび有効期間のアクセストークンを要求すべきである (SHOULD). 認可サーバーは, 要求されたスコープおよび有効期間をどのように受け入れるかを判断する際, クライアントのアイデンティティを考慮すべきであり (SHOULD), 場合によっては要求よりも狭い権限しか持たないアクセストークンを発行することもある (MAY).


 TOC 

10.4.  リフレッシュトークン

認可サーバーはWebアプリケーションクライアントおよびネイティブアプリケーションクライアントに対してリフレッシュトークンを発行してもよい (MAY).

リフレッシュトークンは通信経路・ストレージ上ともに機密に保たれ, 認可サーバーとリフレッシュトークン発行先クライアントの間のみで共有されなければならない (MUST). 認可サーバーは, どのリフレッシュトークンがどのクライアントに発行されたかを記録しておかなくてはならない (MUST).

認可サーバーはクライアントのアイデンティティを認証出来る場合は常に, リフレッシュトークンとクライアントのアイデンティティとの間の紐付けを検証しなければならない (MUST). クライアント認証が不可能な場合は, 認可サーバーはリフレッシュトークンの悪用を防ぐための他の手段を展開すべきである (SHOULD).

例えば, 認可サーバーはアクセストークンリフレッシュレスポンスの都度新しいリフレッシュトークンを発行するリフレッシュトークンローテーションを採用することができる. 前回のリフレッシュトークンは無効にされるが, 認可サーバーには残される. もしリフレッシュトークンが漏洩しアタッカーと正当なクライアントの両方によって引き続き利用された場合, それらの内の一つは無効なリフレッシュトークンを提示し, 認可サーバーへ違反の発生を知らせることとなる.

認可サーバーは, 認可対象外の何者かがトークンの有効性を保持したままリフレッシュトークンを生成・変更したり, トークンの生成方法を推測したりできないことを保証しなければならない (MUST).


 TOC 

10.5.  認可コード

認可コードの伝送経路はセキュアなチャネル上で実施されるべき (SHOULD) であり, クライアントはリダイレクトURIがネットワーク上のリソースを指している場合, そのURIを利用するためにTLSを導入すべきである (SHOULD). 認可コードを機密にしておくために努力がなされるべきである. なぜなら認可コードはユーザーエージェントリダイレクトによって伝送されるため, ユーザーエージェントの履歴とHTTPリファラーヘッダーを通して公開されてしまう可能性があるためである.

認可コードはプロセスを完了するために, 認可サーバーで権限を付与したリソースオーナーがクライアントへ返却されるリソースオーナーと同じであることを確認するために利用されるプレーンテキストの可搬クレデンシャルとして動作する. したがって, もしクライアントが自身のリソースオーナー認証を認可コードに依存する場合は, クライアントのリダイレクトエンドポイントはTLSを必要としなければならない (MUST).

認可コードの有効期間は短く, かつ一度限りしか利用されてはならない (MUST). もし認可サーバーが単一の認可コードをアクセストークンへ交換しようとする複数の試行を検出したならば, 認可サーバーはその認可コードに基づき既に付与されたすべてのアクセストークンを無効化することを試みるべきである (SHOULD).

もしクライアントが認証可能であれば, 認可サーバーはその認可コードが同じクライアントに対して発行されたことを確認するためにそのクライアントを認証しなければならない (MUST).


 TOC 

10.6.  認可コードリダイレクトURIの操作

認可要求に認可コードグラントタイプを用いるとき, クライアントは redirect_uri パラメーターによりリダイレクトURIを指定できる. 攻撃者がリダイレクトURIの値を操作可能であるとき, 認可サーバーによってリソースオーナーのユーザーエージェントを攻撃者の管理下にあるURIに認可コードを含んだ状態でリダイレクトさせることができる.

攻撃者は, 正しいクライアントにおいてアカウントを作成し, 認可フローを開始することができる. 攻撃者がアクセス許可のために認可サーバーに送られたとき, 正当なクライアントにより提供された認可URIを取得し, クライアントのリダイレクトURIを攻撃者の管理下にあるURIに交換する. 攻撃者はその後, 正当なクライアントに向けた操作された認可アクセスリンクをたどるよう被害者を騙す.

認可サーバーにおいて, 被害者は正当で信頼できるクライアントによる正常で有効なリクエストを促され, そのリクエストを認可する. 被害者はその後, 認可コードとともに攻撃者の管理下にあるエンドポイントにリダイレクトされる. 攻撃者は, クライアントにより提供されたオリジナルのリダイレクトURIを用いて,　認可コードを送ることにより認可フローを完了する. クライアントは認可コードとアクセストークンを交換し, それを攻撃者のクライアントのアカウントと紐づけることで, 被害者により (クライアント経由で) 認可された保護されたリソースへのアクセス権を獲得できる.

このような攻撃を防ぐため, 認可サーバーは認可コードの取得に用いたリダイレクトURIと, 認可コードとアクセストークンの交換時に提供されたリダイレクトURIが同一であることを確認しなければならない (MUST). 認可サーバーはパブリッククライアントに対してリダイレクトURIの登録を要求しなければならず (MUST), コンフィデンシャルクライアントに対してもリダイレクトURIの登録を要求すべきである (SHOULD). リダイレクトURIがリクエストにより提供されたとき, 認可サーバーは登録された値を用いてそれを検証しければならない (MUST).


 TOC 

10.7.  リソースオーナーパスワードクレデンシャル

リソースオーナーパスワードクレデンシャルグラントタイプはレガシーシステム, もしくは移行のために利用される. これはクライアントがユーザー名とパスワードを保管するリスク全般を軽減する. しかし特権のあるクレデンシャルをクライアントにさらす必要性を取り除くことはできない.

このグラントタイプは, 本プロトコルで回避するよう努力してきたパスワードアンチパターンを維持しているので, 他のグラントタイプより高いリスクを含んでいる. クライアントがパスワードを濫用することや, (例えば, ログファイルやクライアントが保持している他のリソースから) パスワードが意図せず攻撃者に公開されることがありえる.

加えてリソースオーナーは認可プロセスをコントロールできない (クレデンシャルをクライアントに提示した時点でリソースオーナーの関与は終了する) ので, クライアントはリソースオーナーの要求より有効範囲が広く, 有効期間の長いアクセストークンを取得することができる. 認可サーバーはこのグラントタイプで発行されたアクセストークンについての有効範囲と有効期間をよく検討すべきである.

認可サーバーとクライアントはこのグラントタイプの利用を控え, 可能であれば極力他のグラントタイプを利用すべきである (SHOULD).


 TOC 

10.8.  リクエストの機密性

アクセストークン, リフレッシュトークン, リソースオーナーのパスワード, そしてクライアントのクレデンシャルは平文で伝送してはならない (MUST NOT). 認可コードは平文で伝送するべきではない (SHOULD NOT).


 TOC 

10.9.  エンドポイントの真正性

man-in-the-middle アタックやフィッシングアタックを防ぐため, 認可サーバーは TLS を導入し, [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) に従って認可エンドポイントおよびトークンエンドポイントへのすべてのリクエストで TLS を利用したサーバー認証を必須としなければならない (MUST). クライアントはサーバー身元認証の要件に従って認可サーバーの TLS 証明書を検証しなければならない (MUST).


 TOC 

10.10.  クレデンシャルゲッシングアタック

認可サーバーは, アタッカーにアクセストークン, 認可コード, リフレッシュトークン, リソースオーナーパスワードおよびクライアントクレデンシャルを推測されないようにしなければならない (MUST).

トークンやその他のクレデンシャルなど, エンドユーザーが直接扱うことのないクレデンシャルを生成する場合, 認可サーバーはゲッシングアタックのリスクを低減するため適切のエントロピーを確保しなければならない (MUST). エンドユーザーが扱うクレデンシャルについては, 認可サーバーはその他の保護対策を行わなければならない (MUST).


 TOC 

10.11.  フィッシングアタック

本仕様や類似プロトコルを実際に広く運用するにつれ, エンドユーザーはパスワード入力を求める Web サイトにリダイレクトされるという慣習になじんでゆくであろう. もしエンドユーザーがそういった Web サイトでパスワードを入力する際にそのサイトの真正性検証を怠った場合, この慣習がアタッカーに悪用され, リソースオーナーのパスワードを盗まれる可能性もある.

サービスプロバイダーはエンドユーザーに対してフィッシングアタックにより引き起こされるリスクに関して教育し, エンドユーザーが簡単にサイトの真正性を確認できるメカニズムを提供するべきである. クライアントデベロッパーは, ユーザーエージェントとのインタラクション方式 (外部エージェント / 埋め込みエージェントのどちらを利用するかなど) とセキュリティーとの関係に加え, エンドユーザーによる認可サーバーの真正性検証能力についても熟考すべきである.

フィッシングアタックのリスクを低減するため, 認可サーバーはエンドユーザーとのインタラクションを行うすべてのエンドポイントで TLS を利用しなければならない (MUST).


 TOC 

10.12.  クロスサイトリクエストフォージェリ

クロスサイトリクエストフォージェリ (CSRF) は, 攻撃者が犠牲となるエンドユーザーのユーザーエージェントに (例えば, ユーザーエージェントに誤解を招きやすいリンクやイメージ, 転送によって) 悪意のあるURIを閲覧させることにより (通常, 有効なセッションクッキーの存在によって) 信頼が確立されたサーバーへ接続させる手法である.

クライアントのリダイレクトURIに対するCSRF攻撃は, 攻撃者が自身の認可コードやアクセストークンを紛れ込ませることを可能とし, クライアントに犠牲者の保護されたリソースではなく, 攻撃者のリソースに紐付いたアクセストークンを使わせることが出来てしまう (例えば, 犠牲者の銀行口座情報を攻撃者の管理しているリソースへ保存してしまう, といったことも可能となる).

クライアントは自身のリダイレクトURIに対してCSRF保護対策を導入しなければならない (MUST). 一般的に保護対策は, リダイレクトURIのエンドポイントへ送られたすべての要求に対して, 要求とユーザーエージェントの認証状態を紐付けるための値を含めることにより実現する (例えば, ユーザーエージェントを認証するために使うセッションクッキーのハッシュなど). クライアントは認可要求の発行時, この値を認可サーバーへ伝搬するために state リクエストパラメーターを利用すべきである (SHOULD).

一旦エンドユーザーの認可が得られると, 認可サーバーはエンドユーザーのユーザーエージェントを state パラメーターに含まれる要求されたバインド値と共にクライアントへリダイレクトする. クライアントはバインド値とユーザーエージェントの認証状態を突合することによりリクエストの正当性を確認することが出来る. CSRFを防ぐために使用されるバインド値は推測不能な値を含まねばならず (MUST), ユーザーエージェントの認証状態 (例えば, セッションクッキーやHTML5のローカルストレージ) はクライアントおよびユーザーエージェントのみがアクセスできる状態に保たれなければならない (つまり, 同一起源ポリシーによる保護) (MUST).

認可サーバーの認可エンドポイントへのCSRF攻撃はエンドユーザーに知られることなく, 攻撃者が悪意のあるクライアントへのエンドユーザー認可を取得可能にしてしまう.

認可サーバーは認可エンドポイントにCSRF保護を実装せねばならず, 悪意あるクライアントがリソースオーナーへの通知と明確な同意なく認可を取得出来ないことを保証せねばならない (MUST).


 TOC 

10.13.  クリックジャッキング

クリックジャッキング攻撃において, 攻撃者は正当なクライアントを登録し,その後悪意のあるサイトを構築する. そのサイトは, 透明なiframe内に認可サーバーの認可エンドポイントのWebページをロードし, その認可ページの重要なボタンの直下に置かれるように 丁寧に配置されたダミーボタンの上に重ねられる. エンドユーザーが誤解し目に見えるボタンをクリックするとき, 実際は認可ページ内の (認可ボタンのような) 目に見えないボタンをクリックしている. これは, 攻撃者にリソースオーナーを騙し, 知らないうちにそのクライアントアクセスを許可することを許す.

iframeにおけるこの攻撃形式を防ぐため, ネイティブアプリケーションはエンドユーザーの認可を要求するとき, 埋め込みのブラウザの代わりに外部ブラウザを使用すべきである (SHOULD). ほとんどの最新ブラウザは, 認可サーバーが非標準の x-frame-options ヘッダーを利用することにより強制的にiframeを回避することができる. このヘッダーは deny と sameorigin の2つの値を持つことができ, それぞれすべてのフレーミング, originが異なるサイトからのフレーミングを防ぐ. 古いブラウザはJavaScriptのフレームバースティング技術を利用できるが, すべてのブラウザに有効ではないかもしれない.


 TOC 

10.14.  コードインジェクションとインプットバリデーション

入力値もしくはそれ以外の外部変数がアプリケーションによってサニタイズされずに使用されるとき, コードインジェクション攻撃が発生し, アプリケーションロジックの改ざんを引き起こす. これは攻撃者にアプリケーションデバイスもしくはそのデータへのアクセスを許可し, サービス不能もしくは広範囲な悪意のある副作用を引き起こすかもしれない.

認可サーバーとクライアントは受け取ったどの値も, 特に state, redirect_uri パラメーターは検証し, サニタイズをしなければならない (MUST).


 TOC 

10.15.  オープンリダイレクタ

認可サーバーの認可エンドポイントとクライアントのリダイレクトエンドポイントは不適切な設定によりオープンリダイレクタとして動作しうる. オープンリダイレクタとは正当性の確認をせずにパラメーターで指定されたURLにユーザーエージェントを自動でリダイレクトするエンドポイントである.

オープンリダイレクタは, フィッシング攻撃, もしくはURIのオーソリティ部を見慣れた信頼できる通信先とする事で攻撃者がエンドユーザーを悪意のあるサイトに誘導するのに利用される. 加えて認可サーバーがクライアントにリダイレクトURIの一部のみでの登録を許可した場合, 攻撃者は, 認可サーバーの正当性確認を通過し, 認可コード, アクセストークンを攻撃者が管理するエンドポイントに送信するリダイレクトURIの作成にクライアントの運営しているオープンリダイレクタを利用できる.


 TOC 

11.  IANA Considerations


 TOC 

11.1.  OAuth アクセストークンタイプレジストリー

本仕様では, OAuth アクセストークンタイプレジストリーを定める.

アクセストークンタイプは, 1名以上の (IESG もしくはその代理者によって任命された) Designated Experts の勧告に従い, Specification Required な状態で登録される. (以降, 文中の専門用語については [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) を参照のこと) しかしながら, 発行に先立ってそのトークンタイプを用いることができるように, Designated Experts はそのトークンタイプが公開できる状態になった時点で登録を許可することもありうる.

登録要請は, 適切な件名 (例: "Request for access token type: example") で [TBD]@ietf.org のメーリングリストに通知すべきであり, そこでレビューとコメントが行われる. [[ Note to RFC-EDITOR: メーリングリストのアドレスは, IESG と IANA の協議によって定められる. 提案: oauth-ext-review@ietf.org ]]

Designated Experts は要請から14日以内に登録を承認または拒否し, レビューが行われるメーリングリストおよび IANA へその決定を告げる. 要請が拒否された場合は, その理由の通知が通知され, 可能な場合は承認に向けた提案が行われるべきである.

Designated Experts の決定 (もしくは決定の欠如) に異議がある場合は, Application Area Directors (app-ads@tools.ietf.org もしくは http://www.iesg.org/ にリストアップされている彼らのメールアドレス経由でコンタクト可能) に上訴することができる. また上訴に対する返答にも満足できない場合は, IESG 全体 (iesg@iesg.org のメーリングリスト) に上訴すること.

IANA は, Designated Experts によるすべてのレジストリー更新要請を承認し, すべての登録要請をレビューメーリングリストに送信するべきである.


 TOC 

11.1.1.  レジストリーテンプレート

Type name:
名称 (例: "example")
Additional Token Endpoint Response Parameters:
access_token と同時に返される追加のレスポンスパラメーター. 新規パラメーターは別個 Section 11.2 (OAuth パラメーターレジストリー) に従って OAuth パラメーターレジストリーに登録すること (MUST).
HTTP Authentication Scheme(s):
登録トークンタイプのアクセストークンによるリソースリクエスト認証に用いられる HTTP Authentication スキーマ (もしあれば).
Change controller:
RFC の標準に従う際は, "IETF" と記載する. それ以外の場合は, 責任ある団体の名称を記載する. その他の詳細 (例えば, 郵便番号, メールアドレス, ホームページの URL) も記載してもよい.
Specification document(s):
パラメーター仕様を記載したドキュメントへの参照を記載する. ドキュメントを取得することのできる URI が記載されていることが望ましい. 明確な記載箇所への参照が含まれることが望ましいが必須ではない.


 TOC 

11.2.  OAuth パラメーターレジストリー

本仕様では, OAuth パラメーターレジストリーを定める.

認可エンドポイントリクエスト, 認可エンドポイントレスポンス, トークンエンドポイントリクエスト, トークンエンドポイントレスポンスに含める追加のパラメーターは, 1名以上の (IESG もしくはその代理者によって任命された) Designated Experts の勧告に従い, Specification Required な状態で登録される. (以降, 文中の専門用語については [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) を参照のこと) しかしながら, 発行に先立ってそれらの値を割り当てることができるように, Designated Experts はそれらの値が公開できる状態になった時点で登録を許可することもありうる.

登録要請は, 適切な件名 (例: "Request for parameter: example") で [TBD]@ietf.org のメーリングリストに通知すべきであり, そこでレビューとコメントが行われる. [[ Note to RFC-EDITOR: メーリングリストのアドレスは, IESG と IANA の協議によって定められる. 提案: oauth-ext-review@ietf.org ]]

Designated Experts は要請から14日以内に登録を承認または拒否し, レビューが行われるメーリングリストおよび IANA へその決定を告げる. 要請が拒否された場合は, その理由の通知が通知され, 可能な場合は承認に向けた提案が行われるべきである.

Designated Experts の決定 (もしくは決定の欠如) に異議がある場合は, Application Area Directors (app-ads@tools.ietf.org もしくは http://www.iesg.org/ にリストアップされている彼らのメールアドレス経由でコンタクト可能) に上訴することができる. また上訴に対する返答にも満足できない場合は, IESG 全体 (iesg@iesg.org のメーリングリスト) に上訴すること.

IANA は, Designated Experts によるすべてのレジストリー更新要請を承認し, すべての登録要請をレビューメーリングリストに送信するべきである.


 TOC 

11.2.1.  レジストリーテンプレート

Parameter name:
名称 (例: "example").
Parameter usage location:
パラメーターが利用できる箇所. 想定される箇所は以下の通り: 認可リクエスト, 認可レスポンス, トークンリクエスト, トークンリクエスト.
Change controller:
RFCの標準に従う際は, "IETF"と記載する. それ以外の場合は, 責任ある団体の名称を記載する. その他の詳細 (例えば, 郵便番号, メールアドレス, ホームページのURL) も記載してもよい.
Specification document(s):
パラメーター仕様を記載したドキュメントへの参照を記載する. ドキュメントを取得することのできるURIが記載されていることが望ましい. 明確な記載箇所への参照が含まれることが望ましいが必須ではない.


 TOC 

11.2.2.  初期レジストリーコンテンツ

OAuth パラメーターレジストリーの初期コンテンツは以下の通りである:


 TOC 

11.3.  OAuth 認可エンドポイントレスポンスタイプレジストリー

本仕様では, OAuth 認可エンドポイントレスポンスタイプレジストリーを定める.

認可エンドポイントで利用される追加のレスポンスタイプは, 1名以上の (IESG もしくはその代理者によって任命された) Designated Experts の勧告に従い, Specification Required な状態で登録される. (以降, 文中の専門用語については [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) を参照のこと) しかしながら, 発行に先立ってそれらの値を割り当てることができるように, Designated Experts はそれらの値が公開できる状態になった時点で登録を許可することもありうる.

登録要請は, 適切な件名 (例: "Request for response type: example") で [TBD]@ietf.org のメーリングリストに通知すべきであり, そこでレビューとコメントが行われる. [[ Note to RFC-EDITOR: メーリングリストのアドレスは, IESG と IANA の協議によって定められる. 提案: oauth-ext-review@ietf.org ]]

Designated Experts は要請から14日以内に登録を承認または拒否し, レビューが行われるメーリングリストおよび IANA へその決定を告げる. 要請が拒否された場合は, その理由の通知が通知され, 可能な場合は承認に向けた提案が行われるべきである.

Designated Experts の決定 (もしくは決定の欠如) に異議がある場合は, Application Area Directors (app-ads@tools.ietf.org もしくは http://www.iesg.org/ にリストアップされている彼らのメールアドレス経由でコンタクト可能) に上訴することができる. また上訴に対する返答にも満足できない場合は, IESG 全体 (iesg@iesg.org のメーリングリスト) に上訴すること.

IANA は, Designated Experts によるすべてのレジストリー更新要請を承認し, すべての登録要請をレビューメーリングリストに送信するべきである.


 TOC 

11.3.1.  レジストリーテンプレート

Response type name:
名称 (例: "example").
Change controller:
RFCの標準に従う際は, "IETF"と記載する. それ以外の場合は, 責任ある団体の名称を記載する. その他の詳細 (例えば, 郵便番号, メールアドレス, ホームページのURL) も記載してもよい.
Specification document(s):
パラメーター仕様を記載したドキュメントへの参照を記載する. ドキュメントを取得することのできるURIが記載されていることが望ましい. 明確な記載箇所への参照が含まれることが望ましいが必須ではない.


 TOC 

11.3.2.  初期レジストリーコンテンツ

OAuth 認可エンドポイントレスポンスタイプレジストリーの初期コンテンツは以下の通りである:


 TOC 

11.4.  OAuth拡張エラーレジストリー

本仕様では, OAuth拡張エラーレジストリーを定める.

他のプロトコル拡張 (例えば, 拡張グラントタイプ, アクセストークンタイプ, もしくは拡張パラメーター) で利用される追加のエラーコードは, 1名以上の (IESG もしくはその代理者によって任命された) Designated Experts の勧告に従い, Specification Required な状態で登録される. (以降, 文中の専門用語については [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) を参照のこと) しかしながら, 発行に先立ってそれらの値を割り当てることができるように, Designated Experts はそれらの値が公開できる状態になった時点で登録を許可することもありうる.

登録要請は, 適切な件名 (例: "Request for response type: example") で [TBD]@ietf.org のメーリングリストに通知すべきであり, そこでレビューとコメントが行われる. [[ Note to RFC-EDITOR: メーリングリストのアドレスは, IESG と IANA の協議によって定められる. 提案: oauth-ext-review@ietf.org ]]

Designated Experts は要請から14日以内に登録を承認または拒否し, レビューが行われるメーリングリストおよび IANA へその決定を告げる. 要請が拒否された場合は, その理由が通知され, 可能な場合は承認に向けた提案が行われるべきである.

Designated Experts の決定 (もしくは決定の欠如) に異議がある場合は, Application Area Directors (app-ads@tools.ietf.org もしくは http://www.iesg.org/ にリストアップされている彼らのメールアドレス経由でコンタクト可能) に上訴することができる. また上訴に対する返答にも満足できない場合は, IESG 全体 (iesg@iesg.org のメーリングリスト) に上訴すること.

IANA は, Designated Experts によるすべてのレジストリー更新要請を承認し, すべての登録要請をレビューメーリングリストに送信するべきである.


 TOC 

11.4.1.  レジストリーテンプレート

Error name:
名称 (例: "example").
Error usage location:
エラーが利用できる箇所. 想定される箇所は以下の通り: 認可コード付与エラーレスポンス (Section 4.1.2.1 (エラーレスポンス)), インプリシット付与エラーレスポンス (Section 4.2.2.1 (エラーレスポンス)), トークンエラーレスポンス (Section 5.2 (エラーレスポンス)).
Related protocol extension:
エラーコードと共に用いられる拡張グラントタイプ名, アクセストークンタイプ名, もしくは拡張パラメーター名を記載する.
Change controller:
RFCの標準に従う際は, "IETF"と記載する. それ以外の場合は, 責任ある団体の名称を記載する. その他の詳細 (例えば, 郵便番号, メールアドレス, ホームページのURL) も記載してもよい.
Specification document(s):
エラーコード仕様を記載したドキュメントへの参照を記載する. ドキュメントを取得することのできるURIが記載されていることが望ましい. 明確な記載箇所への参照が含まれることが望ましいが必須ではない.


 TOC 

12.  Acknowledgements

The initial OAuth 2.0 protocol specification was edited by David Recordon, based on two previous publications: the OAuth 1.0 community specification [RFC5849] (Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.), and OAuth WRAP (OAuth Web Resource Authorization Profiles) [I‑D.draft‑hardt‑oauth‑01] (Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, “OAuth Web Resource Authorization Profiles,” January 2010.). The Security Considerations section was drafted by Torsten Lodderstedt, Mark McGloin, Phil Hunt, and Anthony Nadalin.

The OAuth 1.0 community specification was edited by Eran Hammer-Lahav and authored by 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, and Andy Smith.

The OAuth WRAP specification was edited by Dick Hardt and authored by Brian Eaton, Yaron Goland, Dick Hardt, and Allen Tom.

This specification is the work of the OAuth Working Group which includes dozens of active and dedicated participants. In particular, the following individuals contributed ideas, feedback, and wording which shaped and formed the final specification:

Michael Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, Aiden Bell, Scott Cantor, Marcos Caceres, Blaine Cook, Brian Campbell, Brian Eaton, Leah Culver, Bill de hOra, Andre DeMarre, Brian Eaton, Brian Ellin, Igor Faynberg, George Fletcher, Tim Freeman, Evan Gilbert, Yaron Goland, Brent Goldman, Kristoffer Gronowski, Justin Hart, Dick Hardt, Craig Heath, Phil Hunt, Michael B. Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara, Rasmus Lerdorf, Torsten Lodderstedt, Hui-Lan Lu, Casey Lucas, Paul Madsen, Alastair Mair, Eve Maler, James Manger, Mark McGloin, Laurence Miao, Chuck Mortimore, Anthony Nadalin, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Luke Shepard, Vlad Skvortsov, Justin Smith, Niv Steingarten, Christian Stubner, Jeremy Suriel, Paul Tarjan, Allen Tom, Franklin Tse, Nick Walker, Shane Weeden, and Skylar Woodward.


 TOC 

Appendix A.  Editor's Notes

While many people contributed to this specification throughout its long journey, the editor would like to acknowledge and thank a few individuals for their outstanding and invaluable efforts leading up to the publication of this specification. It is these individuals without whom this work would not have existed or reached its successful conclusion.

David Recordon for continuously being one of OAuth’s most valuable assets, bringing pragmatism and urgency to the work, and helping shape it from its very beginning, as well as being one of the best collaborators I had the pleasure of working with.

Mark Nottingham for introducing OAuth to the IETF and setting the community on this course. Lisa Dusseault for her support and guidance as the Application area director. Blaine Cook, Peter Saint-Andre, and Hannes Tschofenig for their work as working group chairs.

James Manger for his creative ideas and always insightful feedback. Brian Campbell, Torsten Lodderstedt, Chuck Mortimore, Justin Richer, Marius Scurtescu, and Luke Shepard for their continued participation and valuable feedback.

Special thanks goes to Mike Curtis and Yahoo! for their unconditional support of this work for over three years.


 TOC 

Appendix B.  翻訳者

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


 TOC 

13.  References


 TOC 

13.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2246] Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” RFC 2246, January 1999 (TXT).
[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, June 1999 (TXT, PS, PDF, HTML, XML).
[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, June 1999 (TXT, HTML, XML).
[RFC2818] Rescorla, E., “HTTP Over TLS,” RFC 2818, May 2000 (TXT).
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
[RFC4627] Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” RFC 4627, July 2006 (TXT).
[RFC4949] Shirey, R., “Internet Security Glossary, Version 2,” RFC 4949, August 2007 (TXT).
[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT).
[RFC5234] Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” STD 68, RFC 5234, January 2008 (TXT).
[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT).
[W3C.REC-html401-19991224] Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (HTML).

 TOC 

13.2. Informative References

[I-D.draft-hardt-oauth-01] Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, “OAuth Web Resource Authorization Profiles,” January 2010.
[I-D.ietf-oauth-saml2-bearer] Mortimore, C., “SAML 2.0 Bearer Assertion Profiles for OAuth 2.0,” draft-ietf-oauth-saml2-bearer-08 (work in progress), August 2011 (TXT).
[I-D.ietf-oauth-v2-bearer] Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Protocol: Bearer Tokens,” draft-ietf-oauth-v2-bearer-08 (work in progress), July 2011 (TXT, PDF).
[I-D.ietf-oauth-v2-http-mac] Hammer-Lahav, E., Barth, A., and B. Adida, “HTTP Authentication: MAC Access Authentication,” draft-ietf-oauth-v2-http-mac-00 (work in progress), May 2011 (TXT, PDF).
[I-D.ietf-oauth-v2-threatmodel] Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” draft-ietf-oauth-v2-threatmodel-00 (work in progress), July 2011 (TXT).
[OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS Standard saml-core-2.0-os, March 2005.
[RFC5849] Hammer-Lahav, E., “The OAuth 1.0 Protocol,” RFC 5849, April 2010 (TXT).

 TOC 

13.3. 翻訳プロジェクト

[oidfj] OpenIDファウンデーションジャパン, “OpenIDファウンデーションジャパン.”
[oidfj-github] OpenIDファウンデーションジャパン, “Githubレポジトリー.”
[oidfj-trans] OpenIDファウンデーションジャパン, “翻訳・教育ワーキンググループ.”

 TOC 

Authors' Addresses

  Eran Hammer-Lahav (editor)
  Yahoo!
Email:  eran@hueniverse.com
URI:  http://hueniverse.com
  
  David Recordon
  Facebook
Email:  dr@fb.com
URI:  http://www.davidrecordon.com/
  
  Dick Hardt
  Microsoft
Email:  dick.hardt@gmail.com
URI:  http://dickhardt.org/