Internet Engineering Task Force (IETF) D. Hardt, Ed. Request for Comments: 6749 Microsoft 廃止: 5849 2012年10月 分類: 標準化過程 ISSN: 2070-1721 OAuth 2.0 認可フレームワーク 概要 OAuth 2.0 認可フレームワークは、リソース所有者に代わって リソース所有者と HTTP サービスとの間の承認操作を仲介することにより、 またはサードパーティアプリケーションが自らのためにアクセスを 取得できるようにすることにより、サードパーティアプリケーションが HTTP サービスへの限定的なアクセスを取得できるようにする。 本仕様は、RFC 5849で記述された OAuth 1.0 プロトコルを 置き換え、廃止する。 本メモの位置付け これはインターネット標準化過程文書である。 本文書は Internet Engineering Task Force (IETF) の成果物である。 これは IETF コミュニティの合意を表している。本文書は公開レビューを 受け、Internet Engineering Steering Group (IESG) によって公開が 承認されている。インターネット標準に関する詳細情報は、 RFC 5741のSection 2で参照できる。 本文書の現在の状態、正誤表、およびフィードバックの提供方法に関する 情報は、次で入手できる。 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. Hardt 標準化過程 [Page 1]
RFC 6749 OAuth 2.0 2012年10月 目次 1. はじめに ....................................................4 1.1. 役割 ......................................................6 1.2. プロトコルフロー ..........................................7 1.3. 認可グラント ..............................................8 1.3.1. 認可コード ........................................8 1.3.2. インプリシット ....................................8 1.3.3. リソース所有者パスワード認証情報 ...................9 1.3.4. クライアント認証情報 ...............................9 1.4. アクセストークン ..........................................10 1.5. リフレッシュトークン ......................................10 1.6. TLS バージョン ............................................12 1.7. HTTP リダイレクト .........................................12 1.8. 相互運用性 ................................................12 1.9. 表記上の規約 ..............................................13 2. クライアント登録 ............................................13 2.1. クライアント種別 ..........................................14 2.2. クライアント識別子 ........................................15 2.3. クライアント認証 ..........................................16 2.3.1. クライアントパスワード .........................16 2.3.2. その他の認証方式 ...............................17 2.4. 未登録クライアント ........................................17 3. プロトコルエンドポイント ....................................18 3.1. 認可エンドポイント ........................................18 3.1.1. レスポンスタイプ ...............................19 3.1.2. リダイレクトエンドポイント .....................19 3.2. トークンエンドポイント ....................................21 3.2.1. クライアント認証 ...............................22 3.3. アクセストークンのスコープ .................................23 4. 認可の取得 ..................................................23 4.1. 認可コードグラント ........................................24 4.1.1. 認可リクエスト .................................25 4.1.2. 認可レスポンス .................................26 4.1.3. アクセストークンリクエスト .....................29 4.1.4. アクセストークンレスポンス .....................30 4.2. インプリシットグラント ....................................31 4.2.1. 認可リクエスト .................................33 4.2.2. アクセストークンレスポンス .....................35 4.3. リソース所有者パスワード認証情報グラント ...................37 4.3.1. 認可リクエストおよびレスポンス .................39 4.3.2. アクセストークンリクエスト .....................39 4.3.3. アクセストークンレスポンス .....................40 4.4. クライアント認証情報グラント ...............................40 4.4.1. 認可リクエストおよびレスポンス .................41 4.4.2. アクセストークンリクエスト .....................41 4.4.3. アクセストークンレスポンス .....................42 4.5. 拡張グラント ..............................................42 Hardt 標準化過程 [Page 2]
RFC 6749 OAuth 2.0 2012年10月 5. アクセストークンの発行 ........................................43 5.1. 成功レスポンス ............................................43 5.2. エラーレスポンス ..........................................45 6. アクセストークンの更新 ........................................47 7. 保護リソースへのアクセス ......................................48 7.1. アクセストークンタイプ ....................................49 7.2. エラーレスポンス ..........................................49 8. 拡張性 ......................................................50 8.1. アクセストークンタイプの定義 ...............................50 8.2. 新しいエンドポイントパラメータの定義 .......................50 8.3. 新しい認可グラントタイプの定義 .............................51 8.4. 新しい認可エンドポイントレスポンスタイプの定義 .............51 8.5. 追加エラーコードの定義 .....................................51 9. ネイティブアプリケーション ....................................52 10. セキュリティ考慮事項 .......................................53 10.1. クライアント認証 ....................................53 10.2. クライアントなりすまし ..............................54 10.3. アクセストークン ....................................55 10.4. リフレッシュトークン .................................55 10.5. 認可コード ..........................................56 10.6. 認可コードのリダイレクト URI 操作 ....................56 10.7. リソース所有者パスワード認証情報 .....................57 10.8. リクエストの機密性 ..................................58 10.9. エンドポイントの真正性の保証 ........................58 10.10. 認証情報推測攻撃 ....................................58 10.11. フィッシング攻撃 ....................................58 10.12. クロスサイトリクエストフォージェリ ..................59 10.13. クリックジャッキング ................................60 10.14. コードインジェクションと入力検証 ....................60 10.16. アクセストークンを誤用したインプリシットフローでの リソース所有者へのなりすまし ........................61 11. IANA 考慮事項 ...............................................62 11.1. OAuth アクセストークンタイプレジストリ ................62 11.1.1. 登録テンプレート .............................62 11.2. OAuth パラメータレジストリ ............................63 11.2.1. 登録テンプレート .............................63 11.2.2. 初期レジストリ内容 .........................64 11.3. OAuth 認可エンドポイントレスポンスタイプレジストリ .....66 11.3.1. 登録テンプレート .............................66 11.3.2. 初期レジストリ内容 .........................67 11.4. OAuth 拡張エラーレジストリ ...........................67 11.4.1. 登録テンプレート .............................68 12. 参考文献 ....................................................68 12.1. 規範参考文献 .........................................68 12.2. 参考情報文献 .........................................70 Hardt 標準化過程 [Page 3]
RFC 6749 OAuth 2.0 2012年10月 Appendix A. Augmented Backus-Naur Form (ABNF) 構文 ..............71 A.1. "client_id" 構文 ........................................71 A.2. "client_secret" 構文 ....................................71 A.3. "response_type" 構文 ....................................71 A.4. "scope" 構文 ............................................72 A.5. "state" 構文 ............................................72 A.6. "redirect_uri" 構文 .....................................72 A.7. "error" 構文 ............................................72 A.8. "error_description" 構文 ................................72 A.9. "error_uri" 構文 ........................................72 A.10. "grant_type" 構文 .......................................73 A.11. "code" 構文 .............................................73 A.12. "access_token" 構文 .....................................73 A.13. "token_type" 構文 .......................................73 A.14. "expires_in" 構文 .......................................73 A.15. "username" 構文 .........................................73 A.16. "password" 構文 .........................................73 A.17. "refresh_token" 構文 ....................................74 A.18. エンドポイントパラメータ構文 ............................74 Appendix B. application/x-www-form-urlencoded メディアタイプの使用 ...74 Appendix C. 謝辞 ................................................75 1. はじめに 従来のクライアントサーバー認証モデルでは、クライアントは リソース所有者の認証情報を使ってサーバーに認証することで、 サーバー上のアクセス制限付きリソース（保護リソース）を 要求する。サードパーティアプリケーションに制限付きリソースへの アクセスを提供するため、リソース所有者は自身の認証情報を そのサードパーティと共有する。これは、いくつかの問題と制限を 生じさせる。 o サードパーティアプリケーションは、将来の使用のために リソース所有者の認証情報、典型的には平文のパスワードを 保存する必要がある。 o サーバーは、パスワードに内在するセキュリティ上の弱点にも かかわらず、パスワード認証をサポートする必要がある。 o サードパーティアプリケーションは、リソース所有者の保護 リソースに対して過度に広いアクセスを得るため、リソース 所有者は期間やリソースの限定された部分集合へのアクセスを 制限する能力を持てない。 o リソース所有者は、すべてのサードパーティへのアクセスを 取り消すことなく、個々のサードパーティへのアクセスだけを 取り消すことができず、そのためにはサードパーティの パスワードを変更しなければならない。 Hardt 標準化過程 [Page 4]
RFC 6749 OAuth 2.0 2012年10月 o いずれかのサードパーティアプリケーションが侵害されると、 エンドユーザーのパスワード、およびそのパスワードで保護 されたすべてのデータが侵害される。 OAuth は、認可レイヤーを導入し、クライアントの役割を リソース所有者の役割から分離することで、これらの問題に 対処する。OAuth では、クライアントはリソース所有者が管理し リソースサーバーがホストするリソースへのアクセスを要求し、 リソース所有者の認証情報とは異なる一組の認証情報を発行される。 保護リソースへアクセスするためにリソース所有者の認証情報を 使用する代わりに、クライアントはアクセストークンを取得する。 これは、特定のスコープ、有効期間、およびその他のアクセス属性を 示す文字列である。アクセストークンは、リソース所有者の承認に 基づき、認可サーバーによってサードパーティクライアントに 発行される。クライアントはアクセストークンを使用して、 リソースサーバーがホストする保護リソースにアクセスする。 たとえば、エンドユーザー（リソース所有者）は、自身のユーザー名と パスワードを印刷サービスと共有することなく、写真共有サービス （リソースサーバー）に保存された自身の保護写真へのアクセスを、 印刷サービス（クライアント）に許可できる。代わりに、彼女は 写真共有サービスに信頼されたサーバー（認可サーバー）で直接 認証し、そのサーバーが印刷サービスに委任固有の認証情報 （アクセストークン）を発行する。 本仕様は HTTP（[RFC2616]）で使用するよう設計されている。 HTTP 以外の任意のプロトコル上で OAuth を使用することは、 本仕様の範囲外である。 情報文書として公開された OAuth 1.0 プロトコル（[RFC5849]）は、 小規模なアドホックコミュニティの取り組みの結果であった。 本標準化過程仕様は、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 に精通している実装者は、 その構造および詳細について何の仮定もせずに本文書に取り組むべきである。 Hardt 標準化過程 [Page 5]
RFC 6749 OAuth 2.0 2012年10月 1.1. 役割 OAuth は 4 つの役割を定義する。 resource owner 保護リソースへのアクセスを許可できるエンティティ。 リソース所有者が人である場合、それはエンドユーザーと呼ばれる。 resource server 保護リソースをホストし、アクセストークンを使用した保護 リソース要求を受け入れて応答できるサーバー。 client リソース所有者に代わり、その認可を受けて保護リソース要求を 行うアプリケーション。「client」という用語は、特定の実装上の 特性（たとえば、アプリケーションがサーバー上、デスクトップ上、 またはその他のデバイス上で実行されるかどうか）を意味しない。 authorization server リソース所有者の認証に成功し、認可を得た後、クライアントに アクセストークンを発行するサーバー。 認可サーバーとリソースサーバーの間の相互作用は、本仕様の 範囲外である。認可サーバーはリソースサーバーと同じサーバーで あっても、別個のエンティティであってもよい。単一の認可サーバーが、 複数のリソースサーバーに受け入れられるアクセストークンを 発行してもよい。 Hardt 標準化過程 [Page 6]
RFC 6749 OAuth 2.0 2012年10月 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 ---| | +--------+ +---------------+ 図 1: 抽象プロトコルフロー 図 1 に示す抽象的な OAuth 2.0 フローは、4 つの役割間の相互作用を 説明し、次の手順を含む。 (A) クライアントはリソース所有者に認可を要求する。認可要求は、 （図示のように）リソース所有者に直接行うことも、望ましくは 認可サーバーを仲介者として間接的に行うこともできる。 (B) クライアントは認可グラントを受け取る。これはリソース 所有者の認可を表す認証情報であり、本仕様で定義される 4 つの グラントタイプのいずれか、または拡張グラントタイプを 使用して表現される。認可グラントタイプは、クライアントが 認可を要求するために用いる方法と、認可サーバーがサポートする タイプに依存する。 (C) クライアントは、認可サーバーに認証し、認可グラントを提示する ことでアクセストークンを要求する。 (D) 認可サーバーはクライアントを認証し、認可グラントを検証し、 有効であればアクセストークンを発行する。 Hardt 標準化過程 [Page 7]
RFC 6749 OAuth 2.0 2012年10月 (E) クライアントはリソースサーバーに保護リソースを要求し、 アクセストークンを提示して認証する。 (F) リソースサーバーはアクセストークンを検証し、有効であれば 要求に応答する。 クライアントがリソース所有者から認可グラントを取得するための 推奨される方法（手順 (A) および (B) に示される）は、認可サーバーを 仲介者として使用することであり、これは Section 4.1 の 図 3 に示されている。 1.3. 認可グラント 認可グラントは、リソース所有者の認可（その保護リソースに アクセスするための認可）を表す認証情報であり、クライアントが アクセストークンを取得するために使用する。本仕様は 4 つの グラントタイプ、すなわち認可コード、インプリシット、リソース 所有者パスワード認証情報、およびクライアント認証情報を定義し、 さらに追加のタイプを定義するための拡張メカニズムも定義する。 1.3.1. 認可コード 認可コードは、クライアントとリソース所有者の間の仲介者として 認可サーバーを使用することで取得される。リソース所有者に直接 認可を要求する代わりに、クライアントはリソース所有者を （[RFC2616] で定義されるユーザーエージェントを介して） 認可サーバーへ誘導し、その認可サーバーはリソース所有者を 認可コードとともにクライアントへ戻す。 認可サーバーは、リソース所有者を認可コードとともにクライアントへ 戻す前に、リソース所有者を認証し、認可を取得する。リソース所有者は 認可サーバーでのみ認証するため、リソース所有者の認証情報が クライアントと共有されることはない。 認可コードは、クライアントを認証できることや、アクセストークンを リソース所有者のユーザーエージェントを通過させずに直接 クライアントへ送信できることなど、いくつかの重要なセキュリティ上の 利点を提供する。これにより、リソース所有者を含む他者に アクセストークンが露出する可能性を避けられる。 1.3.2. インプリシット インプリシットグラントは、JavaScript などのスクリプト言語を使って ブラウザー内に実装されたクライアント向けに最適化された、 簡略化された認可コードフローである。インプリシットフローでは、 クライアントに認可コードを発行する代わりに、クライアントには アクセストークンが直接発行される。 Hardt 標準化過程 [Page 8]
RFC 6749 OAuth 2.0 2012年10月 （リソース所有者の認可の結果として）。このグラントタイプが インプリシットであるのは、（認可コードなどの）中間的な認証情報が 発行されず、後でアクセストークンを取得するために使用されないためである。 インプリシットグラントフロー中にアクセストークンを発行するとき、 認可サーバーはクライアントを認証しない。場合によっては、 アクセストークンをクライアントへ配送するために使用される リダイレクト URI によってクライアントの識別情報を検証できる。 アクセストークンは、リソース所有者、またはリソース所有者の ユーザーエージェントにアクセスできる他のアプリケーションに 露出する可能性がある。 インプリシットグラントは、（ブラウザー内アプリケーションとして 実装されたクライアントなど）一部のクライアントの応答性と効率を 向上させる。これは、アクセストークンを取得するために必要な 往復回数を減らすためである。しかし、この利便性は、 10.3 節および 10.16 節で説明されるようなインプリシット グラントの使用によるセキュリティ上の影響と比較衡量すべきであり、 特に認可コードグラントタイプが利用可能な場合はそうである。 1.3.3. リソース所有者パスワード認証情報 リソース所有者パスワード認証情報（すなわち、ユーザー名と パスワード）は、アクセストークンを取得するための認可グラントとして 直接使用できる。この認証情報は、リソース所有者とクライアントの間に 高い信頼関係がある場合（たとえば、クライアントがデバイスの オペレーティングシステムの一部である、または高い権限を持つ アプリケーションである場合）で、かつ他の認可グラントタイプ （認可コードなど）が利用できない場合にのみ使用されるべきである。 このグラントタイプは、クライアントがリソース所有者の認証情報へ 直接アクセスすることを必要とするが、リソース所有者の認証情報は 1 回のリクエストで使用され、アクセストークンと交換される。 このグラントタイプでは、認証情報を長寿命のアクセストークンまたは リフレッシュトークンと交換することにより、クライアントが将来の 使用のためにリソース所有者の認証情報を保存する必要をなくせる。 1.3.4. クライアント認証情報 クライアント認証情報（または他の形式のクライアント認証）は、 認可スコープがクライアントの制御下にある保護リソースに限定される 場合、または認可サーバーと事前に取り決められた保護リソースに 限定される場合に、認可グラントとして使用できる。クライアント 認証情報は、典型的にはクライアントが自らのために動作している 場合（クライアントがリソース所有者でもある場合）、または 認可サーバーと事前に取り決められた認可に基づいて保護リソースへの アクセスを要求している場合に、認可グラントとして使用される。 Hardt 標準化過程 [Page 9]
RFC 6749 OAuth 2.0 2012年10月 1.4. アクセストークン アクセストークンは、保護リソースへアクセスするために使用される 認証情報である。アクセストークンは、クライアントに発行された 認可を表す文字列である。この文字列は通常、クライアントにとって 不透明である。トークンは、リソース所有者によって許可され、 リソースサーバーおよび認可サーバーによって強制される、特定の スコープとアクセス期間を表す。 トークンは、認可情報を取得するために使用される識別子を示す場合も、 認可情報を検証可能な方法で自己包含する場合もある（すなわち、 何らかのデータと署名から成るトークン文字列）。クライアントが トークンを使用するためには、本仕様の範囲外である追加の認証情報が 必要となる場合がある。 アクセストークンは抽象化レイヤーを提供し、異なる認可構成物 （たとえば、ユーザー名とパスワード）を、リソースサーバーが 理解する単一のトークンに置き換える。この抽象化により、 アクセストークンを、それを取得するために使用された認可グラントより も制限されたものとして発行でき、またリソースサーバーが広範な 認証方式を理解する必要もなくなる。 アクセストークンは、リソースサーバーのセキュリティ要件に基づいて、 形式、構造、および利用方法（たとえば、暗号学的性質）が異なる 場合がある。アクセストークンの属性および保護リソースへアクセス するために使用される方法は、本仕様の範囲外であり、[RFC6750] などの 関連仕様によって定義される。 1.5. リフレッシュトークン リフレッシュトークンは、アクセストークンを取得するために使用される 認証情報である。リフレッシュトークンは認可サーバーによって クライアントに発行され、現在のアクセストークンが無効になるか 期限切れになったときに新しいアクセストークンを取得するため、 または同一もしくはより狭いスコープを持つ追加のアクセストークンを 取得するために使用される（アクセストークンは、リソース所有者により 認可されたものより短い有効期間および少ない権限を持つ場合がある）。 リフレッシュトークンの発行は、認可サーバーの裁量による任意である。 認可サーバーがリフレッシュトークンを発行する場合、それは アクセストークンの発行時に含められる（すなわち、図 1 の手順 (D)）。 リフレッシュトークンは、リソース所有者からクライアントに付与された 認可を表す文字列である。この文字列は通常、クライアントにとって 不透明である。トークンは、認可情報を取得するために使用される Hardt 標準化過程 [Page 10]
RFC 6749 OAuth 2.0 2012年10月 識別子を示す。アクセストークンとは異なり、リフレッシュトークンは 認可サーバーでのみ使用されることを意図しており、リソースサーバーへ 送信されることは決してない。 +--------+ +---------------+ | |--(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 +---------------+ 図 2: 期限切れアクセストークンの更新 図 2 に示すフローは、次の手順を含む。 (A) クライアントは、認可サーバーに認証し、認可グラントを提示する ことでアクセストークンを要求する。 (B) 認可サーバーはクライアントを認証し、認可グラントを検証し、 有効であればアクセストークンとリフレッシュトークンを発行する。 (C) クライアントは、アクセストークンを提示することで、 リソースサーバーに保護リソース要求を行う。 (D) リソースサーバーはアクセストークンを検証し、有効であれば 要求に応答する。 (E) アクセストークンが期限切れになるまで、手順 (C) と (D) を 繰り返す。クライアントがアクセストークンの期限切れを 知っている場合は手順 (G) へ進み、そうでなければ別の 保護リソース要求を行う。 (F) アクセストークンが無効であるため、リソースサーバーは 無効なトークンエラーを返す。 Hardt 標準化過程 [Page 11]
RFC 6749 OAuth 2.0 2012年10月 (G) クライアントは、認可サーバーに認証し、リフレッシュトークンを 提示することで新しいアクセストークンを要求する。クライアント 認証の要件は、クライアント種別および認可サーバーのポリシーに 基づく。 (H) 認可サーバーはクライアントを認証し、リフレッシュトークンを 検証し、有効であれば新しいアクセストークン（および任意で 新しいリフレッシュトークン）を発行する。 手順 (C)、(D)、(E)、および (F) は、Section 7 で説明されるように、 本仕様の範囲外である。 1.6. TLS バージョン 本仕様で Transport Layer Security (TLS) が使用される場合はいつでも、 適切な TLS のバージョン（または複数のバージョン）は、広範な展開状況 および既知のセキュリティ脆弱性に基づいて、時とともに変化する。 本書執筆時点では、TLS バージョン 1.2 [RFC5246] が最新の バージョンであるが、展開基盤は非常に限定的であり、実装において すぐに利用可能でない場合がある。TLS バージョン 1.0 [RFC2246] は 最も広く展開されているバージョンであり、最も広い相互運用性を 提供する。 実装は、そのセキュリティ要件を満たす追加のトランスポート層 セキュリティメカニズムもサポートしてよい（MAY）。 1.7. HTTP リダイレクト 本仕様は HTTP リダイレクトを広範に使用する。これは、クライアント または認可サーバーが、リソース所有者のユーザーエージェントを 別の宛先へ誘導するものである。本仕様の例では HTTP 302 ステータス コードの使用を示しているが、このリダイレクトを実現するために ユーザーエージェントを介して利用可能なその他の任意の方法も許可され、 実装上の詳細とみなされる。 1.8. 相互運用性 OAuth 2.0 は、明確に定義されたセキュリティ特性を持つ豊富な 認可フレームワークを提供する。しかし、多くの任意コンポーネントを 持つ豊富で高度に拡張可能なフレームワークであるため、本仕様だけでは 幅広い相互運用できない実装を生み出す可能性が高い。 加えて、本仕様はいくつかの必須コンポーネントを部分的または完全に 未定義のままにしている（たとえば、クライアント登録、認可サーバーの 機能、エンドポイント発見）。これらのコンポーネントがなければ、 Hardt 標準化過程 [Page 12]
RFC 6749 OAuth 2.0 2012年10月 クライアントは相互運用するために、特定の認可サーバーおよび リソースサーバーに対して手動かつ個別に設定されなければならない。 このフレームワークは、完全なウェブ規模の相互運用性を実現するために 必要な規範的プロファイルおよび拡張を、将来の作業が定義するという 明確な期待のもとで設計された。 1.9. 表記上の規約 本仕様におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は、[RFC2119] で説明されるように解釈される。 本仕様は、[RFC5234] の Augmented Backus-Naur Form (ABNF) 記法を 使用する。さらに、規則 URI-reference は "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986] から取り込まれる。 セキュリティ関連の特定の用語は、[RFC4949] で定義される意味で 理解される。これらの用語には、"attack", "authentication", "authorization", "certificate", "confidentiality", "credential", "encryption", "identity", "sign", "signature", "trust", "validate", および "verify" が含まれるが、これらに限定されない。 特に明記されない限り、すべてのプロトコルパラメータ名および値は 大文字と小文字を区別する。 2. クライアント登録 プロトコルを開始する前に、クライアントは認可サーバーに登録する。 クライアントが認可サーバーに登録する手段は本仕様の範囲外であるが、 典型的にはエンドユーザーと HTML 登録フォームとの相互作用を伴う。 クライアント登録は、クライアントと認可サーバーの間の直接的な 相互作用を必要としない。認可サーバーがサポートする場合、登録は 信頼を確立し、必要なクライアントプロパティ（たとえば、 リダイレクト URI、クライアント種別）を取得するための他の手段に 依拠できる。たとえば、登録は自己発行またはサードパーティ発行の アサーションを使用して達成でき、または認可サーバーが信頼された チャネルを使用してクライアント発見を行うことで達成できる。 Hardt 標準化過程 [Page 13]
RFC 6749 OAuth 2.0 2012年10月 クライアントを登録するとき、クライアント開発者は次を行わなければ ならない（SHALL）。 o Section 2.1 で説明されるクライアント種別を指定すること。 o Section 3.1.2 で説明されるクライアントのリダイレクト URI を 提供すること、および o 認可サーバーが要求するその他の情報（たとえば、アプリケーション名、 Web サイト、説明、ロゴ画像、法的条件への同意）を含めること。 2.1. クライアント種別 OAuth は、認可サーバーに対して安全に認証できる能力（すなわち、 クライアント認証情報の機密性を維持する能力）に基づいて、 2 つのクライアント種別を定義する。 confidential 認証情報の機密性を維持できるクライアント（たとえば、 クライアント認証情報へのアクセスが制限された安全なサーバー上に 実装されたクライアント）、または他の手段を使用して安全な クライアント認証が可能なクライアント。 public 認証情報の機密性を維持できないクライアント（たとえば、 インストールされたネイティブアプリケーションやブラウザー ベースのアプリケーションなど、リソース所有者が使用するデバイス上で 実行されるクライアント）であり、他のいかなる手段によっても 安全なクライアント認証ができないクライアント。 クライアント種別の指定は、認可サーバーによる安全な認証の定義と、 クライアント認証情報の許容される露出レベルに基づく。認可サーバーは クライアント種別について仮定すべきではない（SHOULD NOT）。 クライアントは、異なるクライアント種別およびセキュリティ コンテキストを持つコンポーネントの分散集合として実装されてもよい （たとえば、機密サーバーベースコンポーネントと公開ブラウザー ベースコンポーネントの両方を持つ分散クライアント）。認可サーバーが そのようなクライアントをサポートしない場合、またはその登録に関する 指針を提供しない場合、クライアントは各コンポーネントを別個の クライアントとして登録すべきである（SHOULD）。 Hardt 標準化過程 [Page 14]
RFC 6749 OAuth 2.0 2012年10月 本仕様は、次のクライアントプロファイルを念頭に設計されている。 web application Web アプリケーションは、Web サーバー上で動作する confidential client である。リソース所有者は、リソース所有者が使用する デバイス上のユーザーエージェントでレンダリングされる HTML ユーザーインターフェイスを介してクライアントにアクセスする。 クライアント認証情報、およびクライアントに発行された任意の アクセストークンは Web サーバー上に保存され、リソース所有者に 露出したりアクセス可能になったりしない。 user-agent-based application ユーザーエージェントベースのアプリケーションは public client であり、 クライアントコードが Web サーバーからダウンロードされ、 リソース所有者が使用するデバイス上のユーザーエージェント （たとえば Web ブラウザー）内で実行される。プロトコルデータおよび 認証情報は、リソース所有者が容易にアクセスできる（そして多くの 場合、見える）。このようなアプリケーションはユーザーエージェント内に 存在するため、認可を要求するときにユーザーエージェントの機能を シームレスに利用できる。 native application ネイティブアプリケーションは、リソース所有者が使用するデバイスに インストールされ実行される public client である。プロトコルデータと 認証情報はリソース所有者がアクセスできる。アプリケーションに 含まれる任意のクライアント認証情報は抽出可能であると仮定される。 一方、アクセストークンやリフレッシュトークンなど、動的に発行される 認証情報は、許容可能なレベルの保護を受けることができる。最低限、 これらの認証情報は、アプリケーションが相互作用する可能性のある 悪意あるサーバーから保護される。一部のプラットフォームでは、 これらの認証情報は同じデバイス上に存在する他のアプリケーションから 保護される場合がある。 2.2. クライアント識別子 認可サーバーは、登録されたクライアントにクライアント識別子を 発行する。これは、クライアントによって提供された登録情報を 表す一意の文字列である。クライアント識別子は秘密ではない。 それはリソース所有者に露出され、単独でクライアント認証に 使用してはならない（MUST NOT）。クライアント識別子は認可サーバーに 対して一意である。 クライアント識別子文字列のサイズは、本仕様では未定義のままとする。 クライアントは識別子のサイズについて仮定することを避けるべきである。 認可サーバーは、自らが発行する任意の識別子のサイズを文書化すべきである （SHOULD）。 Hardt 標準化過程 [Page 15]
RFC 6749 OAuth 2.0 2012年10月 2.3. クライアント認証 クライアント種別が confidential である場合、クライアントと 認可サーバーは、認可サーバーのセキュリティ要件に適した クライアント認証方式を確立する。認可サーバーは、自らの セキュリティ要件を満たす任意の形式のクライアント認証を 受け入れてよい（MAY）。 confidential client には、通常、認可サーバーに対して認証するために 使用される一組のクライアント認証情報（たとえば、パスワード、 公開鍵/秘密鍵ペア）が発行される（または確立される）。 認可サーバーは、public client とクライアント認証方式を確立してもよい （MAY）。ただし、認可サーバーは、クライアントを識別する目的で public client 認証に依拠してはならない（MUST NOT）。 クライアントは、各リクエストで複数の認証方式を使用してはならない （MUST NOT）。 2.3.1. クライアントパスワード クライアントパスワードを所有するクライアントは、認可サーバーに 認証するため、[RFC2617] で定義される HTTP Basic 認証スキームを 使用してよい（MAY）。クライアント識別子は Appendix B に従い "application/x-www-form-urlencoded" 符号化アルゴリズムを使用して 符号化され、その符号化値がユーザー名として使用される。 クライアントパスワードは同じアルゴリズムで符号化され、 パスワードとして使用される。認可サーバーは、クライアント パスワードを発行されたクライアントを認証するために、HTTP Basic 認証スキームをサポートしなければならない（MUST）。 例（表示目的のためだけに余分な改行を含む）。 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 あるいは、認可サーバーは、次のパラメータを使用してリクエスト ボディにクライアント認証情報を含めることをサポートしてよい（MAY）。 client_id 必須（REQUIRED）。Section 2.2 で説明される登録プロセス中に クライアントへ発行されたクライアント識別子。 client_secret 必須（REQUIRED）。クライアントシークレット。クライアント シークレットが空文字列である場合、クライアントはこの パラメータを省略してよい（MAY）。 Hardt 標準化過程 [Page 16]
RFC 6749 OAuth 2.0 2012年10月 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 の使用を要求しなければならない （MUST）。 このクライアント認証方式はパスワードを伴うため、認可サーバーは それを利用する任意のエンドポイントをブルートフォース攻撃から 保護しなければならない（MUST）。 2.3.2. その他の認証方式 認可サーバーは、自らのセキュリティ要件に合致する任意の適切な HTTP 認証スキームをサポートしてよい（MAY）。その他の認証方式を 使用する場合、認可サーバーは、クライアント識別子（登録レコード）と 認証スキームとの間の対応を定義しなければならない（MUST）。 2.4. 未登録クライアント 本仕様は、未登録クライアントの使用を排除しない。ただし、 そのようなクライアントの使用は本仕様の範囲外であり、追加の セキュリティ分析と、相互運用性への影響に関するレビューを必要とする。 Hardt 標準化過程 [Page 17]
RFC 6749 OAuth 2.0 2012年10月 3. プロトコルエンドポイント 認可プロセスは、2 つの認可サーバーエンドポイント（HTTP リソース）を 利用する。 o 認可エンドポイント - ユーザーエージェントのリダイレクトを介して、 リソース所有者から認可を取得するためにクライアントが使用する。 o トークンエンドポイント - クライアントが、通常はクライアント認証を 伴って、認可グラントをアクセストークンと交換するために使用する。 さらに 1 つのクライアントエンドポイントがある。 o リダイレクトエンドポイント - 認可サーバーが、リソース所有者の ユーザーエージェントを介して、認可認証情報を含むレスポンスを クライアントへ返すために使用する。 すべての認可グラントタイプが両方のエンドポイントを利用するわけでは ない。拡張グラントタイプは、必要に応じて追加のエンドポイントを 定義してよい（MAY）。 3.1. 認可エンドポイント 認可エンドポイントは、リソース所有者と相互作用し、認可グラントを 取得するために使用される。認可サーバーは、まずリソース所有者の 識別情報を検証しなければならない（MUST）。認可サーバーが リソース所有者を認証する方法（たとえば、ユーザー名とパスワードの ログイン、セッション Cookie）は、本仕様の範囲外である。 クライアントが認可エンドポイントの場所を取得する手段は、本仕様の 範囲外であるが、その場所は通常サービス文書で提供される。 エンドポイント URI は、Appendix B に従う "application/x-www-form-urlencoded" 形式のクエリコンポーネント （[RFC3986] Section 3.4）を含んでよく（MAY）、 追加のクエリパラメータを追加するときはそれを保持しなければならない （MUST）。エンドポイント URI はフラグメントコンポーネントを 含んではならない（MUST NOT）。 認可エンドポイントへのリクエストは、ユーザー認証および平文の 認証情報の送信（HTTP レスポンス内）をもたらすため、認可サーバーは 認可エンドポイントへリクエストを送信するとき、Section 1.6 で 説明される TLS の使用を要求しなければならない（MUST）。 認可サーバーは、認可エンドポイントに対する HTTP "GET" メソッド [RFC2616] の使用をサポートしなければならず（MUST）、"POST" メソッドの使用もサポートしてよい（MAY）。 Hardt 標準化過程 [Page 18]
RFC 6749 OAuth 2.0 2012年10月 値なしで送信されたパラメータは、リクエストから省略されたものとして 扱わなければならない（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] Section 4.3 で 定義される絶対 URI でなければならない（MUST）。エンドポイント URI は Appendix B に従う "application/x-www-form-urlencoded" 形式の クエリコンポーネント（[RFC3986] Section 3.4）を含んでよく（MAY）、 追加のクエリパラメータを追加するときはそれを保持しなければならない （MUST）。エンドポイント URI はフラグメントコンポーネントを 含んではならない（MUST NOT）。 Hardt 標準化過程 [Page 19]
RFC 6749 OAuth 2.0 2012年10月 3.1.2.1. エンドポイントリクエストの機密性 リダイレクトエンドポイントは、要求されたレスポンスタイプが "code" または "token" である場合、またはリダイレクトリクエストが オープンネットワーク上で機微な認証情報の送信をもたらす場合、 Section 1.6 で説明される TLS の使用を要求すべきである（SHOULD）。 本仕様は TLS の使用を義務付けない。なぜなら、本書執筆時点では、 クライアントに TLS の導入を要求することは、多くのクライアント 開発者にとって大きな障壁であるためである。TLS が利用できない場合、 認可サーバーはリダイレクト前に、安全でないエンドポイントについて リソース所有者に警告すべきである（SHOULD）（たとえば、認可 リクエスト中にメッセージを表示する）。 トランスポート層セキュリティの欠如は、クライアントおよび それにアクセスが認可されている保護リソースのセキュリティに 重大な影響を与える可能性がある。トランスポート層セキュリティの使用は、 認可プロセスがクライアントによる委任されたエンドユーザー認証の 一形態として使用される場合（たとえば、サードパーティ サインインサービス）に特に重要である。 3.1.2.2. 登録要件 認可サーバーは、次のクライアントにリダイレクトエンドポイントの 登録を要求しなければならない（MUST）。 o Public clients. o インプリシットグラントタイプを利用する confidential clients。 認可サーバーは、認可エンドポイントを利用する前に、すべての クライアントにリダイレクトエンドポイントの登録を要求すべきである （SHOULD）。 認可サーバーは、クライアントに完全なリダイレクト URI の提供を 要求すべきである（SHOULD）（クライアントは、リクエストごとの カスタマイズを実現するために "state" リクエストパラメータを 使用してよい（MAY））。完全なリダイレクト URI の登録を要求することが 可能でない場合、認可サーバーは URI の scheme、authority、および path の登録を要求すべきである（SHOULD）（認可を要求するときに、 クライアントがリダイレクト URI の query コンポーネントだけを 動的に変更できるようにする）。 認可サーバーは、クライアントに複数のリダイレクトエンドポイントの 登録を許可してよい（MAY）。 リダイレクト URI 登録要件がない場合、攻撃者は認可エンドポイントを、 Section 10.15 で説明されるオープンリダイレクターとして 使用できるようになる可能性がある。 Hardt 標準化過程 [Page 20]
RFC 6749 OAuth 2.0 2012年10月 3.1.2.3. 動的設定 複数のリダイレクト URI が登録されている場合、リダイレクト URI の 一部のみが登録されている場合、またはリダイレクト URI が登録されて いない場合、クライアントは "redirect_uri" リクエストパラメータを 使用して、認可リクエストにリダイレクト URI を含めなければならない （MUST）。 リダイレクト URI が認可リクエストに含まれる場合、認可サーバーは、 リダイレクト URI が登録されているならば、[RFC3986] Section 6 で 定義されるように、受信した値を少なくとも 1 つの登録済み リダイレクト URI（または URI コンポーネント）と比較し一致させ なければならない（MUST）。クライアント登録に完全なリダイレクト URI が 含まれていた場合、認可サーバーは [RFC3986] Section 6.2.1 で 定義される単純な文字列比較を使用して、2 つの 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. トークンエンドポイント トークンエンドポイントは、クライアントが認可グラントまたは リフレッシュトークンを提示することでアクセストークンを取得するために 使用される。トークンエンドポイントは、アクセストークンが直接 発行されるインプリシットグラントタイプを除く、すべての認可 グラントで使用される。 Hardt 標準化過程 [Page 21]
RFC 6749 OAuth 2.0 2012年10月 クライアントがトークンエンドポイントの場所を取得する手段は、 本仕様の範囲外であるが、その場所は通常サービス文書で提供される。 エンドポイント URI は、Appendix B に従う "application/x-www-form-urlencoded" 形式のクエリコンポーネント （[RFC3986] Section 3.4）を含んでよく（MAY）、 追加のクエリパラメータを追加するときはそれを保持しなければならない （MUST）。エンドポイント URI はフラグメントコンポーネントを 含んではならない（MUST NOT）。 トークンエンドポイントへのリクエストは、（HTTP リクエストおよび レスポンス内で）平文の認証情報の送信をもたらすため、認可サーバーは トークンエンドポイントへリクエストを送信するとき、Section 1.6 で 説明される TLS の使用を要求しなければならない（MUST）。 クライアントは、アクセストークンリクエストを行うとき HTTP "POST" メソッドを使用しなければならない（MUST）。 値なしで送信されたパラメータは、リクエストから省略されたものとして 扱わなければならない（MUST）。認可サーバーは、認識できない リクエストパラメータを無視しなければならない（MUST）。リクエスト およびレスポンスパラメータは、複数回含めてはならない（MUST NOT）。 3.2.1. クライアント認証 confidential client またはクライアント認証情報を発行されたその他の クライアントは、トークンエンドポイントへリクエストを行うとき、 Section 2.3 で説明されるように認可サーバーに認証しなければ ならない（MUST）。クライアント認証は次のために使用される。 o リフレッシュトークンおよび認可コードを、それらが発行された クライアントへ結び付けることを強制する。認可コードが安全でない チャネルでリダイレクトエンドポイントへ送信される場合、または リダイレクト URI が完全には登録されていない場合、クライアント 認証は極めて重要である。 o クライアントを無効化するか、その認証情報を変更することで、 侵害されたクライアントから復旧し、攻撃者が盗まれた リフレッシュトークンを悪用することを防ぐ。単一のクライアント 認証情報セットを変更することは、リフレッシュトークンの集合全体を 取り消すよりも大幅に速い。 o 定期的な認証情報のローテーションを必要とする、認証管理の ベストプラクティスを実装する。リフレッシュトークンの集合全体の ローテーションは困難である場合がある一方、単一のクライアント 認証情報セットのローテーションは大幅に容易である。 Hardt 標準化過程 [Page 22]
RFC 6749 OAuth 2.0 2012年10月 クライアントは、トークンエンドポイントへリクエストを送信するとき、 自身を識別するために "client_id" リクエストパラメータを使用してよい （MAY）。トークンエンドポイントへの "authorization_code" の "grant_type" リクエストでは、認証されていないクライアントは、 異なる "client_id" を持つクライアントを意図したコードを誤って 受け入れることを防ぐため、自身の "client_id" を送信しなければ ならない（MUST）。これは、認証コードの置換からクライアントを保護する。 （保護リソースに対して追加のセキュリティを提供するものではない。） 3.3. アクセストークンのスコープ 認可エンドポイントおよびトークンエンドポイントは、クライアントが "scope" リクエストパラメータを使用してアクセスリクエストの スコープを指定することを可能にする。これに対し、認可サーバーは "scope" レスポンスパラメータを使用して、発行されたアクセストークンの スコープをクライアントに通知する。 scope パラメータの値は、空白区切りで、大文字と小文字を区別する 文字列のリストとして表現される。文字列は認可サーバーによって 定義される。値が複数の空白区切り文字列を含む場合、その順序は 重要ではなく、各文字列は要求されたスコープに追加のアクセス範囲を 加える。 scope = scope-token *( SP scope-token ) scope-token = 1*( %x21 / %x23-5B / %x5D-7E ) 認可サーバーは、認可サーバーのポリシーまたはリソース所有者の指示に 基づき、クライアントによって要求されたスコープを完全に、または 部分的に無視してよい（MAY）。発行されたアクセストークンのスコープが クライアントによって要求されたものと異なる場合、認可サーバーは 実際に付与されたスコープをクライアントに通知するため、"scope" レスポンスパラメータを含めなければならない（MUST）。 クライアントが認可を要求するとき scope パラメータを省略した場合、 認可サーバーは、あらかじめ定義されたデフォルト値を使用して リクエストを処理するか、無効なスコープを示してリクエストを 失敗させなければならない（MUST）。認可サーバーは、自身のスコープ 要件およびデフォルト値（定義されている場合）を文書化すべきである （SHOULD）。 4. 認可の取得 アクセストークンを要求するため、クライアントはリソース所有者から 認可を取得する。この認可は認可グラントの形式で表現され、 クライアントはそれを使用してアクセストークンを要求する。OAuth は 4 つのグラントタイプ、すなわち認可コード、インプリシット、 リソース所有者パスワード認証情報、およびクライアント認証情報を 定義する。また、追加のグラントタイプを定義するための拡張 メカニズムも提供する。 Hardt 標準化過程 [Page 23]
RFC 6749 OAuth 2.0 2012年10月 4.1. 認可コードグラント 認可コードグラントタイプは、アクセストークンとリフレッシュトークンの 両方を取得するために使用され、confidential client 向けに最適化されて いる。これはリダイレクトベースのフローであるため、クライアントは リソース所有者のユーザーエージェント（通常は 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) を示す線は、ユーザーエージェントを 通過するため、2 つの部分に分けて描かれている。 図 3: 認可コードフロー Hardt 標準化過程 [Page 24]
RFC 6749 OAuth 2.0 2012年10月 図 3 に示すフローは、次の手順を含む。 (A) クライアントは、リソース所有者のユーザーエージェントを 認可エンドポイントへ誘導することでフローを開始する。 クライアントは、自身のクライアント識別子、要求されたスコープ、 ローカル状態、およびアクセスが許可（または拒否）された後に 認可サーバーがユーザーエージェントを戻すリダイレクト URI を含める。 (B) 認可サーバーは（ユーザーエージェントを介して）リソース所有者を 認証し、リソース所有者がクライアントのアクセスリクエストを 許可するか拒否するかを確定する。 (C) リソース所有者がアクセスを許可すると仮定すると、認可サーバーは 以前に提供されたリダイレクト URI（リクエスト内または クライアント登録時）を使用して、ユーザーエージェントを クライアントへリダイレクトする。リダイレクト URI は、 認可コードと、クライアントが以前に提供した任意のローカル状態を 含む。 (D) クライアントは、前の手順で受け取った認可コードを含めることで、 認可サーバーのトークンエンドポイントにアクセストークンを 要求する。リクエストを行うとき、クライアントは認可サーバーに 認証する。クライアントは、検証のため、認可コードを取得するために 使用されたリダイレクト URI を含める。 (E) 認可サーバーはクライアントを認証し、認可コードを検証し、 受信したリダイレクト URI が手順 (C) でクライアントを リダイレクトするために使用された URI と一致することを確認する。 有効であれば、認可サーバーはアクセストークン、および任意で リフレッシュトークンを返す。 4.1.1. 認可リクエスト クライアントは、Appendix B に従い "application/x-www-form-urlencoded" 形式を使用して、認可エンドポイント URI のクエリコンポーネントに次のパラメータを追加することで リクエスト URI を構築する。 response_type 必須（REQUIRED）。値は "code" に設定しなければならない（MUST）。 client_id 必須（REQUIRED）。Section 2.2 で説明されるクライアント識別子。 redirect_uri 任意（OPTIONAL）。Section 3.1.2 で説明される通り。 Hardt 標準化過程 [Page 25]
RFC 6749 OAuth 2.0 2012年10月 scope 任意（OPTIONAL）。Section 3.3 で説明されるアクセスリクエストの スコープ。 state 推奨（RECOMMENDED）。クライアントがリクエストとコールバックの 間で状態を維持するために使用する不透明な値。認可サーバーは、 ユーザーエージェントをクライアントへ戻すとき、この値を含める。 このパラメータは、Section 10.12 で説明される クロスサイトリクエストフォージェリを防ぐために使用すべきである （SHOULD）。 クライアントは、HTTP リダイレクトレスポンス、またはユーザー エージェントを介して利用可能なその他の手段を使用して、構築された URI へリソース所有者を誘導する。 たとえば、クライアントは、TLS を使用して次の HTTP リクエストを 行うようユーザーエージェントを誘導する（表示目的のためだけに 余分な改行を含む）。 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. 認可レスポンス リソース所有者がアクセスリクエストを許可した場合、認可サーバーは 認可コードを発行し、Appendix B に従い "application/x-www-form-urlencoded" 形式を使用して、次のパラメータを リダイレクト URI のクエリコンポーネントに追加することで、 それをクライアントに届ける。 code 必須（REQUIRED）。認可サーバーによって生成された認可コード。 認可コードは、漏えいのリスクを軽減するため、発行後すぐに 期限切れにならなければならない（MUST）。認可コードの最大有効期間は 10 分が推奨される（RECOMMENDED）。クライアントは認可コードを Hardt 標準化過程 [Page 26]
RFC 6749 OAuth 2.0 2012年10月 複数回使用してはならない（MUST NOT）。認可コードが複数回使用された 場合、認可サーバーはリクエストを拒否しなければならず（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 以外の理由で失敗した 場合、認可サーバーは、Appendix B に従い "application/x-www-form-urlencoded" 形式を使用して、次のパラメータを リダイレクト URI のクエリコンポーネントに追加することで、 クライアントに通知する。 error 必須（REQUIRED）。次のいずれかの単一の ASCII [USASCII] エラーコード。 invalid_request リクエストに必須パラメータがない、無効なパラメータ値を 含む、パラメータを複数回含む、またはその他の形式が 不正である。 Hardt 標準化過程 [Page 27]
RFC 6749 OAuth 2.0 2012年10月 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] テキスト。 "error_description" パラメータの値は、集合 %x20-21 / %x23-5B / %x5D-7E の外の文字を含んではならない（MUST NOT）。 error_uri 任意（OPTIONAL）。エラーに関する情報を持つ人間可読な Web ページを 識別する URI。エラーに関する追加情報をクライアント開発者に 提供するために使用される。 "error_uri" パラメータの値は URI-reference 構文に適合しなければ ならず、したがって集合 %x21 / %x23-5B / %x5D-7E の外の文字を 含んではならない（MUST NOT）。 Hardt 標準化過程 [Page 28]
RFC 6749 OAuth 2.0 2012年10月 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 に従う "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）。 クライアント種別が confidential である場合、またはクライアントに クライアント認証情報が発行されている場合（またはその他の認証要件が 割り当てられている場合）、クライアントは Section 3.2.1 で 説明されるように認可サーバーに認証しなければならない（MUST）。 Hardt 標準化過程 [Page 29]
RFC 6749 OAuth 2.0 2012年10月 たとえば、クライアントは TLS を使用して次の HTTP リクエストを行う （表示目的のためだけに余分な改行を含む）。 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）。 o confidential client、またはクライアント認証情報を発行された任意の クライアント（またはその他の認証要件を持つクライアント）に対して、 クライアント認証を要求すること。 o クライアント認証が含まれる場合、クライアントを認証すること。 o 認可コードが、認証された confidential client に発行されたことを 保証すること。または、クライアントが public である場合、 コードがリクエスト内の "client_id" に発行されたことを保証すること。 o 認可コードが有効であることを検証すること。 o Section 4.1.1 で説明されるように、初期認可リクエストに "redirect_uri" パラメータが含まれていた場合、"redirect_uri" パラメータが存在することを保証し、含まれている場合はそれらの値が 同一であることを保証すること。 4.1.4. アクセストークンレスポンス アクセストークンリクエストが有効であり認可されている場合、 認可サーバーは Section 5.1 で説明されるようにアクセストークンと 任意のリフレッシュトークンを発行する。リクエストのクライアント認証が 失敗した場合、または無効である場合、認可サーバーは Section 5.2 で 説明されるエラーレスポンスを返す。 Hardt 標準化過程 [Page 30]
RFC 6749 OAuth 2.0 2012年10月 成功レスポンスの例。 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 を運用することが知られている public client 向けに 最適化されている。これらのクライアントは通常、JavaScript などの スクリプト言語を使用してブラウザー内に実装される。 これはリダイレクトベースのフローであるため、クライアントは リソース所有者のユーザーエージェント（通常は Web ブラウザー）と 相互作用でき、かつ認可サーバーからの（リダイレクトによる）受信 リクエストを受け取ることができなければならない。 認可コードグラントタイプでは、クライアントが認可のためのリクエストと アクセストークンのためのリクエストを別々に行うのに対し、 インプリシットグラントでは、クライアントは認可リクエストの結果として アクセストークンを受け取る。 インプリシットグラントタイプはクライアント認証を含まず、 リソース所有者の存在とリダイレクト URI の登録に依拠する。 アクセストークンはリダイレクト URI に符号化されるため、 リソース所有者および同じデバイス上に存在する他のアプリケーションに 露出する可能性がある。 Hardt 標準化過程 [Page 31]
RFC 6749 OAuth 2.0 2012年10月 +----------+ | 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 | | | +---------+ 注: 手順 (A) および (B) を示す線は、ユーザーエージェントを 通過するため、2 つの部分に分けて描かれている。 図 4: インプリシットグラントフロー Hardt 標準化過程 [Page 32]
RFC 6749 OAuth 2.0 2012年10月 図 4 に示すフローは、次の手順を含む。 (A) クライアントは、リソース所有者のユーザーエージェントを 認可エンドポイントへ誘導することでフローを開始する。 クライアントは、自身のクライアント識別子、要求されたスコープ、 ローカル状態、およびアクセスが許可（または拒否）された後に 認可サーバーがユーザーエージェントを戻すリダイレクト URI を含める。 (B) 認可サーバーは（ユーザーエージェントを介して）リソース所有者を 認証し、リソース所有者がクライアントのアクセスリクエストを 許可するか拒否するかを確定する。 (C) リソース所有者がアクセスを許可すると仮定すると、認可サーバーは 以前に提供されたリダイレクト URI を使用して、ユーザーエージェントを クライアントへリダイレクトする。 を使用して、ユーザーエージェントを クライアントへリダイレクトする。リダイレクト URI は、 URI フラグメントにアクセストークンを含む。 (D) ユーザーエージェントは、Web ホスト型クライアントリソースへ リクエストを行うことでリダイレクト指示に従う（[RFC2616] に 従い、これはフラグメントを含まない）。ユーザーエージェントは フラグメント情報をローカルに保持する。 (E) Web ホスト型クライアントリソースは、ユーザーエージェントに 保持されたフラグメントを含む完全なリダイレクト URI にアクセスし、 フラグメント内に含まれるアクセストークン（およびその他の パラメータ）を抽出できる Web ページ（通常は埋め込みスクリプトを 含む HTML 文書）を返す。 (F) ユーザーエージェントは、Web ホスト型クライアントリソースによって 提供されたスクリプトをローカルで実行し、アクセストークンを抽出する。 (G) ユーザーエージェントはアクセストークンをクライアントへ渡す。 インプリシットグラントの使用に関する背景については、1.3.2 節および 9 節を参照。インプリシットグラントを使用するときの重要な セキュリティ考慮事項については、10.3 節および 10.16 節を 参照。 4.2.1. 認可リクエスト クライアントは、Appendix B に従い "application/x-www-form-urlencoded" 形式を使用して、認可エンドポイント URI のクエリコンポーネントに次のパラメータを追加することで リクエスト URI を構築する。 response_type 必須（REQUIRED）。値は "token" に設定しなければならない（MUST）。 client_id 必須（REQUIRED）。Section 2.2 で説明されるクライアント識別子。 Hardt 標準化過程 [Page 33]
RFC 6749 OAuth 2.0 2012年10月 redirect_uri 任意（OPTIONAL）。Section 3.1.2 で説明される通り。 scope 任意（OPTIONAL）。Section 3.3 で説明されるアクセスリクエストの スコープ。 state 推奨（RECOMMENDED）。クライアントがリクエストとコールバックの 間で状態を維持するために使用する不透明な値。認可サーバーは、 ユーザーエージェントをクライアントへ戻すとき、この値を含める。 このパラメータは、Section 10.12 で説明される クロスサイトリクエストフォージェリを防ぐために使用すべきである （SHOULD）。 クライアントは、HTTP リダイレクトレスポンス、またはユーザー エージェントを介して利用可能なその他の手段を使用して、構築された URI へリソース所有者を誘導する。 たとえば、クライアントは、TLS を使用して次の HTTP リクエストを 行うようユーザーエージェントを誘導する（表示目的のためだけに 余分な改行を含む）。 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 へユーザーエージェントを 誘導する。 Hardt 標準化過程 [Page 34]
RFC 6749 OAuth 2.0 2012年10月 4.2.2. アクセストークンレスポンス リソース所有者がアクセスリクエストを許可した場合、認可サーバーは アクセストークンを発行し、Appendix B に従い "application/x-www-form-urlencoded" 形式を使用して、次のパラメータを リダイレクト URI のフラグメントコンポーネントに追加することで、 それをクライアントに届ける。 access_token 必須（REQUIRED）。認可サーバーによって発行されたアクセストークン。 token_type 必須（REQUIRED）。Section 7.1 で説明される、発行された トークンのタイプ。値は大文字と小文字を区別しない。 expires_in 推奨（RECOMMENDED）。アクセストークンの有効期間（秒）。 たとえば、値 "3600" は、レスポンスが生成された時点から 1 時間後にアクセストークンが期限切れになることを示す。 省略された場合、認可サーバーは他の手段で有効期限を提供するか、 デフォルト値を文書化すべきである（SHOULD）。 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 にリンクされたアクションを持つ 'continue' ボタンを含む HTML ページを返す方法がある。 Hardt 標準化過程 [Page 35]
RFC 6749 OAuth 2.0 2012年10月 クライアントは、認識できないレスポンスパラメータを無視しなければ ならない（MUST）。アクセストークン文字列のサイズは本仕様では 未定義のままとする。クライアントは値のサイズについて仮定することを 避けるべきである。認可サーバーは、自らが発行する任意の値のサイズを 文書化すべきである（SHOULD）。 4.2.2.1. エラーレスポンス リクエストが、欠落している、無効である、または一致しない リダイレクト URI により失敗した場合、またはクライアント識別子が 欠落しているか無効である場合、認可サーバーはリソース所有者に エラーを通知すべきであり（SHOULD）、ユーザーエージェントを無効な リダイレクト URI へ自動的にリダイレクトしてはならない（MUST NOT）。 リソース所有者がアクセスリクエストを拒否した場合、または リクエストが欠落または無効なリダイレクト URI 以外の理由で失敗した 場合、認可サーバーは、Appendix B に従い "application/x-www-form-urlencoded" 形式を使用して、次のパラメータを リダイレクト URI のフラグメントコンポーネントに追加することで、 クライアントに通知する。 error 必須（REQUIRED）。次のいずれかの単一の ASCII [USASCII] エラーコード。 invalid_request リクエストに必須パラメータがない、無効なパラメータ値を 含む、パラメータを複数回含む、またはその他の形式が 不正である。 unauthorized_client クライアントは、この方法を使用してアクセストークンを 要求する権限を与えられていない。 access_denied リソース所有者または認可サーバーがリクエストを拒否した。 unsupported_response_type 認可サーバーは、この方法を使用してアクセストークンを 取得することをサポートしていない。 invalid_scope 要求されたスコープが無効、不明、または形式不正である。 Hardt 標準化過程 [Page 36]
RFC 6749 OAuth 2.0 2012年10月 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] テキスト。 "error_description" パラメータの値は、集合 %x20-21 / %x23-5B / %x5D-7E の外の文字を含んではならない（MUST NOT）。 error_uri 任意（OPTIONAL）。エラーに関する情報を持つ人間可読な Web ページを 識別する URI。エラーに関する追加情報をクライアント開発者に 提供するために使用される。 "error_uri" パラメータの値は URI-reference 構文に適合しなければ ならず、したがって集合 %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. リソース所有者パスワード認証情報グラント リソース所有者パスワード認証情報グラントタイプは、リソース所有者が クライアントと信頼関係を持つ場合に適している。たとえば、デバイスの オペレーティングシステムや高い権限を持つ Hardt 標準化過程 [Page 37]
RFC 6749 OAuth 2.0 2012年10月 アプリケーションである。認可サーバーは、このグラントタイプを有効に するとき特別な注意を払うべきであり、他のフローが実行可能でない 場合にのみ許可すべきである。 このグラントタイプは、リソース所有者の認証情報（ユーザー名と パスワード。通常は対話的フォームを使用）を取得できるクライアントに 適している。また、HTTP 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) | | +---------+ +---------------+ 図 5: リソース所有者パスワード認証情報フロー 図 5 に示すフローは、次の手順を含む。 (A) リソース所有者は、クライアントに自身のユーザー名とパスワードを 提供する。 (B) クライアントは、リソース所有者から受け取った認証情報を含める ことで、認可サーバーのトークンエンドポイントにアクセストークンを 要求する。リクエストを行うとき、クライアントは認可サーバーに 認証する。 (C) 認可サーバーはクライアントを認証し、リソース所有者の認証情報を 検証し、有効であればアクセストークンを発行する。 Hardt 標準化過程 [Page 38]
RFC 6749 OAuth 2.0 2012年10月 4.3.1. 認可リクエストおよびレスポンス クライアントがリソース所有者の認証情報を取得する方法は、 本仕様の範囲外である。クライアントは、アクセストークンを取得した後、 認証情報を破棄しなければならない（MUST）。 4.3.2. アクセストークンリクエスト クライアントは、HTTP リクエストエンティティボディ内で文字エンコーディング UTF-8 を使用し、Appendix B に従う "application/x-www-form-urlencoded" 形式で次のパラメータを追加することで、 トークンエンドポイントへリクエストを行う。 grant_type 必須（REQUIRED）。値は "password" に設定しなければならない（MUST）。 username 必須（REQUIRED）。リソース所有者のユーザー名。 password 必須（REQUIRED）。リソース所有者のパスワード。 scope 任意（OPTIONAL）。Section 3.3 で説明されるアクセスリクエストの スコープ。 クライアント種別が confidential である場合、またはクライアントに クライアント認証情報が発行されている場合（またはその他の認証要件が 割り当てられている場合）、クライアントは 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 Hardt 標準化過程 [Page 39]
RFC 6749 OAuth 2.0 2012年10月 認可サーバーは次を行わなければならない（MUST）。 o confidential client、またはクライアント認証情報を発行された任意の クライアント（またはその他の認証要件を持つクライアント）に対して、 クライアント認証を要求すること。 o クライアント認証が含まれる場合、クライアントを認証すること。 o 既存のパスワード検証アルゴリズムを使用して、リソース所有者 パスワード認証情報を検証すること。 このアクセストークンリクエストはリソース所有者のパスワードを 利用するため、認可サーバーはエンドポイントをブルートフォース攻撃から 保護しなければならない（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. クライアント認証情報グラント クライアントは、自身の制御下にある保護リソースへのアクセスを 要求している場合、または認可サーバーと事前に取り決められた 別のリソース所有者の保護リソースへのアクセスを要求している場合 （その方法は本仕様の範囲外）、自身のクライアント認証情報のみ （またはその他のサポートされる認証手段）を使用してアクセストークンを 要求できる。 Hardt 標準化過程 [Page 40]
RFC 6749 OAuth 2.0 2012年10月 クライアント認証情報グラントタイプは、confidential client によってのみ 使用されなければならない（MUST）。 +---------+ +---------------+ | | | | | |>--(A)- Client Authentication --->| Authorization | | Client | | Server | | |<--(B)---- Access Token ---------<| | | | | | +---------+ +---------------+ 図 6: クライアント認証情報フロー 図 6 に示すフローは、次の手順を含む。 (A) クライアントは認可サーバーに認証し、トークンエンドポイントから アクセストークンを要求する。 (B) 認可サーバーはクライアントを認証し、有効であれば アクセストークンを発行する。 4.4.1. 認可リクエストおよびレスポンス クライアント認証が認可グラントとして使用されるため、追加の 認可リクエストは必要ない。 4.4.2. アクセストークンリクエスト クライアントは、HTTP リクエストエンティティボディ内で文字エンコーディング UTF-8 を使用し、Appendix B に従う "application/x-www-form-urlencoded" 形式で次のパラメータを追加することで、 トークンエンドポイントへリクエストを行う。 grant_type 必須（REQUIRED）。値は "client_credentials" に設定しなければ ならない（MUST）。 scope 任意（OPTIONAL）。Section 3.3 で説明されるアクセスリクエストの スコープ。 クライアントは、Section 3.2.1 で説明されるように認可サーバーに 認証しなければならない（MUST）。 Hardt 標準化過程 [Page 41]
RFC 6749 OAuth 2.0 2012年10月 たとえば、クライアントはトランスポート層セキュリティを使用して 次の 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 を使用して グラントタイプを指定し、必要な任意の追加パラメータを加えることで、 拡張グラントタイプを使用する。 Hardt 標準化過程 [Page 42]
RFC 6749 OAuth 2.0 2012年10月 たとえば、[OAuth-SAML2] で定義される 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）。 Hardt 標準化過程 [Page 43]
RFC 6749 OAuth 2.0 2012年10月 refresh_token 任意（OPTIONAL）。Section 6 で説明されるように、同じ認可 グラントを使用して新しいアクセストークンを取得するために 使用できるリフレッシュトークン。 scope クライアントによって要求されたスコープと同一である場合は 任意（OPTIONAL）、それ以外の場合は必須（REQUIRED）。 Section 3.3 で説明されるアクセストークンのスコープ。 パラメータは、[RFC4627] で定義される "application/json" メディアタイプを使用して、HTTP レスポンスのエンティティボディに 含められる。パラメータは、各パラメータを最上位構造レベルに追加する ことで JavaScript Object Notation (JSON) 構造へ直列化される。 パラメータ名および文字列値は JSON 文字列として含められる。 数値は JSON 数値として含められる。パラメータの順序は重要ではなく、 変化してよい。 認可サーバーは、トークン、認証情報、またはその他の機微情報を含む 任意のレスポンスにおいて、HTTP "Cache-Control" レスポンスヘッダー フィールド [RFC2616] に値 "no-store" を含め、さらに "Pragma" レスポンスヘッダーフィールド [RFC2616] に値 "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）。 Hardt 標準化過程 [Page 44]
RFC 6749 OAuth 2.0 2012年10月 5.2. エラーレスポンス 認可サーバーは、HTTP 400 (Bad Request) ステータスコード （別途指定される場合を除く）で応答し、レスポンスに次のパラメータを 含める。 error 必須（REQUIRED）。次のいずれかの単一の ASCII [USASCII] エラーコード。 invalid_request リクエストに必須パラメータがない、（グラントタイプ以外の） サポートされていないパラメータ値を含む、パラメータを 繰り返す、複数の認証情報を含む、クライアント認証に複数の メカニズムを利用している、またはその他の形式が不正である。 invalid_client クライアント認証に失敗した（たとえば、不明なクライアント、 クライアント認証が含まれていない、またはサポートされていない 認証方式）。認可サーバーは、どの HTTP 認証スキームが サポートされているかを示すために、HTTP 401 (Unauthorized) ステータスコードを返してよい（MAY）。クライアントが "Authorization" リクエストヘッダーフィールドを介して 認証しようとした場合、認可サーバーは HTTP 401 (Unauthorized) ステータスコードで応答し、クライアントが使用した認証 スキームと一致する "WWW-Authenticate" レスポンス ヘッダーフィールドを含めなければならない（MUST）。 invalid_grant 提供された認可グラント（たとえば、認可コード、 リソース所有者認証情報）またはリフレッシュトークンが無効、 期限切れ、取り消し済みである、認可リクエストで使用された リダイレクト URI と一致しない、または別のクライアントに 発行されたものである。 unauthorized_client 認証されたクライアントは、この認可グラントタイプを使用する 権限を与えられていない。 unsupported_grant_type 認可グラントタイプは認可サーバーによってサポートされて いない。 Hardt 標準化過程 [Page 45]
RFC 6749 OAuth 2.0 2012年10月 invalid_scope 要求されたスコープが無効、不明、形式不正である、または リソース所有者によって付与されたスコープを超えている。 "error" パラメータの値は、集合 %x20-21 / %x23-5B / %x5D-7E の 外の文字を含んではならない（MUST NOT）。 error_description 任意（OPTIONAL）。発生したエラーをクライアント開発者が理解する 助けとして使用される、追加情報を提供する人間可読な ASCII [USASCII] テキスト。 "error_description" パラメータの値は、集合 %x20-21 / %x23-5B / %x5D-7E の外の文字を含んではならない（MUST NOT）。 error_uri 任意（OPTIONAL）。エラーに関する情報を持つ人間可読な Web ページを 識別する URI。エラーに関する追加情報をクライアント開発者に 提供するために使用される。 "error_uri" パラメータの値は URI-reference 構文に適合しなければ ならず、したがって集合 %x21 / %x23-5B / %x5D-7E の外の文字を 含んではならない（MUST NOT）。 パラメータは、[RFC4627] で定義される "application/json" メディアタイプを使用して、HTTP レスポンスのエンティティボディに 含められる。パラメータは、各パラメータを最上位構造レベルに追加する ことで 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" } Hardt 標準化過程 [Page 46]
RFC 6749 OAuth 2.0 2012年10月 6. アクセストークンの更新 認可サーバーがクライアントにリフレッシュトークンを発行した場合、 クライアントは、HTTP リクエストエンティティボディ内で文字エンコーディング UTF-8 を使用し、Appendix B に従う "application/x-www-form-urlencoded" 形式で次のパラメータを追加することで、 トークンエンドポイントへ更新リクエストを行う。 grant_type 必須（REQUIRED）。値は "refresh_token" に設定しなければならない （MUST）。 refresh_token 必須（REQUIRED）。クライアントに発行されたリフレッシュトークン。 scope 任意（OPTIONAL）。Section 3.3 で説明されるアクセスリクエストの スコープ。要求されるスコープは、リソース所有者によって最初に 付与されていないスコープを含んではならず（MUST NOT）、省略された 場合は、リソース所有者によって最初に付与されたスコープと 等しいものとして扱われる。 リフレッシュトークンは、通常、追加のアクセストークンを要求するために 使用される長寿命の認証情報であるため、リフレッシュトークンはそれが 発行されたクライアントに結び付けられる。クライアント種別が confidential である場合、またはクライアントにクライアント認証情報が 発行されている場合（またはその他の認証要件が割り当てられている場合）、 クライアントは 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=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA Hardt 標準化過程 [Page 47]
RFC 6749 OAuth 2.0 2012年10月 認可サーバーは次を行わなければならない（MUST）。 o confidential client、またはクライアント認証情報を発行された任意の クライアント（またはその他の認証要件を持つクライアント）に対して、 クライアント認証を要求すること。 o クライアント認証が含まれる場合、クライアントを認証し、 リフレッシュトークンが認証されたクライアントに発行されたことを 保証すること。 o リフレッシュトークンを検証すること。 有効であり認可されている場合、認可サーバーは Section 5.1 で 説明されるようにアクセストークンを発行する。リクエストの検証が 失敗した場合、または無効である場合、認可サーバーは Section 5.2 で 説明されるエラーレスポンスを返す。 認可サーバーは新しいリフレッシュトークンを発行してよく（MAY）、 その場合、クライアントは古いリフレッシュトークンを破棄し、 新しいリフレッシュトークンに置き換えなければならない（MUST）。 認可サーバーは、クライアントに新しいリフレッシュトークンを発行した後、 古いリフレッシュトークンを取り消してよい（MAY）。新しい リフレッシュトークンが発行される場合、そのリフレッシュトークンの スコープは、クライアントがリクエストに含めたリフレッシュトークンの スコープと同一でなければならない（MUST）。 7. 保護リソースへのアクセス クライアントは、アクセストークンをリソースサーバーに提示することで 保護リソースへアクセスする。リソースサーバーはアクセストークンを検証し、 それが期限切れでなく、そのスコープが要求されたリソースをカバーしている ことを保証しなければならない（MUST）。リソースサーバーが アクセストークンを検証するために使用する方法（および任意の エラーレスポンス）は本仕様の範囲外であるが、一般にリソースサーバーと 認可サーバーの間の相互作用または調整を伴う。 クライアントがリソースサーバーに認証するためにアクセストークンを 利用する方法は、認可サーバーによって発行されたアクセストークンの タイプに依存する。典型的には、使用されるアクセストークンタイプの 仕様によって定義される認証スキームとともに、HTTP "Authorization" リクエストヘッダーフィールド [RFC2617] を使用することを 伴う。たとえば [RFC6750] である。 Hardt 標準化過程 [Page 48]
RFC 6749 OAuth 2.0 2012年10月 7.1. アクセストークンタイプ アクセストークンタイプは、クライアントがアクセストークンを正常に 利用して保護リソース要求を行うために必要な情報（タイプ固有の属性を 含む）をクライアントに提供する。クライアントは、トークンタイプを 理解していない場合、そのアクセストークンを使用してはならない （MUST NOT）。 たとえば、[RFC6750] で定義される "bearer" トークンタイプは、 リクエストにアクセストークン文字列を含めるだけで利用される。 GET /resource/1 HTTP/1.1 Host: example.com Authorization: Bearer mF_9.B5f-4.1JqM 一方、[OAuth-HTTP-MAC] で定義される "mac" トークンタイプは、 HTTP リクエストの特定のコンポーネントに署名するために使用される アクセストークンとともに Message Authentication Code (MAC) 鍵を 発行することで利用される。 GET /resource/1 HTTP/1.1 Host: example.com Authorization: MAC id="h480djs93hd8", nonce="274312:dj83hs9s", mac="kDZvddkndxvhGRXZhvuDjEWhGeE=" 上記の例は、説明目的でのみ提供される。開発者は、使用前に [RFC6750] および [OAuth-HTTP-MAC] の仕様を参照することが 推奨される。 各アクセストークンタイプ定義は、"access_token" レスポンス パラメータとともにクライアントへ送信される追加属性（存在する場合）を 指定する。また、保護リソース要求を行うときにアクセストークンを 含めるために使用される HTTP 認証方式も定義する。 7.2. エラーレスポンス リソースアクセスリクエストが失敗した場合、リソースサーバーは クライアントにエラーを通知すべきである（SHOULD）。そのような エラーレスポンスの詳細は本仕様の範囲外であるが、本文書は OAuth トークン認証スキーム間で共有されるエラー値のための共通 レジストリを Section 11.4 で確立する。 主として OAuth トークン認証のために設計された新しい認証スキームは、 クライアントにエラーステータスコードを提供するためのメカニズムを 定義すべきであり（SHOULD）、そこで許可されるエラー値は本仕様により 確立されたエラーレジストリに登録される。 Hardt 標準化過程 [Page 49]
RFC 6749 OAuth 2.0 2012年10月 そのようなスキームは、有効なエラーコードの集合を登録済み値の 部分集合に制限してよい（MAY）。エラーコードが名前付きパラメータを 使用して返される場合、そのパラメータ名は "error" であるべきである （SHOULD）。 OAuth トークン認証に使用できるが、主としてその目的のために設計された わけではないその他のスキームは、同じ方法でそのエラー値を レジストリに結び付けてよい（MAY）。 新しい認証スキームは、本仕様での使用方法と並行する形で エラー情報を返すため、"error_description" および "error_uri" パラメータの使用も指定することを選択してよい（MAY）。 8. 拡張性 8.1. アクセストークンタイプの定義 アクセストークンタイプは、2 つの方法のいずれかで定義できる。 Access Token Types レジストリに登録する（Section 11.1 の手順に 従う）方法、またはその名前として一意の絶対 URI を使用する方法である。 URI 名を利用するタイプは、一般的に適用可能ではなく、それらが 使用されるリソースサーバーの実装詳細に固有の、ベンダー固有実装に 限定すべきである（SHOULD）。 その他すべてのタイプは登録されなければならない（MUST）。タイプ名は type-name ABNF に適合しなければならない（MUST）。タイプ定義が新しい HTTP 認証スキームを含む場合、タイプ名は（[RFC2617] で定義される） HTTP 認証スキーム名と同一であるべきである（SHOULD）。トークンタイプ "example" は例での使用のために予約されている。 type-name = 1*name-char name-char = "-" / "." / "_" / DIGIT / ALPHA 8.2. 新しいエンドポイントパラメータの定義 認可エンドポイントまたはトークンエンドポイントで使用する新しい リクエストまたはレスポンスパラメータは、Section 11.2 の手順に 従って OAuth Parameters レジストリで定義および登録される。 パラメータ名は param-name ABNF に適合しなければならず（MUST）、 パラメータ値の構文は明確に定義されなければならない（MUST） （たとえば、ABNF を使用する、または既存パラメータの構文への参照）。 param-name = 1*name-char name-char = "-" / "." / "_" / DIGIT / ALPHA Hardt 標準化過程 [Page 50]
RFC 6749 OAuth 2.0 2012年10月 一般的に適用可能ではなく、それらが使用される認可サーバーの実装詳細に 固有である未登録のベンダー固有パラメータ拡張は、他の登録済み値と 衝突する可能性が低いベンダー固有の接頭辞（たとえば 'companyname_' で始まる）を利用すべきである（SHOULD）。 8.3. 新しい認可グラントタイプの定義 新しい認可グラントタイプは、"grant_type" パラメータで使用するための 一意の絶対 URI を割り当てることで定義できる。拡張グラントタイプが 追加のトークンエンドポイントパラメータを必要とする場合、それらは Section 11.2 で説明されるように OAuth Parameters レジストリに 登録されなければならない（MUST）。 8.4. 新しい認可エンドポイントレスポンスタイプの定義 認可エンドポイントで使用する新しいレスポンスタイプは、Section 11.3 の 手順に従って Authorization Endpoint Response Types レジストリで定義 および登録される。レスポンスタイプ名は response-type ABNF に 適合しなければならない（MUST）。 response-type = response-name *( SP response-name ) response-name = 1*response-char response-char = "_" / DIGIT / ALPHA レスポンスタイプが 1 つ以上の空白文字（%x20）を含む場合、 それは値の空白区切りリストとして比較され、値の順序は重要ではない。 登録できる値の順序は 1 つだけであり、それは同じ値集合の他の すべての並びを包含する。 たとえば、レスポンスタイプ "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）。 Hardt 標準化過程 [Page 51]
RFC 6749 OAuth 2.0 2012年10月 拡張エラーコードは、それが組み合わせて使用される拡張が登録済みの アクセストークンタイプ、登録済みエンドポイントパラメータ、または 拡張グラントタイプである場合、（Section 11.4 の手順に従って） 登録されなければならない（MUST）。未登録拡張で使用されるエラーコードは 登録してよい（MAY）。 エラーコードは error ABNF に適合しなければならず（MUST）、 可能であれば識別名を接頭辞として付けるべきである（SHOULD）。 たとえば、拡張パラメータ "example" に設定された無効な値を識別する エラーは "example_invalid" と名付けるべきである（SHOULD）。 error = 1*error-char error-char = %x20-21 / %x23-5B / %x5D-7E 9. ネイティブアプリケーション ネイティブアプリケーションは、リソース所有者が使用するデバイス上に インストールされ実行されるクライアントである（すなわち、デスクトップ アプリケーション、ネイティブモバイルアプリケーション）。ネイティブ アプリケーションは、セキュリティ、プラットフォーム機能、および 全体的なエンドユーザー体験に関連する特別な考慮を必要とする。 認可エンドポイントは、クライアントとリソース所有者の ユーザーエージェントとの相互作用を必要とする。ネイティブ アプリケーションは、外部ユーザーエージェントを呼び出すことも、 アプリケーション内にユーザーエージェントを埋め込むこともできる。 例を示す。 o 外部ユーザーエージェント - ネイティブアプリケーションは、 クライアントをハンドラーとして呼び出すためにオペレーティング システムに登録されたスキームを持つリダイレクト URI、認証情報の 手動コピーアンドペースト、ローカル Web サーバーの実行、 ユーザーエージェント拡張のインストール、またはクライアントの 制御下にあるサーバーホスト型リソースを識別するリダイレクト URI を 提供することにより、認可サーバーからのレスポンスを取得できる。 そのリソースは、レスポンスをネイティブアプリケーションで利用可能にする。 o 埋め込みユーザーエージェント - ネイティブアプリケーションは、 リソース読み込み中に発行される状態変化を監視する、または ユーザーエージェントの Cookie ストレージへアクセスすることで、 埋め込みユーザーエージェントと直接通信してレスポンスを取得する。 外部ユーザーエージェントと埋め込みユーザーエージェントのどちらを 選択するかを決めるとき、開発者は次を考慮すべきである。 o 外部ユーザーエージェントは完了率を向上させる可能性がある。 リソース所有者は認可サーバーとの有効なセッションをすでに 持っている場合があり、再認証の必要がなくなるためである。 それは、慣れたエンドユーザー体験と機能を提供する。 Hardt 標準化過程 [Page 52]
RFC 6749 OAuth 2.0 2012年10月 リソース所有者は、認証を支援するためにユーザーエージェントの機能や 拡張（たとえば、パスワードマネージャー、2 要素デバイスリーダー）に 依拠する場合もある。 o 埋め込みユーザーエージェントは、コンテキストを切り替えて新しい ウィンドウを開く必要をなくすため、使いやすさを向上させる可能性がある。 o 埋め込みユーザーエージェントはセキュリティ上の課題を生じさせる。 リソース所有者は、ほとんどの外部ユーザーエージェントに見られる 視覚的保護へアクセスできない未識別のウィンドウで認証するためである。 埋め込みユーザーエージェントは、認証のための未識別リクエストを 信頼するようエンドユーザーを教育してしまう（フィッシング攻撃を 実行しやすくする）。 インプリシットグラントタイプと認可コードグラントタイプのどちらを 選択するかを決めるとき、次を考慮すべきである。 o 認可コードグラントタイプを使用するネイティブアプリケーションは、 ネイティブアプリケーションがクライアント認証情報を機密に保つことが できないため、クライアント認証情報を使用せずにそうすべきである （SHOULD）。 o インプリシットグラントタイプフローを使用する場合、 リフレッシュトークンは返されないため、アクセストークンが 期限切れになると認可プロセスを繰り返す必要がある。 10. セキュリティ考慮事項 柔軟で拡張可能なフレームワークとして、OAuth のセキュリティ考慮事項は 多くの要因に依存する。以下の節は、Section 2.1 で説明される 3 つのクライアントプロファイル、すなわち Web アプリケーション、 ユーザーエージェントベースアプリケーション、およびネイティブ アプリケーションに焦点を当てたセキュリティ指針を実装者に提供する。 包括的な OAuth セキュリティモデルおよび分析、ならびに プロトコル設計の背景は、[OAuth-THREATMODEL] によって提供される。 10.1. クライアント認証 認可サーバーは、クライアント認証の目的で Web アプリケーション クライアントとクライアント認証情報を確立する。認可サーバーは、 クライアントパスワードより強力なクライアント認証手段を検討することが 奨励される。Web アプリケーションクライアントは、クライアント パスワードおよびその他のクライアント認証情報の機密性を保証しなければ ならない（MUST）。 Hardt 標準化過程 [Page 53]
RFC 6749 OAuth 2.0 2012年10月 認可サーバーは、クライアント認証の目的で、ネイティブアプリケーション またはユーザーエージェントベースアプリケーションクライアントに クライアントパスワードまたはその他のクライアント認証情報を 発行してはならない（MUST NOT）。認可サーバーは、特定のデバイス上の ネイティブアプリケーションクライアントの特定のインストールに対して、 クライアントパスワードまたはその他の認証情報を発行してよい（MAY）。 クライアント認証が不可能な場合、認可サーバーはクライアントの 識別情報を検証するために他の手段を用いるべきである（SHOULD）。 たとえば、クライアントリダイレクト URI の登録を要求することや、 リソース所有者に識別情報の確認を求めることである。有効な リダイレクト URI は、リソース所有者認可を求めるときにクライアントの 識別情報を検証するには十分ではないが、リソース所有者認可を取得した後に 偽造クライアントへ認証情報を配送することを防ぐために使用できる。 認可サーバーは、未認証クライアントと相互作用することのセキュリティ上の 影響を考慮し、そのようなクライアントに発行される他の認証情報 （たとえばリフレッシュトークン）の潜在的な露出を制限する措置を 講じなければならない。 10.2. クライアントなりすまし なりすまされるクライアントが自身のクライアント認証情報を機密に 保てない場合、または保つことができない場合、悪意あるクライアントは 別のクライアントになりすまし、保護リソースへのアクセスを取得できる。 認可サーバーは、可能な限りクライアントを認証しなければならない （MUST）。認可サーバーがクライアントの性質によりクライアントを 認証できない場合、認可サーバーは、認可レスポンスを受け取るために 使用される任意のリダイレクト URI の登録を要求しなければならず（MUST）、 そのような潜在的に悪意あるクライアントからリソース所有者を保護する ために他の手段を利用すべきである（SHOULD）。たとえば、 認可サーバーは、クライアントとそのオリジンを識別する支援を リソース所有者に求めることができる。 認可サーバーは、明示的なリソース所有者認証を強制し、リソース所有者に クライアント、および要求された認可スコープと有効期間に関する情報を 提供すべきである（SHOULD）。現在のクライアントの文脈でその情報を 確認し、リクエストを認可または拒否するかどうかはリソース所有者に 委ねられる。 認可サーバーは、クライアントを認証することなく、または繰り返される リクエストがなりすましではなく元のクライアントから来ていることを 保証するための他の措置に依拠することなく、繰り返される認可リクエストを （リソース所有者の能動的な相互作用なしに）自動的に処理すべきではない （SHOULD NOT）。 Hardt 標準化過程 [Page 54]
RFC 6749 OAuth 2.0 2012年10月 10.3. アクセストークン アクセストークン認証情報（および任意の機密アクセストークン属性）は、 転送中および保存時に機密に保たれなければならず（MUST）、 認可サーバー、そのアクセストークンが有効であるリソースサーバー、 およびアクセストークンが発行されたクライアントの間でのみ共有される。 アクセストークン認証情報は、[RFC2818] で定義されるサーバー認証を 伴う、Section 1.6 で説明される TLS を使用してのみ送信されなければ ならない（MUST）。 インプリシットグラントタイプを使用する場合、アクセストークンは URI フラグメントで送信されるため、権限のない第三者に露出する可能性がある。 認可サーバーは、権限のない第三者が有効なアクセストークンを生成、 変更、または推測できないことを保証しなければならない（MUST）。 クライアントは、必要最小限のスコープでアクセストークンを要求すべきである （SHOULD）。認可サーバーは、要求されたスコープをどのように認めるかを 選択するときにクライアント識別情報を考慮すべきであり（SHOULD）、 要求されたよりも少ない権限を持つアクセストークンを発行してよい（MAY）。 本仕様は、特定のクライアントによって提示されたアクセストークンが、 認可サーバーによってそのクライアントに発行されたものであることを リソースサーバーが保証するための方法を提供しない。 10.4. リフレッシュトークン 認可サーバーは、Web アプリケーションクライアントおよび ネイティブアプリケーションクライアントにリフレッシュトークンを 発行してよい（MAY）。 リフレッシュトークンは、転送中および保存時に機密に保たれなければならず （MUST）、認可サーバーとリフレッシュトークンが発行されたクライアントの 間でのみ共有される。認可サーバーは、リフレッシュトークンと、それが 発行されたクライアントとの結び付けを維持しなければならない（MUST）。 リフレッシュトークンは、[RFC2818] で定義されるサーバー認証を伴う、 Section 1.6 で説明される TLS を使用してのみ送信されなければならない （MUST）。 認可サーバーは、クライアント識別情報を認証できる場合はいつでも、 リフレッシュトークンとクライアント識別情報の結び付けを検証しなければ ならない（MUST）。クライアント認証が不可能な場合、認可サーバーは リフレッシュトークンの悪用を検出するために他の手段を配備すべきである （SHOULD）。 たとえば、認可サーバーは、アクセストークン更新レスポンスごとに 新しいリフレッシュトークンが発行されるリフレッシュトークン ローテーションを採用できる。以前のリフレッシュトークンは無効化される Hardt 標準化過程 [Page 55]
RFC 6749 OAuth 2.0 2012年10月 が、認可サーバーによって保持される。リフレッシュトークンが侵害され、 その後攻撃者と正当なクライアントの両方によって使用された場合、 その一方が無効化されたリフレッシュトークンを提示することになり、 それにより認可サーバーは侵害を知る。 認可サーバーは、権限のない第三者が有効なリフレッシュトークンを生成、 変更、または推測できないことを保証しなければならない（MUST）。 10.5. 認可コード 認可コードの送信は安全なチャネル上で行われるべきであり（SHOULD）、 リダイレクト URI がネットワークリソースを識別する場合、クライアントは そのリダイレクト URI で TLS の使用を要求すべきである（SHOULD）。 認可コードはユーザーエージェントのリダイレクトを介して送信されるため、 ユーザーエージェントの履歴や HTTP referrer ヘッダーを通じて 開示される可能性がある。 認可コードは平文の bearer 認証情報として動作し、認可サーバーで 認可を付与したリソース所有者が、プロセスを完了するために クライアントへ戻ってくる同じリソース所有者であることを検証するために 使用される。したがって、クライアントが自身のリソース所有者認証のために 認可コードに依拠する場合、クライアントリダイレクトエンドポイントは TLS の使用を要求しなければならない（MUST）。 認可コードは短寿命で単回使用でなければならない（MUST）。 認可サーバーが、認可コードをアクセストークンと交換する複数の試行を 観察した場合、認可サーバーは、侵害された認可コードに基づいてすでに 付与されたすべてのアクセストークンを取り消すことを試みるべきである （SHOULD）。 クライアントを認証できる場合、認可サーバーはクライアントを認証し、 認可コードが同じクライアントに発行されたことを保証しなければならない （MUST）。 10.6. 認可コードのリダイレクト URI 操作 認可コードグラントタイプを使用して認可を要求するとき、クライアントは "redirect_uri" パラメータを介してリダイレクト URI を指定できる。 攻撃者がリダイレクト URI の値を操作できる場合、認可サーバーに、 認可コードを付けてリソース所有者のユーザーエージェントを攻撃者の 制御下にある URI へリダイレクトさせることができる。 攻撃者は正当なクライアントでアカウントを作成し、認可フローを 開始できる。攻撃者のユーザーエージェントがアクセスを許可するために 認可サーバーへ送られると、攻撃者は正当なクライアントによって提供された 認可 URI を取得し、クライアントのリダイレクト URI を攻撃者の Hardt 標準化過程 [Page 56]
RFC 6749 OAuth 2.0 2012年10月 制御下にある URI に置き換える。その後、攻撃者は被害者をだまして、 正当なクライアントへのアクセスを認可するために、操作されたリンクを たどらせる。 認可サーバーに到達すると、被害者には正当で信頼されたクライアントに 代わる通常の有効なリクエストが提示され、被害者はそのリクエストを 認可する。その後、被害者は認可コード付きで攻撃者の制御下にある エンドポイントへリダイレクトされる。攻撃者は、クライアントによって 提供された元のリダイレクト URI を使用して認可コードをクライアントへ 送信することで認可フローを完了する。クライアントは認可コードを アクセストークンと交換し、それを攻撃者のクライアントアカウントに 関連付ける。そのアカウントは、（クライアントを介して）被害者によって 認可された保護リソースへのアクセスを得られるようになる。 このような攻撃を防ぐため、認可サーバーは、認可コードを取得するために 使用されたリダイレクト URI が、認可コードをアクセストークンと交換するときに 提供されたリダイレクト URI と同一であることを保証しなければならない （MUST）。認可サーバーは public client にリダイレクト URI の登録を 要求しなければならず（MUST）、confidential client にも要求すべきである （SHOULD）。リクエストにリダイレクト URI が提供されている場合、 認可サーバーはそれを登録済み値に対して検証しなければならない（MUST）。 10.7. リソース所有者パスワード認証情報 リソース所有者パスワード認証情報グラントタイプは、レガシーまたは 移行の理由で使用されることが多い。これは、クライアントがユーザー名と パスワードを保存することの全体的なリスクを低減するが、高い権限を持つ 認証情報をクライアントに露出する必要性をなくすものではない。 このグラントタイプは、このプロトコルが避けようとしている パスワードのアンチパターンを維持するため、他のグラントタイプよりも 高いリスクを伴う。クライアントがパスワードを悪用する可能性があり、 またはパスワードが意図せず攻撃者に開示される可能性がある （たとえば、ログファイルやクライアントによって保持されるその他の記録を 介して）。 加えて、リソース所有者は認可プロセスを制御できないため（リソース所有者の 関与は認証情報をクライアントに渡した時点で終わる）、クライアントは リソース所有者が望むよりも広いスコープのアクセストークンを取得できる。 認可サーバーは、このグラントタイプを介して発行されるアクセストークンの スコープと有効期間を考慮すべきである。 認可サーバーおよびクライアントは、このグラントタイプの使用を最小限にし、 可能な限り他のグラントタイプを利用すべきである（SHOULD）。 Hardt 標準化過程 [Page 57]
RFC 6749 OAuth 2.0 2012年10月 10.8. リクエストの機密性 アクセストークン、リフレッシュトークン、リソース所有者パスワード、 およびクライアント認証情報は、平文で送信してはならない（MUST NOT）。 認可コードは平文で送信すべきではない（SHOULD NOT）。 "state" および "scope" パラメータは、安全でないチャネルで送信されたり 安全でない形で保存されたりする可能性があるため、機微なクライアントまたは リソース所有者情報を平文で含めるべきではない（SHOULD NOT）。 10.9. エンドポイントの真正性の保証 中間者攻撃を防ぐため、認可サーバーは、認可エンドポイントおよび トークンエンドポイントへ送信される任意のリクエストについて、 [RFC2818] で定義されるサーバー認証を伴う TLS の使用を要求しなければ ならない（MUST）。クライアントは、[RFC6125] で定義されるように、 かつサーバー識別情報認証に関する自身の要件に従って、認可サーバーの TLS 証明書を検証しなければならない（MUST）。 10.10. 認証情報推測攻撃 認可サーバーは、攻撃者がアクセストークン、認可コード、 リフレッシュトークン、リソース所有者パスワード、および クライアント認証情報を推測することを防止しなければならない（MUST）。 生成されたトークン（およびエンドユーザーによる取り扱いを意図しない その他の認証情報）を攻撃者が推測する確率は、2^(-128) 以下で なければならず（MUST）、2^(-160) 以下であるべきである（SHOULD）。 認可サーバーは、エンドユーザーによる使用を意図した認証情報を保護するために、 他の手段を利用しなければならない（MUST）。 10.11. フィッシング攻撃 本プロトコルおよび類似プロトコルが広く展開されると、エンドユーザーは、 パスワードの入力を求められる Web サイトへリダイレクトされる慣行に 慣れてしまう可能性がある。エンドユーザーが認証情報を入力する前に これらの Web サイトの真正性を慎重に検証しなければ、攻撃者はこの慣行を 悪用してリソース所有者のパスワードを盗むことが可能になる。 サービスプロバイダーは、フィッシング攻撃がもたらすリスクについて エンドユーザーを教育し、エンドユーザーが自分たちのサイトの真正性を 確認しやすくするメカニズムを提供するよう努めるべきである。 クライアント開発者は、ユーザーエージェントとの相互作用方法 （たとえば、外部、埋め込み）のセキュリティ上の影響、および エンドユーザーが認可サーバーの真正性を検証できる能力を考慮すべきである。 Hardt 標準化過程 [Page 58]
RFC 6749 OAuth 2.0 2012年10月 フィッシング攻撃のリスクを低減するため、認可サーバーは、 エンドユーザーとの相互作用に使用されるすべてのエンドポイントで TLS の使用を要求しなければならない（MUST）。 10.12. クロスサイトリクエストフォージェリ クロスサイトリクエストフォージェリ（CSRF）は、攻撃者が被害者である エンドユーザーのユーザーエージェントに、悪意ある URI（たとえば、 誤解を招くリンク、画像、またはリダイレクトとしてユーザーエージェントに 提供される）をたどらせ、信頼しているサーバー（通常は有効な セッション Cookie の存在によって確立される）へ向かわせる悪用手法である。 クライアントのリダイレクト URI に対する CSRF 攻撃により、攻撃者は 自身の認可コードまたはアクセストークンを注入できる。これにより、 クライアントが被害者の保護リソースではなく、攻撃者の保護リソースに 関連付けられたアクセストークンを使用する結果となり得る （たとえば、被害者の銀行口座情報を攻撃者が制御する保護リソースへ 保存する）。 クライアントは、自身のリダイレクト URI に対して CSRF 保護を実装しなければ ならない（MUST）。これは通常、リダイレクト URI エンドポイントへ送信される 任意のリクエストに、リクエストをユーザーエージェントの認証済み状態へ 結び付ける値（たとえば、ユーザーエージェントを認証するために使用される セッション Cookie のハッシュ）を含めることを要求することで達成される。 クライアントは、認可リクエストを行うとき、この値を認可サーバーへ 送るために "state" リクエストパラメータを利用すべきである（SHOULD）。 エンドユーザーから認可が取得されると、認可サーバーは、"state" パラメータに含まれる必要な結び付け値とともに、エンドユーザーの ユーザーエージェントをクライアントへリダイレクトして戻す。 結び付け値により、クライアントはその値をユーザーエージェントの 認証済み状態と照合することでリクエストの妥当性を検証できる。 CSRF 保護に使用される結び付け値は、（Section 10.10 で説明される） 推測不能な値を含まなければならず（MUST）、ユーザーエージェントの 認証済み状態（たとえば、セッション Cookie、HTML5 ローカルストレージ）は、 クライアントとユーザーエージェントだけがアクセスできる場所 （すなわち、同一オリジンポリシーによって保護される場所）に 保持されなければならない（MUST）。 認可サーバーの認可エンドポイントに対する CSRF 攻撃により、攻撃者は エンドユーザーを関与させたり警告したりすることなく、悪意ある クライアントへのエンドユーザー認可を取得できる結果となり得る。 認可サーバーは、自身の認可エンドポイントに対して CSRF 保護を 実装し、悪意あるクライアントがリソース所有者の認識と明示的同意なしに 認可を取得できないことを保証しなければならない（MUST）。 Hardt 標準化過程 [Page 59]
RFC 6749 OAuth 2.0 2012年10月 10.13. クリックジャッキング クリックジャッキング攻撃では、攻撃者は正当なクライアントを登録し、 その後、認可サーバーの認可エンドポイント Web ページを透明な iframe に 読み込み、それを一連のダミーボタンの上に重ねた悪意あるサイトを構築する。 これらのダミーボタンは、認可ページ上の重要なボタンの真下に配置されるよう 慎重に構築される。エンドユーザーが誤解を招く可視ボタンをクリックすると、 エンドユーザーは実際には認可ページ上の不可視ボタン（たとえば "Authorize" ボタン）をクリックしている。これにより、攻撃者は エンドユーザーが知らないうちに、リソース所有者をだまして自身の クライアントへのアクセスを付与させることができる。 この形式の攻撃を防ぐため、ネイティブアプリケーションはエンドユーザー認可を 要求するとき、アプリケーション内にブラウザーを埋め込む代わりに 外部ブラウザーを使用すべきである（SHOULD）。ほとんどの新しいブラウザーでは、 認可サーバーが（非標準の）"x-frame-options" ヘッダーを使用することで iframe の回避を強制できる。このヘッダーは "deny" と "sameorigin" の 2 つの値を持つことができ、それぞれ任意のフレーミング、または異なる オリジンのサイトによるフレーミングをブロックする。古いブラウザーでは、 JavaScript のフレームバスティング技法を使用できるが、すべての ブラウザーで有効とは限らない。 10.14. コードインジェクションと入力検証 コードインジェクション攻撃は、入力またはその他の外部変数が サニタイズされないままアプリケーションによって使用され、 アプリケーションロジックの変更を引き起こすときに発生する。 これにより、攻撃者がアプリケーションデバイスまたはそのデータへ アクセスする、サービス拒否を引き起こす、または広範な悪意ある副作用を 導入することが可能になる場合がある。 認可サーバーおよびクライアントは、受信した任意の値、特に "state" および "redirect_uri" パラメータの値をサニタイズし （可能であれば検証し）なければならない（MUST）。 10.15. オープンリダイレクター 認可サーバー、認可エンドポイント、およびクライアントの リダイレクトエンドポイントは、不適切に設定され、オープン リダイレクターとして動作する可能性がある。オープンリダイレクターとは、 パラメータを使用して、そのパラメータ値によって指定された場所へ 検証なしにユーザーエージェントを自動的にリダイレクトする エンドポイントである。 オープンリダイレクターは、フィッシング攻撃で使用されたり、攻撃者が 親しみのある信頼された宛先の URI authority コンポーネントを使用して、 エンドユーザーに悪意あるサイトを訪問させたりするために使用され得る。 加えて、認可サーバーがクライアントにリダイレクト URI の一部だけを 登録することを許可する場合、攻撃者はクライアントによって運用される オープンリダイレクターを使用して、 Hardt 標準化過程 [Page 60]
RFC 6749 OAuth 2.0 2012年10月 認可サーバーの検証を通過するが、認可コードまたはアクセストークンを 攻撃者の制御下にあるエンドポイントへ送信するリダイレクト URI を 構築できる。 10.16. インプリシットにおけるリソース所有者なりすましのための アクセストークンの誤用 インプリシットフローを使用する public client について、本仕様は アクセストークンがどのクライアントに発行されたかをクライアントが 判断するための方法を提供しない。 リソース所有者は、攻撃者の悪意あるクライアントにアクセストークンを 付与することで、リソースへのアクセスを進んで委任する場合がある。 これはフィッシングまたはその他の口実による場合がある。攻撃者はまた、 他のメカニズムを介してトークンを盗む場合もある。その後、攻撃者は そのアクセストークンを正当な public client に提供することで、 リソース所有者になりすまそうとする可能性がある。 インプリシットフロー（response_type=token）では、攻撃者は 認可サーバーからのレスポンス内のトークンを容易に差し替え、 本物のアクセストークンを、以前に攻撃者に発行されたものに 置き換えることができる。 クライアントのユーザーを識別するためにバックチャネルで渡される アクセストークンに依拠するネイティブアプリケーションと通信する サーバーも、任意の盗まれたアクセストークンを注入できる侵害された アプリケーションを攻撃者が作成することで、同様に侵害される可能性がある。 リソース所有者だけがそのリソースについて有効なアクセストークンを 提示できると仮定する任意の public client は、このタイプの攻撃に対して 脆弱である。 このタイプの攻撃は、正当なクライアントにおけるリソース所有者に関する 情報を攻撃者（悪意あるクライアント）に露出する可能性がある。 また、攻撃者が、最初にアクセストークンまたは認可コードを付与した リソース所有者と同じ権限で、正当なクライアント上の操作を実行することも 可能にする。 リソース所有者をクライアントに認証することは、本仕様の範囲外である。 認可プロセスを、クライアントへの委任されたエンドユーザー認証の形式として 使用する任意の仕様（たとえば、サードパーティサインインサービス）は、 アクセストークンがそのクライアントでの使用のために発行されたかどうかを クライアントが判断できる追加のセキュリティメカニズム （たとえば、アクセストークンの audience 制限）なしに、インプリシット フローを使用してはならない（MUST NOT）。 Hardt 標準化過程 [Page 61]
RFC 6749 OAuth 2.0 2012年10月 11. IANA 考慮事項 11.1. OAuth アクセストークンタイプレジストリ 本仕様は OAuth Access Token Types レジストリを確立する。 アクセストークンタイプは、1 人以上の Designated Expert の助言に基づき、 oauth-ext-review@ietf.org メーリングリストでの 2 週間のレビュー期間の後、 Specification Required（[RFC5226]）で登録される。ただし、 公開前に値を割り当てられるようにするため、Designated Expert は、 そのような仕様が公開されると満足した時点で登録を承認してよい。 登録要求は、適切な件名（たとえば "Request for access token type: example"） とともに、レビューおよびコメントのため oauth-ext-review@ietf.org メーリングリストへ送信されなければならない。 レビュー期間内に、Designated Expert は登録要求を承認または拒否し、 その決定をレビューリストおよび IANA に伝える。拒否には説明を含めるべきであり、 該当する場合、要求を成功させるための提案も含めるべきである。 IANA は Designated Expert からのレジストリ更新のみを受け入れなければならず、 すべての登録要求をレビュー用メーリングリストへ案内すべきである。 11.1.1. 登録テンプレート Type name: 要求される名前（たとえば "example"）。 Additional Token Endpoint Response Parameters: "access_token" パラメータとともに返される追加レスポンスパラメータ。 新しいパラメータは、Section 11.2 で説明されるように、 OAuth Parameters レジストリに別途登録されなければならない（MUST）。 HTTP Authentication Scheme(s): このタイプのアクセストークンを使用して保護リソース要求を 認証するために使用される HTTP 認証スキーム名（存在する場合）。 Change controller: Standards Track RFC については "IETF" と記す。その他については、 責任を負う当事者の名前を示す。その他の詳細（たとえば、郵便住所、 電子メールアドレス、ホームページ URI）も含めてよい。 Hardt 標準化過程 [Page 62]
RFC 6749 OAuth 2.0 2012年10月 Specification document(s): パラメータを指定する文書への参照。文書のコピーを取得するために 使用できる URI を含めることが望ましい。関連する節の表示も 含めてよいが、必須ではない。 11.2. OAuth パラメータレジストリ 本仕様は OAuth Parameters レジストリを確立する。 認可エンドポイントリクエスト、認可エンドポイントレスポンス、 トークンエンドポイントリクエスト、またはトークンエンドポイント レスポンスに含める追加パラメータは、1 人以上の Designated Expert の 助言に基づき、oauth-ext-review@ietf.org メーリングリストでの 2 週間のレビュー期間の後、Specification Required（[RFC5226]）で 登録される。ただし、公開前に値を割り当てられるようにするため、 Designated Expert は、そのような仕様が公開されると満足した時点で 登録を承認してよい。 登録要求は、適切な件名（たとえば "Request for parameter: example"） とともに、レビューおよびコメントのため oauth-ext-review@ietf.org メーリングリストへ送信されなければならない。 レビュー期間内に、Designated Expert は登録要求を承認または拒否し、 その決定をレビューリストおよび IANA に伝える。拒否には説明を含めるべきであり、 該当する場合、要求を成功させるための提案も含めるべきである。 IANA は Designated Expert からのレジストリ更新のみを受け入れなければならず、 すべての登録要求をレビュー用メーリングリストへ案内すべきである。 11.2.1. 登録テンプレート Parameter name: 要求される名前（たとえば "example"）。 Parameter usage location: パラメータを使用できる場所。可能な場所は authorization request、 authorization response、token request、または token response である。 Change controller: Standards Track RFC については "IETF" と記す。その他については、 責任を負う当事者の名前を示す。その他の詳細（たとえば、郵便住所、 電子メールアドレス、ホームページ URI）も含めてよい。 Hardt 標準化過程 [Page 63]
RFC 6749 OAuth 2.0 2012年10月 Specification document(s): パラメータを指定する文書への参照。文書のコピーを取得するために 使用できる URI を含めることが望ましい。関連する節の表示も 含めてよいが、必須ではない。 11.2.2. 初期レジストリ内容 OAuth Parameters レジストリの初期内容は次の通りである。 o Parameter name: client_id o Parameter usage location: authorization request, token request o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: client_secret o Parameter usage location: token request o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: response_type o Parameter usage location: authorization request o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: redirect_uri o Parameter usage location: authorization request, token request o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: scope o Parameter usage location: authorization request, authorization response, token request, token response o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: state o Parameter usage location: authorization request, authorization response o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: code o Parameter usage location: authorization response, token request o Change controller: IETF o Specification document(s): RFC 6749 Hardt 標準化過程 [Page 64]
RFC 6749 OAuth 2.0 2012年10月 o Parameter name: error_description o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: error_uri o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: grant_type o Parameter usage location: token request o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: access_token o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: token_type o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: expires_in o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: username o Parameter usage location: token request o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: password o Parameter usage location: token request o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: refresh_token o Parameter usage location: token request, token response o Change controller: IETF o Specification document(s): RFC 6749 Hardt 標準化過程 [Page 65]
RFC 6749 OAuth 2.0 2012年10月 11.3. OAuth 認可エンドポイントレスポンスタイプレジストリ 本仕様は OAuth Authorization Endpoint Response Types レジストリを 確立する。 認可エンドポイントで使用する追加レスポンスタイプは、1 人以上の Designated Expert の助言に基づき、oauth-ext-review@ietf.org メーリングリストでの 2 週間のレビュー期間の後、 Specification Required（[RFC5226]）で登録される。ただし、 公開前に値を割り当てられるようにするため、Designated Expert は、 そのような仕様が公開されると満足した時点で登録を承認してよい。 登録要求は、適切な件名（たとえば "Request for response type: example"） とともに、レビューおよびコメントのため oauth-ext-review@ietf.org メーリングリストへ送信されなければならない。 レビュー期間内に、Designated Expert は登録要求を承認または拒否し、 その決定をレビューリストおよび IANA に伝える。拒否には説明を含めるべきであり、 該当する場合、要求を成功させるための提案も含めるべきである。 IANA は Designated Expert からのレジストリ更新のみを受け入れなければならず、 すべての登録要求をレビュー用メーリングリストへ案内すべきである。 11.3.1. 登録テンプレート Response type name: 要求される名前（たとえば "example"）。 Change controller: Standards Track RFC については "IETF" と記す。その他については、 責任を負う当事者の名前を示す。その他の詳細（たとえば、郵便住所、 電子メールアドレス、ホームページ URI）も含めてよい。 Specification document(s): タイプを指定する文書への参照。文書のコピーを取得するために 使用できる URI を含めることが望ましい。関連する節の表示も 含めてよいが、必須ではない。 Hardt 標準化過程 [Page 66]
RFC 6749 OAuth 2.0 2012年10月 11.3.2. 初期レジストリ内容 OAuth Authorization Endpoint Response Types レジストリの初期内容は 次の通りである。 o Response type name: code o Change controller: IETF o Specification document(s): RFC 6749 o Response type name: token o Change controller: IETF o Specification document(s): RFC 6749 11.4. OAuth 拡張エラーレジストリ 本仕様は OAuth Extensions Error レジストリを確立する。 他のプロトコル拡張（すなわち、拡張グラントタイプ、アクセストークン タイプ、または拡張パラメータ）とともに使用される追加エラーコードは、 1 人以上の Designated Expert の助言に基づき、 oauth-ext-review@ietf.org メーリングリストでの 2 週間のレビュー期間の後、 Specification Required（[RFC5226]）で登録される。 ただし、公開前に値を割り当てられるようにするため、Designated Expert は、 そのような仕様が公開されると満足した時点で登録を承認してよい。 登録要求は、適切な件名（たとえば "Request for error code: example"） とともに、レビューおよびコメントのため oauth-ext-review@ietf.org メーリングリストへ送信されなければならない。 レビュー期間内に、Designated Expert は登録要求を承認または拒否し、 その決定をレビューリストおよび IANA に伝える。拒否には説明を含めるべきであり、 該当する場合、要求を成功させるための提案も含めるべきである。 IANA は Designated Expert からのレジストリ更新のみを受け入れなければならず、 すべての登録要求をレビュー用メーリングリストへ案内すべきである。 Hardt 標準化過程 [Page 67]
RFC 6749 OAuth 2.0 2012年10月 11.4.1. 登録テンプレート Error name: 要求される名前（たとえば "example"）。エラー名の値は、集合 %x20-21 / %x23-5B / %x5D-7E の外の文字を含んではならない（MUST NOT）。 Error usage location: エラーを使用できる場所。可能な場所は authorization code grant error response（Section 4.1.2.1）、implicit grant error response （Section 4.2.2.1）、token error response（Section 5.2）、 または resource access error response（Section 7.2）である。 Related protocol extension: エラーコードが組み合わせて使用される拡張グラントタイプ、 アクセストークンタイプ、または拡張パラメータの名前。 Change controller: Standards Track RFC については "IETF" と記す。その他については、 責任を負う当事者の名前を示す。その他の詳細（たとえば、郵便住所、 電子メールアドレス、ホームページ URI）も含めてよい。 Specification document(s): エラーコードを指定する文書への参照。文書のコピーを取得するために 使用できる URI を含めることが望ましい。関連する節の表示も 含めてよいが、必須ではない。 12. 参考文献 12.1. 規範参考文献 [RFC2119] Bradner, S., "RFC において要件レベルを示すための キーワード", BCP 14, RFC 2119, 1997年3月. [RFC2246] Dierks, T. and C. Allen, "TLS Protocol Version 1.0", RFC 2246, 1999年1月. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, 1999年6月. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, 1999年6月. Hardt 標準化過程 [Page 68]
RFC 6749 OAuth 2.0 2012年10月 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2000年5月. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, 2003年11月. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 2005年1月. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, 2006年7月. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, 2007年8月. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2008年5月. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, 2008年1月. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, 2008年8月. [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)", RFC 6125, 2011年3月. [USASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. [W3C.REC-html401-19991224] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 Specification", World Wide Web Consortium Recommendation REC-html401-19991224, 1999年12月, <http://www.w3.org/TR/1999/REC-html401-19991224>. [W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, 2008年11月, <http://www.w3.org/TR/2008/REC-xml-20081126>. Hardt 標準化過程 [Page 69]
RFC 6749 OAuth 2.0 2012年10月 12.2. 参考情報文献 [OAuth-HTTP-MAC] Hammer-Lahav, E., Ed., "HTTP Authentication: MAC Access Authentication", 作業中, 2012年2月. [OAuth-SAML2] Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion Profiles for OAuth 2.0", 作業中, 2012年9月. [OAuth-THREATMODEL] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", 作業中, 2012年10月. [OAuth-WRAP] Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth Web Resource Authorization Profiles", 作業中, 2010年1月. [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 2010年4月. [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, 2012年10月. Hardt 標準化過程 [Page 70]
RFC 6749 OAuth 2.0 2012年10月 Appendix A. Augmented Backus-Naur Form (ABNF) 構文 本節は、[RFC5234] の記法を使用して、本仕様で定義される要素の Augmented Backus-Naur Form (ABNF) 構文記述を提供する。以下の ABNF は Unicode コードポイント [W3C.REC-xml-20081126] に基づいて定義される。 これらの文字は通常 UTF-8 で符号化される。要素は最初に定義された順序で 提示される。 以下の定義の一部は、[RFC3986] の "URI-reference" 定義を使用する。 以下の定義の一部は、これらの共通定義を使用する。 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 （UNICODECHARNOCRLF 定義は、[W3C.REC-xml-20081126] の Section 2.2 に ある Char 定義に基づくが、Carriage Return および Linefeed 文字を 省略している。） A.1. "client_id" 構文 "client_id" 要素は Section 2.3.1 で定義される。 client-id = *VSCHAR A.2. "client_secret" 構文 "client_secret" 要素は Section 2.3.1 で定義される。 client-secret = *VSCHAR A.3. "response_type" 構文 "response_type" 要素は Sections 3.1.1 および 8.4 で定義される。 response-type = response-name *( SP response-name ) response-name = 1*response-char response-char = "_" / DIGIT / ALPHA Hardt 標準化過程 [Page 71]
RFC 6749 OAuth 2.0 2012年10月 A.4. "scope" 構文 "scope" 要素は Section 3.3 で定義される。 scope = scope-token *( SP scope-token ) scope-token = 1*NQCHAR A.5. "state" 構文 "state" 要素は 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" 構文 "redirect_uri" 要素は Sections 4.1.1, 4.1.3, and 4.2.1 で定義される。 redirect-uri = URI-reference A.7. "error" 構文 "error" 要素は Sections 4.1.2.1, 4.2.2.1, 5.2, 7.2, and 8.5 で定義される。 error = 1*NQSCHAR A.8. "error_description" 構文 "error_description" 要素は Sections 4.1.2.1, 4.2.2.1, 5.2, and 7.2 で定義される。 error-description = 1*NQSCHAR A.9. "error_uri" 構文 "error_uri" 要素は Sections 4.1.2.1, 4.2.2.1, 5.2, and 7.2 で定義される。 error-uri = URI-reference Hardt 標準化過程 [Page 72]
RFC 6749 OAuth 2.0 2012年10月 A.10. "grant_type" 構文 "grant_type" 要素は 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" 構文 "code" 要素は Section 4.1.3 で定義される。 code = 1*VSCHAR A.12. "access_token" 構文 "access_token" 要素は Sections 4.2.2 および 5.1 で定義される。 access-token = 1*VSCHAR A.13. "token_type" 構文 "token_type" 要素は 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" 構文 "expires_in" 要素は Sections 4.2.2 および 5.1 で定義される。 expires-in = 1*DIGIT A.15. "username" 構文 "username" 要素は Section 4.3.2 で定義される。 username = *UNICODECHARNOCRLF A.16. "password" 構文 "password" 要素は Section 4.3.2 で定義される。 password = *UNICODECHARNOCRLF Hardt 標準化過程 [Page 73]
RFC 6749 OAuth 2.0 2012年10月 A.17. "refresh_token" 構文 "refresh_token" 要素は Sections 5.1 および 6 で定義される。 refresh-token = 1*VSCHAR A.18. エンドポイントパラメータ構文 新しいエンドポイントパラメータの構文は Section 8.2 で定義される。 param-name = 1*name-char name-char = "-" / "." / "_" / DIGIT / ALPHA Appendix B. application/x-www-form-urlencoded メディアタイプの使用 本仕様の公開時点では、"application/x-www-form-urlencoded" メディアタイプは [W3C.REC-html401-19991224] の Section 17.13.4 で定義されていたが、 IANA MIME Media Types レジストリ (<http://www.iana.org/assignments/media-types>) には登録されていなかった。 さらに、その定義は非 US-ASCII 文字を考慮していないため不完全である。 このメディアタイプを使用してペイロードを生成するときにこの欠点に 対処するため、名前と値はまず UTF-8 文字エンコーディング方式 [RFC3629] を使用して符号化されなければならない（MUST）。 その結果のオクテット列は、その後 [W3C.REC-html401-19991224] で 定義されるエスケープ規則を使用してさらに符号化される必要がある。 このメディアタイプを使用するペイロードからデータを解析するとき、 名前/値符号化を逆変換した結果得られる名前と値は、したがって オクテット列として扱われ、UTF-8 文字エンコーディング方式を使用して 復号される必要がある。 たとえば、次の 6 つの Unicode コードポイントから成る値、 (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) は、 （16 進表記を使用して）次のオクテット列に符号化される。 20 25 26 2B C2 A3 E2 82 AC そして、ペイロードでは次のように表される。 +%25%26%2B%C2%A3%E2%82%AC Hardt 標準化過程 [Page 74]
RFC 6749 OAuth 2.0 2012年10月 Appendix C. 謝辞 最初の OAuth 2.0 プロトコル仕様は、David Recordon によって編集され、 2 つの以前の公開物、すなわち OAuth 1.0 コミュニティ仕様 [RFC5849] および OAuth WRAP (OAuth Web Resource Authorization Profiles) [OAuth-WRAP] に基づいていた。その後、 Eran Hammer は、この RFC へ発展した多くの中間ドラフトを編集した。 Security Considerations 節は Torsten Lodderstedt、Mark McGloin、 Phil Hunt、Anthony Nadalin、および John Bradley によって起草された。 "application/x-www-form-urlencoded" メディアタイプの使用に関する節は Julian Reschke によって起草された。ABNF 節は Michael B. Jones によって 起草された。 OAuth 1.0 コミュニティ仕様は Eran Hammer によって編集され、 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、 および Andy Smith によって執筆された。 OAuth WRAP 仕様は Dick Hardt によって編集され、Brian Eaton、 Yaron Y. Goland、Dick Hardt、および Allen Tom によって執筆された。 本仕様は OAuth Working Group の成果であり、そこには数十名の 活発で献身的な参加者が含まれている。特に、次の個人が最終仕様を 形作り形成したアイデア、フィードバック、および文言に貢献した。 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. Hardt 標準化過程 [Page 75]
RFC 6749 OAuth 2.0 2012年10月 本文書は Blaine Cook、Peter Saint-Andre、Hannes Tschofenig、 Barry Leiba、および Derek Atkins の議長のもとで作成された。 エリアディレクターには Lisa Dusseault、Peter Saint-Andre、 および Stephen Farrell が含まれていた。 著者の連絡先 Dick Hardt (editor) Microsoft EMail: dick.hardt@gmail.com URI: http://dickhardt.org/ Hardt 標準化過程 [Page 76]