2012年8月18日土曜日

OpenID Connect Standard 1.0 - draft 13 日本語私訳

Draft: OpenID Connect Standard 1.0 - draft 13

「OpenID Connect Standard 1.0 - draft 13」も和訳してみました。 原文は http://openid.net/specs/openid-connect-standard-1_0.html です。

 TOC 
DraftN. Sakimura
 NRI
 J. Bradley
 Ping Identity
 M. Jones
 Microsoft
 B. de Medeiros
 Google
 E. Jay
 Illumila
 August 16, 2012


OpenID Connect Standard 1.0 - draft 13

概要

OpenID Connect 1.0は、OAuth 2.0上に作られたシンプルなアイデンティティ層である。そして、相互運用可能でRESTfulな方法により、エンドユーザに関する基本的なプロファイル情報の取得と同様に、認可サーバによる認証に基づくエンドユーザのアイデンティティの検証も、クライアントに対し可能とする。

OpenID Connect Standard 1.0は、 OpenID Connect Messages 1.0の要求と応答メッセージのHTTPプロトコルバインディングである。


目次

1.  はじめに
    1.1.  要求記法および規則
    1.2.  用語
2.   認可エンドポイント
    2.1.  OpenID Connectスコープ
    2.2.  プロトコルフロー
        2.2.1.  認可コード、アクセストークン、IDトークンの取得方法
        2.2.2.  認可コードフロー
        2.2.3.  インプリシットフロー
    2.3.  認可要求
        2.3.1.    クライアントによる認可要求の準備
            2.3.1.1.  シンプル要求メソッド
            2.3.1.2.  要求パラメータメソッド
            2.3.1.3.  要求ファイルメソッド
        2.3.2.  認可サーバによる要求オブジェクトの検証
        2.3.3.  認可サーバによるエンドユーザの認証
        2.3.4.  認可サーバによるエンドユーザの同意／認可の取得
        2.3.5.  認可サーバによるエンドユーザのクライアントへの返却
            2.3.5.1.  エンドユーザによる認可の許可
            2.3.5.2.  エンドユーザによる認可の拒否または無効な要求
3.   トークンエンドポイント
    3.1.  アクセストークンの要求
        3.1.1.  アクセストークン要求
        3.1.2.  アクセストークン応答
        3.1.3.  アクセストークンエラー応答
    3.2.  アクセストークンのリフレッシュ
        3.2.1.  リフレッシュトークン応答
        3.2.2.  リフレッシュトークンエラー応答
4.  ユーザ情報エンドポイント
    4.1.  ユーザ情報要求
    4.2.  ユーザ情報応答
    4.3.  ユーザ情報エラー応答
5.  自己発行アイデンティティプロバイダ
    5.1.  自己発行アイデンティティプロバイダディスカバリ
    5.2.  自己発行アイデンティティプロバイダへのクライアント登録
    5.3.  自己発行アイデンティティプロバイダ要求
    5.4.  自己発行アイデンティティプロバイダ応答
    5.5.  自己発行アイデンティティIDトークン検証
6.  ディスカバリと登録
7.  シリアライゼーション
    7.1.  クエリストリングシリアライゼーション
    7.2.   フォームシリアライゼーション
8.  セキュリティに関する考慮事項
    8.1.  インプリシットグラントフローの脅威
9.  プライバシーに関する考慮事項
10.  IANAに関する考慮事項
    10.1.  OAuthパラメータ登録
        10.1.1.  認可要求パラメータ (display)
        10.1.2.  認可要求パラメータ (prompt)
        10.1.3.  認可要求パラメータ (nonce)
        10.1.4.  認可要求パラメータ (request)
        10.1.5.  認可要求パラメータ (request_uri)
        10.1.6.  IDトークン応答パラメータ
    10.2.  OAuth拡張エラー登録
        10.2.1.   認可エンドポイントエラー (invalid_redirect_uri)
        10.2.2.   認可エンドポイントエラー (interaction_required)
        10.2.3.  認可エンドポイントエラー (login_required)
        10.2.4.  認可エンドポイントエラー (session_selection_required)
        10.2.5.  認可エンドポイントエラー (consent_required)
        10.2.6.  認可エンドポイントエラー (invalid_request_uri)
        10.2.7.  認可エンドポイントエラー (invalid_openid_request_object)
        10.2.8.  ユーザ情報エンドポイントエラー (invalid_schema)
11.  文献
    11.1.   規定文献
    11.2.   参考文献
Appendix A.  脚注
    A.1.  JWT値の例
Appendix B.  謝辞
Appendix C.  通知
Appendix D.  文書履歴
§  著者のアドレス



 TOC 

1.  はじめに

この仕様は、OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]で述べられているエンドポイントのHTTPバインディングについて述べている。


 TOC 

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.) で述べられている通りに解釈されるべきものである。

本文書では、書いてあるままに解釈されるべき値は引用符 ("") で囲んで示している。プロトコルメッセージの中でこれらの値を使用する場合は、値の一部として引用符を用いてはならない (MUST NOT)。


 TOC 

1.2.用語

当仕様は、OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]で定義されている、「アクセストークン」、「リフレッシュトークン」、「認可コード」、「認可グラント」、「認可サーバ」、「認可エンドポイント」、「クライアント」、「クライアント識別子」、「クライアントシークレット」、「保護リソース」、「リソース所有者」、「リソースサーバ」、「トークンエンドポイント」という用語と、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]で定義されている用語を用いる。また当仕様では、以下の用語についても定義する。

要求ファイル (Request File)
認可要求パラメータのセットを表すOpenID要求オブジェクトをコンテンツとするドキュメント。
要求ファイルURI (Request File URI)
要求ファイルを参照するURL。要求ファイルの内容は、認可サーバによって取得可能でなければならない。

 TOC 

2.  認可エンドポイント

認可エンドポイントは、エンドユーザのために認証サービスを行い、OpenID Connectのリライイングパーティクライアントに情報をリリースするためにエンドユーザーからの認可の要求を行う。エンドユーザーがエンドユーザの識別子とその他の情報を必要とするリライイングパーティクライアントアプリケーションにアクセスすると、認証と認可のために認可サーバの認可エンドポイントにエンドユーザは送信される。認可サーバは、エンドユーザの識別子を主張するIDトークンと、保護リソースエンドポイントにあるエンドユーザの情報へのアクセスをクライアントに許可するアクセストークンを発行する。保護リソースエンドポイントは、提示されたアクセストークンに関連したスコープに基づき、異なるアクションを実行したり、異なる情報を返すかもしれない (MAY)。クライアントは、認可要求のresponse_typeパラメータを用いて、アクセストークンとIDトークンの返却方法を指定しなければならない (MUST)。


 TOC 

2.1.  OpenID Connectスコープ

クライアントは、適切なパーミッションを持つアクセストークンを取得するために、認可要求で目的のスコープを指定しなければならない (MUST)。 OpenID Connectで用いられるスコープ名は、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の2.1.2節に定義されている。

認可サーバは、認可サーバのポリシーまたはエンドユーザの指示に基づき、クライアントから要求されたスコープ値を、完全または部分的に無視するかもしれない (MAY)。クライアントは、ユーザ情報エンドポイントで利用可能な情報のサブセットのみを要求することを選択するかもしれない。

以下は、認可要求のscopeパラメータの参考例である:

scope=openid profile email phone

 TOC 

2.2.  プロトコルフロー

認可要求は、アクセストークンとIDトークンを取得するために、インプリシットフロ​​ーと認可コードフローという2つの主要なパスに従う。フローは、アクセストークンとIDトークンがクライアントに返される方法を決定する。アクセストークンは、OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の1.4節に定義されている、保護リソースへアクセスするために使用されるクレデンシャルである。アクセストークンは、リソースオーナーの認可を表しており、認可を受けていない第三者に公開されてはならない (MUST NOT)。

インプリシットフローは、スクリプト言語を使用してブラウザに実装されているクライアントによって主に使用される。アクセストークンとIDトークンは、リソースオーナーとリソースオーナーのユーザエージェントへのアクセス権を持つ他のアプリケーションに対し、それらのトークンを公開するかもしれない(MAY)クライアントに直接返される。認可サーバはアクセストークンを発行する前にクライアント認証を実行しない。

認可コードフローはクライアントに認可コードを返し、クライアントはそれをアクセストークンに直接変換できる。これは、リソースオーナーとリソースオーナーのユーザエージェントへのアクセス権を持つ他の悪意のある可能性のあるアプリケーションに対し、アクセストークンを公開しないという利点を提供する。認可サーバは、認可コードをアクセストークンに交換する前にクライアントを認証することができる。 認可コードフローはクライアントと認可サーバ間で用いられるクライアントシークレットを安全に保持することが可能なクライアントに適している。一方、インプリシットフローはそれが不可能なクライアントに適している。


 TOC 

2.2.1.  認可コード、アクセストークン、IDトークンの取得方法

OpenID Connect Standardでは、クライアントは、アクセストークンとIDトークンを取得するためにユーザーエージェントを介して認可エンドポイントに認可要求を送信する。クライアントは、認可エンドポイントから、または認可エンドポイントから取得したcodeを使用してトークンエンドポイントから、それらのトークンを得るかもしれない (MAY)。後者はコードフロー (Authorization Code Flow)、前者はインプリシットフロー (Implicit Flow)と呼ばれる。


 TOC 

2.2.2.  認可コードフロー

認可コードフローは、次の手順を実施する。

  1. クライアントは、希望する要求パラメータを含む認可要求を準備する。
  2. クライアントは、認可サーバに要求を送信する。
  3. 認可サーバは、エンドユーザを認証する。
  4. 認可サーバは、エンドユーザの同意／承認を取得する。
  5. 認可サーバは、認可コードと共にエンドユーザをクライアントに戻す。
  6. クライアントは、トークンエンドポイント (Token Endpoint)に認可コードを使って応答を要求する。
  7. クライアントは、応答ボディ内にアクセストークンとIDトークンを含む応答を受信する。
  8. クライアントは、エンドユーザの識別子を取得するためにIDトークンの検証を行う。
  9. (任意) クライアントは、アクセストークンと共にユーザ情報エンドポイント (UserInfo Endpoint)にアクセスする。
  10. (任意) クライアントは、ユーザ情報応答を受信する。

各ステップで、メッセージを受信した当事者は、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の検証ルールセットに従って検証しなければならない (MUST)。


 TOC 

2.2.3.  インプリシットフロー

インプリシットフローは、次の手順を実施する。

  1. クライアントは、希望する要求パラメータを含む認可要求を準備する。
  2. クライアントは、認可サーバに要求を送信する。
  3. 認可サーバは、エンドユーザを認証する。
  4. 認可サーバは、エンドユーザの同意／承認を取得する。
  5. 認可サーバは、アクセストークンおよびIDトークンと共にエンドユーザをクライアントに送り戻す。
  6. クライアントは、エンドユーザの識別子を取得するためにIDトークンの検証を行う。
  7. (任意) クライアントは、アクセストークンと共にユーザ情報エンドポイント (UserInfo Endpoint)にアクセスする。
  8. (任意) クライアントは、ユーザ情報応答を受信する。

各ステップで、メッセージを受信した当事者は、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の検証ルールセットに従って検証しなければならない (MUST)。


 TOC 

2.3.認可要求

エンドユーザが保護リソースにアクセスしようとした際に、エンドユーザーの認可をまだ取得していない場合、クライアントは、認可エンドポイントへの認可要求の準備をする。

認可サーバは、認可エンドポイントでのトランスポート層セキュリティ機構の使用を必須としなければならない (MUST)。認可エンドポイントサーバはTLS 1.2 RFC 5246 (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] および／または TLS 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) をサポートしなければならない (MUST)。また、同等のセキュリティを持つ、他のトランスポート層セキュリティ機構をサポートしてもよい (MAY)。

認可サーバは、認可エンドポイントで、RFC 2616 (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]に定義されているHTTP "GET"および"POST"の使用をサポートしなければならない (MUST)。

クライアントは、認可サーバへの認可要求の送信に、HTTP "GET"を使用するかもしれないし、または"POST"を使用するかもしれない (MAY)。HTTP "GET"メソッドを用いる場合、要求パラメータはURI クエリストリングシリアライゼーション (Query String Serialization)によってシリアライゼーションされる。HTTP "POST"メソッドを用いる場合、要求パラメータはフォームシリアライゼーション (Form Serialization)によってシリアライゼーションされる。


 TOC 

2.3.1.  クライアントによる認可要求の準備

クライアントは、HTTP "GET"または"POST"メソッドを用いた要求パラメータと共に、認可エンドポイントへの認可要求の準備を行う。認可URLで使用されるスキームは、HTTPSでなければならない (MUST)。クライアントは、RFC 6125 (Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.) [RFC6125]に従って、TLS/SSLサーバ証明書の確認を行わなければならない (MUST)。

必要な認可要求パラメータは以下の通りである:

response_type
認可応答をクライアントに返す方法を決定するOAuth 2.0で登録された応答タイプ。OAuth 2.0 Multiple Response Type Encoding Practices (de Medeiros, B., Scurtescu, M., and P. Tarjan, “OAuth 2.0 Multiple Response Type Encoding Practices,” May 2012.) [OAuth.Responses]の記述のとおり、以下の登録値がサポートされている:
  • code
  • code id_token
  • id_token
  • token
  • token id_token
  • code token
  • code token id_token
client_id
クライアント識別子
scope
これは、スペースで区切られたASCII文字列の一つとしてopenidを含まなければならない (MUST)。他の値としてprofile、email、address、phoneが含まれるかもしれない (MAY)。この値には、ユーザ情報エンドポイントによって返されるクレームの追加のリストが指定される。
redirect_uri
応答が送信されるリダイレクト先のURI。 このURIのスキーム、ホスト、パス、クエリパラメータ部分は、OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2012.) [OpenID.Registration]仕様に従い、そのclient_idに対して登録されたredirect_urisの中の一つにマッチしなければならない (MUST)。

要求は、下記の任意の、時には必須のパラメータを含めることができる (MAY)。

nonce
IDトークンを持つクライアントセッションを関連付けるためと、リプレイ攻撃を軽減するために使用される文字列値。 値は変更されずにそのまま認可要求からIDトークンへ渡されます。 インプリシットフローではnonceは必須である。コードフローでは任意である。
state
要求とコールバック間で状態を維持するために使用する不明瞭な値は、XSRF攻撃に対する保護の役割を果たす。
request
OpenID要求オブジェクト値。
request_uri
OpenID要求オブジェクトを指すURL。
display
認可サーバがエンドユーザに対して、認証の画面を表示する方法を指定するASCII文字列値。詳細は、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の2.1.2節を参照。
prompt
login、consent、select_account、noneという値を含むことができる、スペース区切りのASCII文字列値のリスト。詳細は、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]を参照。
id_token
ヒントとして認可サーバに渡されるIDトークン。詳細は、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]を参照。

認可エンドポイントに要求を構築・送信するには、次の3つの方法がある。

a.
シンプル要求メソッド
b.
要求パラメータメソッド
c.
要求ファイルメソッド

シンプル要求メソッドは、クライアントがデフォルトのユーザ情報とIDトークンクレームを要望する、シンプルなケースで使用される。

要求パラメータメソッドは、クライアントが異なるユーザ情報のセットとIDトークンクレームを取得したい場合に、OpenID要求オブジェクトを送信することによって使用される。要求パラメータメソッドでは、要求に署名または暗号化をすることもできる。

要求ファイルメソッドは、要求パラメータメソッドと同様に動作するが、OpenID要求オブジェクトを参照するURLを送信するという点で異なる。これは、機能が制限されたユーザエージェントにでさえ、安全かつコンパクトに大きな要求を送信することを可能とする。クライアントは、要求のサイズを最小化するために要求ファイルメソッドを使用するかもしれない (MAY)。


 TOC 

2.3.1.1.  シンプル要求メソッド

クライアントは、適切なパラメータを使用して認可エンドポイントへの認可要求を準備する。HTTP "GET"メソッドを用いる場合、要求パラメータはURI クエリストリングシリアライゼーション (Query String Serialization)によってシリアライゼーションされる。HTTP "POST"メソッドを用いる場合、要求パラメータはフォームシリアライゼーション (Form Serialization)によってシリアライゼーションされる。

以下は、認可要求のURL（表示目的のみのための行の折り返しが含まれる）の参考例を示す。 

https://server.example.com/op/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj

 TOC 

2.3.1.1.1.  クライアントによる認可サーバへの要求の送信

認可要求を構築した後、クライアントはそれをHTTPSエンドユーザ認可エンドポイントに送信する。これは、HTTPSリダイレクトやハイパーリンク、またはユーザエージェントを認可エンドポイントURLに導く任意の手法で行われるかもしれない (MAY)。

以下は、HTTPリダイレクトを使用した参考例である（表示上だけの行折り返りを含む）:

HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj

 TOC 

2.3.1.2.  要求パラメータメソッド

クライアントは、適切なHTTPパラメータシリアライゼーションを使用して認可エンドポイントへの認可要求を準備する。クライアントは、HTTP "POST"メソッドを使用して要求を構築すべき (SHOULD) だが、HTTP "GET"メソッドを使用するかもしれない (MAY)。

認可要求は、2.3.1節 (Client Prepares an Authorization Request)で定義されたrequestパラメータを含まなければならない (MUST)。認可要求は、request_uriパラメータを含んでいてはならない (MUST NOT)。

requestパラメータは、認可要求を含み、また、ユーザ情報エンドポイントから返される内容の指定も行う、OpenID要求オブジェクトである。OpenID要求オブジェクトは、JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.) [JWS]およびJWE (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.) [JWE]を各々を用いて、「署名」もしくは「署名および暗号化」を行うかもしれない (MAY)。それにより、認証、完全性、否認防止、機密性の全て、または一部を提供する。

以下は、base64urlエンコードと署名を行う前のOpenID要求オブジェクトの参考例である:

{
 "response_type": "code id_token",
 "client_id": "s6BhdRkqt3",
 "redirect_uri": "https://client.example.org/cb",
 "scope": "openid profile",
 "state": "af0ifjsldkj",
 "nonce": "n-0S6_WzA2Mj",
 "userinfo":
   {
     "claims":
       {
         "name": {"essential": true},
         "nickname": null,
         "email": {"essential": true},
         "email_verified": {"essential": true},
         "picture": null
       }
   },
 "id_token":
   {
     "max_age": 86400,
     "claims:{"acr": {"values":["2"]}}
   }
}

以下は、base64urlエンコードと署名を行う前のOpenID要求オブジェクトの参考例である（表示上だけの行折り返りを含む）: （※訳注：実際には、エンコード・署名前とエンコード・署名後と公開鍵の参考例）

algorithm = RS256

JSON Encoded Header =  {"alg":"RS256"}
JSON Encoded Payload =
    {
     "response_type":"code id_token",
     "client_id":"s6BhdRkqt3",
     "redirect_uri":"https://client.example.org/cb",
     "scope":"openid profile",
     "state":"af0ifjsldkj",
     "nonce":"n-0S6_WzA2Mj",
     "userinfo":{
       "claims":{
         "name":{"essential":true},
         "nickname":null,"email":{"essential":true},
         "email_verified":{"essential":true},
         "picture":null
        }
      },
     "id_token":{
       "max_age":86400,
       "claims":{
         "acr":{"values":["2"]}
        }
      }
    }
OpenID Request Object =
    eyJhbGciOiJSUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF90b2tlbiIs
    ImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOiJodHRwczpcL
    1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2ZpbG
    UiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl9XekEyTWoiLCJ
    1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6eyJlc3NlbnRpYWwiOnRydWV9LCJu
    aWNrbmFtZSI6bnVsbCwiZW1haWwiOnsiZXNzZW50aWFsIjp0cnVlfSwiZW1haWxfd
    mVyaWZpZWQiOnsiZXNzZW50aWFsIjp0cnVlfSwicGljdHVyZSI6bnVsbH19LCJpZF
    90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiY2xhaW1zIjp7ImFjciI6eyJ2YWx1ZXM
    iOlsiMiJdfX19fQ.krAJHvc-vo5ntIc5suj2u3gU75nZ1ICcidLEw8OCNyOlTR4Gk
    6etZDr5lozMFzhDSXAJ5TxhfUJLsp8VSum8spnmbGaqKr4bEWTirUDGE3TsJCHRQZ
    LzwuAYlLcS-ZaHVk9ue0oB7q_GeGTAIDHBncJP1x1j-MPvNxWbYXQ4wo9O6Y8Qnby
    OrrLl5LHRMrvlLFnc0uqt5QKHqcQa6l9wYQjjWJXoZirsWdJ_wmSsfbQCWMRtA6JN
    bV0q0gImbOGno75GxFKNkguW5JBU4Vj5gEafz2EPSxVsRNWf6MtFvXqOLSZMqoKK4
    0b2akbj0kGdZ8aPPSMoywaGclKlIHh0PQ

The following is the RSA public key information that can be used
to verify the OpenID Request Object signature in the above example.
The values are an array of hexadecimal digits in big endian format.

modulus:
[
 ce,11,16,4c,12,55,4d,f7,14,7a,a9,cc,cc,e4,05,30,
 21,15,41,63,b2,39,46,70,3f,c2,eb,05,68,7c,f2,d2,
 ab,67,23,c6,0a,f0,64,4c,3a,7e,13,60,73,c8,73,10,
 57,8a,4a,e7,55,32,b3,66,0e,c3,32,fd,b1,ee,53,1c,
 35,8c,75,af,6b,b6,c0,89,55,c8,f5,57,b5,9a,13,bc,
 0f,82,5f,a4,20,87,56,59,fe,28,da,0e,99,b3,33,b2,
 fc,5a,78,ab,49,c6,dc,e4,ed,0d,10,a4,06,ed,a2,10,
 fd,b5,8f,cd,a9,45,24,6b,90,20,71,9f,36,82,85,f9,
 40,ec,a6,5b,23,59,ff,ca,12,ad,c7,20,3b,15,d0,38,
 f3,42,da,49,56,72,28,0a,6f,ac,a8,98,86,87,00,09,
 2c,1f,d3,2e,82,43,ec,24,12,2e,a6,55,74,49,b7,56,
 81,4b,2c,25,2d,80,34,f2,88,e9,e6,19,19,43,7f,5e,
 08,cd,a4,d4,47,57,76,16,da,af,df,7c,43,d3,d9,4f,
 05,c0,d5,c7,ef,b8,64,d9,6c,35,b1,10,a2,e3,30,a5,
 6e,2a,b4,f5,62,fb,3e,d8,d4,d7,85,90,16,d4,a8,c5,
 4b,fd,d4,c0,b9,03,93,ec,38,75,53,7e,c7,9b,43,9f
]

exponent: [01,00,01]

以下は、OpenID要求メソッドを含む、認可要求の参考例である（表示上だけの行折り返りを含む）:

https://server.example.com/authorize?
response_type=code%02id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
&request=eyJhbGciOiJSUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF
90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOi
JodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3Blbm
lkIHByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl
9XekEyTWoiLCJ1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6eyJlc3NlbnRpYW
wiOnRydWV9LCJuaWNrbmFtZSI6bnVsbCwiZW1haWwiOnsiZXNzZW50aWFsIjp0cn
VlfSwiZW1haWxfdmVyaWZpZWQiOnsiZXNzZW50aWFsIjp0cnVlfSwicGljdHVyZS
I6bnVsbH19LCJpZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiY2xhaW1zIjp7Im
FjciI6eyJ2YWx1ZXMiOlsiMiJdfX19fQ.krAJHvc-vo5ntIc5suj2u3gU75nZ1IC
cidLEw8OCNyOlTR4Gk6etZDr5lozMFzhDSXAJ5TxhfUJLsp8VSum8spnmbGaqKr4
bEWTirUDGE3TsJCHRQZLzwuAYlLcS-ZaHVk9ue0oB7q_GeGTAIDHBncJP1x1j-MP
vNxWbYXQ4wo9O6Y8QnbyOrrLl5LHRMrvlLFnc0uqt5QKHqcQa6l9wYQjjWJXoZir
sWdJ_wmSsfbQCWMRtA6JNbV0q0gImbOGno75GxFKNkguW5JBU4Vj5gEafz2EPSxV
sRNWf6MtFvXqOLSZMqoKK40b2akbj0kGdZ8aPPSMoywaGclKlIHh0PQ

 TOC 

2.3.1.2.1.  クライアントによる認可サーバへの要求の送信

認可要求を構築した後、クライアントはそれをHTTPS認可エンドポイントに送信する。これは、HTTPSリダイレクトやハイパーリンク、またはユーザエージェントを認可エンドポイントに導く任意の手法で行われるかもしれない (MAY)。

以下は、HTTPリダイレクトを使用した参考例である（表示上だけの行折り返りを含む）:

HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
&request=eyJhbGciOiJSUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF
90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOi
JodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3Blbm
lkIHByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl
9XekEyTWoiLCJ1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6eyJlc3NlbnRpYW
wiOnRydWV9LCJuaWNrbmFtZSI6bnVsbCwiZW1haWwiOnsiZXNzZW50aWFsIjp0cn
VlfSwiZW1haWxfdmVyaWZpZWQiOnsiZXNzZW50aWFsIjp0cnVlfSwicGljdHVyZS
I6bnVsbH19LCJpZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiY2xhaW1zIjp7Im
FjciI6eyJ2YWx1ZXMiOlsiMiJdfX19fQ.krAJHvc-vo5ntIc5suj2u3gU75nZ1IC
cidLEw8OCNyOlTR4Gk6etZDr5lozMFzhDSXAJ5TxhfUJLsp8VSum8spnmbGaqKr4
bEWTirUDGE3TsJCHRQZLzwuAYlLcS-ZaHVk9ue0oB7q_GeGTAIDHBncJP1x1j-MP
vNxWbYXQ4wo9O6Y8QnbyOrrLl5LHRMrvlLFnc0uqt5QKHqcQa6l9wYQjjWJXoZir
sWdJ_wmSsfbQCWMRtA6JNbV0q0gImbOGno75GxFKNkguW5JBU4Vj5gEafz2EPSxV
sRNWf6MtFvXqOLSZMqoKK40b2akbj0kGdZ8aPPSMoywaGclKlIHh0PQ

 TOC 

2.3.1.3.  要求ファイルメソッド

要求ファイルメソッドは、OpenID要求オブジェクトを格納する要求ファイルを使用する点で、他のメソッドと異なる。これは、認可要求の一部として要求ファイルのURLを送信する。

クライアントは、HTTP "GET"または"POST"メソッドを用いて認可要求の準備をする。クライアントは、HTTP "GET"メソッドを使用すべき (SHOULD) だが、HTTP "POST"メソッドを使用するかもしれない (MAY)。認可URLで使用されるスキームは、HTTPSでなければならない (MUST)。クライアントは、RFC 6125 (Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.) [RFC6125]に従って、TLS/SSLサーバ証明書の確認を行わなければならない (MUST)。

認可要求は、requestパラメータを含んでいてはならない (MUST NOT)。認可要求は、request_uriを含んでいなければならない (MUST)。URLのターゲットの中身は、OpenID要求オブジェクトでなければならない。ターゲットのOpenID要求オブジェクトが認可サーバによって検証可能な方法で署名されていない限りrequest_uri値に使用されるスキームは、HTTPSでなければならない (MUST)。request_uri値は、認可サーバによって到達可能でなければならない (MUST)。また、クライアントによって到達可能であるべきである (SHOULD)。

以下は、要求ファイルの参考例である（表示上だけの行折り返りを含む）:

eyJhbGciOiJSUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF90b2tlbiI
sImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOiJodHRwczp
cL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2Z
pbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl9XekEyTWo
iLCJ1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6eyJlc3NlbnRpYWwiOnRydWV
9LCJuaWNrbmFtZSI6bnVsbCwiZW1haWwiOnsiZXNzZW50aWFsIjp0cnVlfSwiZW1
haWxfdmVyaWZpZWQiOnsiZXNzZW50aWFsIjp0cnVlfSwicGljdHVyZSI6bnVsbH1
9LCJpZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiY2xhaW1zIjp7ImFjciI6eyJ
2YWx1ZXMiOlsiMiJdfX19fQ.krAJHvc-vo5ntIc5suj2u3gU75nZ1ICcidLEw8OC
NyOlTR4Gk6etZDr5lozMFzhDSXAJ5TxhfUJLsp8VSum8spnmbGaqKr4bEWTirUDG
E3TsJCHRQZLzwuAYlLcS-ZaHVk9ue0oB7q_GeGTAIDHBncJP1x1j-MPvNxWbYXQ4
wo9O6Y8QnbyOrrLl5LHRMrvlLFnc0uqt5QKHqcQa6l9wYQjjWJXoZirsWdJ_wmSs
fbQCWMRtA6JNbV0q0gImbOGno75GxFKNkguW5JBU4Vj5gEafz2EPSxVsRNWf6MtF
vXqOLSZMqoKK40b2akbj0kGdZ8aPPSMoywaGclKlIHh0PQ

 TOC 

2.3.1.3.1.  クライアントによる要求ファイルのURLの生成

その後、クライアントは、ローカルまたはリモートに要求ファイルを格納する。これが要求URI "request_uri"である。認可サーバがファイルの変更を検出できるように、URIには"#"のあとにbase64urlでエンコードされたSHA-256 [FIPS180-2]ハッシュが付加されるかもしれない (MAY)。

要求ファイルにユーザの属性値が含まれている場合、認可サーバ以外には明らかにしてはいけない (MUST NOT)という点に注意すべきである。このように、 "request_uri"はそのライフタイム中、適切なエントロピーを持っている必要があり、認証成功後または合理的なタイムアウト後に削除しなければならない。

クライアントはその後、ローカルまたはリモートに要求ファイルを記録し、その要求ファイルのURI "request_uri"を取得する。

以下は、参考例である（表示上だけの行折り返しを含む）:

https://client.example.org/rf.txt
#yhjJGgQ3UwE2Lm2i_wZNb5QxQ6XRnfzqYOretJMFTQI

 TOC 

2.3.1.3.2.  クライアントによるHTTPSリダイレクトを用いた認可サーバへの要求の送信

クライアントは、認可エンドポイントへの認可要求を送信する。

URL全体は、512バイトを超えてはならない (MUST NOT)。

以下は、参考例である（表示上だけの行折り返しを含む）:

HTTP/1.1 302 Found
Location: https://server.example.com/authorize
?response_type=code%20id_token
&client_id=s6BhdRkqt3
&request_uri=https%3A%2F%2Fclient.example.org%2Frf.txt
%23959w6lFunlMyjSaxmW0FtqvkRsmCaAIWuwl6QKeY89g
&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj&scope=openid

 TOC 

2.3.1.3.3.  認可サーバによる要求ファイルの取得

要求受信時に、認可サーバーは、既にキャッシュしていない限り、コンテンツ取得のためにrequest_uriにGET要求を送信しなければならない (MUST)。 そして、認可要求のパラメータを再作成するためにそれをパースする。

RPは、異なるパラメータを利用できるように各要求に対し一意なURIを用いるか、そうでなければ認可サーバにrequest_uriをキャッシュさせないようにすべき (SHOULD) であることに注意。

以下は、 この取得プロセスの参考例である。 

GET /rf.txt HTTP/1.1
Host: client.example.org

 TOC 

2.3.2.認可サーバによる要求オブジェクトの検証

認可サーバは、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の5.1節に従って、要求を検証する。


 TOC 

2.3.3.  認可サーバによるエンドユーザの認証

認可サーバーは、必要なすべてのパラメータが存在し、有効であることを確認するために、要求を検証する。 要求が有効であれば、認可サーバはエンドユーザを認証しなければならない (MUST)。認可サーバがエンドユーザを認証する方法（例えばユーザ名とパスワードによるログイン、セッションクッキー）は、この仕様の範囲外である。認証方法に応じて、認可サーバは認証ユーザインタフェースを表示するかもしれない (MAY)。

認可サーバは、次のケースでエンドユーザの認証を試みなければならない (MUST):

  • エンドユーザが認可サーバによってまだ認証されていない。
  • 認可要求のpromptパラメータにloginが指定されている。このとき認可サーバは、エンドユーザがすでに認証されている場合でも、エンドユーザを再認証しなければならない (MUST)。

認可サーバは、次のケースでエンドユーザの認証を試みてはならない (MUST NOT):

  • 認可要求の"prompt"パラメータにnoneが指定されている。このとき認可サーバは、エンドユーザが認証されていない場合、エラーを返さなければならない (MUST)。

 TOC 

2.3.4.  認可サーバによるエンドユーザの同意／認可の取得

エンドユーザが認証されると、認可サーバは、認可決定を取得する必要がある (MUST)。これは、エンドユーザに対し、同意の内容を認識させた上で同意を得るための対話をエンドユーザーに提示することによって行うか、または他の手段（例えば、事前に管理上の手段による同意を経由）を介して同意を確立することによって、実施されるかもしれない (MAY)。

認可サーバは、次のケースでエンドユーザに対し、認可の要求を試みなければならない (MUST):

  • エンドユーザは、認可要求に対し、クライアントを事前に認可していない。
  • 認可要求のpromptパラメータにconsentが指定されている。このとき認可サーバは、エンドユーザが事前にそのクライアントを認可していた場合でも、エンドユーザに認可を要求しなければならない (MUST)。

認可サーバは、次のケースでエンドユーザに対し、認可の要求を試みてはならない (MUST NOT):

  • 認可要求の"prompt"パラメータにnoneが指定されている。このとき認可サーバは、エンドユーザが事前にそのクライアントを認可していない場合、エラーを返さなければならない (MUST)。

 TOC 

2.3.5.  認可サーバによるエンドユーザのクライアントへの返却

認可が決定されると、認可サーバは、成功またはエラー応答を返す。


 TOC 

2.3.5.1.  エンドユーザによる認可の許可

リソースオーナがアクセス要求を許可したとき、認可サーバは、"application/x-www-form-urlencoded"フォーマットで、認可要求に指定されたredirect_uriに応答パラメータを追加することによってクライアントに対し、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の2.1.3節に記述されている認可応答を発行する。

認可要求のresponse_typeパラメータが、tokenまたはid_tokenを含んでいる場合、すべての応答パラメータがリダイレクト先のURIのフラグメントコンポーネントに追加されるべき (SHOULD) であることに注意すること。それ以外の場合、応答パラメータはリダイレクト先のURIのクエリコンポーネントに追加される。

以下は、異なるresponse_type値を持つ要求とその応答の参考例である（表示上だけの行折り返りを含む）:

ケース1: response_type=code 

https://server.example.com/op/authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj


HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&state=af0ifjsldkj

ケース2: response_type=token id_token 

https://server.example.com/op/authorize?
response_type=token%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj


HTTP/1.1 302 Found
Location: https://client.example.org/cb#
access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
&token_type=Bearer
&id_token=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZXJ2ZXIuZ
XhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiczZCa
GRSa3F0MyIsIm5vbmNlIjoibi0wUzZfV3pBMk1qIiwiZXhwIjoxMzExMjgxOTcwL
CJpYXQiOjEzMTEyODA5NzB9.RgXxzppVvn1EjUiV3LIZ19SyhdyREe_2jJjW5EC8
XjNuJfe7Dte8YxRXxssJ67N8MT9mvOI3HOHm4whNx5FCyemyCGyTLHODCeAr_id0
29-4JP0KWySoan1jmT7vbGHhu89-l9MTdaEvu7pNZO7DHGwqnMWRe8hdG7jUES4w
4ReQTygKwXVVOaiGoeUrv6cZdbyOnpGlRlHaiOsv_xMunNVJtn5dLz-0zZwVftKV
pFuc1pGaVsyZsOtkT32E4c6MDHeCvIDlR5ESC0ct8BLvGJDB5954MjCR4_X2GAEH
onKw4NF8wTmUFvhslYXmjRNFs21Byjn3jNb7lSa3MBfVsw
&state=af0ifjsldkj

ケース3: response_type=code id_token 

https://server.example.com/op/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj


HTTP/1.1 302 Found
Location: https://client.example.org/cb#
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&id_token=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZXJ2ZXIuZ
XhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiczZCa
GRSa3F0MyIsIm5vbmNlIjoibi0wUzZfV3pBMk1qIiwiZXhwIjoxMzExMjgxOTcwL
CJpYXQiOjEzMTEyODA5NzB9.RgXxzppVvn1EjUiV3LIZ19SyhdyREe_2jJjW5EC8
XjNuJfe7Dte8YxRXxssJ67N8MT9mvOI3HOHm4whNx5FCyemyCGyTLHODCeAr_id0
29-4JP0KWySoan1jmT7vbGHhu89-l9MTdaEvu7pNZO7DHGwqnMWRe8hdG7jUES4w
4ReQTygKwXVVOaiGoeUrv6cZdbyOnpGlRlHaiOsv_xMunNVJtn5dLz-0zZwVftKV
pFuc1pGaVsyZsOtkT32E4c6MDHeCvIDlR5ESC0ct8BLvGJDB5954MjCR4_X2GAEH
onKw4NF8wTmUFvhslYXmjRNFs21Byjn3jNb7lSa3MBfVsw
&state=af0ifjsldkj

ケース4: response_type=token code 

https://server.example.com/op/authorize?
response_type=token%20code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj


HTTP/1.1 302 Found
Location: https://client.example.org/cb#
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
&token_type=Bearer
&state=af0ifjsldkj

ケース5: response_type=token code id_token 

https://server.example.com/op/authorize?
response_type=token%20code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj


HTTP/1.1 302 Found
Location: https://client.example.org/cb#
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
&token_type=Bearer
&id_token=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZXJ2ZXIuZ
XhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiczZCa
GRSa3F0MyIsIm5vbmNlIjoibi0wUzZfV3pBMk1qIiwiZXhwIjoxMzExMjgxOTcwL
CJpYXQiOjEzMTEyODA5NzB9.RgXxzppVvn1EjUiV3LIZ19SyhdyREe_2jJjW5EC8
XjNuJfe7Dte8YxRXxssJ67N8MT9mvOI3HOHm4whNx5FCyemyCGyTLHODCeAr_id0
29-4JP0KWySoan1jmT7vbGHhu89-l9MTdaEvu7pNZO7DHGwqnMWRe8hdG7jUES4w
4ReQTygKwXVVOaiGoeUrv6cZdbyOnpGlRlHaiOsv_xMunNVJtn5dLz-0zZwVftKV
pFuc1pGaVsyZsOtkT32E4c6MDHeCvIDlR5ESC0ct8BLvGJDB5954MjCR4_X2GAEH
onKw4NF8wTmUFvhslYXmjRNFs21Byjn3jNb7lSa3MBfVsw
&state=af0ifjsldkj

IDトークンを検証するために使用される公開鍵情報

The following is the RSA public key information that can be used
to verify the ID Token signatures in the above examples.
The values are an array of hexadecimal digits in big endian format.

modulus:
[
 ce,11,16,4c,12,55,4d,f7,14,7a,a9,cc,cc,e4,05,30,
 21,15,41,63,b2,39,46,70,3f,c2,eb,05,68,7c,f2,d2,
 ab,67,23,c6,0a,f0,64,4c,3a,7e,13,60,73,c8,73,10,
 57,8a,4a,e7,55,32,b3,66,0e,c3,32,fd,b1,ee,53,1c,
 35,8c,75,af,6b,b6,c0,89,55,c8,f5,57,b5,9a,13,bc,
 0f,82,5f,a4,20,87,56,59,fe,28,da,0e,99,b3,33,b2,
 fc,5a,78,ab,49,c6,dc,e4,ed,0d,10,a4,06,ed,a2,10,
 fd,b5,8f,cd,a9,45,24,6b,90,20,71,9f,36,82,85,f9,
 40,ec,a6,5b,23,59,ff,ca,12,ad,c7,20,3b,15,d0,38,
 f3,42,da,49,56,72,28,0a,6f,ac,a8,98,86,87,00,09,
 2c,1f,d3,2e,82,43,ec,24,12,2e,a6,55,74,49,b7,56,
 81,4b,2c,25,2d,80,34,f2,88,e9,e6,19,19,43,7f,5e,
 08,cd,a4,d4,47,57,76,16,da,af,df,7c,43,d3,d9,4f,
 05,c0,d5,c7,ef,b8,64,d9,6c,35,b1,10,a2,e3,30,a5,
 6e,2a,b4,f5,62,fb,3e,d8,d4,d7,85,90,16,d4,a8,c5,
 4b,fd,d4,c0,b9,03,93,ec,38,75,53,7e,c7,9b,43,9f
]

exponent: [01,00,01]

 TOC 

2.3.5.2.  エンドユーザによる認可の拒否または無効な要求

エンドユーザが認可を拒否したか、ユーザ認証に失敗した場合、認可サーバは、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の2.1.4節に定義されたエラー認可応答を返さなければならない (MUST)。認可サーバは、適切なエラーパラメータと共に認可要求で指定されたリダイレクト先のURIにクライアントを返す。その他のパラメータは返されるべきではない(SHOULD)。

エラー応答のパラメータは次のとおりである:

error
必須。エラーコード。REQUIRED. The error code.
error_description
任意。人間が読める形式のUTF-8でエンコードされたエラーのテキスト記述。
error_uri
任意。エラーについての追加情報を含むWebページへのURI。
state
認可要求にstateパラメータが含まれている場合、必須。 クライアントから受信した値をそのまま設定。

認可要求のresponse_typeパラメータが、tokenまたはid_tokenを含んでいる場合、すべてのエラー応答パラメータがリダイレクト先のURIのフラグメントコンポーネントに追加されるべきである (SHOULD)。それ以外の場合、応答パラメータはリダイレクト先のURIのクエリコンポーネントに追加される。

以下は、参考例である（表示目的のためだけの次の行への折り返しがある）。 

HTTP/1.1 302 Found
Location: https://client.example.org/cb?
error=invalid_request
&error_description=the%20request%20is%20not%20valid%20or%20malformed
&state=af0ifjsldkj

 TOC 

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

トークンエンドポイントは、IDトークンとその他の変数と同様にアクセストークンの取得とリフレッシュのための要求を処理する。

クライアントは、トークンエンドポイントへの要求に、HTTP "POST"メソッドを使用しなければならない (MUST)。 要求パラメータは、フォームシリアライゼーション (Form Serialization)を用いて追加される。

クライアントは、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の2.2.1節に記述のとおり、トークンエンドポイントへの要求に認証パラメータを提供するかもしれない (MAY)。

認可サーバは、トークンエンドポイントで、RFC 2616 (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]に定義されているHTTP "POST"メソッドの使用をサポートしなければならない (MUST)。

認可サーバはトランスポート層セキュリティ機構の使用を必須としなければならない (MUST)。認可エンドポイントサーバはTLS 1.2 RFC 5246 (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] および／または TLS 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) をサポートしなければならない (MUST)。また、同等のセキュリティを持つ、他のトランスポート層セキュリティ機構をサポートしてもよい (MAY)。

トークン、シークレット、またはその他の機密情報を含むすべてのトークンエンドポイント応答は、以下のHTTP応答ヘッダフィールドと値を含まなければならない (MUST):


ヘッダ名ヘッダ値
Cache-Control no-store
Pragma no-cache

 HTTP応答ヘッダと値

 TOC 

3.1.  アクセストークンの要求

アクセストークンを取得するため、クライアントは、認可コードフロー (Authorization Code Flow)に記述されている方法を用いて取得した認可コードを持っていなければならない (MUST)。


 TOC 

3.1.1.  アクセストークン要求

アクセストークンやリフレッシュトークン、IDトークンを取得するために、クライアントは、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の2.2.1で文書化されているとおり、client_idに対して登録されている認証方法を用いてトークンエンドポイントに対して認証しなければならない (MUST)。クライアントは、OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の4.1.3節で規定されているフォームシリアライゼーション (Form Serialization)を用いてトークンエンドポイントに対しHTTPS POSTでパラメータを送信する。

以下は、 アクセストークン要求の参考例である: 

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

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

認可サーバは以下を実施しなければならない (MUST):

  • クライアントの発行したクライアントクレデンシャル（もしくは他の認証の要件）によるクライアント認証を要求する、
  • クライアント認証が含まれていた場合、クライアントを認証し、かつ認可コードが認証されたクライアントに対して発行されたものであるかを確認する、
  • 認可コードが有効であるかを確認する、そして、
  • redirect_uriが最初の認可要求に含まれている場合、redirect_uriパラメータが存在するかを確認するのと、その値がスキーム、ホスト、パス、クエリパラメータの各セグメントで一致するかを確認する。


 TOC 

3.1.2.アクセストークン応答

要求トークンの受信時に、認可サーバは、受信した認可コードに対応する正常応答またはエラー応答のいずれかを返さなければならない (MUST)。

成功応答は"application/json"メディアタイプを返し、その応答ボディはOpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の2.2.3節に文書化されたアクセストークン応答である。

以下は、 成功応答の参考例である。 

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

{
 "access_token": "SlAV32hkKG",
 "token_type": "Bearer",
 "refresh_token": "8xLOxBtZp8",
 "expires_in": 3600,
 "id_token": "eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZXJ2Z
XIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoic
zZCaGRSa3F0MyIsIm5vbmNlIjoibi0wUzZfV3pBMk1qIiwiZXhwIjoxMzExMjgxO
TcwLCJpYXQiOjEzMTEyODA5NzB9.RgXxzppVvn1EjUiV3LIZ19SyhdyREe_2jJjW
5EC8XjNuJfe7Dte8YxRXxssJ67N8MT9mvOI3HOHm4whNx5FCyemyCGyTLHODCeAr
_id029-4JP0KWySoan1jmT7vbGHhu89-l9MTdaEvu7pNZO7DHGwqnMWRe8hdG7jU
ES4w4ReQTygKwXVVOaiGoeUrv6cZdbyOnpGlRlHaiOsv_xMunNVJtn5dLz-0zZwV
ftKVpFuc1pGaVsyZsOtkT32E4c6MDHeCvIDlR5ESC0ct8BLvGJDB5954MjCR4_X2
GAEHonKw4NF8wTmUFvhslYXmjRNFs21Byjn3jNb7lSa3MBfVsw"
}

 TOC 

3.1.3.  アクセストークンエラー応答

トークン要求が無効または未認証の場合、認可サーバは、HTTP応答コード400と共にapplication/jsonメディアタイプを用いて、HTTP応答のエンティティボディ内にOpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]に定義されたトークンエラー応答を返す応答を構築する。

以下は、参考例である: 

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

{
 "error": "invalid_request"
}

 TOC 

3.2.  アクセストークンのリフレッシュ

アクセストークンをリフレッシュするために、クライアントは、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の2.2.1節で文書化されているとおり、client_idに対して登録されている認証方法を用いてトークンエンドポイントに対して認証しなければならない (MUST)。クライアントは、OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の4.1.3節で規定されているフォームシリアライゼーション (Form Serialization)を用いてトークンエンドポイントに対しHTTPS POSTでパラメータを送信する。

認可サーバは、リフレッシュトークンの妥当性を検証しなければならない (MUST)。


 TOC 

3.2.1.リフレッシュトークン応答

リフレッシュトークンの受信時に、認可サーバは、受信したリフレッシュトークンに対応する成功応答またはエラー応答のいずれかを返さなければならない (MUST)。

リフレッシュトークンの検証成功時、成功応答は"application/json"メディアタイプを返し、その応答ボディは、id_tokenを返してはならない(MUST NOT)点を除けば、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の2.2.3節に文書化されたアクセストークン応答である。

以下は、 リフレッシュトークンの要求と応答の参考例である: 

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

client_id=s6BhdRkqt3
&client_secret=some_secret12345
&grant_type=refresh_token
&refresh_token=8xLOxBtZp8
&scope=openid%20profile


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

{
 "access_token": "TlBN45jURg",
 "token_type": "Bearer",
 "refresh_token": "9yNOxJtZa5",
 "expires_in": 3600
}

 TOC 

3.2.2.  リフレッシュトークンエラー応答

リフレッシュトークン要求が無効または未認証の場合、認可サーバは、OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の5.2節に定義されたトークンエラー応答を返す。


 TOC 

4.  ユーザ情報エンドポイント

エンドユーザに関するクレームを取得するために、クライアントは、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]にあるユーザ情報エンドポイントに対し、GETまたはPOSTで要求する。

認可サーバはトランスポート層セキュリティ機構の使用を必須としなければならない (MUST)。認可エンドポイントサーバはTLS 1.2 RFC 5246 (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] および／または TLS 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) をサポートしなければならない (MUST)。また、同等のセキュリティを持つ、他のトランスポート層セキュリティ機構をサポートしてもよい (MAY)。

認可サーバは、認可エンドポイントで、RFC 2616 (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]に定義されているHTTP "GET"およびHTTP "POST"の使用をサポートしなければならない (MUST)。

認可サーバは、OAuth 2.0 Bearer Tokens (Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” June 2012.) [OAuth.Bearer]のアクセストークンを受け付けなければならない (MUST)。

認可サーバは、JavaScriptクライアントにエンドポイントへのアクセスを可能とするために、Cross Origin Resource Sharing (CORS) (van Kestern, “Cross-Origin Resource Sharing,” July 2010.) [CORS]や適切なその他の方法をサポートすべきである (SHOULD)。


 TOC 

4.1.  ユーザ情報要求

クライアントは、HTTP GETまたはPOST要求のいずれかで、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の2.3.1節に定義されたユーザ情報要求を送信すべきである (SHOULD)。

OpenID Connectの認可要求から取得したアクセストークンは、ベアラトークンとして送信しなければならない (MUST)。OAuth 2.0 Bearer Tokens (Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” June 2012.) [OAuth.Bearer]仕様の2節では、アクセストークンの許可された送信方法について文書化している。

クライアントは、GETによりすべての要求に対してAuthorizationヘッダの方法を使用することが推奨される (RECOMMENDED)。

以下は、 参考例である。 

GET /userinfo?schema=openid HTTP/1.1
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X

 TOC 

4.2.ユーザ情報応答

ユーザ情報エンドポイント応答内の user_id クレームは、追加のユーザ情報エンドポイントのクレームを使用する前に、IDトークン内の user_id クレームと正確に一致していなければならない(MUST)。

ユーザ情報要求の受信時に、ユーザ情報エンドポイントは、HTTP応答ボディでOpenID Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]のユーザ情報応答のJSONシリアライゼーションを返さなければならない (MUST)。応答ボディがテキストのJSON構造の場合、HTTP応答のcontent-typeは、application/jsonが設定されなければならない (MUST)。JSON応答が署名または暗号化されている場合、content-typeは、 application/jwtを設定しなければならない (MUST)。

ユーザ情報応答の受信時に、クライアントは、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の5.3節（ユーザ情報応答検証）に従って、応答を検証しなければならない (MUST)。

以下は、 応答の参考例である。 

HTTP/1.1 200 OK
Content-Type: application/json

{
 "user_id": "248289761001",
 "name": "Jane Doe"
 "given_name": "Jane",
 "family_name": "Doe",
 "email": "janedoe@example.com",
 "picture": "http://example.com/janedoe/me.jpg"
}

 TOC 

4.3.  ユーザ情報エラー応答

エラー状態が発生した際、ユーザ情報エンドポイントは、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の2.3.3節に規定されているエラーコードを利用して、OAuth 2.0 Bearer Tokens (Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” June 2012.) [OAuthBearer] の3節で定義されているエラー応答を返す。

以下は、 エラー応答の参考例である: 

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example.com",
                     error="invalid_token",
                     error_description="The access token expired"

 TOC 

5.  自己発行アイデンティティプロバイダ

自己署名IDトークンを発行するパーソナルOPを使用するユーザを示す特殊な発行元"https://self-issued.me"がある。


 TOC 

5.1.  自己発行アイデンティティプロバイダディスカバリ

入力された識別子がドメインself-issued.meを含む場合、動的ディスカバリは実行されない。以下の静的構成値が使用される。

{
 "authorization_endpoint":
   "openid:",
 "issuer":
   "https://self-issued.me",
 "scopes_supported":
   ["openid", "profile", "email", "address", "phone"],
 "response_types_supported":
   ["id_token"],
 "user_id_types_supported":
   ["pairwise"],
 "id_token_algs_supported":
   ["RS256"],
 "request_object_algs_supported":
   ["RS256"]
 }

注: クライアントが自己発行OPのディスカバリに対し特殊扱いが不要となるように、OpenID Foundationは、上記の静的構成ファイルを返すサイト https://self-issued.me/ をホスティングすることを検討するかもしれません。


 TOC 

5.2.  自己発行アイデンティティプロバイダへのクライアント登録

自己発行OPを使用している場合、クライアントはOPに登録され、以下のクライアント登録応答を取得したものとみなされます。 When using a Self-Issued OP, the Client is deemed to have registered with the OP and obtained following Client Registration Response.

client_id
クライアントのredirect_uri。
expires_at
0.

注: クライアントが自己発行OPの登録に対し特殊処理が不要となるように、OpenID Foundationは、上記の応答を返す（ステートレス）エンドポイント https://self-issued.me/registration/1.0/ をホスティングすることを検討するかもしれません。


 TOC 

5.3.  自己発行アイデンティティプロバイダ要求

クライアントは、以下の必須 (REQUIRED) パラメータを使用して認可エンドポイントへ認可要求を送信する。

response_type
必須。値 id_token。
client_id
必須。クライアントのredirect_uri。redirect_uriと同じであるため、redirect_uriを要求で送信する必要がないことに注意。
scope
必須。2.1節 (OpenID Connect Scopes)に定義されているとおりのscopeパラメータ。
policy_url
必須。受信した属性の使用方法をクライアントがエンドユーザに提供するページのURL。OPはエンドユーザにこのURLを表示すべきである (SHOULD)。標準のOPのケースとは異なり、自己発行OPは、登録時にこの値を受け取ることができないため、認可要求の一部として提供される必要がある。

他のパラメータも送られるかもしれない (MAY)。全てのクレームはid_tokenで返されることに注意。 Note that all claims are returned in the id_token.

URL全体は、2048バイトを超えてはならない (MUST NOT)。

以下は、参考例である（表示上だけの行折り返しを含む）:

HTTP/1.1 302 Found
Location: openid://
?response_type=id_token
&client_id=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&policy_url=https%3A%2F%2Fclient.example.org%2Fusage%2F
&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj

 TOC 

5.4.  自己発行アイデンティティプロバイダ応答

自己発行アイデンティティプロバイダ応答は、issクレーム値がhttps://self-issued.meであるという点と、全てのクレームがid_tokenで返されるという点を除けば、通常のインプリシットフロー応答と同じである。インプリシットフロー応答であるため、応答パラメータはフラグメントで返されることになる。


 TOC 

5.5. 自己発行アイデンティティIDトークン検証

認可応答あるいはトークンエンドポイント応答におけるIDトークンの妥当性を検証するために、クライアントは以下を行わなければならない (MUST)。

  1. クライアントは、iss (issuer)クレームの値がhttps://self-isued.meであることを検証しなければならない (MUST)。issが異なる値を含んでいた場合、そのIDトークンは自己発行ではなく、代わりにOpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]の5.2節に従って検証されなければならない (MUST)。
  2. クライアントは、aud (audience)クレームの値が、クライアントが認証要求で送ったredirect_uriの値であることを検証しなければならない (MUST)。
  3. クライアントは、JWTヘッダのalgパラメータで指定されたアルゴリズムと、user_jwkクレームの中の鍵を使用して、JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.) [JWS]に従い、IDトークンの署名を検証しなければならない (MUST)。鍵はJWK形式である。
  4. algの値はRS256のデフォルトであるべきである (SHOULD)。また、ES256かもしれない。
  5. user_id値がuser_jwkクレームの鍵値を連結したものに対するSHA-256ハッシュをbase64urlエンコーディングしたものであることを、クライアントは検証しなければならない (MUST)。alg値がRS256の場合、鍵値modとexpが、この順序で連結される。alg値がES256の場合、鍵値crvとxとyが、この順序で連結される。
  6. 現在の時刻は exp クレームの値より小さくなければならない（場合により、クロックスキューのため、多少のズレを許可する）。
  7. iat クレームは、攻撃対策のために保存しているナンスの保存時間の上限を制限するために、現在時刻からあまりにも大きく乖離しているときはトークンを拒絶したいといった場合に用いられることができる。許容範囲は、クライアント次第である。
  8. ナンス値が認可要求で送信されていた場合、nonceクレームの値が存在している、かつ認可要求で送信されたものと同じ値であることを確認するためにチェックしなければならない (MUST)。リプレイ攻撃を検出するための詳細な方法は、クライアント固有のものである。

以下は、base64urlデコードされた自己発行IDトークンの参考例である（表示上だけの行折り返しを含む）: 

{
 "iss": "https://self-issued.me",
 "user_id": "wBy8QvHbPzUnL0x63h13QqvUYcOur1X0cbQpPVRqX5k",
 "aud": "https://client.example.org/cb",
 "nonce": "n-0S6_WzA2Mj",
 "exp": 1311281970,
 "iat": 1311280970,
 "user_jwk": {"alg":"RSA",
        "mod": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
   4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
   tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
   QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
   SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
   w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
        "exp":"AQAB"
        }
}

 TOC 

6.  ディスカバリと登録

いくつかのOpenID Connect環境では、OpenIDプロバイダ、および/またはリライイングパーティの事前設定済みのセットを使用することができる。これらのケースでは、アイデンティティやサービス、またはクライアントの動的登録に関する情報の動的ディスカバリをサポートする必要はない。

しかし、事前設定で連携されていないリライイングパーティとOpenIDプロバイダ間で、予定していなかった対話をサポートすることを選択する場合、OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” May 2012.) [OpenID.Discovery] および OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2012.) [OpenID.Registration] に定義されている機能を実装すべきである (SHOULD)。


 TOC 

7.  シリアライゼーション

要求メッセージは、以下の方法の一つを用いてシリアライゼーションされるかもしれない (MAY)。

  1. クエリストリングシリアライゼーション
  2. フォームシリアライゼーション


 TOC 

7.1.  クエリストリングシリアライゼーション

クエリストリングシリアライゼーションを用いてパラメータをシリアライゼーションするために、クライアントは、[W3C.REC‑html401‑19991224] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.)に定義されたapplication/x-www-form-urlencodedフォーマットを用いて、URLのクエリコンポーネントにパラメータと値を追加して文字列を構築する。クエリストリングのシリアライゼーションは、通常、HTTP GET要求に用いられる。

以下は、 このようなシリアライゼーションの参考例である。 

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

 TOC 

7.2.  フォームシリアライゼーション

パラメータと値は、[W3C.REC‑html401‑19991224] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.)に定義されたapplication/x-www-form-urlencodedフォーマットを用いて、HTTP要求のエンティティボディにパラメータと値を追加することによってフォームシリアライゼーションされる。フォームのシリアライゼーションは、通常、HTTP POST要求で使用されます。

以下は、 このようなシリアライゼーションの参考例である。 

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

scope=openid&response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

 TOC 

8.セキュリティに関する考慮事項

この仕様では、OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]に定義されたセキュリティに関する考慮事項を参照する。

加えて、以下の攻撃方法と対策のリストも考慮される。


 TOC 

8.1.  インプリシットグラントフローの脅威

インプリシットグラントフローでは、アクセストークンは、HTTPSを通してクライアントのredirect_uriのフラグメント部分で返される。このようにして、OPとユーザエージェント間、ユーザエージェントとRP間で保護される。キャプチャができる唯一の個所は、TLSセッションが終端されるユーザエージェントだけである。そしてそれは、ユーザエージェントがマルウェアに感染している場合に可能性がある。


 TOC 

9.プライバシーに関する考慮事項

ユーザ情報応答は、通常、個人識別情報 (PII) が含まれている。このように、指定目的のための情報リリースに対するエンドユーザーの同意は、該当する規則に従って認可時または事前に取得するべきである (SHOULD)。 使用目的は通常 redirect_uri に関連付けて登録されている。

必要なユーザ情報データのみがクライアントに格納されているべきであり (SHOULD)、クライアントは使用目的の宣言と受信したデータを関連付けておくべきである (SHOULD)。

エンドユーザが自分のデータに誰がアクセスしたかを監視できるように、リソースサーバはエンドユーザに対し、ユーザ情報アクセスログを利用できるようにすべきである (SHOULD)。

クライアント間の相関関係の危険性からエンドユーザを保護するために user_id として、仮名識別子(PPID)の使用を考慮する必要がある。


 TOC 

10.  IANAに関する考慮事項


 TOC 

10.1.  OAuthパラメータ登録


 TOC 

10.1.1.  認可要求パラメータ (display)

以下は、この仕様の認可要求に対するパラメータ登録要求である。

  • パラメータ名: display
  • パラメータ使用箇所: 認可要求
  • 変更制御者: IETF
  • 仕様書: [[ 当文書 ]]
  • 関連情報: なし

 TOC 

10.1.2.  認可要求パラメータ (prompt)

以下は、この仕様の認可要求に対するパラメータ登録要求である。

  • パラメータ名: prompt
  • パラメータ使用箇所: 認可要求
  • 変更制御者: IETF
  • 仕様書: [[ 当文書 ]]
  • 関連情報: なし

 TOC 

10.1.3.  認可要求パラメータ (nonce)

以下は、この仕様の認可要求に対するパラメータ登録要求である。

  • パラメータ名: nonce
  • パラメータ使用箇所: 認可要求
  • 変更制御者: IETF
  • 仕様書: [[ 当文書 ]]
  • 関連情報: なし

 TOC 

10.1.4.  認可要求パラメータ (request)

以下は、この仕様の認可要求に対するパラメータ登録要求である。

  • パラメータ名: request
  • パラメータ使用箇所: 認可要求
  • 変更制御者: IETF
  • 仕様書: [[ 当文書 ]]
  • 関連情報: なし

 TOC 

10.1.5.  認可要求パラメータ (request_uri)

以下は、この仕様の認可要求に対するパラメータ登録要求である。

  • パラメータ名: request_uri
  • パラメータ使用箇所: 認可要求
  • 変更制御者: IETF
  • 仕様書: [[ 当文書 ]]
  • 関連情報: なし

 TOC 

10.1.6.  IDトークン応答パラメータ

以下は、この仕様のIDトークン応答に対するパラメータ登録要求である。

  • パラメータ名: id_token
  • パラメータ使用箇所: 認可応答、アクセストークン応答
  • 変更制御者: IETF
  • 仕様書: [[ 当文書 ]]
  • 関連情報: なし

 TOC 

10.2.  OAuth拡張エラー登録


 TOC 

10.2.1.  認可エンドポイントエラー (invalid_redirect_uri)

以下は、この仕様の認可エラー応答に対するエラー登録要求である。

  • エラー名: Error name: invalid_redirect_uri
  • エラー使用箇所: 認可エンドポイント
  • 関連プロトコル拡張:
  • 変更制御者: IETF
  • 仕様書: [[ 当文書 ]]

 TOC 

10.2.2.  認可エンドポイントエラー (interaction_required)

以下は、この仕様の認可エラー応答に対するエラー登録要求である。

  • エラー名: interaction_required
  • エラー使用箇所: 認可エンドポイント
  • 関連プロトコル拡張:
  • 変更制御者: IETF
  • 仕様書: [[ 当文書 ]]

 TOC 

10.2.3.  認可エンドポイントエラー (login_required)

以下は、この仕様の認可エラー応答に対するエラー登録要求である。

  • エラー名: login_required
  • エラー使用箇所: 認可エンドポイント
  • 関連プロトコル拡張:
  • 変更制御者: IETF
  • 仕様書: [[ 当文書 ]]

 TOC 

10.2.4.  認可エンドポイントエラー (session_selection_required)

以下は、この仕様の認可エラー応答に対するエラー登録要求である。

  • エラー名: session_selection_required
  • エラー使用箇所: 認可エンドポイント
  • 関連プロトコル拡張:
  • 変更制御者: IETF
  • 仕様書: [[ 当文書 ]]

 TOC 

10.2.5.  認可エンドポイントエラー (consent_required)

以下は、この仕様の認可エラー応答に対するエラー登録要求である。

  • エラー名: consent_required
  • エラー使用箇所: 認可エンドポイント
  • 関連プロトコル拡張:
  • 変更制御者: IETF
  • 仕様書: [[ 当文書 ]]

 TOC 

10.2.6.  認可エンドポイントエラー (invalid_request_uri)

以下は、この仕様の認可エラー応答に対するエラー登録要求である。

  • エラー名: invalid_request_uri
  • エラー使用箇所: 認可エンドポイント
  • 関連プロトコル拡張:
  • 変更制御者: IETF
  • 仕様書: [[ 当文書 ]]

 TOC 

10.2.7.  認可エンドポイントエラー (invalid_openid_request_object)

以下は、この仕様の認可エラー応答に対するエラー登録要求である。

  • エラー名: invalid_openid_request_object
  • エラー使用箇所: 認可エンドポイント
  • 関連プロトコル拡張:
  • 変更制御者: IETF
  • 仕様書: [[ 当文書 ]]

 TOC 

10.2.8.  ユーザ情報エンドポイントエラー (invalid_schema)

以下は、この仕様の認可エラー応答に対するエラー登録要求である。

  • エラー名: invalid_schema
  • エラー使用箇所: ユーザ情報エンドポイント
  • 関連プロトコル拡張:
  • 変更制御者: IETF
  • 仕様書: [[ 当文書 ]]

 TOC 

11.  文献


 TOC 

11.1. 規定文献

[JWE] Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.
[JWS] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.
[JWT] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.
[OAuth.Bearer] Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” June 2012.
[OAuth.Responses] de Medeiros, B., Scurtescu, M., and P. Tarjan, “OAuth 2.0 Multiple Response Type Encoding Practices,” May 2012.
[OAuth2.0] Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.
[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” May 2012.
[OpenID.Messages] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.
[OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2012.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2246] Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” RFC 2246, January 1999 (TXT).
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616, June 1999 (TXT, PS, PDF, HTML, XML).
[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT).
[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, March 2011 (TXT).
[W3C.REC-html401-19991224] Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (HTML).

 TOC 

11.2. 参考文献

[CORS] van Kestern, “Cross-Origin Resource Sharing,” July 2010.

 TOC 

Appendix A.  脚注


 TOC 

A.1.  JWT値の例

ｋの使用の参考例で使用されているJWT値は、実際のJWT値の単なるプレースホルダである。例では、プレースホルダの値として "jwt_header.jwt_part2.jwt_part3"を使用する。実際のJWTの例については、JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT]仕様を参照。


 TOC 

Appendix B.  謝辞

The OpenID Community would like to thank the following people for the work they've done in the drafting and editing of this specification.

Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom

Breno de Medeiros (breno@gmail.com), Google

George Fletcher (gffletch@aol.com), AOL

Hideki Nara (hideki.nara@gmail.com), Takt Communications

John Bradley (ve7jtb@ve7jtb.com), Ping Identity

Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd.

Michael B. Jones (mbj@microsoft.com), Microsoft

Ryo Ito (ryo.ito@mixi.co.jp), mixi, Inc.


 TOC 

Appendix C.  通知

Copyright (c) 2012 The OpenID Foundation.

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.


 TOC 

Appendix D.  文書履歴

[[ To be removed from the final specification ]]

-13

  • Defined means of using a self-issued OP

-12

  • Updated matching of redirect URI to include query parameters to match Google's implementation

-11

  • Removed claims_in_id_token scope value, per decision on June 15, 2012 special working group call

-10

  • Changed verified to email_verified, per issue #564
  • Added scope value claims_in_id_token as a switch to indicate that the UserInfo claims should be returned in the id_token, per issue #561
  • Changed optional claim request parameter to essential, per issue #577
  • Removed Check ID Endpoint, per issue #570
  • Specified that parameters present in both the OpenID Request Object and the OAuth 2.0 Authorization Request MUST exactly match, per issue #575
  • Changed OpenID Request Object from being specified as a JWT to being specified as a JWS signed base64url encoded JSON object, per issue #592
  • Made use of the nonce REQUIRED when using the implicit flow and OPTIONAL when using the code flow, per issue #569
  • Changed client.example.com to client.example.org, per issue #251
  • Removed example text for generating a nonce via a signed session cookie, per issue #562
  • Use standards track version of JSON Web Token spec (draft-ietf-oauth-json-web-token)

-09

  • Added error interaction_required and removed user_mismatched, per issue #523
  • Changed invalid_request_request_uri to invalid_request_uri and invalid_request_redirect_uri to invalid_redirect_uri, per issue #553
  • Added optional id_token to authorization request parameters, per issue #535
  • Removed use of non-existent scope parameters registry, per issue #558
  • Updated Notices
  • Updated References

-08

  • Updated version number and date
  • Fix #543 Section 2.3.1.3 Request file requiring all request params to be included is false
  • Fix Section 5.1 to reference Messages 2.4.1 rather than 3.3
  • Added reference to CORS for JS clients to user_info and check_id endpoints

-07

  • Removed definition and usage for assertion and claim object
  • Removed Request File Registration Service
  • Consistent use of End-User
  • email scope allows access to the 'verified' claim
  • Removed language pertaining to custom userinfo schemas
  • Updated error section for refreshing access token
  • Remove 'audience' parameter from Authorization Request
  • Moved display=none to prompt=none
  • Moved IANA considerations from Messages
  • Check ID Endpoint returns only JSON
  • Removed PPID scope value
  • Reference Messages for validation of request object encryption and signature
  • Redefined 'nonce' in Authorization Request. Changed to REQUIRED parameter.
  • Changed usage of "approval" to "consent"
  • Use RFC 6125 to verify TLS endpoints
  • Added Privacy considerations
  • Changed 'request_uri' to require HTTPS unless the referenced content is signed and only needs to be reachable by AS
  • Added hash and entropy considerations to 'request_uri'
  • Added requirement to compare user_id from userinfo endpoint to id_token
  • Check ID Endpoint SHOULD use POST
  • Changed UserInfo Error Response to augment and return OAuth 2.0 Bearer Token Error Response
  • Added section about string comparison rules needed
  • Added Response Encoding according to Multiple Response Types spec
  • Allows only 'id_token' for 'response_type' parameter in Authorization Request
  • Clarified redirect_uris matching
  • Added explanation of select_account
  • Changed Security Considerations to refer to corresponding section in Messages
  • Check ID Endpoint uses ID Token as Access Token according to Bearer Token spec
  • Update John Bradley email and affiliation for Implementer's Draft
  • Removed invalid_authorization_code, invalid_id_token error codes

-06

  • Reworked return type wording in section 4.4.1 per ticket #174.
  • Added reference to registered return types.
  • Bumped Version number and date.
  • Make clear the server passes the value of nonce through untouched. Ticket #97.
  • Prevent caching of request_uri. Ticket #148.
  • Add nonce to request examples. Ticket #147.
  • Fixed 4.3.1.3 per ticket #150.
  • Fixed 4.3.2 to remove display scopes per ticket #172.
  • Make scope optional for refresh in 5.2.
  • Reference messages 3.2.2 for field definitions in section 5.2.1 per ticket #159.
  • Removed scopes from display value in 4.3.1 per ticket #172.
  • Make "code" and "id_token token" response types mandatory for Authorization Servers to support.

-05

  • Changed check_session to check_id.
  • schema=openid now required when requesting UserInfo.
  • Removed display values popup, touch, and mobile, since not well defined.
  • Resolve issue #135, clarifying that the access_token MAY be sent in the message body.

-04

  • Changes associated with renaming "Lite" to "Basic Client" and replacing "Core" and "Framework" with "Messages" and "Standard".
  • Numerous cleanups, including updating references.

-03

  • Added secret_type to the Token Endpoint.
  • Minor edits to the samples.

-02

  • Incorporates feedback from Nat Sakimura.

-01

  • First Draft that incorporates the merge of the Core and Framework specs.

 TOC 

著者アドレス

  Nat Sakimura
  Nomura Research Institute, Ltd.
Email:  n-sakimura@nri.co.jp
  
  John Bradley
  Ping Identity
Email:  ve7jtb@ve7jtb.com
  
  Michael B. Jones
  Microsoft
Email:  mbj@microsoft.com
  
  Breno de Medeiros
  Google
Email:  breno@google.com
  
  Edmund Jay
  Illumila
Email:  ejay@mgi1.com
投稿者 時刻:
ラベル: ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)