Draft: OpenID Connect Implicit
Client Profile 1.0 - draft 06
Abstract
OpenID Connect 1.0は、OAuth 2.0上に作られたシンプルなアイデンティティ層である。そして、相互運用可能でRESTfulな方法により、エンドユーザに関する基本的なプロファイル情報の取得と同様に、認可サーバによる認証に基づくエンドユーザのアイデンティティの検証も、クライアントに対し可能とする。
OpenID Connect Implicit Client Profile 1.0 は、OpenID Connect Standard 1.0仕様の一プロファイ ルであり、OAuthインプリシットグラントタイプを用いた基本的なウェブベースのリライイングパーティについて、理解と実装を容易にすることを狙いとしている。 OpenIDプロバイダに関しては、Standard仕様を参照すること。当プロファイルはOpenIDプロバイダの実装とセキュリティに関する考慮事項については除外している。
Table of Contents
1. はじめに1.1. 要求記法および規則1.2. 用語2. プロトコルフロー2.1. OpenID Connect Scope値2.2. インプリシットフロー2.2.1. クライアントによる認可要求の準備2.2.2. クライアントによる認可サーバへの要求の送信2.2.3. 認可サーバによるエンドユーザの認証2.2.4. 認可サーバによるエンドユーザの同意／承認の取得2.2.5. 認可サーバによるエンドユーザのクライアントへの返却2.2.5.1. エンドユーザによる認可の許可2.2.5.2. エンドユーザによる認可の拒否または無効な要求2.2.5.3. リダイレクトURI応答の例2.3. IDトークン2.3.1. IDトークンの検証2.3.2. アクセストークンの検証2.4. ユーザ情報エンドポイント2.4.1. ユーザ情報要求2.4.2. ユーザ情報応答2.4.2.1. 住所クレーム2.4.2.2. クレームの不変性と一意性2.4.3. ユーザ情報エラー応答3. 自己発行OpenIDプロバイダ3.1. 自己発行OpenIDプロバイダディスカバリ3.2. 自己発行OpenIDプロバイダへのクライアント登録3.3. 自己発行OpenIDプロバイダ要求3.4. 自己発行OpenIDプロバイダ応答3.5. 自己発行IDトークン検証4. シリアライゼーション4.1. クエリストリングシリアライゼーション4.2. フォームシリアライゼーション5. 文字列操作6. 実装に関する考慮事項6.1.
ディスカバリと登録7. セキュリティに関する考慮事項8. プライバシーに関する考慮事項9. IANAに関する考慮事項10. 文献10.1. 規定文献10.2. 参考文献Appendix A. 謝辞Appendix B. 通知Appendix C. 文書履歴§ 著者のアドレス
1. はじめに
OpenID Connect Implicit Clinet Profileは、OpenID Connect Standard 1.0 仕様 ( Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” January 2013. ) [OpenID.Standard] の一プロファイルであり、OAuthインプリシットグラントタイプを用いた基本的なウェブベースのリライイングパーティについて、実装が容易になるよう作成されている。OAuth認可コードグラントタイプを用いた基本的なウェブベースのリライイングパーティのためのプロファイルについては、OpenID Connect Basic Client Profile 1.0 ( Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Profile 1.0,” January 2013. ) [OpenID.Basic]を参照すること。OpenIDプロバ イダおよび非ウェブベースのアプリケーションについてはStandard仕様を参照すること。 当プロファイルはOpenIDプロバイダの実装とセキュリティに関する考慮事項については除外している。
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)。
1.2. 用語
当仕様は、OAuth 2.0 ( Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012. ) [RFC6749]で定義されている、「アクセストークン」、「リフレッシュトークン」、「認可コード」、「認可グラント」、「認可サーバ」、「認可エンドポイント」、「クライアント」、「クライアント識別子」、「クライアントシークレット」、「保護リソース」、「リソース所有者」、「リソースサーバ」、「トークンエンドポイント」という用語を用いる。また当仕様では、以下の用語についても定義する。
リライイングパーティ (Relying Party (RP))
OpenIDプロバイダからクレームを要求するアプリケーション
OpenIDプロバイダ (OpenID Provider (OP))
リライイングパーティに対し、クレームを提供する能力を持つサービス。
クレーム (Claim)
クレームプロバイダが、あるエンティティについて主張する、そのエンティティに関する情報の一部
クレームプロバイダ (Claims Provider)
エンティティに関するクレームを返すことが可能なサーバ
エンドユーザ (End-User)
リソースオーナーである人
エンティティ (Entity)
独立した別個の存在を持ち、あるコンテキストの中で識別することが可能な何か。エンドユーザはエンティティの一例である。
個人識別情報 (Personally Identifiable Information (PII))
(a) その情報に関連する自然人を識別するのに用いられる情報。(b)その情報に関連する自然人に直接的・間接的に関連付けられているかもしれない情報。
仮名識別子 (Pairwise Pseudonymous Identifier (PPID))
他のリライイングパーティにおけるエンティティのPPIDとは関連付けることができない、一つのリライイングパーティに対して用いられるエンティティを識別する識別子
IDトークン
JSON Web Token (JWT) ( Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012. ) 認証イベントに関するクレームが含まれている[JWT]
発行元 (Issuer)
クレームのセットを発行するエンティティ
発行元識別子
発行元を検証可能な識別子として機能するHTTPS URL
ユーザ情報エンドポイント
クライアントがアクセストークンを提示した際に、対応する認可グラントによって表される、エンドユーザに関して認可された情報を返す、保護リソース
2. プロトコルフロー
認可要求は、インプリシットフローと認可コードフローの二種類のうちのいずれか一つを用いる。認可コードフローはクライアントと認可サーバ間で用いられるクライアントシークレットを安全に保持することが可能なクライアントに適している。一方、インプリシットフローはそれが不可能なクライアントに適している。TLSをサポートしていないクライアントは、アクセストークンの盗聴を防ぐために認可コードフローを用いなければならない(MUST)。
当仕様はインプリシットフローを用いるクライアントについてのみ文書化する。OpenIDプロバイダは両方のフローをサポートしなければならない(MUST)。認可コードフローを使用するクライアントとOpenIDプロバイダは、OpenID Connect Standard 1.0 ( Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” January 2013. ) [OpenID.Standard] 仕様を参照すべきである。
2.1.OpenID Connect Scope値
OpenID Connectのクライアントは、OAuth 2.0 ( Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012. ) [RFC6749]の3.3節で定義されているscope 値を、アクセストークンに要求するアクセス権限を示すのに用いる。アクセストークンに関連付けられたスコープは、OAuth 2.0によって保護されているエンドポイントへアクセスする際にどんなリソースを利用することができるかを決定する。OpenID Connectのスコープは、ユーザ情報エンドポイントで利用可能な情報のセットを要求するために用いられる。OAuth 2.0は、拡張機能として、追加のスコープ値を指定することができる。当仕様では、OpenID Connectで利用されるscope値のみ記載している。
以下のスコープで要求されたクレームは、認可サーバに任意として扱われる。
OpenID Request Object ( Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013. ) [OpenID.Messages] を用いることにより、クレームは必須として扱われることができる。
OpenID Connectでは、以下のscope 値が定義されている。
openid
必須 (REQUIRED)。クライアントは、認可サーバに対し、OpenID Connect要求を行っていることを通知する。もしopenid スコープ値が存在しなかった場合、その要求はOpenID Connect要求として扱ってはならない(MUST NOT)。
profile
任意 (OPTIONAL)。このスコープ値は、発行されたアクセストークンによって与えられる、ユーザ情報エンドポイントでのエンドユーザのデフォルトのprofile クレーム ( Reserved Member Definitions ) アクセスを要求する。これらのクレームは以下の通り: name 、 family_name 、 given_name 、 middle_name 、 nickname 、 preferred_username 、 profile 、 picture 、 website 、 gender 、 birthdate 、 zoneinfo 、 locale 、 updated_time 。
email
任意 (OPTIONAL)。このスコープ値は、発行されたアクセストークンによって与えられる、ユーザ情報エンドポイントに対する、email とemail_verified クレームへのアクセスを要求する。
address
任意 (OPTIONAL)。このスコープ値は、発行されたアクセストークンによって与えられる、ユーザ情報エンドポイントに対する、address クレームへのアクセスを要求する。
phone
任意 (OPTIONAL)。このスコープ値は、発行されたアクセストークンによって与えられる、ユーザ情報エンドポイントに対する、phone_number クレームへのアクセスを要求する。
offline_access
このスコープ値は、OpenID Connect Implicit Client Profile 1.0では使用されないだろう (MAY NOT)。使用方法についてはOpenID Connect Basic Client Profile 1.0 ( Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Profile 1.0,” January 2013. ) [OpenID.Basic]を参照すること。
ASCIIの大文字小文字を区別したスコープ値をスペース区切りでリスト化することにより、複数のスコープ値が使用されるかもしれない (MAY)。
いくつかのケースでは、エンドユーザーは、クライアントによって要求された一部またはすべての情報の提供をOpenIDプロバイダに拒否させるためのオプションが表示される。ユーザが開示を求められる情報量を最小化するために、クライアントは、ユーザ情報エンドポイントから入手可能な情報のサブセットのみを要求することを選択するかもしれない。
以下は、 scope 要求の参考例である。
scope=openid profile email phone
2.2. インプリシットフロー
インプリシットフローは以下の手順で構成される:
クライアントは、希望する要求パラメータを含む認可要求を準備する。
クライアントは、認可サーバに要求を送信する。
認可サーバはエンドユーザーを認証する。
認可サーバは、エンドユーザーの同意／承認を取得する。
認可サーバは、アクセストークンおよびIDトークンと共にエンドユーザをクライアントに送り戻す。
2.2.1. クライアントによる認可要求の準備
エンドユーザが保護リソースにアクセスしようとした際に、エンドユーザーの認可をまだ取得していない場合、クライアントは、認可エンドポイントへの認可要求の準備をする。
認可エンドポイントURLで使用されるスキームは、HTTPSでなければならない (MUST)。
クライアントは 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 を用いて要求を構築してもよい (MAY)。
HTTP GET メソッドを用いる場合、要求パラメータは クエリストリングシリアライゼーション ( Query String Serialization ) によってシリアライゼーションされる。HTTP POST メソッドを用いた場合、要求パラメータは、[W3C.REC‑html401‑19991224] ( Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999. ) で定義されている application/x-www-form-urlencoded フォーマットを用いてHTTP要求エンティティボディに追加される。
このプロファイルは、さらに以下の要求パラメータを規定する。
response_type
この値は、スペース区切りのリストとして、 token とid_token を含まなければならない (MUST)。これはアクセストークンとIDトークンの両方がレスポンスのURLフラグメントとして返されることを要求する。
要求内の他の必須 (REQUIRED) パラメータは以下の通り。
client_id
OAuth 2.0クライアント識別子。
scope
OAuth 2.0 scope 値。これは、スペースで区切られたASCII文字列の一つとしてopenid を含まなければならない (MUST)。任意 (OPTIONAL) scope値として profile 、email 、address 、phone 、offline_access も定義されている。
redirect_uri
応答が送信されるリダイレクト先のURI。これは、プロバイダと共にあらかじめ登録しなければならない (MUST)。
要求は、下記の任意の、時には必須のパラメータを含めることができる (MAY)。
nonce
必須 (REQUIRED)。IDトークンを持つクライアントセッションを関連付けるためと、リプレイ攻撃を軽減するために使用される文字列値。値は変更されずにそのままIDトークンに渡されます。これを達成する一つの方法は、署名されたセッションクッキーとしてランダムな値を格納して、 nonce パラメータの値を渡すことである。その場合には、返されたIDトークンのnonce は、第三者によるIDトークンリプレイを検出するために署名されたセッションクッキーと比較される。
state
推奨 (RECOMMENDED)。要求とコールバック間で状態を維持するために使用する不明瞭な値は、XSRF攻撃に対する保護の役割を果たす。
display
認可サーバがエンドユーザに対して、認証と同意のユーザインタフェース画面を表示する方法を指定するASCII文字列値。次の値がサポートされている。 page 認可サーバは、ユーザエージェントの（ポップアップとかではない）完全な画面として認証と同意のUIを表示すべきである (SHOULD)。displayパラメータが指定されていない場合、これがデフォルトの表示モードである。 popup 認可サーバは、ユーザエージェントのポップアップウィンドウとして認証と同意のUIを表示すべきである (SHOULD)。ポップアップユーザエージェントウィンドウは幅450ピクセル、高さ500ピクセルであるべきである (SHOULD)。 touch 認可サーバは、タッチインタフェースを活用したデバイス向けのUIを表示すべきである (SHOULD)。認可サーバは、タッチデバイスの検出を試み、さらにインターフェースをカスタマイズしてもよい (MAY)。 wap 認可サーバは、フィーチャーフォンの画面向けの認証と同意のUIを表示すべきである (SHOULD)。
prompt
認可サーバが再認証と同意のためにエンドユーザに対しプロンプトを表示するかどうかを指定する、スペース区切りの大文字小文字を区別したASCII文字列値のリスト。設定可能な値は以下のとおり。 none 認可サーバは、認証も同意もユーザインタフェース画面を表示してはならない(MUST NOT)。エンドユーザがまだ認証されていないか、またはクライアントが要求されたクレームに対して事前設定された同意を保持していない場合は、エラーが返される。これは、既存の認証および/または同意が存在するかを確認するための手段として使用することができる。 login 認可サーバは、再認証のためにエンドユーザにプロンプトを表示しなければならない。 consent 認可サーバは、クライアントに情報を返す前にエンドユーザに同意のためのプロンプトを表示しなければならない (MUST)。 select_account 認可サーバは、エンドユーザにユーザアカウントを選択するためのプロンプトを表示しなければならない (MUST)。これは、認可サーバで複数のアカウントを持つユーザは、彼らが現在のセッションを持っているかもしれない複数のアカウントの間で選択することを許可する。 prompt パラメータは、エンドユーザが現在のセッションのためにまだ存在していることを確認するためか、または要求に注意を喚起するためにクライアントで使用することができる。
login_hint
(必要に応じて) ユーザが認可サービスでの認証に用いるかもしれないログイン識別子に関して、認可サービスに対して与えるヒント。
このヒントは、ユーザに対して初めにユーザのEメールアドレス (またはその他の識別子) を求め、それをディスカバリした認可サービスに対しヒントとして受け渡す場合に、RPによって用いられる。ヒント値はディスカバリに用いた値とマッチしていることが推奨される。このパラメータの使用はOPの裁量に任されている。
以下は、認可要求のURL（表示目的のみのための行の折り返しが含まれる）の参考例を示す。
https://server.example.com/authorize?
response_type=token%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
2.2.2. クライアントによる認可サーバへの要求の送信
認可要求を構築した後、クライアントはそれをHTTPS認可エンドポイントに送信する。これは、HTTPSリダイレクト、ハイパーリンク、またはユーザエージェントをそのURLへ導く他の安全な手段を介して行ってもよい (MAY)。
以下は、HTTPリダイレクトを使用した参考例である（表示上だけの行折り返りを含む）:
HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=token%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
2.2.3. 認可サーバによるエンドユーザの認証
認可サーバは、同意が正しいパーティからのものであるかを確認するために、リソースオーナーを認証する。 認証が実行される方法の正確な方法はこの仕様の範囲外である。
2.2.4. 認可サーバによるエンドユーザの同意／認可の取得
認可サーバは、要求されたクレームに対して、認可決定を取得する。 これは、エンドユーザに対し、同意の内容を認識させた上で同意を得るための対話をエンドユーザーに提示することによって行うか、または他の手段（例えば、事前に管理上の手段による同意を経由）を介して同意を確立することによって、実施できる。
openid スコープ値は、このOAuth 2.0要求がOpenID Connect要求であることを宣言する。その他の全てのスコープ値の使用は任意 (OPTIONAL) である。
2.2.5. 認可サーバによるエンドユーザのクライアントへの返却
認可が決定されると、認可サーバは、正常応答またはエラー応答を返す。
2.2.5.1. エンドユーザによる認可の許可
リソースオーナがアクセス要求を許可したとき、認可サーバはアクセストークンを発行し、 OAuth 2.0 ( Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012. ) [RFC6749]の4.2.2節と、OAuth 2.0 Multiple Response Type Encoding Practices ( de Medeiros, B., Scurtescu, M., and P. Tarjan, “OAuth 2.0 Multiple Response Type Encoding Practices,” November 2012. ) [OAuth.Responses] の定義に従い、 application/x-www-form-urlencoded を用いて、リダイレクトURIのフラグメントコンポーネントに以下のパラメータを追加し、クライアントへ導く。
インプリシットフローでは、全体の応答は、OAuth 2.0 ( Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012. ) [RFC6749] の4.2.2節で定義されたリダイレクトURLのフラグメントコンポーネントとして返される。
access_token
必須 (REQUIRED)。ユーザ情報エンドポイントのためのアクセストークン。
token_type
必須 (REQUIRED)。OAuth 2.0のトークンタイプ値。この値は "bearer" か、クライアントが認可サーバとネゴシエートしたその他の token_type でなければならない (MUST)。このプロファイルを実装するクライアントは、OAuth 2.0 Bearer Token Usage ( Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012. ) [RFC6750] 仕様をサポートしなければならない (MUST)。当プロファイルではベアラトークンの仕様についてのみ記述する。
id_token
必須 (REQUIRED)。IDトークン。
state
OAuth 2.0 scope 値。state パラメータは、クライアントの認可要求に存在した場合は必須。クライアントは、 state 値が認可要求のstate パラメータと正確に一致することを確認しなければならない(MUST)。
expires_in
任意 (OPTIONAL)。アクセストークンの秒単位の有効期限。
クライアントは、リソースサーバ上の保護リソースにアクセスするためにアクセストークンを使用することができる。
以下は、参考例である（表示上だけの行折り返しを含む）:
HTTP/1.1 302 Found
Location: https://client.example.org/cb#
access_token=SlAV32hkKG
&token_type=bearer
&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0. DeWt4Qu ... ZXso
&expires_in=3600
&state=af0ifjsldkj
2.2.5.2. エンドユーザによる認可の拒否または無効な要求
エンドユーザーが認可を拒否するか、またはエンドユーザーの認証が失敗した場合、認可サーバは、OAuth 2.0 ( Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012. ) [RFC6749] の4.1.2.1節に定義されているエラー認可応答を返さなければならない(MUST)。その他のパラメータは返されるべきではない(SHOULD)。
2.2.5.3. リダイレクトURI応答の例
クライアントは、ユーザーエージェントのために、フラグメントエンコードされた応答を解析し、検証用のWebサーバクライアントにそれをPOSTする方法を提供しなければならない。
以下は、クライアントがそのredirect_uri でホストする可能性のあるJavaScriptファイルの例である。これは、認可サーバからのリダイレクトによってロードされます。フラグメントは解析され、受信した情報を検証するURIにPOSTで送信される。
以下は、 リダイレクトURI応答の参考例である。
GET /cb HTTP/1.1
Host: client.example.org
HTTP/1.1 200 OK
Content-Type: text/html
<script type="text/javascript">
// First, parse the query string
var params = {}, postBody = location.hash.substring(1),
regex = /([^&=]+)=([^&]*)/g, m;
while (m = regex.exec(postBody)) {
params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
}
// And send the token over to the server
var req = new XMLHttpRequest();
// using POST so query isn't logged
req.open('POST', 'https://' + window.location.host +
'/catch_response', true);
req.setRequestHeader('Content-Type',
'application/x-www-form-urlencoded');
req.onreadystatechange = function (e) {
if (req.readyState == 4) {
if (req.status == 200) {
// If the response from the POST is 200 OK, redirect the user
window.location = 'https://'
+ window.location.host + '/redirect_after_login'
}
// if the OAuth response is invalid, generate an error message
else if (req.status == 400) {
alert('There was an error processing the token')
} else {
alert('Something other than 200 was returned')
}
}
};
req.send(postBody);
2.3. IDトークン
IDトークンは、認証イベントおよび他の要求されたクレームに関するクレームを含むセキュリティトークンである。IDトークンはJSON Web Token (JWT) ( Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012. ) [JWT] として表される。
IDトークンは、認証イベントおよびユーザ識別子を管理するために使用され、aud (audience) および nonce
以下のクレームは、IDトークン内で必須である (REQUIRED)。
iss
必須 (REQUIRED)。応答の発行元の発行元識別子。
sub
必須 (REQUIRED)。主体の識別子。クライアントによって消費されることを意図している、発行元内でローカルユニークな再割り当てされないエンドユーザの識別子。 例： 24400320 または AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4 。 長さはASCIIで255文字を超えてはならない（MUST NOT）。
aud
必須 (REQUIRED)。このIDトークンが意図している聴衆。それはクライアントのOAuth 2.0のclient_id でなければならない (MUST)。
azp
任意 (OPTIONAL)。認可された当事者。IDトークンを要求したクライアントとは異なる場合、このメンバーは、OAuthアクセストークンとしてこのIDトークンを使用するよう認可されたOAuth 2.0クライアントを識別する。認可された当事者のclient_id を含まなければならない (MUST)。
exp
必須 (REQUIRED)。それ以降はIDトークンを処理のために受け入れてはならない（MUST NOT）ことを示す有効期限。このパラメータの処理は、現在の日時が、記載されている有効期限の日時より前でなければならない (MUST) ことが要求される。実装者は、クロックスキューを考慮するために、通常数分を超えない程度のずれを許容してもよい(MAY)。値は、UTCの1970-01-01T0:0:0Zから要望する日時までの秒数である。一般に日時についての詳細、特にUTCに関しては、RFC 3339 ( Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002. ) [RFC3339] 参照すること。
iat
必須 (REQUIRED)。 JWTが発行された時刻。値は、UTCの1970-01-01T0:0:0Zから要望する日時までの秒数である。一般に日時についての詳細、特にUTCに関しては、RFC 3339 ( Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002. ) [RFC3339] を参照すること。
auth_time
UTCの1970-01-01T0:0:0Zから、エンドユーザー認証が発生した日時までの秒数である。
nonce
必須 (REQUIRED)。IDトークンを持つクライアントセッションを関連付けるためと、リプレイ攻撃を軽減するために使用される文字列値。値は変更されずにそのまま認可要求からIDトークンへ渡されます。クライアントは nonce クレーム値が認可要求で送信した nonce パラメータの値と等しいかを検証しなければならない (MUST)。認可要求に存在する場合、認可サーバは、認可要求で送信されたナンス値を nonce クレームの値としてIDトークン ( ID Token ) に含めなければならない (MUST)。インプリシットフローではnonceは必須 (REQUIRED) である。コードフローでは任意 (OPTIONAL) である。
at_hash
任意 (OPTIONAL)。アクセストークンのハッシュ値。インプリシットフローでIDトークンがaccess_token と共に発行される場合、必須 (REQUIRED)。この値は、JWS ( Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” December 2012. ) [JWS] ヘッダ内のalg パラメータに指定された JWA ( Jones, M., “JSON Web Algorithms (JWA),” December 2012. ) [JWA] で規定されているハッシュアルゴリズムを使用してaccess_token をハッシュ化することによって作成されたハッシュの左から半分をbase64urlエンコードすることによって生成される。例えば、alg がRS256 の場合、SHA-256でaccess_token をハッシュ化し、その左から128bitに対しbase64urlエンコードを行う。
sub_jwk
任意 (OPTIONAL)。Section 3 ( Self-Issued OpenID Provider ) に規定されている、自己発行OpenIDプロバイダによって発行されたIDトークンの署名のチェックに用いられる公開鍵値。鍵はJWK形式である。OPが自己発行OPのときsub_jwk クレームの使用は必須 (REQUIRED) であり、OPが自己発行OPでないときの使用は推奨されない (NOT RECOMMENDED)。
JWTは、それを利用している全ての当事者によって認識されるその他のクレームを含むかもしれない (MAY)。
IDトークンはJWS ( Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” December 2012. ) [JWS]によって署名されなければならない (MUST)。そして必要に応じて (OPTIONALLY) JWS ( Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” December 2012. ) [JWS] と JWE ( Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2012. ) [JWE]を用いて署名と暗号化の両方をそれぞれ実施する。これによって、認証、完全性、否認防止、および必要に応じて機密性を提供する。
クライアントは、IDトークンの検証 ( ID Token Verification ) により、IDトークンの妥当性を直接検証しなければならない (MUST)。
以下は、base64urlデコードされたIDトークンの参考例である（表示上だけの行折り返しを含む）:
{
"iss": "https://server.example.com ",
"sub": "24400320",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"at_hash": "MTIzNDU2Nzg5MDEyMzQ1Ng"
}
2.3.1. IDトークンの検証
認可応答におけるIDトークンの妥当性を検証するために、クライアントは以下を行わなければならない (MUST)。
クライアントは、iss (issuer)クレームの値によって識別される発行元が聴衆として登録したclient_id が、aud (audience) クレームに含まれていることを検証しなければならない (MUST)。IDトークンにそのクライアントが有効な聴衆であると列挙されていないか、そのクライアントが信頼していない追加の聴衆が含まれていた場合、IDトークンを拒絶しなければならない (MUST)。
クライアントは、JWTヘッダのalg パラメータに指定されたアルゴリズムを用いて、JWS ( Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” December 2012. ) [JWS]に従ってIDトークンの署名を検証しなければならない (MUST)。
alg の値はRS256 であるべきである (SHOULD)。他の署名アルゴリズムを用いたトークンの妥当性検証は、OpenID Connect Messages ( Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013. ) [OpenID.Messages]仕様に記述されている。クライアントは、発行元によるディスカバリの中で提供される署名キーを使用しなければならない (MUST)。発行元は、iss (issuer)クレームの値と正確に一致しなければならない。
現在の時刻は exp クレームの値より小さくなければならない（場合により、クロックスキューのため、多少のズレを許可する）。
iat クレームは、攻撃対策のために保存しているナンスの保存時間の上限を制限するために、現在時刻からあまりにも大きく乖離しているときはトークンを拒絶したいといった場合に用いられることができる。許容範囲は、クライアント次第である。nonce クレームの値は、認可要求で送信されたものと同じ値であることを検証するためにチェックしなければならない (MUST)。クライアントはリプレイ攻撃のためにnonce 値をチェックすべきである (SHOULD)。リプレイ攻撃を検出するための詳細な方法は、クライアント固有のものである。acr クレームが要求された場合、クライアントは、主張されているクレームの値が適切であることを確認すべきである(SHOULD)。acr クレームの値の意味と処理は、この仕様の範囲外である。
（※訳注：acrの詳細は「OpenID Connect Messages 1.0」を参照）auth_time クレームが要求されていた場合、クライアントは、最後のユーザ認証から経過した時間があまりに大きいと判断した場合、値の検証と再認証の要求を行うべきである(SHOULD)。
2.3.2. アクセストークンの検証
インプリシットフローでIDトークンと共に発行されたアクセストークンの妥当性を検証するために、クライアントは以下を行うべきである (SHOULD)。
IDトークンの JWS ( Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” December 2012. ) [JWS] ヘッダ内の alg パラメータとして JWA ( Jones, M., “JSON Web Algorithms (JWA),” December 2012. ) [JWA] 内に指定されたハッシュアルゴリズムで access_token をハッシュする。
ハッシュの左半分を取り、それをbase64urlエンコーディングする。
at_hash がIDトークンに存在する場合、その値は、前段の手順で生成された値と一致しなければならない (MUST)。
2.4. ユーザ情報エンドポイント
追加の属性とトークンを取得するには、クライアントはユーザ情報エンドポイントへの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)。
注：ユーザ情報エンドポイント応答が、IDトークンの sub (subject) 要素によって識別される対話を行ったユーザに関するものなのかについては保証されてない。ユーザ情報エンドポイント応答内の sub クレームは、追加のユーザ情報エンドポイントのクレームを使用する前に、IDトークン内の sub クレームと正確に一致していなければならない(MUST)。
2.4.1. ユーザ情報要求
クライアントは、エンドユーザの詳細情報を取得するためにユーザ情報エンドポイントに以降のパラメータを使用して要求を送るかもしれない (MAY)。ユーザ情報エンドポイントは、OAuth 2.0 Bearer Token Usage ( Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012. ) [RFC6750] 仕様に準拠したOAuth 2.0 ( Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012. ) [RFC6749]の保護リソースである。このように、アクセストークンは、HTTP Authorizationヘッダを使用して指定する必要があります (SHOULD)。
access_token
アクセストークンは、OpenID Connectの認証要求から取得されます。このパラメータは、HTTP AuthorizationヘッダーまたはフォームエンコードされたHTTP POSTのボディ·パラメータのいずれかを介して1つのメソッドを使って送らなければなりません。
schema
必須。返されるデータのスキーマ。 唯一の定義されたschema 値は openid である。
id
この識別子は予約されている。 これは、openid スキーマが使用されているときは、エンドポイントで無視しなければならない (MUST)。
以下は、 参考例である。
GET /userinfo?schema=openid HTTP/1.1
Host: server.example.com
Authorization: Bearer SlAV32hkKG
2.4.2. ユーザ情報応答
要求されたスキーマがopenid の場合、ユーザ情報クレームがJSONオブジェクトのメンバーとして返却されなければならない (MUST)。応答ボディはUTF-8を用いてエンコードされるべきである (SHOULD)。下記で定義されたクレームが返されるかもしれないし、(以下に定義されていない) 追加のクレームが返されるかもしれない。
クレームが返されない場合、そのクレームの名前は、クレームのセットを表すJSONオブジェクトから省略されるべきであり (SHOULD)、nullまたは空の文字列値を持つべきではない (SHOULD NOT)。
メンバは複数の言語とスクリプトで表されるかもしれない (MAY)。言語とスクリプトを指定するため、BCP47 ( Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009. ) [RFC5646] 言語タグに対し、区切られた各メンバ名を # で区切って加えなければならない (MUST)。例えば、日本語のカタカナで家族名を表現するには family_name#ja-Kana-JP と指定する。これは、 family_name#ja-Hani-JP として表現される漢字表記に対する発音に基づいたインデックスとして一般的に用いられる。
メンバ 型 説明
sub
文字列
発行元内でエンドユーザを示す必須識別子。sub (subject) クレームは、ユーザ情報応答に必ず含まれなければならない (MUST)。
name
文字列
エンドユーザのロケールと設定に応じて順序づけられた、エンドユーザのすべての名前のパートを含む表示可能な形式でのフルネーム。
given_name
文字列
エンドユーザの名。
family_name
文字列
エンドユーザの姓。
middle_name
文字列
エンドユーザのミドルネーム。
nickname
文字列
エンドユーザのカジュアルな名前。given_name と同じであるかもしれないし、同じではないかもしれない (MAY)。例えば、 Mike という nickname 値 が、Michael という given_name 値と一緒に返される可能性がある。
preferred_username
文字列
janedoe や j.doe のような、エンドユーザーがRP側で希望する、簡略化された名前。この値は @ や / や空白のような特殊文字を含む任意の有効なJSON文字列であるかもしれない (MAY)。RPは、この値の一意性に依存してはならない (MUST NOT)。 (Section 2.4.2.2 ( Claim Stability and Uniqueness ) 参照)
profile
文字列
エンドユーザのプロファイルページのURL。
picture
文字列
エンドユーザのプロファイル画像のURL。
website
文字列
エンドユーザのウェブページまたはブログのURL。
email
文字列
エンドユーザの優先電子メールアドレス。RPは、この値の一意性に依存してはならない (MUST NOT)。 (Section 2.4.2.2 ( Claim Stability and Uniqueness ) 参照)
email_verified
真偽値
エンドユーザの電子メールアドレスが検証されている場合はtrue、それ以外の場合はfalse。
gender
文字列
エンドユーザの性別。この仕様で定義されている値は female と male である。定義されている値のいずれも適用できない場合は他の値が使用されるかもしれない (MAY)。
birthdate
文字列
ISO 8601:2004 ( International Organization for Standardization, “ISO 8601:2004. Data elements and interchange formats - Information interchange - Representation of dates and times,” 2004. ) YYYY-MM-DD フォーマットで表されたエンドユーザの誕生日。省略されていることを示すため、年には 9999 が指定されるかもしれない (MAY)。年のみを表現するために、YYYY フォーマットが許可される。プラットフォームの日付関連関数に依存している場合、年のみを指定することは様々な月日となってしまう可能性があるため、実装者は正確に日付を処理するためにこの要因を考慮するべきという点に注意すること。
zoneinfo
文字列
エンドユーザのタイムゾーンを表したゾーン情報 [zoneinfo] ( Public Domain, “The tz database,” June 2011. ) タイムゾーンデータベースに示された文字列。例： Europe/Paris や America/Los_Angeles 。
locale
文字列
エンドユーザのロケール。BCP47 ( Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009. ) の言語タグとして表現される。これは通常、ダッシュで区切られた、 ISO 639-1 Alpha-2 ( International Organization for Standardization, “ISO 639-1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code,” 2002. ) ISO 3166-1 Alpha-2 ( International Organization for Standardization, “ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes,” 1997. ) en-US や fr-CA 。 互換性の注意点として、いくつかの実装では、例えば、en_US のように、ダッシュ以外の区切り文字としてアンダースコアを使用している。実装は、同様にこのロケールの構文を受け入れることを選んでもよい (MAY)。
phone_number
文字列
エンドユーザの優先電話番号。このクレームのフォーマットは E.164 ( International Telecommunication Union, “E.164: The international public telecommunication numbering plan,” 2010. ) [E.164] を推奨 (RECOMMENDED)。例： +1 (425) 555-1212 や +56 (2) 687 2400 。
address
JSONオブジェクト
エンドユーザの優先アドレス。address メンバの値は、 JSON ( Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006. ) [RFC4627] の Section 2.5.2.1 ( Address Claim ) に定義されているメンバのいくつか、またはすべてを含むJSON構造体である。
updated_time
文字列
RFC 3339 ( Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002. ) [RFC3339] で定義された日時で表された、エンドユーザの情報の最終更新日時。例： 2011-01-03T23:58:42+0000 。
以下は、 応答の参考例である。
[OpenID.Registration] ( Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” January 2013. ) で異なるフォーマットが規定されない限り、ユーザ情報エンドポイントは、JSONフォーマットでクレームを返さなければならない (MUST)。ユーザ情報エンドポイントは、フォーマットを示すためにContent-Typeヘッダーを返さなければならない (MUST)。以下は、受け入れられるコンテントタイプである。
Content-Type 返されるフォーマット
application/json
plain text JSON object
application/jwt
JSON Web Token (JWT)
2.4.2.1. 住所クレーム
物理的な郵送先住所のコンポーネント。 実装では、入手可能な情報とエンドユーザのプライバシー設定に応じて、 address のフィールドのサブセットのみを返すかもしれない (MAY)。たとえば、 country やregion は、より詳細なアドレス情報なしで、返されるかもしれない。
実装では、formatted サブフィールド中に単一の文字列だけで完全なアドレスを返してもよい (MAY)、またはその他のサブフィールドを用いて、個々のコンポーネントのフィールドを返してもよい (MAY)、またはそれらの両方を返すかもしれない (MAY)。両方の変数が返された場合、formattedアドレスは複数のコンポーネントフィールドをどのように組み合わせるべき (SHOULD) かを示し、双方は同等のアドレスを示しているべきである (SHOULD)。
formatted
表示や宛名ラベルで使用するためにフォーマットされた完全な住所。このフィールドは改行を含むかもしれない (MAY)。 これは、このフィールドにおける、並べ替えやフィルタリングに用いられる際の最優先のサブフィールドである。
street_address
家番号、ストリート名、私書箱、複数行の拡張された住所情報を含むことができる完全な住所コンポーネント。 このフィールドは改行を含むかもしれない (MAY)。
locality
都市や地域のコンポーネント。
region
州、地方、県や地域のコンポーネント。
postal_code
ZIPコードまたは郵便番号コンポーネント。
country
国の名前のコンポーネント。
2.4.2.2. クレームの不変性と一意性
sub (subject) クレームは、2.3 ( ID Token ) 節の記述のとおり、ある特定のエンドユーザに対し、ローカルユニークでかつ、決して再割り当てされない (MUST) ため、クライアントが不変であるという前提を置ける唯一のクレームである。
したがって、ある特定のエンドユーザに対し、一意性が保証された唯一の識別子は、発行元の識別子と sub クレームの組み合わせであり、preferred_username やemail などの他のフィールドは、ある特定のエンドユーザに対する一意の識別子として使用してはならない (MUST NOT)。
他のすべてのクレームは、異なる発行元間で不変性またはユーザ間での一意性の保証はできない。そして発行元は、ローカルな制限とポリシーを適用することが許される。 たとえば、発行元は、異なる時点の異なるエンドユーザ間で、与えられたpreferred_username またはemail アドレスクレームを再利用するかもしれない (MAY)。そして、ある特定のエンドユーザについて、主張したpreferred_username やemail アドレスが変わるかもしれない (MAY)。
2.4.3. ユーザ情報エラー応答
エラー状態が発生した際、ユーザ情報エンドポイントは OAuth 2.0 Bearer Token Usage ( Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012. ) [RFC6750] の3節で定義されているエラー応答を返す。
OAuth 2.0 Bearer Token Usage ( Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012. ) [RFC6750] の3.1節に定義されているエラーコードに加え、当仕様では以下のエラーコードを定義する:
invalid_schema
要求されたスキーマは無効またはサポートされていない。
3. 自己発行OpenIDプロバイダ
自己署名IDトークンを発行するパーソナルOPを使用するユーザを示す特殊な発行元"https://self-issued.me "がある。
3.1. 自己発行OpenIDプロバイダディスカバリ
入力された識別子がドメインself-issued.meを含む場合、動的ディスカバリは実行されない。以下の静的構成値が使用される。
{
"authorization_endpoint":
"openid:",
"issuer":
"https://self-issued.me ",
"scopes_supported":
["openid", "profile", "email", "address", "phone"],
"response_types_supported":
["id_token"],
"subject_types_supported":
["pairwise"],
"id_token_signing_alg_values_supported":
["RS256"],
"request_object_signing_alg_values_supported":
["none", "RS256"]
}
注: クライアントが自己発行OPのディスカバリに対し特殊扱いが不要となるように、OpenID Foundationは、上記の静的構成ファイルを返すサイト https://self-issued.me/ をホスティングすることを検討するかもしれません。
3.2. 自己発行アイデンティティプロバイダへのクライアント登録
自己発行OPを使用している場合、クライアントはOPに登録され、以下のクライアント登録応答を取得したものとみなされます。
client_id
クライアントのredirect_uri 。
expires_at
0。
注: クライアントが自己発行OPの登録に対し特殊処理が不要となるように、OpenID Foundationは、上記の応答を返す（ステートレス）エンドポイント https://self-issued.me/registration/1.0/
3.3. 自己発行OpenIDプロバイダ要求
クライアントは、以下の必須 (REQUIRED) パラメータを使用して認可エンドポイントへ認可要求を送信する。
response_type
必須 (REQUIRED)。文字列定数値 id_token 。
client_id
必須 (REQUIRED)。クライアントのredirect_uri 。redirect_uri と同じであるため、redirect_uri を要求で送信する必要がないことに注意。
scope
必須 (REQUIRED)。Section 2.1 ( OpenID Connect Scope Values ) に定義されているとおりのscope パラメータ値。
policy_url
必須 (REQUIRED)。受信した属性の使用方法をクライアントがエンドユーザに提供するページのURL。OPはエンドユーザにこのURLを表示すべきである (SHOULD)。標準のOPのケースとは異なり、自己発行OPは、登録時にこの値を受け取ることができないため、認可要求の一部として提供される必要がある。
request
任意 (OPTIONAL)。OpenID Connect Messages 1.0 ( Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013. ) [OpenID.Messages] の Section 2.1.1.1 に定義されている通りのOpenID要求オブジェクト値。OpenID要求オブジェクトは、クライアントによってJWEで暗号化されているかもしれない。IDトークンの sub (subject) は、JWEの kid (Key ID) として送信されなければならない (MUST)。
id_token_hint
任意 (OPTIONAL)。クライアントとユーザの現在または過去の認証セッションに関するヒントとして、認可サーバから渡されたIDトークン ( ID Token ) 。prompt=none が送信されたとき、これは存在するべきである (SHOULD)。この値は、発行元によって署名された JWS ( Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” December 2012. ) [JWS] エンコードされたIDトークンである。この JWS ( Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” December 2012. ) [JWS] は、機密性の追加のために、発行元の公開鍵により JWE ( Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2012. ) [JWE] 暗号化されるかもしれない。RPによって受信されたIDトークンが暗号化されていた場合、クライアントは署名されたIDトークンを復号しなければならない (MUST)。クライアントは、サーバが復号可能な鍵を用いて再暗号化するかもしれない (MAY)。自己発行されたIDトークンの sub (subject) は、JWEの kid (Key ID) として送信されなければならない (MUST)。
他のパラメータも送られるかもしれない (MAY)。全てのクレームはIDトークンで返されることに注意。
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
3.4. 自己発行OpenIDプロバイダ応答
自己発行OpenIDプロバイダ応答は、以下の微修正を加えた通常のインプリシットフロー応答と同等である。インプリシットフロー応答であるため、応答パラメータはフラグメントで返されることになる。
iss (issuer) クレーム値は https://self-issued.me IDトークンの署名をチェックするのに用いる公開鍵値を値として持つ sub_jwk クレームが存在する。
sub (subject) クレーム値は、sub_jwk クレーム内のbase64urlエンコードされた鍵値のUTF-8表現バイト列のSHA-256ハッシュをbase64urlエンコードした値である。kty 値がRSA の場合、鍵値n とe が、この順序で連結される。kty 値がEC の場合、鍵値crv とx とy が、この順序で連結される。ユーザ情報エンドポイントにアクセスするためのアクセストークンは返されないため、全てのクレームはIDトークン内に含めて返さなければならない。
3.5. 自己発行IDトークン検証
認可応答あるいはトークンエンドポイント応答におけるIDトークンの妥当性を検証するために、クライアントは以下を行わなければならない (MUST)。
クライアントは、iss (issuer)クレームの値がhttps://self-isued.me iss に異なる値が含まれていた場合、IDトークンは自己発行されたものではなく、代わりに Section 2.3.1 ( ID Token Validation ) に従って検証しなければならない (MUST)。
クライアントは、聴衆としてクライアントが認証要求で送ったredirect_uri の値がaud (audience)クレームに含まれていることを検証しなければならない (MUST)。
クライアントは、sub_jwk クレームの中のJWKフォーマットの鍵のJWTヘッダ [JWT] ( Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012. ) 内にある alg パラメータで示されたアルゴリズムを用いて、JWS ( Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” December 2012. ) [JWS] に従ってIDトークンの署名を検証しなければならない (MUST)。
alg の値はRS256 のデフォルトであるべきである (SHOULD)。また、ES256 かもしれない。クライアントは、sub (subject) クレーム値が、sub_jwk クレーム内のbase64urlエンコードされた鍵値のUTF-8表現バイト列のSHA-256ハッシュをbase64urlエンコードした値であることを検証しなければならない (MUST)。
kty 値がRSA の場合、鍵値n とe が、この順序で連結される。kty 値がEC の場合、鍵値crv とx とy が、この順序で連結される。
現在の時刻は exp クレームの値より小さくなければならない（場合により、クロックスキューのため、多少のズレを許可する）。
iat クレームは、攻撃対策のために保存しているナンスの保存時間の上限を制限するために、現在時刻からあまりにも大きく乖離しているときはトークンを拒絶したいといった場合に用いられることができる。許容範囲は、クライアント次第である。ナンス値が認可要求で送信されていた場合、nonce クレームの値が存在している、かつ認可要求で送信されたものと同じ値であることを検証しなければならない (MUST)。クライアントはリプレイ攻撃に対応するためにnonce 値をチェックすべきである (SHOULD)。リプレイ攻撃を検出するための詳細な方法は、クライアント固有のものである。
以下は、base64urlデコードされた自己発行IDトークンの参考例である（表示上だけの行折り返しを含む）:
{
"iss": "https://self-issued.me ",
"sub": "wBy8QvHbPzUnL0x63h13QqvUYcOur1X0cbQpPVRqX5k",
"aud": "https://client.example.org/cb ",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"sub_jwk": {
"kty":"RSA",
"n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
"e":"AQAB"
}
}
4. シリアライゼーション
要求メッセージは、以下の方法の一つを用いてシリアライゼーションされるかもしれない (MAY)。
クエリストリングシリアライゼーション
フォームシリアライゼーション
4.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
4.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
5. 文字列操作
いくつかのOpenID Connectメッセージを処理すると、既知の値とメッセージの値を比較する必要がある。たとえば、ユーザ情報エンドポイントによって返されたクレームの名前は、sub のような特定のクレームの名前と比較されることがある。しかし、Unicode文字列を比較すると、重要なセキュリティ上の影響がある。
そのため、JSON文字列や他のUnicode文字列の比較は以下のように実施しなければならない (MUST):
Unicodeコードポイントの配列を生成するエスケープが適用されているJSONを削除する。
Unicode Normalization ( Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” 09 2009. ) [USA15] は、JSON文字列とその比較対象の文字列のいずれにも適用されない (MUST NOT)。
二つの文字列の比較は、Unicodeコードポイントとしての等価比較を行わなければならない (MUST)。
いくつかの場所で、この仕様は、文字列のスペース区切りリストを使用します。 全てのそのようなケースで、ASCII空白文字(0x20)のみが、この目的のために使用されるかもしれません (MAY)。
6. 実装に関する考慮事項
当仕様では、OAuthインプリシットグラントタイプを用いたリライイングパーティによって使用される機能を定義する。これらのリライイングパーティはいずれも、当仕様で必須 (REQUIRED) または MUSTと記述されている機能を実装しなければならない (MUST)。
6.1. ディスカバリと登録
いくつかの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)。
7. セキュリティに関する考慮事項
セキュリティに関する考慮事項については、OpenID Connect Standard 1.0 仕様 ( Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” January 2013. ) [OpenID.Standard] を参照すること。
8. プライバシーに関する考慮事項
ユーザ情報応答は、通常、個人識別情報 (PII) が含まれている。このように、指定目的のための情報リリースに対するエンドユーザーの同意は、該当する規則に従って認可時または事前に取得するべきである (SHOULD)。 使用目的は通常 redirect_uri に関連付けて登録されている。
必要なユーザ情報データのみがクライアントに格納されているべきであり (SHOULD)、クライアントは使用目的の宣言と受信したデータを関連付けておくべきである (SHOULD)。
エンドユーザが自分のデータに誰がアクセスしたかを監視できるように、リソースサーバはエンドユーザに対し、ユーザ情報アクセスログを利用できるようにすべきである (SHOULD)。
クライアント間の相関関係の危険性からエンドユーザを保護するために sub (subject) として、仮名識別子(PPID)の使用を考慮する必要がある。
9. IANAに関する考慮事項
この文書ではIANAへの要求はない。
10. 文献
10.1. 規定文献
[E.164] International Telecommunication Union, “E.164: The international public telecommunication numbering plan ,” 2010. [ISO3166-1] International Organization for
Standardization, “ISO 3166-1:1997. Codes for the representation of names of
countries and their subdivisions -- Part 1: Country codes ,” 1997. [ISO639-1] International Organization for
Standardization, “ISO 639-1:2002. Codes for the representation of names of
languages -- Part 1: Alpha-2 code,” 2002. [ISO8601-2004] International Organization for
Standardization, “ISO 8601:2004. Data elements and interchange formats - Information interchange -
Representation of dates and times,” 2004. [JWA] Jones, M., “JSON Web Algorithms (JWA) ,” draft-ietf-jose-json-web-algorithms (work in progress), December 2012 (HTML ). [JWE] Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE) ,” draft-ietf-jose-json-web-encryption (work in progress), December 2012 (HTML ). [JWS] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS) ,” draft-ietf-jose-json-web-signature (work in progress), December 2012 (HTML ). [JWT] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT) ,” draft-ietf-oauth-json-web-token (work in progress), December 2012 (HTML ). [OAuth. Responses] de Medeiros, B., Scurtescu, M., and P. Tarjan, “OAuth 2.0 Multiple Response Type Encoding Practices ,” November 2012. [OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0 ,” January 2013. [OpenID.Messages] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0 ,” January 2013. [OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0 ,” January 2013. [OpenID.Standard] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0 ,” January 2013. [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 ).[RFC3339] Klyne, G., Ed. and C. Newman , “Date and Time on the Internet: Timestamps ,” RFC 3339, July 2002 (TXT , HTML , XML ).[RFC4627] Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON) ,” RFC 4627, July 2006 (TXT ). [RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2 ,” RFC 5246, August 2008 (TXT ). [RFC5646] Phillips, A. and M. Davis, “Tags for Identifying Languages ,” BCP 47, RFC 5646, September 2009 (TXT ). [RFC6749] Hardt, D., “The OAuth 2.0 Authorization Framework ,” RFC 6749, October 2012 (TXT ). [RFC6750] Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage ,” RFC 6750, October 2012 (TXT ). [USA15] Davis, M. , Whistler, K. , and M. Dürst, “Unicode Normalization Forms,” Unicode Standard Annex 15, 09 2009.[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 ). [zoneinfo] Public Domain, “The tz database ,” June 2011.
10.2. 参考文献
[OpenID.Basic] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Profile 1.0 ,” January 2013.
Appendix A. 謝辞
The OpenID Community would like to thank the following people for the work they've done in the drafting and editing of this specification.
Andreas Akre Solberg (andreas.solberg@uninett.no ), UNINET
Anthony Nadalin (tonynad@microsoft.com ), Microsoft
Axel Nennker (axel.nennker@telekom.de ), Deutsche Telekom
Breno de Medeiros (breno@gmail.com ), Google
Casper Biering (cb@peercraft.com ), Peercraft
Chuck Mortimore (cmortimore@salesforce.com ), Salesforce
David Recordon (dr@fb.com ), Facebook
Edmund Jay (ejay@mgi1.com ), Illumila
George Fletcher (george.fletcher@corp.aol.com ), AOL
Hideki Nara (hideki.nara@gmail.com ), Takt Communications
John Bradley (ve7jtb@ve7jtb.com ), Ping Identity
Johnny Bufu (jbufu@janrain.com ), Janrain
Justin Richer (jricher@mitre.org ), Mitre
Luke Shepard (lshepard@fb.com ), Facebook
Michael B. Jones (mbj@microsoft.com ), Microsoft
Nat Sakimura (n-sakimura@nri.co.jp ), Nomura Research Institute, Ltd.
Nov Matake (nov@matake.jp ), Independent
Pamela Dingle (pdingle@pingidentity.com ), Ping Identity
Paul Tarjan (pt@fb.com ), Facebook
Roland Hedberg (roland.hedberg@adm.umu.se ), Independent
Ryo Ito (ryo.ito@mixi.co.jp ), mixi, Inc.
Torsten Lodderstedt (t.lodderstedt@telekom.de ), Deutsche Telekom
Appendix B. 通知
Copyright (c) 2013 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.
Appendix C. 文書履歴
[[ To be removed from the final specification ]]
-06
Fixed #637 removed requirement for hash of at_token and code to be SHA2 in Section 2.1.2.1 and Section 5.2.
Added Section 2.5 Access Token Validation.
Fixed #620 - Update Section 2.2.5.1 to allow for other token types, but make bearer mandatory to support for implicit clients.
Fixed #657 - Update Section 3.3 to say that the sub is sent as the kid if the id_token is encrypted in the request.
Added Implementation Considerations section.
Fixed #698 - Inconsistent use of articles.
Updated Scopes description.
Added auth_time definition to ID Token schema.
Fixed #655 - Specify UTF-8 as encoding scheme whenever necessary.
Renamed the user_jwk Claim to sub_jwk , paralleling the change from user_id to sub .
Defined the sub_jwk claim.
Clarified that the offline_access scope value MAY NOT be used with the Implicit Client Profile.
To remove ambiguity in the self-issued sub computation, changed the text "the concatenation of the key values" to "the concatenation of the bytes of the UTF-8 representations of the base64url encoded key values".
Tracked JWK parameter name changes alg -> kty, mod -> n, exp -> e.
-05
Fixed #687 - Inconsistency between user_id and prn claims. The fix changed these names: user_id -> sub, user_id_types_supported -> subject_types_supported, user_id_type -> subject_type, and prn -> sub.
Fixed #689 - Track JWT change that allows JWTs to have multiple audiences.
Fixed #660 - Clarified that returning the sub value from the UserInfo endpoint is mandatory.
Fixed #636 - ID Token authorized party claim.
Fixed #689 - Add caution about multiple audiences.
Fixed #694 - Add login_hint
-04
Make it clear that nonce is REQUIRED for implicit
RE #607 add example decoded id_token for non self-issued.
Fixed #614 - Discovery - 3.2 Distinguishing between signature and integrity parameters for HMAC algorithms. This fix tracks the parameter changes made to the JWE spec in draft-ietf-jose-json-web-encryption-06. It deletes the parameters {userinfo,id_token}_encrypted_response_int. It replaces the parameters {userinfo,id_token,request_object,token_endpoint}_algs_supported with {userinfo,id_token,request_object,token_endpoint}_signing_alg_values_supported and {userinfo,id_token,request_object,token_endpoint}_encryption_{alg,enc}_values_supported.
Fixed #666 - JWS signature validation vs. verification.
Fixed #682 - Change remaining uses of "birthday" to "birthdate".
Referenced OAuth 2.0 RFCs -- RFC 6749 and RFC 6750.
-03
Defined means of using a self-issued OP
-02
Added preferred_username claim under profile scope
Added ID Token section to describe required claims
Added section on claim stability
-01
Removed claims_in_id_token scope value, per decision on June 15, 2012 special working group call
-00
Initial version, based upon Basic Client specification version -17
Renamed from Basic Client to Implicit Client, per issue #567
Changed verified to email_verified , per issue #564
Removed Check ID Endpoint and added ID token signature verification text, per issue #570
Changed client.example.com to client.example.org, per issue #251
Added claims_in_id_token scope definition to Basic and Implicit, per issue #594
Use standards track version of JSON Web Token spec (draft-ietf-oauth-json-web-token)
著者アドレス
