The OAuth 2.0 Protocol
draft-ietf-oauth-v2-10

Abstract

これはOAuth 2.0プロトコルの仕様書である.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on May 24, 2011.

Copyright Notice

Copyright (c) 2010 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.4.  クライアントプロファイル
        1.4.1.  ウェブサーバー
        1.4.2.  ユーザーエージェント
        1.4.3.  ネイティブアプリケーション
        1.4.4.  自律クライアント
2.  クライアントクレデンシャル
    2.1.  クライアントパスワードクレデンシャル
3.  エンドユーザー認可の取得
    3.1.  認可レスポンス
    3.2.  エラーレスポンス
        3.2.1.  エラーコード
4.  アクセストークンの取得
    4.1.  アクセス許可タイプ
        4.1.1.  認可コード
        4.1.2.  リソースオーナーパスワードクレデンシャル
        4.1.3.  アサーション
        4.1.4.  リフレッシュトークン
    4.2.  アクセストークンレスポンス
    4.3.  エラーレスポンス
        4.3.1.  エラーコード
5.  保護リソースへのアクセス
    5.1.  認証済リクエスト
        5.1.1.  認証リクエストヘッダー
        5.1.2.  URI クエリーパラメーター
        5.1.3.  フォームエンコードボディーパラメーター
    5.2.  WWW-Authenticate レスポンスヘッダーフィールド
        5.2.1.  エラーコード
6.  拡張性
    6.1.  クライアントクレデンシャルタイプの拡張
    6.2.  エンドポイントパラメーターの拡張
    6.3.  ヘッダーパラメーターの拡張
    6.4.  アクセス許可タイプの拡張
7.  Security Considerations
8.  IANAに関する考察
    8.1.  OAuthパラメーターの登録
        8.1.1.  登録用テンプレート
        8.1.2.  例
Appendix A.  Examples
Appendix B.  Contributors
Appendix C.  Acknowledgements
Appendix D.  Document History
Appendix E.  翻訳者
9.  References
    9.1.  Normative References
    9.2.  Informative References
    9.3.  翻訳プロジェクト
§  Authors' Addresses

1.  はじめに

分散Webサービスやクラウドコンピューティングの利用が進み, サードパーティーアプリケーションがサーバー上にあるリソースにアクセスする機会が増している. これらのリソースは通常保護されており, リソースオーナーのクレデンシャル (典型例としてはユーザー名とパスワード) による認証を必要とする.

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

• サードパーティーアプリケーションは, 後の利用のためにリソースオーナーのクレデンシャルを保存しておかなければならない. 通常はパスワードが平文で保存されることになる.
• サーバーはパスワードベースの認証方式をサポートしなければならない. パスワードを利用することによりセキュリティが低下する.
• サードパーティーアプリケーションは過度に多くのリソースオーナーの保護リソースに対してアクセス権を得ることになる. リソースオーナーは, アクセスをリソースのサブセットに限定したり, アクセス可能な期間を限ったり, リソースに対して一部の操作のみを許可するといったことができない.
• リソースオーナーは各サードパーティーごとにアクセス権を無効化することはできず, アクセス権を無効化する際には全てのサードパーティーが持つアクセス権を無効化しなければならない. つまりそれはパスワード変更を意味する.

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

クライアントは, 保護リソースにアクセスする為にリソースオーナーのクレデンシャルを使う代わりに, アクセストークンを取得する. (アクセストークンとは, ある特定のスコープ, 期間およびその他の属性と紐付けられた文字列である) アクセストークンのフォーマットは, 本仕様の定めるところではない.

トークンは, 認証サーバーがリソースオーナーの同意のもとサードパーティーに対して発行するものである. クライアントは, リソースサーバーにホストされている保護リソースにアクセスする為に, アクセストークンを利用する. 認証サーバーとリソースサーバーの連携方法は, 本仕様の定めるところではない.

例えば, あるユーザー (リソースオーナー) が, 印刷サービス (クライアント) に対して, 写真共有サービス上 (リソースサーバー) に保管されている彼女の保護された写真へのアクセス権を与えることを考える. OAuthでは, その際彼女のユーザー名とパスワードを印刷サービスに与える必要はない. そのかわり, 彼女は写真共有サービスの信任を得た認証サービス (認証サーバー) に対して認証を行い, 認証サービスが印刷サービスにデリゲーション専用のクレデンシャル (token) を発行する.

この仕様書ではOAuthを HTTP (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] (もしくは [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) で定義されたHTTP over TLS) の元で利用する方法を定める. 他の仕様書がその他の転送プロトコルの元での利用について本仕様を拡張する可能性もある.

1.1.  要求記法および規則

本文書で用いられる各キーワード「MUST (しなければならない)」, 「MUST NOT (してはならない)」, 「REQUIRED (必須である)」, 「SHALL (するものとする)」, 「SHALL NOT (しないものとする)」, 「SHOULD (すべきである)」, 「SHOULD NOT (すべきではない)」, 「RECOMMENDED (推奨される)」, 「MAY (してもよい)」, 「OPTIONAL (任意である)」は [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) で述べられている通りに解釈されるべきものである.

このドキュメントでは [I‑D.ietf‑httpbis‑p1‑messaging] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” March 2010.) におけるAugmented Backus-Naur Form(ABNF)表記法を利用している. 加えて, 次の規則([RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.) 記載: realm, auth-param; [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) 記載: URI-Reference; [I‑D.ietf‑httpbis‑p1‑messaging] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” March 2010.) 記載: OWS, RWS, and quoted-string)に従う.

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

1.2.  用語定義

保護リソース

アクセスが制限されたリソース. OAuth認証済みリクエストを利用して取得が可能である.

リソースサーバー

保護リソースに対するリクエストを受付け, レスポンスを返すサーバー.

クライアント

認可を取得して, 保護リソースに対するリクエストを行うアプリケーション.

リソースオーナー

保護リソースへのアクセスを許可するエンティティー.

エンドユーザー

人間のリソースオーナー.

トークン

クライアントに対して発行されたアクセス認可を表す文字列である. 文字列は通常はクライアントにとって不透明な値である. トークンは特定の範囲とアクセス期間を表し, それらはリソースオーナーによって許可され, リソースサーバーと認可サーバーによって強制される. トークンは認可情報を取り出すための識別子を意味してもよい, またはそれ自身に検証可能な方法で認可情報を含んでいてもよい(データと署名を含むトークン文字列など). トークンはpure capabilitiesでもよい. クライアントがトークンを利用するために特別に追加の認証クレデンシャルを要求してもよい.

アクセストークン

クライアントがリソースオーナーに変わって認証済みリクエストを行うために使われるトークン.

リフレシュトークン

クライアントがリソースオーナーの関与無く新しいアクセストークンを得るために使われるトークン.

認可コード

生存期間の短いトークンで, エンドユーザーによって提供されたアクセス許可を表す. 認可コードはアクセストークンとリフレッシュトークンを得るために使われる.

認可サーバー

リソースオーナーの認証とリソースオーナーからの認可取得が成功した後, トークンを発行するサーバー. 認可サーバーとリソースサーバーは同じサーバーでも, 分かれていてもよい.

エンドユーザー認可エンドポイント

認可サーバーのHTTPエンドポイントで, エンドユーザーの認証と認可の取得を行う. エンドユーザー認可エンドポイントについては Section 3 (エンドユーザー認可の取得) に記載する.

トークンエンドポイント

認可サーバーのHTTPエンドポイントで, トークンの発行と期限切れトークンのリフレッシュを行う. トークンエンドポイントについては Section 4 (アクセストークンの取得) に記載する.

クライアント識別子

認可サーバーがクライアント自身を識別するために発行される一意な識別子. クライアント識別子に対応するシークレットがあってもよい. クライアント識別子については Section 2 (クライアントクレデンシャル) に記載する.

1.3.  概要

OAuthはリソースオーナーの代わりに保護リソースにアクセスする方法をクライアントに提供する. クライアントが保護リソースにアクセスする前に, クライアントは初めにリソースオーナーの認可を取得し, アクセス許可とアクセストークン(権限の範囲, 期間と他の属性を示している)を交換しなけばならない. クライアントはリソースサーバーにアクセストークンを渡すことにより, 保護リソースにアクセスする.

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

Figure 1 (プロトコルフロー概要) で示されたフロー概要は以下のステップを含む.

(A)

クライアントはリソースオーナーに認可を要求する. クライアントは直接リソースオーナーのクレデンシャルを要求すべきではない. その代わり, クライアントは認可サーバーもしくは他のものを経由して認可を要求すべきである. 例えば, クライアントはアクセス許可を発行する認可サーバーにリソースオーナーをリダイレクトさせる. やむを得ない場合, クライアントはエンドユーザーと直接やりとりを行い, エンドユーザーのユーザー名とパスワードを要求する. もしクライアントが自律的に動作しているとき, 認可要求は本仕様の定めるところではない.

(B)

クライアントはリソースオーナーの認可を表すアクセス許可を取得する. アクセス許可は以下のように表される :

• 認可コード - 認可サーバー経由で取得したアクセス許可. Section 3 (エンドユーザー認可の取得) はエンドユーザーが存在してユーザーエージェントを使うときの認可コード取得方法を記載する.
• アサーション - 異なるトラストフレームワークを利用して取得したアクセス許可. アサーションはクライアントがアクセストークンを取得するために既存のトラストリレーションシップを利用することを可能にする. それらはOAuthと他のトラストフレームワークのブリッジを提供する. アサーションにより示されるアクセス許可はアサーションの種類やコンテント, 発行方法に依存し, それは本仕様の定めるところではない.
• リソースオーナー パスワードクレデンシャル - 直接リソースオーナーとやりとりするときに取得される. リソースオーナーパスワードクレデンシャル (すなわちユーザー名とパスワード) は, リソースオーナーとクライアントの間に高度な信用があるときのみ利用されるべきである. (例えばコンピューターOSや特別に許可されたアプリケーションを利用するときなど) しかしながら, [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認証とは異なり, リソースオーナーのクレデンシャルは1つのリクエストのために利用され, アクセストークンおよびリフレッシュトークンと交換される. よってクライアントはリソースオーナーのクレデンシャルを将来の利用のため保存する必要はない.

(C)

クライアントは, 認可サーバーに対して自身を認証し, アクセス許可を提示することで, アクセストークンを要求する. トークンリクエストについては Section 4 (アクセストークンの取得) に記載する.

(D)

認可サーバーはクライアントクレデンシャルとアクセス許可の正当性を確認し, アクセストークンを発行する. オプションでアクセストークンに付随するリフレッシュトークンを発行する場合もある. アクセストークンは通常, アクセス許可よりも短い生存期間を持つ. リフレッシュトークンは通常, アクセス許可の期間と等しい生存期間を持つ. アクセストークンの有効期限が切れた場合でも, リフレッシュトークンを利用すると, リソースオーナーに再度アクセス許可を要求することなく新しいアクセストークンが取得できる.

(E)

クライアントは保護リソースへのリクエストを実行し, アクセスを得るためにアクセストークンを提供する. 保護リソースへのアクセスについては Section 5 (保護リソースへのアクセス) に記載する.

(F)

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

クライアントが自身の代理として振る舞う (クライアントがリソースオーナーでもある) とき, クライアントはアクセス権を取得しない. 簡略化されたプロトコルフローは Figure 2 (自身の代理として振る舞うクライアントのためのプロトコルフロー) に示される.

  +--------+                                  +---------------+
  |        |--(C)--- Client Credentials ----->| Authorization |
  |        |                                  |     Server    |
  |        |<-(D)------ Access Token ---------|               |
  |        |                                  +---------------+
  | Client |
  |        |                                  +---------------+
  |        |--(E)------ Access Token -------->|    Resource   |
  |        |                                  |     Server    |
  |        |<-(F)---- Protected Resource -----|               |
  +--------+                                  +---------------+

クライアントがユーザーエージェントプロファイル(Section 1.4.2 (ユーザーエージェント) に記載する)を利用するとき, クライアントは Figure 3 (間接的なアクセス許可プロトコルフロー) にあるように, 認可リクエストの結果としてアクセストークンを取得する.

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

1.4.  クライアントプロファイル

OAuthは, 認可を確立しアクセストークンと交換するための, リッチで拡張可能なフレームワークを提供することで, 広範囲のクライアントタイプをサポートする. この仕様書で詳述されている方式は, ウェブサーバー, ユーザーエージェント, ネイティブアプリケーション, 自律アプリケーションの４つのクライアントタイプに対応するために作成されている. 追加のシナリオやクライアントタイプを対象に含めるため, 他の仕様書によって追加の認可フローやクライアントプロファイルが定義されることもある.

1.4.1.  ウェブサーバー

ウェブサーバープロファイルは, エンドユーザーのユーザーエージェント (通常はウェブブラウザー) と交信可能で, かつ認可サーバーからのリクエストを受信可能な (HTTPサーバーとして動作できる) クライアントに適している.

  +----------+          Client Identifier      +---------------+
  |         -+----(A)--- & Redirect URI ------>|               |
  | End-user |                                 | Authorization |
  |    at    |<---(B)-- User authenticates --->|     Server    |
  | Browser  |                                 |               |
  |         -+----(C)-- Authorization Code ---<|               |
  +-|----|---+                                 +---------------+
    |    |                                         ^      v
   (A)  (C)                                        |      |
    |    |                                         |      |
    ^    v                                         |      |
  +---------+                                      |      |
  |         |>---(D)-- Client Credentials, --------'      |
  |   Web   |          Authorization Code,                |
  |  Client |            & Redirect URI                   |
  |         |                                             |
  |         |<---(E)----- Access Token -------------------'
  +---------+       (w/ Optional Refresh Token)

Figure 4 (ウェブサーバーフロー) に示すウェブサーバーフローの手順を以下に述べる.

(A)

ウェブクライアントは, まず初めにエンドユーザーのユーザーエージェントを Section 3 (エンドユーザー認可の取得) に記載されているエンドユーザー認可エンドポイントへリダイレクトする. その際クライアントは, クライアント識別子, 要求するスコープ, ローカルステート, アクセスが認可 (もしくは否認) された時点でエンドユーザーがリダイレクトされるリダイレクトURIをリクエストに含める.

(B)

認証サーバーは, ユーザーエージェント経由でエンドユーザーを認証し, クライアントのアクセス要求を許可するかどうかを確認する.

(C)

エンドユーザーがアクセスを許可すると, 認可サーバーはクライアントが事前に提供したリダイレクトURIにユーザーエージェントをリダイレクトさせる. そのとき渡される認可情報には, クライアントがアクセストークン取得のために使用する認可コードが含まれる.

(D)

クライアントは Section 4 (アクセストークンの取得) に記載の通り, 認可サーバーに対して認証を行い直前の手順で受け取った認可コードを提示することで, 認可サーバーにアクセストークンを要求する.

(E)

認可サーバーはクライアントクレデンシャルと認可コードを検証し, アクセストークンを返す.

1.4.2.  ユーザーエージェント

ユーザーエージェントプロファイルは, ユーザーエージェント上で動作するクライアントアプリケーションに適している. 典型例としては, JavaScriptなどのスクリプト言語を用いて実装された, ブラウザー上で動作するアプリケーションなどが挙げられる. これらのクライアントは, クライアントシークレットを機密に保つことができない. そして, クライアントの認証はユーザーエージェントのsame origin policyに基づいている.

その他のプロファイルとは違い, このプロファイルではクライアントがエンドユーザー認可とアクセストークンを単一のリクエストで要求する. アクセストークンは, エンドユーザー認可リクエストに対するHTTPリダイレクトレスポンス内に含まれる. クライアントは, ユーザーエージェントを他のウェブサーバー, もしくはユーザーエージェントにアクセスしてレスポンスからアクセストークンを抽出しクライアントに渡すことができるローカルリソースにリダイレクトするよう, 認可サーバーに要求する.

このプロファイルでは, クライアントはエンドユーザーのコンピューターやデバイス上で実行される. これらの環境ではクライアントシークレットにアクセスされ, 悪用される可能性がある. このためユーザーエージェントプロファイルではクライアントシークレットを利用しない. アクセストークンはリダイレクトURI中に含まれているため, エンドユーザーやコンピューター, またはデバイス上のその他のアプリケーションにアクセスされる可能性がある.

         +----------+          Client Identifier     +----------------+
         |          |>---(A)-- & Redirection URI --->|                |
         |          |                                |                |
  End <--+  -  -  - +----(B)-- User authenticates -->|  Authorization |
  User   |          |                                |     Server     |
         |          |<---(C)--- Redirect URI -------<|                |
         |  Client  |         with Access Token      |                |
         |    in    |            in Fragment         +----------------+
         |  Browser |
         |          |                                +----------------+
         |          |>---(D)--- Redirect URI ------->|                |
         |          |         without Fragment       |   Web Server   |
         |          |                                |   with Client  |
         |    (F)   |<---(E)--- Web Page with ------<|    Resource    |
         |  Access  |              Script            |                |
         |   Token  |                                +----------------+
         +----------+

Figure 5 (ユーザーエージェントフロー) に示すユーザーエージェントフローの手順を以下に述べる.

(A)

クライアントはユーザーエージェントを Section 3 (エンドユーザー認可の取得) に記載されたエンドユーザー認可エンドポイントに送る. その際クライアントは, クライアント識別子, 要求するスコープ, ローカルステート, アクセスが認可 (もしくは否認) された時点でエンドユーザーがリダイレクトされるリダイレクトURIをリクエストに含める.

(B)

認証サーバーは, ユーザーエージェント経由でエンドユーザーを認証し, クライアントのアクセス要求を許可するかどうかを確認する.

(C)

エンドユーザーがアクセスを許可すると, 認可サーバーはクライアントが事前に提供したリダイレクトURIにユーザーエージェントをリダイレクトさせる. そのリダイレクトURIのURIフラグメントには, アクセストークンが含まれる.

(D)

ユーザーエージェントはリダイレクト命令に従い, ウェブサーバーに対してリクエストを行う. このリクエストにはフラグメント情報は含まれない. ユーザーエージェントはフラグメント情報をローカルに保持する.

(E)

ウェブサーバーは, ウェブページ (一般的にはスクリプトが組み込まれたHTMLページ) を返す. そのウェブページでは, ユーザーエージェントはフラグメントを含む完全なリダイレクトURIにアクセスし, フラグメントに含まれるアクセストークン (およびその他のパラメーター) を抽出することができる.

(F)

ユーザーエージェントはウェブサーバーによって提供されたスクリプトをローカルで実行し, アクセストークンを抽出しクライアントに渡す.

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

ネイティブアプリケーションは, エンドユーザーのコンピューターやデバイス上でネイティブコードとして動作するクライアントである. (例えば, ユーザーエージェントの外部で実行されるアプリケーションや, デスクトッププログラムなど) これらのクライアントは, 一般的にエンドユーザーのユーザーエージェントとやりとりする (またはユーザーエージェント自体を組み込む) ことが可能である. しかし, エンドユーザーとのインタラクションはある程度制限される. 多くの場合, ネイティブアプリケーションは (ファイアウォールやOSからの制限などにより) サーバーからのダイレクトコールバックリクエストを受けることができない.

ネイティブアプリケーションクライアントは, クライアントの要件や期待されるエンドユーザー体験に応じて異なる方法で実装されている. ネイティブアプリケーションクライアントは下記のいずれかの方法で動作する.

• 外部のユーザーエージェント経由で, Section 3 (エンドユーザー認可の取得) に記載されたエンドユーザー認可エンドポイントを利用する. この場合クライアントは, カスタムURIスキーマではじまるURIや, 自身のサーバー上にあるリソースのURIをリダイレクトURIとして提供することで, レスポンスを取得する. 前者の場合, そのスキーマはこのクライアントアプリケーションを呼び出すようにOSに登録されている. 後者の場合, そのリソースはウィンドウタイトルやユーザーエージェント外からアクセス可能なその他のロケーションを利用して, クライアントにレスポンスを渡す.
• 組み込みユーザーエージェント経由で, Section 3 (エンドユーザー認可の取得) に記載されたエンドユーザー認可エンドポイントを利用する. クライアントは組み込みユーザーエージェントと直接やりとりすることでレスポンスを取得する.
• エンドユーザーにパスワードを入力させ, それを直接利用してアクセストークンを取得する. エンドユーザーのパスワードが直接サードパーティークライアントに渡り, クライアントはパスワードを平文で保持する必要があるため, 一般的にこの方法は推奨されない. またこの場合, サーバーはパスワードベースの認証をサポートする必要がある.

外部ブラウザと組み込みユーザーエージェントのどちらを利用するか検討するにあたって, 開発者は下記のことを考慮すべきである.

• 外部のユーザーエージェントを利用すると, エンドユーザーがすでにログイン済な場合に再認証を必要としないことがあるため, 認可フローの成功率があがる可能性がある.
• 組み込みユーザーエージェントを利用すると, コンテキストを変更したり新規ウィンドウを開く必要がないため, 一般によりよいエンドユーザーフローを提供することができる.
• 組み込みユーザーエージェントを利用すると, 多くのユーザーエージェントと異なり認証を行うウィンドウに関して視覚的に得られる情報が限られるため, セキュリティー面で課題が残る.

1.4.4.  自律クライアント

自律クライアントは, 既存の信頼関係または認可フレームワークを利用する. 自律クライアントは, クライアントの要件またはクライアントが依存する既存のトラストフレームワークに基づいて異なる方法で実装される. 自律クライアントは下記のいずれかの方法で動作する.

• クライアントクレデンシャルを利用し, 認可サーバーから認証されたアクセストークンを取得する. アクセストークンのスコープは, クライアントの制御下の保護リソース, または事前にリソースオーナーが認可サーバとの間で取り決めた範囲に制限される.
• 認可サーバーがサポートするアサーションフォーマットで示される, 既存のアクセス許可を利用する. この場合クライアントは, アサーション発行者から (SAML (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) [OASIS.saml‑core‑2.0‑os] などの) アサーションを獲得したり, アサーションを自己発行する必要がある. アサーションフォーマット, アサーション獲得プロセス, アサーション検証方法は, アサーション発行者と認可サーバーによって定義されており, 本仕様の定めるところではない.

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

認可サーバーとやりとりする際, クライアントはクライアント識別子を使って自身を特定し, クライアントクレデンシャルを使って認証を行う. この仕様書では, パスワードクレデンシャルによるクライアント認証メカニズムを提供する.

クライアントクレデンシャルの取得方法はこの仕様の範囲外であるが, これは通常認可サーバーへの登録時に行われる. [[ OAuth Discovery はクライアントパスワードを取得する方法を提供する. ]]

一部のクライアントの性質上, 認可サーバーは, クライアントオペレーターとの信頼確立なしにクライアントシークレットの機密性を仮定すべきではない (SHOULD NOT). 認可サーバーは, クライアントシークレットの機密性を確保できないクライアントに対してクライアントシークレットを発行すべきでははない (SHOULD NOT).

認可サーバーは, 任意の適切なクレデンシャルと認証スキーマの組み合わせによってクライアントを認証することができる (MAY). クライアントは, 単一リクエスト中で複数のクレデンシャルまたは認証メカニズムを利用してはならない (MUST NOT).

2.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ベーシック認証スキーマを利用してリクエスト中に含められる.

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

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

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

代替方法として, 以下に示すパラメーターを利用してリクエストボディーにパスワードを含めることもできる (MAY).

client_secret

必須 (REQUIRED). クライアントパスワード.

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

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

  grant_type=authorization_code&client_id=s6BhdRkqt3&
  client_secret=gX1fBat3bV&code=i1WsRn1uB1&
  redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

認可サーバーは, クライアントクレデンシャル送信方法として, リクエストパラメーターとHTTPベーシック認証スキーマの両方をサポートしなければならない (MUST). 認可サーバーはパスワード送信にふさわしい認証スキーマを追加でサポートしてもよい (MAY).

3.  エンドユーザー認可の取得

クライアントがエンドユーザーの保護リソースにアクセスするには, まず最初にエンドユーザーから保護リソースにアクセスするための認可を得なければならない (MUST). エンドユーザーの認可を得ると, クライアントはアクセストークンと交換するための認可コードを取得する. この認可を得るために, クライアントはエンドユーザーをエンドユーザー認可エンドポイントにリダイレクトする.

エンドユーザー認可エンドポイントにリダイレクトされたエンドユーザーは, まず認可サーバーに対して認証を行い, クライアントからのアクセス要求を承認または否認する. 認可サーバーによる認証方法 (例. ユーザー名とパスワードによるログイン, OpenID, セッション・クッキー), およびエンドユーザーから認可の承認・否認を得る方法は, TLSのようなセキュアな通信を使うかどうかを含めて, 本仕様の定めるところではない. しかしながら, 認可サーバーは最初にエンドユーザーのアイデンティティを確認しなければならない (MUST).

エンドユーザー認可エンドポイントのURLは, 対象サービスのドキュメントあるいは [[ OAuth Discovery ]] から見つけることができる. エンドユーザー認可エンドポイントのURIは [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) のSection 3で定義されているクエリー部を含んでいる可能性がある (MAY). これらのクエリーパラメーターは, 他のクエリーパラメーターを追加する場合もそのままにしなければならない.

エンドユーザー認可エンドポイントへのリクエストは, ユーザー認証および重要な情報の伝送をともなうため, 認可サーバーはエンドポイントへのリクエストにTLSのようなトランスポート層でのセキュリティ機構を必須とすべきである (SHOULD).

エンドユーザーのユーザーエージェントを認可サーバーにリダイレクトさせるにあたり, クライアントはエンドユーザー認可エンドポイントURIのクエリー部に下記のパラメーターを [W3C.REC‑html401‑19991224] (Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) で定義された application/x-www-form-urlencoded フォーマットで追加して, リクエストURIを構築する.

response_type

必須 (REQUIRED). レスポンスとして要求するもの (アクセストークン, 認可コード, またはその両方). レスポンスとしてアクセストークンを要求する場合は token を, 認可コードを要求する場合は code, またはその両方を要求する場合は code_and_token を指定しなければならない (MUST). 認可サーバーはこれらのうちひとつかそれ以上のパラメーターをサポートしなくてもよい (MAY). [[code_and_token は検討中であり, 仕様から取り除かれるかもしれない ]]

client_id

必須 (REQUIRED). Section 2 (クライアントクレデンシャル) で記載するクライアント識別子.

redirect_uri

クライアントと認可サーバー間で事前にリダイレクト先のURIが決められていない場合は必須 (REQUIRED). エンドユーザーによる認可ステップ完了時に, 認可サーバーがユーザーエージェントをリダイレクトする先の絶対URI. 認可サーバーはクライアントにリダイレクト先のURIを事前登録させるべきである (SHOULD).

scope

任意 (OPTIONAL). このリクエストで要求するアクセス権のスコープを空白区切りの文字列で指定する. scope の値に何を指定するかは認可サーバーによって定義される. 空白区切りで複数の値を含む場合は, その順序に意味はなく, それぞれの値を合わせた範囲が要求するアクセス権になる.

state

任意 (OPTIONAL). このリクエストから完了時のコールバックまでのあいだ, クライアントが状態管理に利用できる値. 認可サーバーはここで指定された値をそのままリダイレクトURIに含めて, ユーザーエージェントをリダイレクトする.

クライアントはHTTPリダイレクトレスポンスや, 他にエンドユーザーのユーザーエージェントで利用可能な手段を使って, ここで構築したURIにリダイレクトする. 認可サーバーはエンドユーザー認可エンドポイントでHTTPの GET メソッドをサポートしなければならず (MUST), POST メソッドも同様にサポートしてよい (MAY).

たとえば, クライアントはエンドユーザーのユーザーエージェントをリダイレクトし, 以下のHTTPリクエストをセキュリティ保護されたトランスポート層から送信させる (改行は掲載上の都合による)

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

クライアントがリダイレクトURIを認可サーバーに事前登録していた場合, 認可サーバーは受け取ったリダイレクトURIが登録されているものとマッチするか検証しなければならない (MUST). [[ マッチングの方法について追記する ]]

パラメーターの値が空の場合は, パラメーター自体が指定されていないものとして扱われなければならない (MUST). 認可サーバーは処理できないパラメーターを無視すべきである (SHOULD).

認可サーバーはすべての必須パラメーターが正しく指定されていることを検証し, リクエストが不正だった場合はただちにユーザーエージェントをリダイレクトURIにリダイレクトする. そのときのリダイレクトURIには, Section 3.2 (エラーレスポンス) で記載する適切なエラーコードが指定されている.

認可サーバーはエンドユーザーを認証し, (エンドユーザーに選択させるか, 他の方法で確認することで) 認可の可否を得る. その後, 認可サーバーはHTTPリダイレクトレスポンスや, 他にエンドユーザーのユーザーエージェントで利用可能な手段を使って, 指定されたリダイレクトURIにリダイレクトする.

3.1.  認可レスポンス

エンドユーザーがアクセス要求を許可した場合, 認可サーバーはアクセストークン, 認可コード, またはその両方を発行し, 以下のパラメーターを付加した上でリダイレクトURIへリダイレクトさせる.

code

レスポンスタイプが code または code_and_token の場合は必須 (REQUIRED). その他の場合は含まれてはならない (MUST NOT). 認可サーバーによって発行された認可コード. 認可コードは発行された後, 短時間で失効すべきである (SHOULD). 認可サーバーは一度使われた認可コードを無効にしなけらばならない (MUST). 認可コードはクライアント識別子とリダイレクトURIに紐付いている.

access_token

レスポンスタイプが token または code_and_token の場合に必須 (REQUIRED). その他の場合は含まれてはならない (MUST NOT). 認可サーバーによって発行されたアクセストークン. アクセストークン文字列は, Section 5.1.1 (認証リクエストヘッダー) で定義されるアクセスークンのルールに従わなければならない (MUST).

expires_in

任意 (OPTIONAL). アクセストークンが含まれていた場合に, アクセストークンの生存期間を秒数で表したもの. 例えば, 3600 という値は, 認可サーバーによってレスポンスが生成された1時間後にアクセストークンが失効することを表す.

scope

任意 (OPTIONAL). アクセストークンが含まれていた場合に, アクセストークンのスコープを空白区切りの文字列で表したもの. scope の値に何を指定するかは認可サーバーによって定義される. 空白区切りで複数の値を含む場合は, その順序に意味はなく, それぞれの値を合わせたアクセス範囲が要求するアクセス権になる. 認可サーバーはクライアントによってリクエストされたスコープと異なるスコープを与えた場合, このパラメーターを含むべきである (SHOULD).

state

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

認可サーバーがリダイレクトURIにパラメーターを追加する方法は, クライアントからの認可リクエストで response_type パラメーターによって指定されるレスポンスタイプで決まる.

レスポンスタイプが code の場合, 認可サーバーは [W3C.REC‑html401‑19991224] (Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) で定義される application/x-www-form-urlencoded フォーマットで, リダイレクトURIのクエリー部にパラメーターを追加する.

例えば, 認可サーバーはエンドユーザーのユーザーエージェントを以下のHTTPレスポンスによってリダイレクトさせる.

  HTTP/1.1 302 Found
  Location: https://client.example.com/cb?code=i1WsRn1uB1

レスポンスタイプが token の場合, 認可サーバーは [W3C.REC‑html401‑19991224] (Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) で定義される application/x-www-form-urlencoded フォーマットで, リダイレクトURIのフラグメント部にパラメーターを追加する.

例えば, 認可サーバーはエンドユーザーのユーザーエージェントを以下のHTTPレスポンスによってリダイレクトさせる.

  HTTP/1.1 302 Found
  Location: http://example.com/rd#access_token=FJQbwq9&expires_in=3600

レスポンスタイプが code_and_token の場合, 認可サーバーは, code, state パラメーターをリダイレクトURIのクエリー部に, access_token, scope, expires_in パラメーターをフラグメント部に, [W3C.REC‑html401‑19991224] (Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) で定義される application/x-www-form-urlencoded フォーマットで追加する.

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

  HTTP/1.1 302 Found
  Location: http://example.com/rd?code=i1WsRn1uB1
            #access_token=FJQbwq9&expires_in=3600

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

3.2.  エラーレスポンス

エンドユーザーがアクセス要求を拒否したか要求が不正だった場合, 認可サーバーは [W3C.REC‑html401‑19991224] (Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) で定義される application/x-www-form-urlencoded フォーマットでリダイレクトURIのクエリー部に以下に示すパラメーターを追加して, クライアントにエラーを通知する:

error

必須 (REQUIRED). Section 3.2.1 (エラーコード) に記載するいずれか1つのエラーコード.

error_description

任意 (OPTIONAL). エラーについての詳しい情報を人間に読めるかたちで記したもので, 起こっているエラーを理解・解決するために使用される.

error_uri

任意 (OPTIONAL). エラーについての情報を記したウェブページを指すURIで, エンドユーザーにエラーについての詳しい情報を提供するために使用される.

state

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

例えば, 認可サーバーは以下のようなHTTPレスポンスを送出することで, エンドユーザーのユーザーエージェントをリダイレクトする:

  HTTP/1.1 302 Found
  Location: https://client.example.com/cb?error=access-denied

3.2.1.  エラーコード

認可サーバーは以下のいずれかのエラーコードをエラーレスポンスに含める.

invalid_request

リクエストが必須のパラメーターを含んでいない, サポートしていないパラメーターないしパラメーター値を含む, あるいは形式に問題がある.

invalid_client

指定されたクライアント識別子が不正である.

unauthorized_client

クライアントは指定されたレスポンスタイプを使用する権限を持たない.

redirect_uri_mismatch

指定されたリダイレクトURIが事前登録されたものとマッチしない.

access_denied

エンドユーザーか認可サーバーが要求を拒否した.

unsupported_response_type

要求されたレスポンスタイプを認可サーバーがサポートしていない.

invalid_scope

要求されたスコープが不正か, 未知のものか, 形式に問題がある.

[[ エラーコードの拡張方法について追記すること ]]

4.  アクセストークンの取得

クライアントは, 認可サーバーに (認可コードやリソースオーナーのクレデンシャル, アサーションもしくはリフレッシュトークンの形で) アクセス許可を提示し, アクセストークンを取得する.

トークンエンドポイントに対するリクエストでは, HTTPリクエストおよびレスポンス内にクレデンシャルが平文で含まれるため, 認可サーバーはトークンエンドポイントへのリクエストに対してトランスポート層でのセキュリティ機構の利用を必須としなければならない (MUST). サーバーは [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) で定義されるTLS 1.2をサポートしなければならず (MUST), それに加えて他のトランスポート層でのセキュリティ機構をサポートすることもできる (MAY).

クライアントはトークンエンドポイントにHTTP POST リクエストを送信し, アクセストークンを要求する. トークンエンドポイントのURIは対象サービスのドキュメント, あるいは [[ OAuth Discovery ]] を利用して得ることができる. トークンエンドポイントURIはクエリー部を含んでいる可能性がある (MAY).

クライアントは, 自身のクレデンシャルを Section 2 (クライアントクレデンシャル) に記載された方法でリクエストに追加することで, 認可サーバーに対して認証を行う. 認可サーバーは, クライアントのアイデンティティを問わない場合 (匿名クライアントなど) やクライアントのアイデンティティが他の方法で確立されている場合 (アサーション形式のアクセス許可など), 認証無しのアクセストークンリクエストを受け入れてもよい (MAY).

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

grant_type

必須 (REQUIRED). リクエストに含まれるアクセス許可タイプ. 値は以下のいずれかでなければならない (MUST). authorization_code, password, assertion, refresh_token, none.

client_id

クライアントアイデンティティが (アサーションなどの) 他の方法で確立されない限り必須 (REQUIRED). Section 2 (クライアントクレデンシャル) に記載されるクライアント識別子.

scope

任意 (OPTIONAL). 要求するアクセス範囲. 空白区切りの文字列で表される. scope の値に何を指定するかは認可サーバーによって定義される. 空白区切りで複数の値を含む場合は, その順序に意味はなく, それぞれの値を合わせたアクセス範囲が要求するアクセス権になる. 利用されるアクセス許可がすでに承認済のスコープを持つ場合 (認可コードやアサーションを利用した場合), 要求されたスコープは先に承認されたスコープの範囲を超えてはならない (MUST).

さらにクライアントは, 利用するアクセス許可タイプごとに決められた適切なパラメーターを含めなければならない (MUST). 詳細は Section 4.1 (アクセス許可タイプ) に記述する.

パラメーターの値が空の場合はパラメーター自体が指定されていないものとして扱われなければならない (MUST). 認可サーバーは処理できないパラメーターを無視すべきである (SHOULD).

4.1.  アクセス許可タイプ

クライアントは, アクセストークンを要求する際, 次の4つのアクセス許可タイプ (認可コード, パスワードクレデンシャル, アサーション, リフレッシュトークン) のうち1つを利用する.

アクセス許可タイプとして none を指定して (アクセス許可を含めずに) アクセストークンを要求する場合, それは自身のコントロール下にある保護リソースや, 他のリソースオーナーが (本仕様のスコープ外の方法で) 事前に認可サーバーと調整を終えている保護リソースに対するアクセス要求を意味する.

4.1.1.  認可コード

アクセス許可タイプ authorization_code を用いる場合は, 次のパラメーターを含める.

code

必須 (REQUIRED). 認可サーバーから取得した認可コード.

redirect_uri

必須 (REQUIRED). 初期リクエストで利用したリダイレクトURI.

例えばクライアントは, クライアントクレデンシャルを Section 2 (クライアントクレデンシャル) に記載する client_secret パラメーターに載せ, セキュリティ保護されたトランスポート層を用いて次のようなHTTPリクエストを行う. (改行は掲載上の都合による)

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

  grant_type=authorization_code&client_id=s6BhdRkqt3&
  client_secret=gX1fBat3bV&code=i1WsRn1uB1&
  redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

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

• (もしクライアントクレデンシャルが含まれていれば) クライアントクレデンシャルの妥当性を確認し, それが認可コードとマッチすることを確認する.
• 認可コードとリダイレクトURIが妥当かつ保存済みアソシエーションに一致することを検証する.

もしリクエストが妥当ならば, 認可サーバーは Section 4.2 (アクセストークンレスポンス) に記載の通り成功レスポンスを返す.

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

アクセス許可タイプ password を用いる場合は, 次のパラメーターを含める. [[ ユーザー名とパスワードの国際化に関する考察を追記 ]]

username

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

password

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

例えばクライアントは, クライアントクレデンシャルを Section 2 (クライアントクレデンシャル) に記載する client_secret パラメーターに載せ, セキュリティ保護されたトランスポート層を用いて次のようなHTTPリクエストを行う. (改行は掲載上の都合による)

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

  grant_type=password&client_id=s6BhdRkqt3&
  client_secret=47HDu8s&username=johndoe&password=A3ddj3w

認可サーバーは (クライアントクレデンシャルが含まれていればクライアントクレデンシャルと) エンドユーザークレデンシャルの妥当性を確認しなければならない (MUST). それらが妥当であれば, Section 4.2 (アクセストークンレスポンス) に記載の通り, アクセストークンレスポンスを返さなければならない (MUST).

4.1.3.  アサーション

アクセス許可タイプ assertion を用いる場合は, 以下のパラメーターを含める.

assertion_type

必須 (REQUIRED). 認可サーバーにより定義されるアサーションのフォーマット. 値は絶対URIでなければならない (MUST).

assertion

必須 (REQUIRED). アサーション.

例えばクライアントは, セキュリティ保護されたトランスポート層を用いて次のようなHTTPリクエストを行う. この場合, クライアント認証はアサーション経由で行われる. (改行は掲載上の都合による)

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

  grant_type=assertion&
  assertion_type=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aassertion&
  assertion=PHNhbWxwOl...[omitted for brevity]...ZT4%3D

認可サーバーは (クライアントクレデンシャルがある場合は) クライアントクレデンシャルを検証し, Section 4.2 (アクセストークンレスポンス) で記載されるアクセストークンレスポンスを返さなければならない (MUST). 認可サーバーはリフレッシュトークンを発行すべきでない (SHOULD NOT). (その代わりクライアントに同じもしくは新しいアサーションを要求する)

認可サーバーは生存時間が限られたアクセストークンを発行すべきであり (SHOULD), もし同じアサーションが有効であるならば, それを用いて新しいアクセストークンを要求することによりクライアントにアクセストークンを更新させるべきである (SHOULD). アサーションが無効な場合, クライアントは新しい有効なアサーションを取得しなければならない (MUST).

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

アクセス許可タイプ refresh_token を用いる場合は, 以下のパラメーターを含める.

refresh_token

必須 (REQUIRED). 更新されるアクセストークンと関連づけられたリフレッシュトークン.

例えばクライアントは, クライアントクレデンシャルを Section 2 (クライアントクレデンシャル) に記載する client_secret パラメーターに載せ, セキュリティ保護されたトランスポート層を用いて次のようなHTTPリクエストを行う. (改行は掲載上の都合による)

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

  grant_type=refresh_token&client_id=s6BhdRkqt3&
  client_secret=8eSEIpnqmM&refresh_token=n4E9O119d

認可サーバーは (もしクライアントクレデンシャルが存在する場合はクライアントクレデンシャルと) リフレッシュトークンの正当性, リソースオーナーの認可の有効性を検証しなければならない (MUST). リクエストが有効であれば, 認可サーバーは Section 4.2 (アクセストークンレスポンス) で記載されるアクセストークンレスポンスを返す. 認可サーバーは新しいリフレッシュトークンを発行してもよい (MAY).

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

認可サーバーは, 認可済の有効なアクセストークンリクエストを受信および検証した後, アクセストークン (と任意でリフレッシュトークン) を発行し, ステータスコード200 (OK) とともに以下のパラメーターをHTTPレスポンスボディーに付加してレスポンスを構築する.

トークンレスポンスは以下のパラメーターを含む.

access_token

必須 (REQUIRED). 認可サーバーによって発行されたアクセストークン. アクセストークンの文字列は Section 5.1.1 (認証リクエストヘッダー) で定義されたアクセストークンのルールに従わなければならない.

expires_in

任意 (OPTIONAL). アクセストークンの有効期間を表す秒数. 例えば, 3600 という値は, 認可サーバーによってレスポンスが生成された1時間後にアクセストークンが失効することを表す.

refresh_token

任意 (OPTIONAL). リフレッシュトークンは Section 4.1.4 (リフレッシュトークン) で記載される通り, 同一のエンドユーザーのアクセス許可を使って新しいアクセストークンを取得するのに利用される. 認可サーバーはアクセス許可タイプが none に設定されている場合, リフレッシュトークンを発行すべきでない (SHOULD NOT).

scope

任意 (OPTIONAL). スペース区切りの文字列のリストで表されるアクセストークンのスコープ. scope の値は認可サーバーによって定義される. 空白区切りで複数の値を含む場合は, その順序に意味はなく, それぞれの値を合わせたアクセス範囲が要求するアクセス権になる. 要求されたスコープがクライアントから要求されたものと異なる場合, 認可サーバーはこのパラメーターを含めるべきである.

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

認可サーバーは, トークン, シークレット, その他センシティブな情報を含むいかなるレスポンスにおいても, HTTP Cache-Control ヘッダーの値を no-store として含めなければならない (MUST).

例：

  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store

  {
    "access_token":"SlAV32hkKG",
    "expires_in":3600,
    "refresh_token":"8xLOxBtZp8"
  }

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

4.3.  エラーレスポンス

トークンリクエストが不正または未認可の場合, 認可サーバーはメディアタイプ application/json でHTTPレスポンスボディーに以下に示すパラメーターを付与して, クライアントにエラーを通知する.

error

必須 (REQUIRED). Section 4.3.1 (エラーコード) に記載されているいずれか1つのエラーコード.

error_description

任意 (OPTIONAL). エラーについての詳しい情報を人間に読めるかたちで記したもので, 起こっているエラーを理解・解決するために使用される.

error_uri

任意 (OPTIONAL). エラーについての情報を記したウェブページを指すURIで, エンドユーザーにエラーについての詳しい情報を提供するために使用される.

例:

  HTTP/1.1 400 Bad Request
  Content-Type: application/json
  Cache-Control: no-store

  {
    "error":"invalid_request"
  }

クライアントが Authorization リクエストヘッダーによるHTTP認証を利用して無効なクレデンシャルを与えた場合, 認可サーバーはステータスコード HTTP 401 (Unauthorized) を返さなくてはならない. そうでなければ認可サーバーはステータスコードHTTP 400 (Bad Request) を返すものとする (SHALL).

4.3.1.  エラーコード

認可サーバーは以下のいずれかのエラーコードをエラーレスポンスに含める.

invalid_request

必須のパラメーターを指定していない, サポートされていないパラメーターもしくは値を含んでいる, パラメーターに重複がある, 複数クレデンシャルを含む, クライアント認証の為の2つ以上のメソッドを利用している, あるいは形式に問題がある.

invalid_client

不正なクライアント識別子を指定した, クライアントが認証に失敗した, クライアントがクレデンシャルを含めなかった, 複数のクライアントクレデンシャルを指定した, サポートされていないクレデンシャルタイプを使用した.

unauthorized_client

クライアントは指定されたアクセス許可タイプを使用する権限を持たない.

invalid_grant

指定されたアクセス認可が無効, 期限切れ, もしくは取り消された. (例：無効なアサーション, 期限切れの認可コード, 間違ったエンドユーザーのパスワードクレデンシャル, 認可コードとリダイレクトURIの不一致)

unsupported_grant_type

リクエストに含むアクセス許可のタイプもしくは他の属性が認可サーバーでサポートされていない.

invalid_scope

指定されたscopeが不正, 未知, 形式に問題がある, もしくは前回許可したscopeの範囲を超えている.

[[ エラーコードを拡張する仕組みを追加 ]]

5.  保護リソースへのアクセス

クライアントはアクセストークンをリソースサーバーに提示し, 保護リソースにアクセスする. アクセストークンはbearer tokenとして機能し, アクセストークンのトークン文字列は共有対称鍵として機能する. このことから, アクセストークンをその他の鍵と同じように扱う必要がある (例えば, エンドユーザーのパスワードのように). アクセストークンはセキュアでないチャンネルを平文で送られるべきではない (SHOULD NOT).

セキュアな通信を使わずに平文でアクセストークンを送る必要がある場合には, 不正なアクセストークンがもつ潜在的なリスクを減じるために, 認可サーバーはスコープと生存期間が限られたアクセストークンを発行すべきである (SHOULD).

クライアントは, セキュアな通信かそうでないかに関わらず, 未知のリソースサーバーに対してアクセストークンを含む認証済リクエストを行ってはならない (MUST NOT).

リソースサーバーはアクセストークンを検証し, トークンの有効期限が切れてないこと, およびそのトークンのスコープが要求されたリソースをカバーしていることを確認しなければならない (MUST). リソースサーバーがアクセストークンを検証するために用いるメソッドについては, この仕様の定める範囲ではない. しかし, 一般的にそれらのメソッドは, リソースサーバーと認証サーバーの間の連携および調整の方法を含んでいる.

5.1.  認証済リクエスト

クライアントは Authorization リクエストヘッダーを使って, 認証済トークンリクエストを生成する. リソースサーバーは, Section 5.1.1 (認証リクエストヘッダー) に記載する OAuth HTTP認証スキーマを用いた認証済リクエストを受け入れなければならない (MUST). リソースサーバーは付加的なメソッドをサポートしてもよい (MAY).

代替手段として, クライアントは, Section 5.1.2 (URI クエリーパラメーター) に記載するHTTPリクエストURI中のクエリー部, もしくは Section 5.1.3 (フォームエンコードボディーパラメーター) に記載する application/x-www-form-urlencoded コンテントタイプのHTTPボディーのいずれかにアクセストークンを含めてもよい (MAY).

クライアントは, Authorization リクエストヘッダーが利用できない場合, リクエストURIまたはボディーだけを用いるべきである (SHOULD). さらに, クライアントは1リクエスト中で2つ以上のメソッドを使用してはならない (MUST NOT).

5.1.1.  認証リクエストヘッダー

クライアントは Authorization リクエストヘッダーを用いて, 認証済トークンリクエストを生成する. クライアントは, リクエストにアクセストークンを含めるために OAuth 認証スキーマを用いる.

例:

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

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.) によって定義された下記に示すフレームワークに従う.

  credentials    = "OAuth" RWS access-token [ CS 1#auth-param ]
  access-token   = 1*( quoted-char / <"> )

  CS             = OWS "," OWS

  quoted-char    =   "!" / "#" / "$" / "%" / "&" / "'" / "("
                   / ")" / "*" / "+" / "-" / "." / "/" / DIGIT
                   / ":" / "<" / "=" / ">" / "?" / "@" / ALPHA
                   / "[" / "]" / "^" / "_" / "`" / "{" / "|"
                   / "}" / "~" / "\" / "," / ";"

注釈: [RFC5849] (Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.) は, OAuth 認証スキーマの異なるフォーマットを定義している. リソースサーバーは, 以前のバージョンで必須 (REQUIRED) とされていた oauth_signature_method パラメーターの有無を元に, 2つのバージョンを区別することができる. oauth_signature_method は本仕様ではサポートしていない.

5.1.2.  URI クエリーパラメーター

HTTPリクエストURIにアクセストークンを含める場合, クライアントは oauth_token パラメーターとして, [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) に定義するリクエストURIのクエリー部にアクセストークンを付与する.

例えば, クライアントはトランスポート層のセキュリティ機能を利用し, 次のようなHTTPリクエストを行う.

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

HTTPリクエストURIのクエリー部には, OAuth以外のリクエスト固有のパラメーターが含まれる可能性がある. その場合, oauth_token パラメーターはリクエスト固有のパラメーターの後ろに付与され, 適切に & (ASCII code 38) で分割されるべきである (SHOULD).

例:

  http://example.com/resource?x=y&oauth_token=vF9dft4qmT

注釈: oauth_token パラメーターは, [RFC5849] (Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.) に記載する以前のバージョンのOAuthプロトコルで用いられている. リソースサーバーは, 以前のバージョンで必須 (REQUIRED) とされていた oauth_signature_method パラメーターの有無を元に, 2つのバージョンを区別することができる. oauth_signature_method は本仕様ではサポートしていない.

5.1.3.  フォームエンコードボディーパラメーター

HTTPリクエストボディーにアクセストークンを含める場合, クライアントは oauth_token パラメーターとしてアクセストークンをリクエストボディーに付与する. クライアントは下記の必要条件 (REQUIRED) が成り立つ場合のみ, このメソッドを用いることができる.

• エンティティーボディーがシングルパートである.
• エンティティーボディーが [W3C.REC‑html401‑19991224] (Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) で定義される application/x-www-form-urlencoded コンテントタイプのエンコード要件を満たす
• HTTPリクエストエンティティーヘッダーの Content-Type フィールドが, application/x-www-form-urlencoded である.
• HTTPリクエストメソッドが POST, PUT, または DELETE である.

エンティティーボディーには, OAuth以外のリクエスト固有パラメーターが含まれる可能性がある. その場合, oauth_token パラメーターはリクエスト固有のパラメーターの後ろに付与され, 適切に & (ASCII code 38) で分割されるべきである (SHOULD).

例えば, クライアントはトランスポート層のセキュリティ機能を利用し, 次のようなHTTPリクエストを行う.

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

  oauth_token=vF9dft4qmT

注釈: oauth_token パラメーターは, [RFC5849] (Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.) に記載する以前のバージョンのOAuthプロトコルで用いられている. リソースサーバーは, 以前のバージョンで必須 (REQUIRED) とされていた oauth_signature_method パラメーターの有無を元に, 2つのバージョンを区別することができる. oauth_signature_method は本仕様ではサポートしていない.

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

保護リソースへのリクエストが, 不正または形式に問題があるアクセストークンを含む場合, リソースサーバーはHTTP WWW-Authenticate レスポンスヘッダーフィールドを含めなければならない (MUST). WWW-Authenticate は, [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.) により定義されている以下のフレームワークを使用する.

  challenge       = "OAuth" RWS token-challenge

  token-challenge = realm
                    [ CS error ]
                    [ CS error-desc ]
                    [ CS error-uri ]
                    [ CS scope ]
                    [ CS 1#auth-param ]

  error           = "error" "=" <"> token <">
  error-desc      = "error_description" "=" quoted-string
  error-uri       = "error_uri" = <"> URI-Reference <">
  scope           = quoted-value /
                    <"> quoted-value *( 1*SP quoted-value ) <">
  quoted-value    = 1*quoted-char

例:

  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: OAuth realm='Example Service', error='expired-token'

realm 属性は, [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.) に定義された通り, 保護リソース領域を分割するために使用される. [[ 説明を追加 ]]

error 属性は, リクエストが拒否された理由をクライアントに通知するために使用される. パラメーターの値は Section 5.2.1 (エラーコード) に記載する.

error_description 属性は, 追加情報を含んだ解読可能なテキストを提供し, エラー原因の理解と解明を助ける.

error_uri 属性は, エラーに関する情報をもつ解読可能なウェブページを識別するURIを提供し, エンドユーザーにエラーに関する追加情報を提供するために使用される. もし値が絶対URIでなければ, それはリクエストされた保護リソースに対する相対URIである.

scope 属性は, 要求されたリソースへのアクセスに必要となるスペース区切りのスコープ値のリストである. この属性は保護リソースへのアクセスに必要なアクセストークンのスコープを示す.

5.2.1.  エラーコード

invalid_request

必須のパラメーターを指定していない, サポートされていないパラメーターもしくは値を含んでいる, パラメーターに重複がある, アクセストークンを含むための2つ以上のメソッドを使っている, その他不正な形式のリクエスト. リソースサーバーは HTTP 400 (Bad Request)のステータスコードを応答しなければならない (MUST).

invalid_token

提供されたアクセストークンが無効. 新しい認可が必要であることをクライアントに示すために, リフレッシュできない期限切れのトークンを受け取った場合, リソースサーバーはこのエラーコードを使用するべきである (SHOULD). リソースサーバーは HTTP 401 (Unauthorized) ステータスコードを応答しなければならない (MUST).

expired_token

提供されたアクセストークンが期限切れ. リソースサーバーは, クライアントがレスポンスを受け取り, 期限切れアクセストークンとセットで発行されたリフレッシュトークンを用いて新しいアクセストークンをリクエストできると期待する場合のみ, このエラーコードを用いるべきである (SHOULD). リソースサーバーは HTTP 401 (Unauthorized) ステータスコードを返さなければならない (MUST).

insufficient_scope

リクエストはアクセストークンの持つ権限よりも, より高い権限を要求する. リソースサーバーは HTTP 403 (Forbidden) ステータスコードを返すべきである (SHOULD). また, 保護リソースのアクセスに必要なスコープを scope 属性として含んでもよい (MAY).

[[ エラーコードを拡張する仕組みを追加 ]]

リクエストが認証情報を欠いている場合 (例えば, クライアントが認証が必要なこと, またはサポートされていない認証方法を使って認証しようとしていることに気付かなかった場合), リソースサーバーはエラーコードおよびその他のエラー情報を含めてはならない (SHOULD).

例:

  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: OAuth realm='Example Service'

6.  拡張性

6.1.  クライアントクレデンシャルタイプの拡張

[[ TBD ]]

6.2.  エンドポイントパラメーターの拡張

エンドユーザー認可エンドポイントおよびトークンエンドポイントにおいて, リクエストおよびレスポンスパラメーターを追加定義するアプリケーションは, 以下の2つのいずれかを選択するものとする (SHALL). (Section 8.1 (OAuthパラメーターの登録) で定められた手順に従って) パラメーターレジストリーに登録する. x_ をパラメーター名のプレフィックスとして用いる.

x_ プレフィクスを用いるパラメーターは, ベンダー固有の拡張に限定する (MUST). これらの拡張は汎用に適用されるものではなく, パラメーターをサポートする認可サーバーの実装に固有のものである. これに該当しないパラメーターはレジストリー登録を必要とし (MUST), x_ プレフィックスを用いてはならない (MUST NOT).

パラメーター名はパラメーター名 ABNF に従い (MUST), パラメーター値のシンタックスは (ABNF や既存のパラメーターシンタックスを用いて) 明確に定義すること (MUST).

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

6.3.  ヘッダーパラメーターの拡張

OAuthの Authorization および WWW-Authenticate ヘッダーパラメーターを追加定義するアプリケーションは, パラメーターレジストリーへの登録を行うこと (MUST). レジストリーへの登録は Section 8.1 (OAuthパラメーターの登録) に従う.

パラメーター名はパラメーター名 ABNF に従い (MUST), x_ で始まってはならない (MUST NOT). パラメーター値はパラメーター値 ABNF に従い (MUST), そのシンタックスは (ABNF や既存のパラメーターシンタックスを用いて) 明確に定義すること (MUST).

  param-value  = quoted-value | quoted-string

6.4.  アクセス許可タイプの拡張

アサーションアクセス許可タイプは, 認可サーバーが本仕様で未定義の付加的なアクセス許可を受け入れることを想定している. アクセス許可タイプを追加するアプリケーションは, 新規および既存のアサーションタイプおよびフォーマットを利用することができる.

7.  Security Considerations

[[ TBD ]]

8.  IANAに関する考察

8.1.  OAuthパラメーターの登録

この文書はOAuthパラメーターの登録について規定する.

エンドユーザーの認可エンドポイントに対するリクエスト, エンドユーザーの認可エンドポイントからのレスポンス, トークンエンドポイントに対するリクエスト, トークンエンドポイントからのレスポンス, Authorization ヘッダーフィールド, および WWW-Authenticate ヘッダーフィールドで利用される追加パラメーターは, IESGまたは代理に選出されたものにより指名をうけた, 1名以上の指定専門家のアドバイスに基づいて, 要求仕様([RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) で使われる用語)とともに追加される. しかしながら, 公開に先立って値を割り当てる行為を許可するために, 指定専門家は将来仕様が公開される条件が満たされるなどした場合は, 値の登録を許可しても良い.

登録要求は, レビュー, コメントを目的として, 適切なサブジェクト (e.g., "Request for parameter: example") で [TBD]@ietf.org メーリングリストに対して送られるべきである. [[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation with the IESG and IANA. Suggested name: oauth-ext-review. ]]

14日の期間が経過する前に, 指定専門家は登録要求を承認するか棄却し, この決定はレビューリストとIANAの両方に通知される. 棄却には説明, または内容自体が妥当であるならば, どうすれば要求が受理されるかという提案が伴なっているべきである. 21日間を越えて未決となっている登録要求は, 解決のために (iesq@iesq.org メーリングリストを利用して) IESG宛に通知される.

8.1.1.  登録用テンプレート

パラメーター名:

要求名称 (e.g., "example").

パラメーター使用位置:

パラメーターが使用できる位置. 使用されうる位置は, エンドユーザー認可エンドポイントリクエスト, エンドユーザー認可エンドポイントレスポンス, トークンエンドポイントリクエスト, トークンエンドポイントレスポンス, Authorization ヘッダーフィールド, そして WWW-Authenticate ヘッダーフィールドである.

変更管理者:

標準化過程のRFCであるため, "IETF" と記載すること. その他, 責任ある当事者の名称を記載すること. 他の詳細 (e.g. 住所, メールアドレス, ホームページURI) を含んでいても良い.

仕様文書:

パラメーターを規定する文書への参照であり, 文書のコピーを取得することができるURIを含むことが望ましい. 関連する節の表示を含んでいても良いが, 必須ではない.

関連情報:

任意で, さらなる関連情報を含む追加の文書への引用を記載する.

8.1.2.  例

次の例は, この仕様書で定義されている scope パラメーターに対するパラメーター登録要求である.

パラメーター名:

scope

パラメーター使用位置:

エンドユーザー認可エンドポイントリクエスト, エンドユーザー認可エンドポイントレスポンス, トークンエンドポイントリクエスト, トークンエンドポイントレスポンス, および WWW-Authenticate ヘッダーフィールド.

変更管理者:

IETF

仕様文書:

[[ 本文書 ]]

関連情報:

なし.

Appendix A.  Examples

[[ TBD ]]

Appendix B.  Contributors

The following people contributed to preliminary versions of this document: Blaine Cook (BT), Brian Eaton (Google), Yaron Goland (Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter), Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and concepts within are a product of the OAuth community, WRAP community, and the OAuth Working Group.

The OAuth Working Group has dozens of very active contributors who proposed ideas and wording for this document, including: [[ If your name is missing or you think someone should be added here, please send Eran a note - don't be shy ]]

Michael Adams, Andrew Arnott, Dirk Balfanz, Brian Campbell, Leah Culver, Brian Ellin, Igor Faynberg, George Fletcher, Evan Gilbert, Justin Hart, John Kemp, Chasen Le Hara, Torsten Lodderstedt, Eve Maler, James Manger, Laurence Miao, Chuck Mortimore, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Justin Smith, Jeremy Suriel, and Franklin Tse.

Appendix C.  Acknowledgements

[[ Add OAuth 1.0a authors + WG contributors ]]

Appendix D.  Document History

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

-10

• Fixed typos. Many editorial changes. Rewrote introduction. removed terminology grouping.
• Allowed POST for end-user authorization endpoint.
• Fixed token endpoint to not require client authentication.
• Made URI query and POST body 'oauth_token' parameter optional.
• Moved all parameter names and values to use underscores.
• Changed 'basic_credentials' to 'password', 'invalid_client_credentials' and 'invalid_client_id' to 'invalid_client'.
• Added note that access token requests without an access grant should not include a refresh token.
• Changed scheme name from 'Token' to 'OAuth', simplified request format to simple string for token instead of key=value pair (still supported for extensions).
• Defined permitted access token string characters (suitable for inclusion in an HTTP header).
• Added a note about conflicts with previous versions.
• Moved 'client_id' definition from client authentication to access token endpoint.

-09

• Fixed typos, editorial changes.
• Added token expiration example.
• Added scope parameter to end-user authorization endpoint response.
• Added note about parameters with empty values (same as omitted).
• Changed parameter values to use '-' instead of '_'. Parameter names still use '_'.
• Changed authorization endpoint client type to response type with values: code, token, and both.
• Complete cleanup of error codes. Added support for error description and URI.
• Add initial extensibility support.

-08

• Renamed verification code to authorization code.
• Revised terminology, structured section, added new terms.
• Changed flows to profiles and moved to introduction.
• Added support for access token rescoping.
• Cleaned up client credentials section.
• New introduction overview.
• Added error code for invalid username and password, and renamed error code to be more consistent.
• Added access grant type parameter to token endpoint.

-07

• Major rewrite of entire document structure.
• Removed device profile.
• Added verification code support to user-agent flow.
• Removed multiple formats support, leaving JSON as the only format.
• Changed assertion assertion_format parameter to assertion_type.
• Removed type parameter from token endpoint.

-06

• Editorial changes, corrections, clarifications, etc.
• Removed conformance section.
• Moved authors section to contributors appendix.
• Added section on native applications.
• Changed error response to use the requested format. Added support for HTTP Accept header.
• Flipped the order of the web server and user-agent flows.
• Renamed assertion flow format parameter name to assertion_format to resolve conflict.
• Removed the term identifier from token definitions. Added a cryptographic token definition.
• Added figure titles.
• Added server response 401 when client tried to authenticate using multiple credentials.
• Clarified support for TLS alternatives, and added requirement for TLS 1.2 support for token endpoint.
• Removed all signature and cryptography.
• Removed all discovery.
• Updated HTML4 reference.

-05

• Corrected device example.
• Added client credentials parameters to the assertion flow as OPTIONAL.
• Added the ability to send client credentials using an HTTP authentication scheme.
• Initial text for the WWW-Authenticate header (also added scope support).
• Change authorization endpoint to end-user endpoint.
• In the device flow, change the user_uri parameter to verification_uri to avoid confusion with the end-user endpoint.
• Add format request parameter and support for XML and form-encoded responses.

-04

• Changed all token endpoints to use POST
• Clarified the authorization server's ability to issue a new refresh token when refreshing a token.
• Changed the flow categories to clarify the autonomous group.
• Changed client credentials language not to always be server-issued.
• Added a scope response parameter.
• Fixed typos.
• Fixed broken document structure.

-03

• Fixed typo in JSON error examples.
• Fixed general typos.
• Moved all flows sections up one level.

-02

• Removed restriction on redirect_uri including a query.
• Added scope parameter.
• Initial proposal for a JSON-based token response format.

-01

• Editorial changes based on feedback from Brian Eaton, Bill Keenan, and Chuck Mortimore.
• Changed device flow type parameter values and switch to use only the token endpoint.

-00

• Initial draft based on a combination of WRAP and OAuth 1.0a.

Appendix E.  翻訳者

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

• Daichi Morifuji
• Kazuyoshi Kato (mixi)
• Nov Matake (Cerego Japan)
• Nozomi Yamakawa (NRI)
• Ryo Ito
• Takanori Ishikawa (mixi)
• Tatsuya Katsuhara (NRI)
• Tom Tsuruhara (mixi)
• Toyoaki Ohgochi
• Yusuke Kondo (Yahoo! Japan)

9.  References

9.1. Normative References

9.2. Informative References

9.3. 翻訳プロジェクト

Authors' Addresses