The OAuth 2.0 Authorization Framework

Abstract

OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである. サードパーティーアプリケーションによるアクセス権の取得には, リソースオーナーとHTTPサービスの間で同意のためのインタラクションを伴う場合もあるが, サードパーティーアプリケーション自身が自らの権限においてアクセスを許可する場合もある. 本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである.

Status of This Memo

This is an Internet Standards Track document.

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

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

Copyright Notice

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

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

Table of Contents

1.  はじめに
    1.1.  登場人物
    1.2.  プロトコルフロー
    1.3.  認可グラント
        1.3.1.  認可コード
        1.3.2.  インプリシット
        1.3.3.  リソースオーナーパスワードクレデンシャル
        1.3.4.  クライアントクレデンシャル
    1.4.  アクセストークン
    1.5.  リフレッシュトークン
    1.6.  TLSバージョン
    1.7.  HTTPリダイレクト
    1.8.  相互運用性
    1.9.  表記規約
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.  アクセストークンタイプ
    7.2.  エラーレスポンス
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.  オープンリダイレクタ
    10.16.  インプリシットフローにおけるリソースオーナーなりすましのためのアクセストークン不正利用
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.  References
    12.1.  Normative References
    12.2.  Informative References
    12.3.  翻訳プロジェクト
Appendix A.  Augmented Backus-Naur Form (ABNF) Syntax
    A.1.  "client_id" Syntax
    A.2.  "client_secret" Syntax
    A.3.  "response_type" Syntax
    A.4.  "scope" Syntax
    A.5.  "state" Syntax
    A.6.  "redirect_uri" Syntax
    A.7.  "error" Syntax
    A.8.  "error_description" Syntax
    A.9.  "error_uri" Syntax
    A.10.  "grant_type" Syntax
    A.11.  "code" Syntax
    A.12.  "access_token" Syntax
    A.13.  "token_type" Syntax
    A.14.  "expires_in" Syntax
    A.15.  "username" Syntax
    A.16.  "password" Syntax
    A.17.  "refresh_token" Syntax
    A.18.  Endpoint Parameter Syntax
Appendix B.  Use of application/x-www-form-urlencoded Media Type
Appendix C.  Acknowledgements
Appendix D.  翻訳者

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利用については対象としない.

Informationalドキュメントとして発行されたOAuth 1.0 ([RFC5849] (Hammer-Lahav, E., Ed., “The OAuth 1.0 Protocol,” April 2010.)) は, 小規模のアドホックなコミュニティにより作られた. Standard Trackである本仕様は, OAuth 1.0で得られた経験を元に, IETFコミュニティから発生したさらなるユースケースや拡張性を加味して策定されている. OAuth 2.0はOAuth 1.0との互換性はない. 2つのバージョンは共存可能であり, 実装者は両方をサポートすることも可能である. しかしながら本仕様は, 新規実装されるサービスではOAuth 2.0をサポートし, OAuth 1.0は既存サービスのサポートのためにのみ用いることを想定している. OAuth 2.0プロトコルには, OAuth 1.0と共通の実装詳細はごく少ない. OAuth 1.0に詳しい実装者は, OAuth 1.0の知識に基づく憶測を持たずに本仕様を理解すること.

1.1.  登場人物

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

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

保護されたリソースへのアクセスを許可するエンティティー. リソースオーナーが人間の場合, エンドユーザーと呼ばれる.

リソースサーバー (resource server)

保護されたリソースをホストし, アクセストークンを用いた保護されたリソースへのリクエストを受理してレスポンスを返すことのできるサーバー.

クライアント (client)

リソースオーナーの認可を得て, リソースオーナーの代理として保護されたリソースに対するリクエストを行うアプリケーション. 「クライアント」という表現は, 該当アプリケーションの実装上の特徴には関係がない. (OAuthクライアントは, サーバー上で動くアプリケーションであることもあれば, デスクトップアプリケーションやその他のデバイス上で動くアプリケーションであることもある)

認可サーバー (authorization server)

リソースオーナーの認証とリソースオーナーからの認可取得が成功した後, アクセストークンをクライアントに発行するサーバー.

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

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 (Abstract Protocol Flow)で示されたOAuth 2.0のフロー概要は, 4つのロール間での相互作用と以下のステップについて記載している.

(A)

クライアントはリソースオーナーに対して認可を要求する. その際 (図のように) リソースオーナーに直接認可要求を行うことも出来るが, 認可サーバーを経由して間接的に行うことがのぞましい.

(B)

クライアントは, リソースオーナーの認可を表すクレデンシャルとして認可グラントを受け取る. 認可グラントは本仕様で定義される4つのグラントタイプの内の1つ, または拡張されたグラントタイプで発行される. どの認可グラントタイプを用いるかは, クライアントの利用する認可リクエストの方式と認可サーバーがサポートするグラントタイプに依存する.

(C)

クライアントは認可サーバーに対して自身を認証し, 認可グラントを提示することで, アクセストークンを要求する.

(D)

認可サーバーはクライアントを認証し, 認可グラントの正当性を確認する. そして認可グラントが正当であれば, アクセストークンを発行する.

(E)

クライアントはリソースサーバーの保護されたリソースへリクエストを行い, 発行されたアクセストークンにより認証を行う.

(F)

リソースサーバーはアクセストークンの正当性を確認し, 正当であればリクエストを受け入れる.

クライアントがリソースオーナーから認可グラントを取得する (図中AおよびB) 際には, 認可サーバーが仲介を行う方式が望ましい. この方式はSection 4.1 (認可コードによる認可)のFigure 3 (認可コード処理フロー)に示されている.

1.3.  認可グラント

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

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

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

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

1.3.2.  インプリシット

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

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

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

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

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

このグラントタイプでは, クライアントがリソースオーナークレデンシャルへ直接アクセスすることになるが, リソースオーナークレデンシャルは一度きりのリクエストにのみ使用され, アクセストークンに交換される. このグラントタイプでは, クレデンシャルを寿命の長いアクセストークンやリフレッシュトークンと交換することにより, クライアントがリソースオーナークレデンシャルを後の利用のために保存しておく必要がなくなる.

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

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

1.4.  アクセストークン

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

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

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

アクセストークンはリソースサーバーのセキュリティ要件に基づいて異なるフォーマット, 構成, および利用方法を持つことができる (暗号の特性). アクセストークンの属性と保護されたリソースにアクセスするための方法は本仕様に定めるところではなく, [RFC6750] (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.)のように本仕様と対になる仕様によって定義される.

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

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

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

  +--------+                                           +---------------+
  |        |--(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 (Refreshing an Expired Access Token) のフローは, 以下の各ステップからなる.

(A)

クライアントは, 認可サーバーに対して自身を認証して認可グラントを提示することによって, アクセストークンを要求する.

(B)

認可サーバーはクライアントを認証して認可グラントを確認し, 有効である場合はアクセストークンとリフレッシュトークンを発行する.

(C)

クライアントはアクセストークンを提示してリソースサーバー上の保護されたリソースに対してリクエストを行う.

(D)

リソースサーバーはアクセストークンの正当性を確認し, 有効な場合はリクエストを処理する.

(E)

ステップ (C) と (D) はアクセストークンの有効期限が切れるまで繰り返される. クライアントがアクセストークンの期限切れを検知した場合, ステップ (G) にスキップし, そうでなければ保護されたリソースへのリクエストを続ける.

(F)

アクセストークンが有効でないとき, リソースサーバーはエラーを返し, トークンが無効なことを伝える.

(G)

クライアントは, 認可サーバーに対して自身を認証してリフレッシュトークンを提示することによって, 新しいアクセストークンを要求する. クライアント認証の必要条件はクライアントタイプと認可サーバーのポリシーによって異なる.

(H)

認可サーバーはクライアントを認証しリフレッシュトークンの正当性を確認し, 正当であれば新たなアクセストークン (およびオプションで新たなリフレッシュトークン) を発行する.

Section 7 (保護されたリソースへのアクセス)に述べる通り, (C), (D), (E) および (F) は本仕様の定めるところではない.

1.6.  TLSバージョン

本仕様でTransport Layer Security (TLS) を用いる場合, 将来的に実運用やセキュリティ上の脆弱性が発見されたりすることで, 適切なTLSのバージョンは変化しうる. 本仕様執筆時点では, TLSバージョン1.2 [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) が最新バージョンであるが, 現実にはその実装は限られており, すぐに利用可能な状態ではない可能性もある. TLSバージョン1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) は最も広く実装されており, 最も広い相互運用性をもたらすであろう.

実装者は, 自身のセキュリティ要件に合わせて, TLSの他にさらにトランスポートレイヤーのセキュリティメカニズムをサポートすることも可能である.

1.7.  HTTPリダイレクト

本仕様では, クライアントもしくは認可サーバーがリソースオーナーのユーザーエージェントを別の場所にリダイレクトさせる際に, HTTPリダイレクトを用いる. 本仕様の例では302 HTTPステータスを用いるが, それ以外にもユーザーエージェントを通じてリダイレクトを行うことができる方法であれば, どのような手段を用いても良い. どのような手段を用いるかは実装者に委ねる.

1.8.  相互運用性

OAuth 2.0は明確に定義されたセキュリティ特性を持つリッチな認可フレームワークである. しかしながら, リッチで多くのオプション要素を持つ高度に拡張可能なフレームワークであることから, 様々な要因によって相互運用性を損なう実装をもたらす可能性もある.

加えて, 本仕様はいくつかの必須要素を部分的または完全に未定義な状態で残す. (例: クライアント登録, 認可サーバーに求められる機能, エンドポイントのディスカバリーなど) これらの要素が欠けているため, 相互運用性を確保するには, クライアントは各認可サーバーおよびリソースサーバーに対して個別に手動で設定される必要がある.

将来的には, Web全体に渡る相互運用性獲得のために必要な規範的プロフィールや拡張が定義されることを期待する.

1.9.  表記規約

本仕様書で用いられる各キーワード「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., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) における Augmented Backus-Naur Form (ABNF) 表記法を使用している. 加えてURI-referenceの規則には "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) を用いる. [RFC5234] (Crocker, D., Ed. 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)」などがあるが, これらだけに限定はされない.

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

2.  クライアント登録

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

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

クライアントを登録する場合, クライアント開発者は以下を満たすものとする (SHALL).

• Section 2.1 (クライアントタイプ) で説明されているようなクライアントタイプを指定し,
• Section 3.1.2 (リダイレクトエンドポイント) で説明されているようなリダイレクトURIを提供し,
• 認可サーバーが要求するその他の情報 (例えばアプリケーション名, Webサイト, 説明, ロゴイメージ, 利用規則など) を提供する.

2.1.  クライアントタイプ

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

コンフィデンシャル (confidential)

クレデンシャルの機密性を維持することができるクライアント (例えば, クライアントクレデンシャルへのアクセスが制限されたセキュアサーバー上に実装されたクライアント), または他の手段を使用したセキュアなクライアント認証ができるクライアント.

パブリック (public)

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

クライアントタイプは, 認可サーバーが定めるセキュア認証の定義とクライアントクレデンシャルの許容公開レベルに基づいて決定される. 認可サーバーは, クライアントタイプに関して憶測に頼るべきではない (SHOULD NOT).

クライアントによっては, 分散された複数のコンポーネントによって実装され, それぞれのコンポーネントが異なるクライアントタイプおよびセキュリティ特性を持つ場合もある. (例: コンフィデンシャルなサーバーベースコンポーネントとパブリックなブラウザベースのコンポーネントからなるクライアントなど) 認可サーバーがこのようなクライアントをサポートしない, もしくはクライアント登録に関して何らかのガイダンスを提供していない場合, クライアントはそれぞれのコンポーネントを別のクライアントとして登録すべきである (SHOULD).

本仕様は以下のようなクライアントプロファイルを考慮して設計されている,

Webアプリケーション (web application)

Webアプリケーションは, Webサーバー上で実行されているコンフィデンシャルクライアントである. リソースオーナーは, リソースオーナーのデバイス上のユーザーエージェントにレンダリングされたHTMLユーザーインターフェイスを通してクライアントにアクセスする. クライアントに発行されたアクセストークンと同様にクライアントクレデンシャルはWebサーバー上に保存され, リソースオーナーによって公開されたりアクセス可能な状態にならない.

ユーザーエージェントベースアプリケーション (user-agent-based application)

ユーザーエージェントベースアプリケーションは, クライアントコードがWebサーバーからダウンロードされリソースオーナーのデバイス上のユーザーエージェント (例えばWebブラウザ) 内で実行されるパブリッククライアントである. プロトコルのデータとクレデンシャルはリソースオーナーに簡単にアクセス (かつ多くの場合は閲覧) できる. このようなアプリケーションはユーザーエージェント内にあるので, 認可を要求する時ユーザーエージェントの能力をシームレスに使用することができる.

ネイティブアプリケーション (native application)

ネイティブアプリケーションは, リソースオーナーのデバイス上にインストールされ実行されるパブリッククライアントである. リソースオーナーはプロトコルのデータとクレデンシャルにアクセス可能である. アプリケーションに含まれるいかなるクライアント認証用のクレデンシャルも, 抽出可能であると想定される. 一方, アクセストークンやリフレッシュトークンといった動的に発行されたクレデンシャルは許容できるレベルの保護が得られる. 少なくとも, これらのクレデンシャルはアプリケーションと対話できる悪意のあるサーバーから保護されている. プラットフォームによっては, これらのクレデンシャルは同じデバイス上に存在する他のアプリケーションからも保護されているであろう.

2.2.  クライアント識別子

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

クライアント識別子の文字列長は本仕様の定めるところではない. クライアントは識別子のサイズに関して憶測を持つべきではない. 認可サーバーは, 発行するいかなる識別子に関しても, そのサイズに関する情報を提供すべきである (SHOULD).

2.3.  クライアント認証

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

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

認可サーバーはパブリッククライアントとクライアント認証によって信頼確立してもよい (MAY). しかし, 認可サーバーはクライアントを識別する目的で, パブリッククライアントを信頼してはならない (MUST NOT).

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

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). この場合, クライアント識別子はAppendix B (Use of application/x-www-form-urlencoded Media Type)の定めるapplication/x-www-form-urlencoded形式にエンコードされ, エンコードされた値がユーザーネームとして用いられる. クライアントパスワードも同様にエンコードされ, パスワードとして利用される. 認可サーバーは, クライアントパスワードを発行されたクライアントの認証の為にHTTP Basic認証スキームをサポートしなければならない (MUST).

例 (改行は表示上の都合による):

  Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

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

client_id

必須 (REQUIRED). Section 2.2 (クライアント識別子) に示されるクライアント登録時に発行されたクライアント識別子.

client_secret

必須 (REQUIRED). クライアントのシークレット. 空の場合は省略してもよい (MAY).

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

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

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

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

パスワード認証を行う場合, 認可サーバーはSection 1.6 (TLSバージョン)にある通りTLSの利用を必須としなければならない (MUST).

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

2.3.2.  その他の認証方式

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

2.4.  未登録クライアント

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

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

認可プロセスは, 認可サーバー上の2つのエンドポイント (HTTP リソース) およびクライアント上の1つのエンドポイントを利用する. 認可サーバー上のエンドポイントは以下の通り:

• 認可エンドポイント - ユーザーエージェント経由でリソースオーナーから認可を得るためにクライアントから利用される.
• トークンエンドポイント - 認可グラントとアクセストークンを交換するために, クライアントから利用される. 通常はクライアント認証を行う.

クライアント上のエンドポイントは以下の通り:

• リダイレクトエンドポイント - リソースオーナーのユーザーエージェント経由で認可クレデンシャルを含むレスポンスをクライアント側へ返すために, 認可サーバーによって利用される.

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

3.1.  認可エンドポイント

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

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

エンドポイントURIは application/x-www-form-urlencoded (Appendix B (Use of application/x-www-form-urlencoded Media Type)) フォーマットのクエリーコンポーネント ([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 (Section 1.6 (TLSバージョン)) を利用されなければならない (MUST).

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

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

3.1.1.  レスポンスタイプ

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

response_type

必須 (REQUIRED). レスポンスタイプの値は Section 4.1.1 (認可リクエスト) で後述する認可コードをリクエストするための code あるいは, Section 4.2.1 (認可リクエスト) で後述するアクセストークン (インプリシットグラント) をリクエストする token あるいは, Section 8.4 (新たな認可エンドポイントレスポンスタイプの定義) で後述する登録されている拡張された値のいずれかでなければならない (MUST).

拡張レスポンスタイプに空白文字 (%x20) 区切りのリスト値が含まれていてもよい (MAY). なお値の順序は問題としない (例：レスポンスタイプ a b と b a は同じである). このような復号レスポンスタイプの意味は各々の仕様にて定義される.

認可リクエストで response_type がない場合, もしくは未知のレスポンスタイプであった場合, 認可サーバーは Section 4.1.2.1 (エラーレスポンス) で述べるエラーレスポンスを返さなくてはならない (MUST).

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 (Appendix B (Use of application/x-www-form-urlencoded Media Type)) フォーマットのクエリーコンポーネント ([RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) セクション3.4) を含んでもよい (MAY). クエリーパラメーターを追加する際, ここで指定されたクエリーコンポーネントは維持すること (MUST). エンドポイントURIはフラグメントコンポーネントを含んではいけない (MUST NOT).

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

リダイレクトエンドポイントは, リクエストされたレスポンスタイプが code または token である場合, およびリダイレクトリクエストによってオープンネットワーク上にセンシティブなクレデンシャルが転送されることになる場合は, Section 1.6 (TLSバージョン) に記載されているTLSを要求するべきである (SHOULD). 本仕様作成時点においてクライアントがTLS対応するのは多くの開発者にとって大きな障害となることから, 本仕様ではTLSの使用を強制はしない. TLSが利用できない場合, 認可サーバーはリダイレクト前にリソースオーナーに対して安全でないエンドポイントであることを警告するべきである (SHOULD). (例えば, 認可リクエスト時にメッセージを表示する)

トランスポート層のセキュリティの欠如は, クライアントのセキュリティ, およびアクセス認可対象の保護リソースのセキュリティに, 深刻な影響を及ぼす. トランスポート層のセキュリティは, クライアントが認可プロセスをエンドユーザー認証の委譲の為に利用する場合に, 特に重要である. (例えばサードパーティーサインインサービス)

3.1.2.2.  登録要件

認可サーバーは, 以下のようなクライアントに対してリダイレクトエンドポイントの事前登録を要求すること (MUST):

• パブリッククライアント.
• インプリシットグラントタイプを利用するコンフィデンシャルクライアント.

認可サーバーは, すべてのクライアントに対して, 認可エンドポイントアクセス前にリダイレクトURIの事前登録を要求すべきである (SHOULD).

認可サーバーは, クライアントに (一部分ではなく) 完全なリダイレクトURIの登録を要求するべきである (SHOULD). (クライアントはリクエスト毎のカスタマイズするために state リクエストパラメーターを使用できる (MAY)) 完全なリダイレクトURIの登録を要求することができない場合, 認可サーバーはURIスキーム, オーソリティー, パス (認可要求の時, リダイレクトURIのクエリーコンポーネントのみ動的に変更を許可する) の登録を要求するべきである (SHOULD).

認可サーバーはクライアントに複数のリダイレクトエンドポイントの登録を許可してもよい (MAY).

リダイレクトURI登録が不要な場合, 攻撃者に認可エンドポイントを Section 10.15 (オープンリダイレクタ) に記載されているオープンリダイレクターとして利用されてしまうおそれがある.

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コンポーネント) と比較し, 少なくとも1つと一致することを確認しなければならない (MUST). もしクライアントの登録にフルのリダイレクトURIが含まれていた場合, 認可サーバーは [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) セクション6.2.1.で定義されているように単純な文字列比較を使用し二つのURIを比較しなければいけない (MUST).

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

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

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

クライアントのリダイレクトエンドポイントへリダイレクトすると, 通常はHTMLドキュメントが返され, そのレスポンスがユーザーエージェントに処理される. リダイレクトエンドポイントから直接HTMLレスポンスが返される場合, そのHTMLドキュメントに含まれるすべてのスクリプトはリダイレクトURIとそれに含まれるクレデンシャルにアクセス権限可能となる.

クライアントはリダイレクトエンドポイントのレスポンスにどのサードパーティーのスクリプトもインクルードするべきではない (SHOULD NOT). (例えばサードパーティーのアクセス解析, ソーシャルプラグイン, アドネットワーク) そのかわりに, クライアントはURIからクレデンシャルを抽出し, クレデンシャルを (URIや他のどこかに) 露出することなくユーザーエージェントを再び別のエンドポイントへリダイレクトするべきである (SHOULD). サードパーティのスクリプトがインクルードされていた場合, クライアントは自身の (URIからクレデンシャルを取得したり取り除くための) スクリプトが最初に実行されることを保証しなくてはならない (MUST).

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

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

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

エンドポイントURIは application/x-www-form-urlencoded (Appendix B (Use of application/x-www-form-urlencoded Media Type)) フォーマットのクエリーコンポーネント ([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 (Section 1.6 (TLSバージョン)) を必須としなくてはならない (MUST).

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

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

3.2.1.  クライアント認証

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

• リフレッシュトークンおよび認可コードとその発行先のクライアントとの紐づけを強化する. 認可コードがセキュアでないチャネルを通じてリダイレクトエンドポイントに送信された場合, またはリダイレクトURIが完全に登録されていない場合, クライアント認証は非常に重要である.
• クライアントの無効化あるいはクライアントクレデンシャルの変更によって, 盗まれたリフレッシュトークンの濫用を防止するなど, なんらかの攻撃にさらされたクライアントによる被害を抑える. 一連のすべてのリフレッシュトークンを無効化するよりも, クライアントクレデンシャルの変更の方が遥かにすばやく実施できる.
• 定期的なクレデンシャルの更新など, 認証管理のベストプラクティスを実装する. 一連のすべてのリフレッシュトークンを更新するのは困難だが, クライアントクレデンシャルの更新は非常に容易である.

クライアントは, トークンエンドポイントへのリクエスト時に自身を識別するために, client_id パラメーターを用いてもよい (MAY). トークンエンドポイントへのリクエスト時に authorization_code grant_type を指定する場合, 認証を行わないクライアントは, リクエストに client_id を含み, 異なる client_id に対して発行されたコードを不用意に受け入れてしまうことを防がなければならない (MUST). これはクライアントに対する認可コード置換攻撃への対策となる (保護リソースに対してのセキュリティ対策は提供していない).

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

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

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

  scope       = scope-token *( SP scope-token )
  scope-token = 1*( %x21 / %x23-5B / %x5D-7E )

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

認可リクエスト時にクライアントがスコープパラメーターを省略した場合, 認可サーバーは事前に定義されたデフォルト値が指定されたものとするか, 無効なスコープを意味しているものとしてリクエスト失敗とするかのどちらかを処理しなければならない (MUST). 認可サーバーはスコープ要件と (もし定義されていれば) デフォルト値をドキュメント化するべきである (SHOULD).

4.  認可の取得

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

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)

注記: (A), (B), (C) のステップを表す線はユーザーエージェント経由で渡されるため２つに分かれている.

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

(A)

クライアントがリソースオーナーのユーザーエージェントを認可エンドポイントに送ることで, フローが開始する. このときクライアントは, クライアント識別子, リクエストスコープ, ローカルステート, および認可サーバーがアクセス許可 (あるいは拒否) 取得後にユーザーエージェントを戻すリダイレクトURIをリクエストに含める.

(B)

認可サーバーは (ユーザーエージェント経由で) リソースオーナーを認証し, リソースオーナーにアクセス要求の許可/拒否をたずねる.

(C)

リソースオーナーがアクセスを許可した場合, 認可サーバーは予め与えられていた (リクエストもしくはクライアント登録時に指定される) リダイレクトURIを用いて, ユーザーエージェントをリダイレクトさせてクライアントに戻す. リダイレクトURIには, 認可コード, クライアントから事前に送られたローカルステートが含まれる.

(D)

クライアントは前のステップで取得した認可コードを認可サーバーのトークンエンドポイントに送ることでアクセストークンを要求する. このとき, クライアントは認可サーバーとの間で認証を行う. またクライアントは認可コード取得時に使用したリダイレクトURIを検証のためリクエストに含める.

(E)

認可サーバーはクライアントを認証し, 認可コードを検証し, 受け取ったリダイレクトURIがステップ (C) で使用したURIと同一であることを確かめる. その結果, 正当である場合, 認可サーバーはアクセストークンと任意でリフレッシュトークンを返却する.

4.1.1.  認可リクエスト

クライアントは, Appendix B (Use of application/x-www-form-urlencoded Media Type) で規定された 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にユーザーエージェントを送る.

4.1.2.  認可レスポンス

リソースオーナーがアクセスリクエストを許可した場合, 認可サーバーは認可コードを発行し, application/x-www-form-urlencoded (Appendix B (Use of application/x-www-form-urlencoded Media Type)) フォーマットを用いてリダイレクト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

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

4.1.2.1.  エラーレスポンス

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

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

error

必須 (REQUIRED). 次のASCII ([USASCII] (American National Standards Institute, “Coded Character Set -- 7-bit American Standard Code for Information Interchange,” 1986.)) で表されるエラーコードの中の1つ:

invalid_request

リクエストに必須パラメーターが含まれていない, サポート外のパラメーターが付与されている, 同一のパラメーターが複数含まれる場合, その他不正な形式であった場合もこれに含まれる.

unauthorized_client

クライアントは現在の方法で認可コードを取得することを認可されていない.

access_denied

リソースオーナーまたは認可サーバーがリクエストを拒否した

unsupported_response_type

認可サーバーは現在の方法による認可コード取得をサポートしていない.

invalid_scope

リクエストスコープが不正, 未知, もしくはその他の不当な形式である.

server_error

認可サーバーがリクエストの処理ができないような予期しない状況に遭遇した. (500 Internal Server Error のHTTPステータスコードをHTTPのリダイレクトでクライアントに返すことができないため, このエラーコードは必要である)

temporarily_unavailable

認可サーバーが一時的な過負荷やメンテナンスによってリクエストを扱うことが出来ない. (503 Service Unavailable のHTTPステータスコードをHTTPのリダイレクトでクライアントに返すことができないため, このエラーコードは必要である)

error パラメーター値は %x20-21 / %x23-5B / %x5D-7E 以外の文字セットを含んではならない (MUST NOT).

error_description

任意 (OPTIONAL). クライアント開発者が発生したエラーを理解する際の手助けとなる, 可読性のあるASCII ([USASCII] (American National Standards Institute, “Coded Character Set -- 7-bit American Standard Code for Information Interchange,” 1986.)) 文字列で表される追加情報.
error_description パラメーター値は %x20-21 / %x23-5B / %x5D-7E 以外の文字セットを含んではならない (MUST NOT).

error_uri

任意 (OPTIONAL). クライアント開発者が発生したエラーに関する追加の情報を得ることができるWebページのURI.
error_uri パラメーター値はURI構文に従い (MUST), %x21 / %x23-5B / %x5D-7E 以外の文字セットを含んではならない (MUST NOT).

state

state パラメーターがクライアントからの認可リクエストに含めれていた場合は必須 (REQUIRED). クライアントから受け取った値をそのまま返す.

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

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

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

クライアントはトークンエンドポイントに対して, 次のようなパラメーターを付与してリクエストを送信する. パラメーターはHTTPリクエストのエンティティーボディにUTF-8でそれぞれエンコード (Appendix B (Use of application/x-www-form-urlencoded Media Type)) して application/x-www-form-urlencoded フォーマットで含める.

grant_type

必須 (REQUIRED). 値は authorization_code でなければならない (MUST).

code

必須 (REQUIRED). 認可サーバーから受け取った認可コード.

redirect_uri

Section 4.1.1 (認可リクエスト) で示す認可リクエストに, redirect_uri パラメーターが含まれていた場合は必須 (REQUIRED). 認可リクエスト時と同じ値でなければならない (MUST).

client_id

Section 3.2.1 (クライアント認証) で示すように認可サーバーよってクライアントが認証されていなければ必須 (REQUIRED) .

クライアントタイプがコンフィデンシャルである場合, あるいはクライアントクレデンシャルが発行された (もしくはその他の認証が要求された) クライアントの場合は, 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

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

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

• コンフィデンシャルクライアント, あるいはクライアントクレデンシャルが発行された (もしくはその他の認証が要求された) クライアントにクライアント認証を要求する.
• クライアントの認証情報が含まれていた場合はクライアントを認証する.
• クライアントがコンフィデンシャルクライアントの場合は, 認可コードが確かに認証されたクライアントに対して発行されたことを確認する. クライアントがパブリッククライアントの場合は, 認可コードが確かに指定された client_id に紐づくクライアントに対して発行されていることを確認する.
• 認可コードが正当であることを検証する.
• Section 4.1.1 (認可リクエスト) で述べた認可リクエスト時に redirect_uri パラメータが含まれていた場合, ここでも redirect_uri が存在し認可リクエスト時と同じ値であることを確認する.

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"
  }

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 |
  |         |
  +---------+

注記: ユーザーエージェントを通過するため, Step (A) と (B) を示す線は2つに分かれる.

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

(A)

クライアントがリソースオーナーのユーザーエージェントを認可エンドポイントに送ることで, フローが開始する. このときクライアントは, クライアント識別子, リクエストスコープ, ローカルステート, および認可サーバーがアクセス許可取得後にユーザーエージェントを戻すリダイレクトURIをリクエストに含める.

(B)

認可サーバーは (ユーザーエージェントを通して) リソースオーナーを認証し, リソースオーナーにアクセス要求の許可/拒否をたずねる.

(C)

リソースオーナーがアクセスを許可した場合, 認可サーバーは予め与えられていたリダイレクトURIを用いて, ユーザーエージェントをリダイレクトさせてクライアントに戻す. リダイレクトURIには, アクセストークンが含まれる.

(D)

ユーザーエージェントは, リダイレクトの指示に従い, Web上にホストされたクライアントリソースにリクエストを送信する (このときフラグメントは送信されない.[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.)を参照). ユーザーエージェントはフラグメントの情報をローカルに保持する.

(E)

Webでホストされたクライアントリソースにアクセスすると, Webページ (通常, 埋め込みのスクリプトが含まれるHTMLドキュメント) が返される. そのWebページでは, ユーザーエージェントによって保持されているフラグメントを含む完全なリダイレクトURLにアクセスし, フラグメントに含まれているアクセストークン (とその他のパラメーター) を取り出すことができる.

(F)

ユーザーエージェントは上記Webページに含まれるスクリプトをローカルに実行し, アクセストークンを取り出す.

(G)

ユーザーエージェントはアクセストークンをクライアントに渡す.

インプリシットグラントを利用する背景については1.3.2 (インプリシット)と 9 (ネイティブアプリケーション)セクションを参照のこと. インプリシットグラントを利用するときの重要なセキュリティ面での考慮点については10.3 (アクセストークン) と10.16 (インプリシットフローにおけるリソースオーナーなりすましのためのアクセストークン不正利用)セクションを参照のこと.

4.2.1.  認可リクエスト

クライアントは, Appendix B (Use of application/x-www-form-urlencoded Media Type) に従い 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にユーザーエージェントを送る.

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

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

access_token

必須 (REQUIRED). 認可サーバーによって発行されたアクセストークン.

token_type

必須 (REQUIRED). 詳細は Section 7.1 (アクセストークンタイプ) を参照のこと. 大文字・小文字は区別しない.

expires_in

推奨 (RECOMMENDED). アクセストークンの有効期間を秒で表したもの. 例えばこの値が 3600 であれば, そのアクセストークンは発行から1時間後に期限切れとなる. 省略された場合, 認可サーバは他の手段を用いて終了時間を提供するか初期値を明記すべきである (SHOULD).

scope

クライアントによって要求された scope と同一の場合は任意 (OPTIONAL). その他の場合は必須 (REQUIRED). 詳細は Section 3.3 (アクセストークンのスコープ) を参照のこと.

state

クライアントの認可リクエストに state が含まれていた場合は必須 (REQUIRED). クライアントから受け取った値をそのまま返す.

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

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

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

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

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

4.2.2.1.  エラーレスポンス

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

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

error

必須 (REQUIRED). 次の中の1つのアスキー [USASCII] (American National Standards Institute, “Coded Character Set -- 7-bit American Standard Code for Information Interchange,” 1986.) エラーコード:

invalid_request

リクエストに必要なパラメーターが含まれていない. 不正なパラメーターが付与されていた場合や, パラメータが複数回指定されていた場合, その他不正な形式であった場合もこれに含まれる.

unauthorized_client

クライアントは現在の方法でアクセストークンを取得することを認可されていない.

access_denied

リソースオーナーまたは認可サーバーがリクエストを拒否した.

unsupported_response_type

認可サーバーは現在の方法によるアクセストークン取得をサポートしていない.

invalid_scope

リクエストスコープが不正, 未知, もしくはその他の不当な形式である.

server_error

認可サーバーがリクエストの処理ができないような予期しない状況に遭遇した. (このエラーコードはHTTPステータスコード500 Internal Server ErrorがHTTPリダイレクトではクライアントへ返されないため必要である)

temporarily_unavailable

認可サーバーが一時的な過負荷やメンテナンスによってリクエストを扱うことが出来ない. (このエラーコードはHTTPステータスコード503 Service UnavailabeがHTTPリダイレクトではクライアントへ返されないため必要である)

error パラメータの値は %x20-21 / %x23-5B / %x5D-7E 以外の文字を含んではならない (MUST NOT).

error_description

任意 (OPTIONAL). クライアント開発者が発生したエラーを理解する際の手助けとなる, ASCII [USASCII] (American National Standards Institute, “Coded Character Set -- 7-bit American Standard Code for Information Interchange,” 1986.) の可読性のある追加情報.
error_description パラメータの値は %x20-21 / %x23-5B / %x5D-7E 以外の文字を含んではならない (MUST NOT).

error_uri

任意 (OPTIONAL). クライアント開発者が発生したエラーに関する追加の情報を得ることができるWebページのURI.
error_uri パラメータの値は%x21 / %x23-5B / %x5D-7E 以外の文字を含んではならない (MUST NOT).

state

もし state パラメーターがクライアントからの認可リクエストに含めれている場合は必須 (REQUIRED). クライアントから受け取った値をそのまま返す.

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

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

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 (リソースオーナーパスワードクレデンシャルフロー) のフローは以下の通りである.

(A)

リソースオーナーはクライアントにユーザー名とパスワードを提供する.

(B)

クライアントは認可サーバーのトークンエンドポイントにリソースオーナーから取得したクレデンシャルを含めることでアクセストークンを要求する. リクエストを生成する際に, クライアントは認可サーバーによって認証される.

(C)

認可サーバーはクライアントを認証し, リソースオーナーのクレデンシャルを検証する. もし有効であればアクセストークンを発行する.

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

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

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

クライアントは, 下記のパラメーターを Appendix B (Use of application/x-www-form-urlencoded Media Type) に従い application/x-www-form-urlencoded フォーマットでHTTPリクエストボディーに含め, UTF-8でエンコードして, リクエストを構築する.

grant_type

必須 (REQUIRED). 値には password を指定しなければならない (MUST).

username

必須 (REQUIRED). リソースオーナーのユーザーネーム.

password

必須 (REQUIRED). リソースオーナーのパスワード.

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

  grant_type=password&username=johndoe&password=A3ddj3w

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

• コンフィデンシャルクライアント, あるいはクライアントクレデンシャルが発行された (もしくはその他の認証が要求された) クライアントにクライアント認証を要求し,
• クライアントの認証情報が含まれていた場合はクライアントを認証し,
• 既存のパスワード確認のアルゴリズムを用いてリソースオーナーパスワードクレデンシャルの妥当性を確認する

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

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"
  }

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

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

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

  +---------+                                  +---------------+
  |         |                                  |               |
  |         |>--(A)- Client Authentication --->| Authorization |
  | Client  |                                  |     Server    |
  |         |<--(B)---- Access Token ---------<|               |
  |         |                                  |               |
  +---------+                                  +---------------+

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

(A)

クライアントは自身の認証情報を含めてトークンエンドポイントにアクセストークンリクエストを送る.

(B)

認可サーバーはクライアントを認証し, 認証に成功すればアクセストークンを発行する.

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

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

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

クライアントは, HTTPリクエストボディーに Appendix B (Use of application/x-www-form-urlencoded Media Type) に従い application/x-www-form-urlencoded フォーマットで下記のパラメーターを追加し, UTF-8でエンコードして, トークンエンドポイントにリクエストを送る.

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

  grant_type=client_credentials

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

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"
  }

4.5.  拡張グラント

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

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

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

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

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

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

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

5.1.  成功レスポンス

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

access_token

必須 (REQUIRED). 認可サーバーが発行するアクセストークン.

token_type

必須 (REQUIRED). トークンのタイプ. 値は大文字・小文字を区別しない. 詳細は Section 7.1 (アクセストークンタイプ) を参照のこと.

expires_in

推奨 (RECOMMENDED). アクセストークンの有効期間を表す秒数. 例えばこの値が 3600 であれば, そのアクセストークンは発行から1時間後に期限切れとなる. 省略された場合, 認可サーバはドキュメントまたは他の手段によってデフォルトの有効期間を提示すべきである (SHOULD).

refresh_token

任意 (OPTIONAL). リフレッシュトークン. 同じ認可グラントを用いて新しいアクセストークンを取得するのに利用される. 詳細は Section 6 (アクセストークンの更新) を参照のこと.

scope

クライアントから全く同一のスコープが要求された場合は任意 (OPTIONAL). その他は必須 (REQUIRED). アクセストークンのスコープ. 詳細は Section 3.3 (アクセストークンのスコープ) を参照のこと.

これらのパラメーターは, [RFC4627] (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) で定義されているメディアタイプ application/json 形式で, HTTPレスポンスボディーに含まれる. JavaScript Object Notation (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"
  }

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

5.2.  エラーレスポンス

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

error

必須 (REQUIRED). 以下のASCII [USASCII] (American National Standards Institute, “Coded Character Set -- 7-bit American Standard Code for Information Interchange,” 1986.) エラーコードより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 パラメータの値は %x20-21 / %x23-5B / %x5D-7E 以外の文字を含んではならない (MUST NOT).

error_description

任意 (OPTIONAL). クライアント開発者が発生したエラーを理解する際の手助けとなる, 可読性のあるASCII [USASCII] (American National Standards Institute, “Coded Character Set -- 7-bit American Standard Code for Information Interchange,” 1986.)テキストの追加情報.
error_description パラメータの値は %x20-21 / %x23-5B / %x5D-7E 以外の文字を含んではならない (MUST NOT).

error_uri

任意 (OPTIONAL). クライアント開発者が発生したエラーに関する追加の情報を得ることができるWebページのURI.
error_uri パラメータの値はURI参照でなければならない(MUST). また, それ故に%x21 / %x23-5B / %x5D-7E 以外の文字を含んではならない (MUST NOT).

これらのパラメーターは, [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"
  }

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

認可サーバーがクライアントにリフレッシュトークンを発行していれば, クライアントはトークンエンドポイントに更新リクエストを送ることができる. 以下のパラメーターが Appendix B (Use of application/x-www-form-urlencoded Media Type)によるapplication/x-www-form-urlencoded 形式で, UTF-8エンコードされて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

  grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

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

• コンフィデンシャルクライアント, あるいはクライアントクレデンシャルが発行された (もしくはその他の認証が要求された) クライアントにクライアント認証を要求し,
• クライアントの認証情報が含まれていた場合はクライアントを認証し, リフレッシュトークンが確かにそのクライアントに対して発行されたものであることを確認し,
• リフレッシュトークンを検証する.

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

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

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

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

クライアントがリソースサーバーの認証を受けるためにどのようにアクセストークンを用いるかは, リソースサーバーから払い出されたアクセストークンのタイプに依存する. 一般的には, [RFC6750] (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.)のようなアクセストークンタイプの仕様に定義される認証スキームに従って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.) が利用される.

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

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

例えば, [RFC6750] (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) に定義される bearer トークンタイプでは, 単にリクエストにアクセストークンを含めるだけでよい.

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

一方, [OAuth‑HTTP‑MAC] (Hammer-Lahav, E., Ed., “HTTP Authentication: MAC Access Authentication,” February 2012.) に定義される mac トークンタイプでは, アクセストークンと共にMessage Authentication Code (MAC)キーを発行する. このMACキーはHTTPリクエストの一部分を署名するのに利用される.

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

尚, 上記はあくまで参考例であり, 開発者は利用前に [RFC6750] (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) や [OAuth‑HTTP‑MAC] (Hammer-Lahav, E., Ed., “HTTP Authentication: MAC Access Authentication,” February 2012.) を参照することが推奨される.

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

7.2.  エラーレスポンス

リソースアクセスに失敗した場合, リソースサーバーはクライアントにエラーを通知すべきである (SHOULD). このようなエラーに関する詳細については本仕様の範疇外であるが, エラーの値はOAuthトークン認証スキームで共有されるため, 本ドキュメントではSection 11.4 (OAuth拡張エラーレジストリー)で共有レジストリを設置している.

主にOAuthトークン認証のために設計された新しい認証スキームでは, エラーの値を本仕様によって設置されているエラーレジストリに登録することを考慮した上で, エラーステータスコードをクライアントに提示するためのメカニズムを定義すべきである (SHOULD). そのようなスキームは有効なエラーコードのセットを登録されている値のサブセットに制限してもよい (MAY). エラーコードが名前付きパラメータで返却された場合, そのパラメータ名はerrorにすべきである(SHOULD).

OAuthトークン認証にも使えるが, 主とする目的のためには設計されていない他のスキームについては, 同様の方法でエラーの値を登録してもよい(MAY).

新しい認証スキームは, 本仕様と同様の方法によって, エラー情報を返却するためにerror_descriptionとerror_uriパラメータを選択してもよい(MAY).

8.  仕様の拡張性

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

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

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

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

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

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

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

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

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 としては登録することはできないが, 両方の値は同じレスポンスタイプを示すために使うことが出来る.

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

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

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

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

  error      = 1*error-char
  error-char = %x20-21 / %x23-5B / %x5D-7E

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

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

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

• 外部のユーザーエージェント - ネイティブアプリケーションは, クライアントを起動するためのハンドラとしてオペレーションシステムに登録したスキームをリダイレクトURIにして利用する, クレデンシャルをコピーアンドペーストする, ローカルのWebサーバーを利用する, ユーザーエクステンションをインストールする, クライアントの管理下にあるサーバー上のリソースをリダイレクトURIとして利用するなど, ネイティブアプリケーションがレスポンスにアクセスすることを可能にする手段を用いて, 認可サーバーからのレスポンスを取得することができる.
• 埋め込まれたユーザーエージェント - ネイティブアプリケーションは, リソースを読み込んでいる間に発生した状態変更の監視やユーザーエージェントのクッキーストレージへのアクセスなど, 埋め込まれたユーザーエージェントとの直接通信によりレスポンスを受け取ることができる.

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

• 認可サーバーが再認証を要求しない仕様になっており, かつリソースオーナーがアクティブセッションを保有している場合, 外部のユーザーエージェントは完了率をあげるかもしれない. それは慣れ親しんだエンドユーザー体験と機能性を提供する. リソースオーナーはまた認証を手助けするユーザーエージェントの機能や拡張 (パスワードマネージャ, 2要素のリーダー装置) に頼ることができる.
• 埋め込みのユーザーエージェントはコンテキストの切り替えと新しいウィンドウオープンを取り除くことで, ユーザービリティを向上させることができるかもしれない.
• リソースオーナーはほとんどの外部ユーザーエージェントで見られる視覚的な保護機能にアクセスすることなく未確認のウィンドウ内で認証するため, 埋め込みのユーザーエージェントはセキュリティ問題を引き起こす. 埋め込みのユーザーエージェントは (フィッシング攻撃が簡単に実行できる) 未確認の認証要求を信用するようエンドユーザーに刷り込んでしまう.

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

• ネイティブアプリケーションはその性質上クライアントクレデンシャルを秘匿に保てないため, 認可コードグラントタイプを利用するネイティブアプリケーションはクライアントクレデンシャルを使うべきではない (SHOULD).
• インプリシットグラントタイプのフローを利用すると, リフレッシュトークンは返されないため, アクセストークンの期限が切れるたびに認可プロセスを繰り返す必要がある.

10.  Security Considerations

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

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

10.1.  クライアント認証

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

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

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

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

10.2.  クライアント偽装

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

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

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

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

10.3.  アクセストークン

アクセストークンクレデンシャル (およびあらゆる秘匿アクセストークン属性) は, 通信経路・ストレージ上ともに機密に保たれなければならない (MUST). またそれらの情報は, 認可サーバー, アクセストークンが通用するリソースサーバー, およびアクセストークンを発行されたクライアントの間でのみ共有される (MUST). アクセストークンクレデンシャルは Section 1.6 (TLSバージョン) にあるTLSを用いて [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) で定義されているサーバー認証をした上で送信されなければならない (MUST).

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

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

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

この仕様は, 提示されたアクセストークンが認可サーバーから提示元のクライアントに発行されたことを確認するいかなる方法もリソースサーバーに提供しない.

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

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

リフレッシュトークンは通信経路・ストレージ上ともに機密に保たれ, 認可サーバーとリフレッシュトークン発行先クライアントの間のみで共有されなければならない (MUST). 認可サーバーは, どのリフレッシュトークンがどのクライアントに発行されたかを記録しておかなくてはならない (MUST). リフレッシュトークンは Section 1.6 (TLSバージョン) にあるTLSを用いて [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) で定義されているサーバー認証をした上で送信されなければならない (MUST).

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

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

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

10.5.  認可コード

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.8.  リクエストの機密性

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

state, scope パラメータは安全ではないチャンネル上で伝送される, もしくは安全ではない方法でに保存されることがあるため, クライアントやリソースオーナーのセンシティブな情報をプレインテキスト内に含むべきではない (SHOULD NOT).

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

man-in-the-middle アタックを防ぐため, 認可サーバーは TLS を導入し, [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) に従って認可エンドポイントおよびトークンエンドポイントへのすべてのリクエストで TLS を利用したサーバー認証を必須としなければならない (MUST). クライアントはサーバー身元認証の要件に従い, [RFC6125] (Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.) で定義されている認可サーバーのTLS 証明書の検証を行わなければならない (MUST).

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

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

攻撃者が生成されたトークン (とエンドユーザーにより扱われないその他のクレデンシャル) を推測する可能性は 2^(-128) 以下にしなければならず (MUST), 2^(-160) 以下にすべきである (SHOULD).

エンドユーザーが扱うクレデンシャルについては, 認可サーバーはその他の保護対策を行わなければならない (MUST).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.16.  インプリシットフローにおけるリソースオーナーなりすましのためのアクセストークン不正利用

インプリシットフローを利用するパブリッククライアントについて, この仕様はアクセストークンがどのクライアントに発行されたかを特定する方法をクライアントに提供しない.

リソースオーナーは攻撃者の悪意のあるクライアントにアクセストークンを許可することにより, 進んでリソースへのアクセスを委任するかもしれない. これはフィッシングまたは何か他の詐欺が原因となるかもしれない. 攻撃者はまた, なんらかのメカニズムでトークンを盗むかもしれない. それから, 攻撃者は正当なパブリッククライアントへのアクセストークンを提供することでリソースオーナーへのなりすましを試みるかもしれない.

インプリシットフロー (response_type=token) では, 攻撃者は認可サーバーからのレスポンスに含まれるトークンを簡単に変更し, 以前攻撃者自身に発行された実際のアクセストークンに置き換えることができる.

アクセストークンを差し込める信用できないアプリケーションを作成する攻撃者により, クライアントのユーザーを特定するためにネイティブアプリケーションと通信しバックチャネルでアクセストークンを受け取っているサーバーは同様の危険性を持つ.

リソースオーナーだけがそのリソースに対する有効なアクセストークンを提示できると仮定されるいかなるパブリッククライアントも, このタイプの攻撃に対して脆弱である.

このタイプの攻撃は正当なクライアントでリソースオーナーの情報を攻撃者 (悪意のあるクライアント) に公開するかもしれない. これはまた, 合法なクライアントにて攻撃者にもともとアクセストークンもしくは認可コードを与えられたリソースオーナーと同等の資格で活動することを許可する.

クライアントへのリソースオーナー認証方法はこの仕様の範囲外である. ユーザー認証をクライアント (3rdパーティーサインインサービスなど) に委任する認可プロセスを使用するどんな仕様でも, アクセストークンがその使用のために発行されたかどうか特定するためのセキュリティメカニズム (オーディエンス制限のあるアクセストークン) の追加なしにインプリシットフローを利用してはならない (MUST NOT).

11.  IANA Considerations

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

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

アクセストークンのタイプは, 1名以上の Designated Experts の勧告に従い, oauth-ext-review@ietf.org のメーリングリストで14日間の審査期間を経て, 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") で oauth-ext-review@ietf.org のメーリングリストに通知すべきであり, そこでレビューとコメントが行われる.

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

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

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 が記載されていることが望ましい. 明確な記載箇所への参照が含まれることが望ましいが必須ではない.

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

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

認可エンドポイントリクエスト, 認可エンドポイントレスポンス, トークンエンドポイントリクエスト, トークンエンドポイントレスポンスに含める追加のパラメーターは, 1名以上の Designated Experts の勧告に従い, oauth-ext-review@ietf.org のメーリングリストで14日間の審査期間を経て, 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") で oauth-ext-review@ietf.org のメーリングリストに通知すべきであり, そこでレビューとコメントが行われる.

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

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

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

Parameter name:

名称 (例: "example").

Parameter usage location:

パラメーターが利用できる箇所. 想定される箇所は以下の通り: 認可リクエスト, 認可レスポンス, トークンリクエスト, トークンリクエスト.

Change controller:

RFCの標準に従う際は, "IETF"と記載する. それ以外の場合は, 責任ある団体の名称を記載する. その他の詳細 (例えば, 郵便番号, メールアドレス, ホームページのURL) も記載してもよい.

Specification document(s):

パラメーター仕様を記載したドキュメントへの参照を記載する. ドキュメントを取得することのできる URI が記載されていることが望ましい. 明確な記載箇所への参照が含まれることが望ましいが必須ではない.

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

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

• Parameter name: client_id
• Parameter usage location: authorization request, token request
• Change controller: IETF
• Specification document(s): RFC 6749

• Parameter name: client_secret
• Parameter usage location: token request
• Change controller: IETF
• Specification document(s): RFC 6749

• Parameter name: response_type
• Parameter usage location: authorization request
• Change controller: IETF
• Specification document(s): RFC 6749

• Parameter name: redirect_uri
• Parameter usage location: authorization request, token request
• Change controller: IETF
• Specification document(s): RFC 6749

• Parameter name: scope
• Parameter usage location: authorization request, authorization response, token request, token response
• Change controller: IETF
• Specification document(s): RFC 6749

• Parameter name: state
• Parameter usage location: authorization request, authorization response
• Change controller: IETF
• Specification document(s): RFC 6749

• Parameter name: code
• Parameter usage location: authorization response, token request
• Change controller: IETF
• Specification document(s): RFC 6749

• Parameter name: error_description
• Parameter usage location: authorization response, token response
• Change controller: IETF
• Specification document(s): RFC 6749

• Parameter name: error_uri
• Parameter usage location: authorization response, token response
• Change controller: IETF
• Specification document(s): RFC 6749

• Parameter name: grant_type
• Parameter usage location: token request
• Change controller: IETF
• Specification document(s): RFC 6749

• Parameter name: access_token
• Parameter usage location: authorization response, token response
• Change controller: IETF
• Specification document(s): RFC 6749

• Parameter name: token_type
• Parameter usage location: authorization response, token response
• Change controller: IETF
• Specification document(s): RFC 6749

• Parameter name: expires_in
• Parameter usage location: authorization response, token response
• Change controller: IETF
• Specification document(s): RFC 6749

• Parameter name: username
• Parameter usage location: token request
• Change controller: IETF
• Specification document(s): RFC 6749

• Parameter name: password
• Parameter usage location: token request
• Change controller: IETF
• Specification document(s): RFC 6749

• Parameter name: refresh_token
• Parameter usage location: token request, token response
• Change controller: IETF
• Specification document(s): RFC 6749

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

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

認可エンドポイントで利用される追加のレスポンスタイプは, 1名以上の Designated Experts の勧告に従い, oauth-ext-review@ietf.org のメーリングリストで14日間の審査期間を経て, 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 のメーリングリストに通知すべきであり, そこでレビューとコメントが行われる.

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

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

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

Response type name:

名称 (例: "example").

Change controller:

RFCの標準に従う際は, "IETF"と記載する. それ以外の場合は, 責任ある団体の名称を記載する. その他の詳細 (例えば, 郵便番号, メールアドレス, ホームページのURL) も記載してもよい.

Specification document(s):

パラメーター仕様を記載したドキュメントへの参照を記載する. ドキュメントを取得することのできるURIが記載されていることが望ましい. 明確な記載箇所への参照が含まれることが望ましいが必須ではない.

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

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

• Response type name: code
• Change controller: IETF
• Specification document(s): RFC 6749

• Response type name: token
• Change controller: IETF
• Specification document(s): RFC 6749

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

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

他のプロトコル拡張 (例えば, 拡張グラントタイプ, アクセストークンタイプ, もしくは拡張パラメーター) で利用される追加のエラーコードは, 1名以上の Designated Experts の勧告に従い, oauth-ext-review@ietf.org のメーリングリストで14日間の審査期間を経て, Specification Required [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) な状態で登録される. しかしながら, 発行に先立ってそれらの値を割り当てることができるように, Designated Experts はそれらの値が公開できる状態になった時点で登録を許可することもありうる.

登録要請は, 適切な件名 (例: "Request for error code: example") で oauth-ext-review@ietf.org のメーリングリストに通知すべきであり, そこでレビューとコメントが行われる.

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

IANA は, Designated Experts によるすべてのレジストリー更新要請を承認し, すべての登録要請をレビューメーリングリストに送信されなければならない.

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

Error name:

名称 (例: "example"). エラーの名称の値には %x20-21 / %x23-5B / %x5D-7E 以外の文字を含んではいけない.

Error usage location:

エラーが利用できる箇所. 想定される箇所は以下の通り: 認可コード付与エラーレスポンス (Section 4.1.2.1 (エラーレスポンス)), インプリシット付与エラーレスポンス (Section 4.2.2.1 (エラーレスポンス)), トークンエラーレスポンス (Section 5.2 (エラーレスポンス)), リソースアクセスエラーレスポンス (Section 7.2 (エラーレスポンス)).

Related protocol extension:

エラーコードと共に用いられる拡張グラントタイプ名, アクセストークンタイプ名, もしくは拡張パラメーター名を記載する.

Change controller:

RFCの標準に従う際は, "IETF"と記載する. それ以外の場合は, 責任ある団体の名称を記載する. その他の詳細 (例えば, 郵便番号, メールアドレス, ホームページのURL) も記載してもよい.

Specification document(s):

エラーコード仕様を記載したドキュメントへの参照を記載する. ドキュメントを取得することのできるURIが記載されていることが望ましい. 明確な記載箇所への参照が含まれることが望ましいが必須ではない.

12.  References

12.1. Normative References

12.2. Informative References

12.3. 翻訳プロジェクト

Appendix A.  Augmented Backus-Naur Form (ABNF) Syntax

This section provides Augmented Backus-Naur Form (ABNF) syntax descriptions for the elements defined in this specification using the notation of [RFC5234] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.). The ABNF below is defined in terms of Unicode code points [W3C.REC‑xml‑20081126] (Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, “Extensible Markup Language (XML) 1.0 (Fifth Edition),” November 2008.); these characters are typically encoded in UTF-8. Elements are presented in the order first defined.

Some of the definitions that follow use the URI-reference definition from [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.).

Some of the definitions that follow use these common definitions:

  VSCHAR     = %x20-7E
  NQCHAR     = %x21 / %x23-5B / %x5D-7E
  NQSCHAR    = %x20-21 / %x23-5B / %x5D-7E
  UNICODECHARNOCRLF = %x09 /%x20-7E / %x80-D7FF /
                      %xE000-FFFD / %x10000-10FFFF

(The UNICODECHARNOCRLF definition is based upon the Char definition in Section 2.2 of [W3C.REC‑xml‑20081126] (Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, “Extensible Markup Language (XML) 1.0 (Fifth Edition),” November 2008.), but omitting the Carriage Return and Linefeed characters.)

A.1.  "client_id" Syntax

The client_id element is defined in Section 2.3.1 (クライアントパスワード):

  client-id     = *VSCHAR

A.2.  "client_secret" Syntax

The client_secret element is defined in Section 2.3.1 (クライアントパスワード):

  client-secret = *VSCHAR

A.3.  "response_type" Syntax

The response_type element is defined in Sections 3.1.1 (レスポンスタイプ) and 8.4 (新たな認可エンドポイントレスポンスタイプの定義):

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

A.4.  "scope" Syntax

The scope element is defined in Section 3.3 (アクセストークンのスコープ):

  scope       = scope-token *( SP scope-token )
  scope-token = 1*NQCHAR

A.5.  "state" Syntax

The state element is defined in Sections 4.1.1 (認可リクエスト), 4.1.2 (認可レスポンス), 4.1.2.1 (エラーレスポンス), 4.2.1 (認可リクエスト), 4.2.2 (アクセストークンレスポンス), and 4.2.2.1 (エラーレスポンス):

  state      = 1*VSCHAR

A.6.  "redirect_uri" Syntax

The redirect_uri element is defined in Sections 4.1.1 (認可リクエスト), 4.1.3 (アクセストークンリクエスト), and 4.2.1 (認可リクエスト):

  redirect-uri      = URI-reference

A.7.  "error" Syntax

The error element is defined in Sections 4.1.2.1 (エラーレスポンス), 4.2.2.1 (エラーレスポンス), 5.2 (エラーレスポンス), 7.2 (エラーレスポンス), and 8.5 (追加のエラーコードの定義):

  error             = 1*NQSCHAR

A.8.  "error_description" Syntax

The error_description element is defined in Sections 4.1.2.1 (エラーレスポンス), 4.2.2.1 (エラーレスポンス), 5.2 (エラーレスポンス), and 7.2 (エラーレスポンス):

  error-description = 1*NQSCHAR

A.9.  "error_uri" Syntax

The error_uri element is defined in Sections 4.1.2.1 (エラーレスポンス), 4.2.2.1 (エラーレスポンス), 5.2 (エラーレスポンス), and 7.2 (エラーレスポンス):

  error-uri         = URI-reference

A.10.  "grant_type" Syntax

The grant_type element is defined in Sections 4.1.3 (アクセストークンリクエスト), 4.3.2 (アクセストークンリクエスト), 4.4.2 (アクセストークンリクエスト), 4.5 (拡張グラント), and 6 (アクセストークンの更新):

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

A.11.  "code" Syntax

The code element is defined in Section 4.1.3 (アクセストークンリクエスト):

  code       = 1*VSCHAR

A.12.  "access_token" Syntax

The access_token element is defined in Sections 4.2.2 (アクセストークンレスポンス) and 5.1 (成功レスポンス):

  access-token = 1*VSCHAR

A.13.  "token_type" Syntax

The token_type element is defined in Sections 4.2.2 (アクセストークンレスポンス), 5.1 (成功レスポンス), and 8.1 (アクセストークンタイプの定義):

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

A.14.  "expires_in" Syntax

The expires_in element is defined in Sections 4.2.2 (アクセストークンレスポンス) and 5.1 (成功レスポンス):

  expires-in = 1*DIGIT

A.15.  "username" Syntax

The username element is defined in Section 4.3.2 (アクセストークンリクエスト):

  username = *UNICODECHARNOCRLF

A.16.  "password" Syntax

The password element is defined in Section 4.3.2 (アクセストークンリクエスト):

  password = *UNICODECHARNOCRLF

A.17.  "refresh_token" Syntax

The refresh_token element is defined in Sections 5.1 (成功レスポンス) and 6 (アクセストークンの更新):

  refresh-token = 1*VSCHAR

A.18.  Endpoint Parameter Syntax

The syntax for new endpoint parameters is defined in Section 8.2 (新たなエンドポイントパラメーターの定義):

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

Appendix B.  Use of application/x-www-form-urlencoded Media Type

At the time of publication of this specification, the application/x-www-form-urlencoded media type was defined in Section 17.13.4 of [W3C.REC‑html401‑19991224] (Raggett, D., Le Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) but not registered in the IANA MIME Media Types registry (<http://www.iana.org/assignments/media-types>). Furthermore, that definition is incomplete, as it does not consider non-US-ASCII characters.

To address this shortcoming when generating payloads using this media type, names and values MUST be encoded using the UTF-8 character encoding scheme [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.) first; the resulting octet sequence then needs to be further encoded using the escaping rules defined in [W3C.REC‑html401‑19991224] (Raggett, D., Le Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.).

When parsing data from a payload using this media type, the names and values resulting from reversing the name/value encoding consequently need to be treated as octet sequences, to be decoded using the UTF-8 character encoding scheme.

For example, the value consisting of the six Unicode code points (1) U+0020 (SPACE), (2) U+0025 (PERCENT SIGN), (3) U+⁠0026 (AMPERSAND), (4) U+002B (PLUS SIGN), (5) U+⁠00A3 (POUND SIGN), and (6) U+20AC (EURO SIGN) would be encoded into the octet sequence below (using hexadecimal notation):

  20 25 26 2B C2 A3 E2 82 AC

and then represented in the payload as:

  +%25%26%2B%C2%A3%E2%82%AC

Appendix C.  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., Ed., “The OAuth 1.0 Protocol,” April 2010.), and OAuth WRAP (OAuth Web Resource Authorization Profiles) [OAuth‑WRAP] (Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, “OAuth Web Resource Authorization Profiles,” January 2010.). Eran Hammer then edited many of the intermediate drafts that evolved into this RFC. The Security Considerations section was drafted by Torsten Lodderstedt, Mark McGloin, Phil Hunt, Anthony Nadalin, and John Bradley. The section on use of the "application/x-www-form-urlencoded" media type was drafted by Julian Reschke. The ABNF section was drafted by Michael B. Jones.

The OAuth 1.0 community specification was edited by Eran Hammer 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, 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 Y. 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 that shaped and formed the final specification:

Michael Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, Aiden Bell, John Bradley, Marcos Caceres, Brian Campbell, Scott Cantor, Blaine Cook, Roger Crew, Leah Culver, Bill de hOra, Andre DeMarre, Brian Eaton, Wesley Eddy, Wolter Eldering, Brian Ellin, Igor Faynberg, George Fletcher, Tim Freeman, Luca Frosini, Evan Gilbert, Yaron Y. Goland, Brent Goldman, Kristoffer Gronowski, Eran Hammer, Dick Hardt, Justin Hart, Craig Heath, Phil Hunt, Michael B. Jones, Terry 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, William Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Luke Shepard, Vlad Skvortsov, Justin Smith, Haibin Song, Niv Steingarten, Christian Stuebner, Jeremy Suriel, Paul Tarjan, Christopher Thomas, Henry S. Thompson, Allen Tom, Franklin Tse, Nick Walker, Shane Weeden, and Skylar Woodward.

This document was produced under the chairmanship of Blaine Cook, Peter Saint-Andre, Hannes Tschofenig, Barry Leiba, and Derek Atkins. The area directors included Lisa Dusseault, Peter Saint-Andre, and Stephen Farrell.

Appendix D.  翻訳者

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

• Boku Kihara (Lepidum)
• Kazuki Shimizu (Lepidum)
• Masaru Kurahayashi (Yahoo! Japan)
• Naohiro Fujie (Itochu Techno Solutions)
• Noboru Kurumai (Fujitsu)
• Nov Matake
• Ryo Ito (mixi, Inc.)
• Tatsuya Katsuhara (NRI)
• Yusuke Kondo (Yahoo! Japan)

Author's Address