2012年8月16日木曜日

OpenID Connect Messages 1.0 - draft 12 日本語私訳

Draft: OpenID Connect Messages 1.0 - draft 12

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

 TOC 
DraftN. Sakimura
 NRI
 J. Bradley
 Ping Identity
 M. Jones
 Microsoft
 B. de Medeiros
 Google
 C. Mortimore
 Salesforce
 E. Jay
 Illumila
 June 23, 2012


OpenID Connect Messages 1.0 - draft 12

概要

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

当仕様は、エンドポイントと関連付けられたメッセージフォーマットのみを定義する。実際の使用に際しては、OpenID Connect Standardのような関連のプロトコルバインディング仕様のいずれかに基づいていなければならない (MUST)。


目次

1.  はじめに
    1.1.  要求記法および規則
    1.2.  用語
    1.3.  概要
2.  メッセージ
    2.1.  認可エンドポイント
        2.1.1.  IDトークン
        2.1.2.  認可要求
            2.1.2.1.  OpenID要求オブジェクト
        2.1.3.  認可応答
        2.1.4.  認可エラー応答
    2.2.  トークンエンドポイント
        2.2.1.  クライアント認証
        2.2.2.  アクセストークン要求
        2.2.3.  アクセストークン応答
        2.2.4.  トークンエラー応答
    2.3.  ユーザ情報エンドポイント
        2.3.1.  ユーザ情報要求
        2.3.2.  ユーザ情報応答
            2.3.2.1.  住所クレーム
            2.3.2.2.  クレームの不変性と一意性
        2.3.3.  ユーザ情報エラー応答
    2.4.  ユーザ識別子タイプ
        2.4.1.  仮名識別子のアルゴリズム
    2.5.  クレームタイプ
        2.5.1.  通常クレーム
        2.5.2.  集約および分散クレーム
3.  シリアライゼーション
    3.1.  JSONシリアライゼーション
4.  署名と暗号化
    4.1.  サポートアルゴリズム
    4.2.  鍵
    4.3.  署名
    4.4.  暗号化
5.  検証
    5.1.  認可要求の検証
        5.1.1.  暗号化された要求オブジェクト
        5.1.2.  署名された要求オブジェクト
        5.1.3.  パラメータの検証
    5.2.  IDトークンの検証
    5.3.  ユーザ情報応答の検証
    5.4.  アクセストークンの検証
    5.5.  コードの検証
6.  文字列操作
7.  関連仕様
8.  セキュリティに関する考慮事項
    8.1.  要求露見
    8.2.  サーバなりすまし
    8.3.  トークン製造／変更
    8.4.  サーバ応答露見
    8.5.  サーバ応答否認
    8.6.  要求否認
    8.7.  アクセストークンリダイレクト
    8.8.  トークン再利用
    8.9.  認可コードの盗聴・漏洩 (セカンダリ認証子キャプチャ)
    8.10.  トークン置換
    8.11.  タイミング攻撃
    8.12.  他の暗号化関連の攻撃
    8.13.  署名および暗号化の順序
    8.14.  発行元識別子
    8.15.  TLSの要件
9.  プライバシーに関する考慮事項
    9.1.  リフレッシュトークンおよびアクセストークンの有効期間
10.  IANAに関する考慮事項
11.  文献
    11.1.  規定文献
    11.2.  参考文献
Appendix A.  謝辞
Appendix B.  通知
Appendix C.  文書履歴
§著者アドレス



 TOC 

1.  はじめに


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

本文書では、書いてあるままに解釈されるべき値は引用符 ("") で囲んで示している。プロトコルメッセージの中でこれらの値を使用する場合は、値の一部として引用符を用いてはならない (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]で定義されている、「アクセストークン」、「リフレッシュトークン」、「認可コード」、「認可グラント」、「認可サーバ」、「認可エンドポイント」、「クライアント」、「クライアント識別子」、「クライアントシークレット」、「保護リソース」、「リソース所有者」、「リソースサーバ」、「トークンエンドポイント」という用語と、JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT]で定義されている、「クレーム名」、「クレーム値」という用語を用いる。また当仕様では、以下の用語についても定義する。

認証 (Authentication)
エンドユーザが以前にプロビジョニングされたクレデンシャルを所持しているかを確認する行為。
認証コンテキスト (Authentication Context)
認証応答に関する資格の決定を行う前に、リライイングパーティが必要とする情報。 このようなコンテキストには、実際に使用された認証方法または、ITU-T X.1254 | ISO/IEC 29115 (International Telecommunication Union and International Organization for Standardization, “ITU-T Recommendation X.1254 | ISO/IEC DIS 29115 -- Information technology - Security techniques - Entity authentication assurance framework,” November 2011.) [ISO29115]のエンティティ認証保証レベルが含まれる可能性があるが、それに限定されるものではない。
認証コンテキストクラス参照 (Authentication Context Class Reference)
認証コンテキストを識別する識別子。
クレーム (Claim)
クレームプロバイダが、あるエンティティについて主張する、そのエンティティに関する情報の一部
クレームプロバイダ (Claims Provider)
エンティティに関するクレームを返すことが可能なサーバ
エンドユーザ (End-User)
リソース所有者である人
エンティティ (Entity)
独立した別個の存在を持ち、あるコンテキストの中で識別することが可能な何か。エンドユーザはエンティティの一例である。
個人識別情報 (Personally Identifiable Information (PII))
(a) その情報に関連する自然人を識別するのに用いられる情報。(b)その情報に関連する自然人に直接的・間接的に関連付けられているかもしれない情報。
仮名識別子 (Pairwise Pseudonymous Identifier (PPID))
リライイングパーティに対して用いられるエンティティを識別する識別子。あるリライイングパーティにおけるエンティティのPPIDは、他のリライイングパーティにおけるエンティティのPPIDと関連付けることができない。
IDトークン
認証イベントに関するクレームが含まれているトークン。
発行元 (Issuer)
クレームのセットを発行するエンティティ
発行元識別子 (Issuer Identifier)
発行元を検証可能な識別子。発行元識別子は、スキームとホスト、そして任意でポート番号とパスというコンポーネントを含むHTTPS URLである（クエリやフラグメントコンポーネントは存在しないかもしれない）。
メッセージ (Message)
OpenIDリライイングパーティとOpenIDプロバイダ間の要求と応答。
OpenIDプロバイダ (OpenID Provider (OP))
リライイングパーティに対し、クレームを提供する能力を持つサービス。認証イベント関係のクレームや、id_tokenやユーザ情報エンドポイント応答に含まれる他のクレームを返すことのできるOAuth 2.0の認可サーバである。
OPエンドポイント (OP Endpoints)
認可エンドポイント、トークンエンドポイント、ユーザ情報エンドポイント。
OpenID要求オブジェクト (OpenID Request Object)
OpenIDの要求パラメータを保持しているJSONオブジェクト。
リライイングパーティ (Relying Party (RP))
OpenIDプロバイダからクレームを要求するアプリケーション。拡張されたOAuth 2.0クライアント。
ユーザ情報エンドポイント (UserInfo Endpoint)
クライアントがアクセストークンを提示した際に、エンドユーザに関するクレームを返す保護リソース。

 TOC 

1.3.  概要

OpenID Connectプロトコルは、抽象的には、次の手順に従う。

  1. RP (クライアント)は、OP (認可サーバ)のエンドユーザ認可エンドポイントへ要求を送信する。
  2. OPはエンドユーザを認証し、適切な認可を取得する。
  3. OPは、アクセストークン、IDトークン、およびその他のいくつかの変数と共に応答する。
  4. RPは、ユーザ情報エンドポイント (UserInfo Endpoint)に対し、アクセストークンと共に要求を送信する。
  5. ユーザ情報エンドポイントは、リソースサーバでサポートしている追加のエンドユーザ情報を返す。

当仕様は、抽象的なメッセージフローとメッセージフォーマットのみを定義する。実際の使用に際しては、OpenID Connect Basic Client (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Profile 1.0,” June 2012.) [OpenID.Basic]や、OpenID Connect Standard (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” June 2012.) [OpenID.Standard]のような関連のプロトコルバインディング仕様のいずれかに基づいていなければならない (MUST)。


 TOC 

2.  メッセージ

OpenID Connectプロトコルでは、抽象的には、エンドポイントと対話するRPによって処理が進行する。関連するエンドポイントはいくつかある。

  1. 認可エンドポイント: RPは、OPの認可エンドポイントに要求を送信する。OPはその後、認可を実施する資格があるかを調べるためにエンドユーザを認証する。そして、エンドユーザの認可行為を基に、認可サーバは、認可コードcodeを含む認可応答を返す。いくつかのクライアントでは、codeなしでaccess_tokenを取得するインプリシットグラントが使用されることがある。この場合、response_typeには、tokenが含まれていなければならない (MUST)。id_tokenがresponse_typeで指定された場合、エンドポイントからid_tokenも同様に返される。
  2. トークンエンドポイント: クライアントは、access_tokenを含むアクセストークン応答を取得するために、トークンエンドポイントへアクセストークン要求を送信する。
  3. ユーザ情報エンドポイント: エンドユーザに関するクレームを取得するために、ユーザ情報エンドポイントにaccess_tokenを送信してもよい (MAY)。

 TOC 

2.1.  認可エンドポイント

RPは、response_typeとscopeに従い、認可応答またはIDトークン (ID Token)またはその両方を取得するために、OPの認可エンドポイントに認可要求を送信する。


 TOC 

2.1.1.  IDトークン

IDトークンは、認証イベントおよび他の要求されたクレームに関するクレームを含むセキュリティトークンである。 IDトークンはJSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT] として表される。

IDトークンは、認証イベントおよびユーザ識別子を管理するために使用され、aud (audience) および nonce クレームを介して特定のクライアントをスコープとしている。

以下のクレームは、IDトークン内で必須または任意である (REQUIRED, OPTIONAL)。

iss
必須。応答の発行元の発行元識別子。
user_id
必須。クライアントによって消費されることを意図している、発行元内でローカルユニークな再割り当てされないエンドユーザの識別子。 例： 24400320 または AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4 。 長さはASCIIで255文字を超えてはならない（MUST NOT）。
aud
必須。このメンバは、このIDトークンが意図している聴衆を識別する。 それはクライアントのOAuth 2.0のclient_id でなければならない (MUST)。
exp
必須。整数型。それ以降は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
必須。整数型。iat (issued at) クレームは、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] 参照すること。
acr
任意。（認証コンテキストクラス参照）: IDトークンの認証コンテキストクラス参照を指定する。値は、実施された認証のITU-T X.1254 | ISO/IEC 29115 (International Telecommunication Union and International Organization for Standardization, “ITU-T Recommendation X.1254 | ISO/IEC DIS 29115 -- Information technology - Security techniques - Entity authentication assurance framework,” November 2011.) [ISO29115]のエンティティ認証保証レベルにマップされた、"1"、"2"、"3"、"4"である。値"0"は、エンドユーザの認証が、ISO/IEC 29115のレベル1の要件を満たしていなかったことを示す。例えば、長寿命のブラウザクッキーを使用した認証は、"レベル0"の使用が適切である一例である。レベル0の認証は、金銭的な価値のあるリソースへのアクセスを認可するのには決して用いるべきではない(これは、OpenID 2.0 PAPE (Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider Authentication Policy Extension 1.0,” December 2008.) [OpenID.PAPE]のnist_auth_level 0に相当する) 。絶対URIまたは登録短縮名 (Johansson, L., “An IANA registry for SAML 2.0 Level of Assurance Context Classes,” February 2012.) [LoA.Registry]が、acr値として使用されるかもしれない (MAY)。
nonce
IDトークンを持つクライアントセッションを関連付けるためと、リプレイ攻撃を軽減するために使用される文字列値。 値は変更されずにそのまま認可要求からIDトークンへ渡されます。 IDトークン (ID Token) 内に存在した場合、クライアントは nonce クレーム値が認可要求で送信したnonce パラメータの値と等しいかを検証しなければならない (MUST)。認可要求に存在する場合、認可サーバは、認可要求で送信されたナンス値を nonce クレームの値としてIDトークン (ID Token)に含めなければならない (MUST)。インプリシットフローではnonceは必須である。コードフローでは任意である。
auth_time
任意。OpenID要求オブジェクト (OpenID Request Object)のid_token ("id_token" member)メンバが、クレーム要求auth_timeを含んでいる場合、このクレームは必須である (REQUIRED)。クレームの値は、UTCの1970-01-01T0:0:0Zから、エンドユーザ認証が発生した日時までの秒数である（auth_timeクレームは、意味的にはOpenID 2.0 PAPE (Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider Authentication Policy Extension 1.0,” December 2008.) [OpenID.PAPE] のauth_time応答パラメータに相当する）。
at_hash
任意。インプリシットフローでIDトークンがaccess_tokenと共に発行される場合、必須。この値は、JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.) [JWS]ヘッダのalgパラメータの中で使用されているハッシュと同じ長さのSHA-2ファミリーのハッシュアルゴリズムを使用してaccess_tokenをハッシュ化することによって作成されたハッシュの左から半分をbase64urlエンコードすることによって生成される。例えば、algがHS256の場合、SHA-256でaccess_tokenをハッシュ化し、その左から128bitに対しbase64urlエンコードを行う。
c_hash
任意。インプリシットフローでIDトークンがcodeと共に発行される場合、必須。この値は、JWSヘッダのalgパラメータの中で使用されているハッシュと同じ長さのSHA-2ファミリーのハッシュアルゴリズムを使用してaccess_tokenをハッシュ化することによって作成されたハッシュの左から半分をbase64urlエンコードすることによって生成される。例えば、algがHS256の場合、SHA-256でcodeをハッシュ化し、その左から128bitに対しbase64urlエンコードを行う。

IDトークンは、JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.) [JWS]を用いて署名を行うか、任意で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]の両方を用いて署名と暗号化を行わなければならない (MUST)。それにより、認証、完全性、否認防止、機密性の全て、または一部 (Signing and Encryption order)を提供する。

クライアントは、IDトークンの検証 (ID Token Verification)により、IDトークンの妥当性を直接検証しなければならない (MUST)。


 TOC 

2.1.2.  認可要求

認可要求は、RPからOPの認可エンドポイントに送信されるメッセージである。これはOAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の認可要求を拡張したものである。OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の4.1.1節および4.2.1節では、OAuth 2.0認可要求パラメータについて定義されている。この仕様では、パラメータの値は以下のように定義されている。

response_type
このパラメータは、認可エンドポイントからの応答で返されるパラメータを制御する。
OAuth 2.0仕様では、2つの応答タイプを文書化している:
code
response_typeパラメータの値として指定された場合、成功応答にはOAuth 2.0仕様で定義されている認可コードが含まれなければならない (MUST)。成功応答、エラー応答共に、応答のクエリコンポーネントにパラメータとして追加しなければならない (MUST)。すべてのトークンは、トークンエンドポイントから返される。認可サーバは、このresponse_typeをサポートしなければならない (MUST)。
token
response_typeパラメータの値として指定された場合、成功応答にはOAuth 2.0仕様で定義されているアクセストークンが含まれなければならない (MUST)。成功応答、エラー応答共に、フラグメントエンコーディングされなければならない (MUST)。IDトークンは、クライアントに提供されない。
OpenID Connectは、以下の登録済みの追加応答タイプ (de Medeiros, B., Scurtescu, M., and P. Tarjan, “OAuth 2.0 Multiple Response Type Encoding Practices,” May 2012.) [OAuth.Responses]もサポートする:
id_token
response_typeパラメータの値として指定された場合、成功応答にはOAuth 2.0仕様で定義されているIDトークンが含まれなければならない (MUST)。成功応答、エラー応答共に、フラグメントエンコーディングされるべきである (SHOULD)。認可サーバは、このresponse_typeをサポートすべきである (SHOULD)。
id_token token
response_typeパラメータの値として指定された場合、成功応答にはIDトークンとアクセストークンの両方が含まれなければならない (MUST)。成功応答、エラー応答共に、フラグメントエンコーディングされるべきである (SHOULD)。認可サーバは、このresponse_typeをサポートしなければならない (MUST)。
code token
response_typeパラメータの値として指定された場合、成功応答にはOAuth 2.0仕様で定義されている認可コードとアクセストークンの両方が含まれなければならない (MUST)。成功応答、エラー応答共に、フラグメントエンコーディングされるべきである (SHOULD)。
code id_token
response_typeパラメータの値として指定された場合、成功応答には認可コードとIDトークンの両方が含まれなければならない (MUST)。成功応答、エラー応答共に、フラグメントエンコーディングされるべきである (SHOULD)。
code id_token token
response_typeパラメータの値として指定された場合、成功応答には認可コードとIDトークンとアクセストークンが含まれなければならない (MUST)。成功応答、エラー応答共に、フラグメントエンコーディングされるべきである (SHOULD)。
認可サーバは、response_typeの値としてcode、id_token、id_token tokenの3つ全てをサポートしなければならない (MUST)。
クライアントは、認可サーバでサポートされているOAuth 2.0で登録された任意の応答タイプを要求するかもしれない (MAY)。
scope
スペース区切りの大文字小文字を区別したASCII文字列値のリスト。この値には、ユーザ情報エンドポイントから返される任意のクレームの追加のリストが指定される。以下のスコープ値が定義されている:
openid
必須。クライアントは、認可サーバに対し、OpenID Connect要求を行っていることを通知する。もしopenidスコープ値が存在しなかった場合、その要求はOpenID Connect要求として扱ってはならない(MUST NOT)。 このスコープ値はユーザ情報エンドポイントでのuser_idクレームへのアクセスを要求する。
profile
任意。このスコープ値は、発行されたアクセストークンによって与えられる、ユーザ情報エンドポイントでのエンドユーザのデフォルトのprofileクレーム (Reserved Member Definitions)アクセスを要求する。これらのクレームは以下の通り: name、 family_name、 given_name、 middle_name、 nickname、 preferred_username、 profile、 picture、 website、 gender、 birthday、 zoneinfo、 locale、 updated_time。
email
このスコープ値は、発行されたアクセストークンによって与えられる、ユーザ情報エンドポイントでのemailとemail_verifiedクレームへのアクセスを要求する。
address
このスコープ値は、発行されたアクセストークンによって与えられる、ユーザ情報エンドポイントでのaddressクレームへのアクセスを要求する。
phone
このスコープ値は、発行されたアクセストークンによって与えられる、ユーザ情報エンドポイントでのphone_numberクレームへのアクセスを要求する。

要求の中で必須 (REQUIRED) な他のOAuth 2.0パラメータには以下が含まれる:

client_id
OAuth 2.0クライアント識別子。
redirect_uri
応答が送信されるリダイレクト先のURI。

要求は、以下のOAuth 2.0パラメータを含んでいるかもしれない (MAY):

state
推奨。 要求とコールバック間で状態を維持するために使用する不明瞭な値は、XSRF攻撃に対する保護の役割を果たす。

以下の拡張パラメータも定義されている:

nonce
リプレイ攻撃を軽減するために使用するランダムで一意な文字列値。 インプリシットフローではnonceは必須である。コードフローでは任意である。
display
任意。認可サーバがエンドユーザに対して、認証と同意のユーザインタフェース画面を表示する方法を指定するASCII文字列値。
page
認可サーバは、ユーザエージェントの（ポップアップとかではない）完全な画面として認証と同意のUIを表示すべきである (SHOULD)。displayパラメータが指定されていない場合、これがデフォルトの表示モードである。
popup
認可サーバは、ユーザエージェントのポップアップウィンドウとして認証と同意のUIを表示すべきである (SHOULD)。ポップアップユーザエージェントウィンドウは幅450ピクセル、高さ500ピクセルであるべきである (SHOULD)。
touch
認可サーバは、タッチインタフェースを活用したデバイス向けのUIを表示すべきである (SHOULD)。認可サーバは、タッチデバイスの検出を試み、さらにインターフェースをカスタマイズしてもよい (MAY)。
wap
認可サーバは、フィーチャーフォンの画面向けの認証と同意のUIを表示すべきである (SHOULD)。
prompt
任意。認可サーバが再認証と同意のためにエンドユーザに対しプロンプトを表示するかどうかを指定する、スペース区切りの大文字小文字を区別したASCII文字列値のリスト。設定可能な値は以下のとおり。
none
認可サーバは、認証も同意もユーザインタフェース画面を表示してはならない(MUST NOT)。エンドユーザがまだ認証されていないか、またはクライアントが要求されたscopeに対して事前設定された同意を保持していない場合は、エラーが返される。これは、既存の認証および/または同意が存在するかを確認するための手段として使用することができる。
login
認可サーバは、再認証のためにエンドユーザにプロンプ​​トを表示しなければならない。
consent
認可サーバは、クライアントに情報を返す前にエンドユーザに同意のためのプロンプ​​トを表示しなければならない (MUST)。
select_account
認可サーバは、エンドユーザにユーザアカウントを選択するためのプロンプ​​トを表示しなければならない (MUST)。これは、認可サーバで複数のアカウントを持つユーザは、彼らが現在のセッションを持っているかもしれない複数のアカウントの間で選択することを許可する。
promptパラメータは、エンドユーザが現在のセッションのためにまだ存在していることを確認するためか、または要求に注意を喚起するためにクライアントで使用することができる。
request
任意。OpenID要求オブジェクト (OpenID Request Object)値。
request_uri
任意。OpenID要求オブジェクトを指すURL。これは参照によってOpenID要求オブジェクトを渡すために使用される。
id_token
任意。クライアントとユーザの現在または過去の認証セッションに関するヒントとして、認可サーバから渡されたIDトークン (ID Token)。prompt=noneが送信されたとき、これは存在するべきである (SHOULD)。

 TOC 

2.1.2.1.  OpenID要求オブジェクト

OpenID要求オブジェクトは、デフォルトのものとは異なるかもしれない (MAY) OpenID要求パラメータを提供するために使用される。OpenID要求オブジェクトのサポートを実装するかどうかは任意である (OPTIONAL)。デフォルトのユーザ情報 (UserInfo Endpoint)以外のクレームセットおよびIDトークンクレームセットを要求または提供する際は、これのサポートが必要となる。

OpenID要求オブジェクトは、認可要求の"request"パラメータの値として渡される、署名とbase64urlエンコードが施されたJSONオブジェクトであるJWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.) [JWS]である。OpenID要求オブジェクトは、JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.)に規定されたのと同様の手法の入れ子処理を用いて、署名後にJWE (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.) [JWE]を用いて暗号化が行われることもある (MAY)。OpenID要求オブジェクトは、代わりに、request_uriパラメータを用いて、参照として送信されることもある (MAY)。ユーザ情報エンドポイントから返される情報に影響するパラメータは、"userinfo"メンバである。IDトークン内で返される情報に影響するパラメータは、"id_token"メンバである。

OAuth 2.0認可要求に含まれている認可要求パラメータは、 （署名付き要求の一部にすることができるように）OpenID要求オブジェクトにも含まれている。OAuth 2.0認可要求とOpenID要求オブジェクトの両方に存在するすべてのパラメータ値は、完全一致しなければならない (MUST)。

OAuth 2.0仕様で任意である認可要求パラメータは、一つの例外を除いて、OAuth 2.0認可要求パラメータとして渡さずに、OpenID要求オブジェクトのみに含まれるかもしれない (MAY)。その一つの例外とは、（OAuth 2.0実装がopenidスコープ値へアクセスできるように）scopeパラメータが常にOAuth 2.0認可要求パラメータに存在しなければならない (MUST)、という点である。しかし、requestとrequest_uriパラメータは、OpenID要求オブジェクトに含まれていてはならない (MUST NOT)。

OpenID要求オブジェクトは、当仕様で定義されていない他のメンバを含むかもしれない (MAY)。ただ一つの例外を除いて、OpenID要求オブジェクトのメンバは、両当事者によって理解されなければならない (MUST)。その例外は、OpenIDプロバイダが、自身が提供できない、または理解していないクレームの要求を無視するかもしれない (MAY) ことである。 しかし、リライイングパーティは、要求したすべての必要なクレームが提供されていない場合、エラー状態と考えるかもしれない (MAY)。

OpenID要求オブジェクトは、署名されていても、されていなくても（平文）もよい (MAY)。 平文は、JWSヘッダでnoneアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2012.)を使用することによって示す。署名される場合、OpenID要求オブジェクトは、JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT]仕様での定義と同様の意味を持つ、iss (issuer)とaud (audience)クレームをメンバとして含むべきである (SHOULD)。

当仕様で定義されたOpenID要求オブジェクトのメンバは以下の通り:

userinfo
任意。（ユーザ情報要求）: ユーザ情報エンドポイントから返される値に影響を与える要求。存在しない場合、ユーザ情報エンドポイントはデフォルトの方法で動作する。
id_token
任意。（IDトークン要求）: IDトークンで返される値に影響を与える要求。存在しない場合、デフォルトのIDトークンの内容が使用される。存在した場合、IDトークンのデフォルトクレーム (ID Token)に加え、追加のクレームを要求するのにこれらのパラメータは使用される。

base64urlエンコーディングとJWS署名を行う前のOpenID要求オブジェクトの例は以下の通り: 

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

 TOC 

2.1.2.1.1.  "userinfo"メンバ

userinfo（ユーザ情報要求）メンバの構造は、以下のメンバを含むかもしれないJSONオブジェクトである:

claims
任意。（要求クレーム）: scope値によって要求されるものに加えて、ユーザ情報エンドポイントから要求されている個々のクレームのセットを含むJSONオブジェクト。存在しない場合、scope値によって要求される、OPが保持しているユーザ情報クレームのみが返される。このクレームの詳細については、"userinfo"と"id_token"の"claims"メンバの節 ("claims" member with "userinfo" and "id_token" members)を参照。
preferred_locales
任意。優先順に並べられた、BCP47 (Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.) [RFC5646]の言語タグ値のJSON配列として表された、クレーム要求全体に適切な言語とスクリプトのリスト。

userinfoオブジェクトのすべてのメンバは任意 (OPTIONAL) である。他のメンバが存在しているかもしれない (MAY)。その場合、両当事者が理解すべきである (SHOULD)。


 TOC 

2.1.2.1.2.  "id_token"メンバ

OpenID要求オブジェクトのid_token（IDトークン要求）メンバの構造と機能は、userinfoメンバと似ている。それは任意のclaimsとpreferred_localesメンバを含むかもしれない (MAY)。これらのメンバの構造は、userinfoメンバと同じである。claimsがid_tokenオブジェクトに存在した場合、その中で要求されたクレームが、通常のIDトークンで返されるクレームセットに追加される。

"userinfo"と"id_token"の"claims"メンバの節 ("claims" member with "userinfo" and "id_token" members)に記述されたクレームに加え、以下のクレームが、claimsメンバ内で指定されることによってIDトークン内に要求されるかもしれない (MAY)。

user_id
任意。（ユーザ識別子）: IDトークンが要求されているユーザ識別子。 指定されたユーザが現在認可サーバに認証されていない場合、認可要求のpromptパラメータがnoneに設定されていない限り、認証を求められる場合がある。要求内のクレーム値は、単一要素valueを含むオブジェクトである。
 "user_id": {"value":"248289761001"}
auth_time
任意。（認証時刻）: IDトークン (ID Token)応答にauth_timeクレームを含むことを要求。 要求内のクレーム値は、nullである。
acr
任意。（認証コンテキストクラス参照）: 希望の認証コンテキストクラス参照を要求。要素のvaluesは、優先順位の順序で表示される許容する認証コンテキストクラス参照を表す順序付き文字列の配列である。
 "acr": {"values":["2","http://id.incommon.org/assurance/bronze"]}

claimsメンバに加えて、以下の追加メンバがOpenID要求オブジェクトのid_tokenメンバ内で定義されている:

max_age
任意。（最大認証有効期限）: 全ての既存の認証が、指定した秒数よりも古い場合、エンドユーザを積極的に認証する必要があることを示す。（max_age要求パラメータは、OpenID 2.0 PAPE (Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider Authentication Policy Extension 1.0,” December 2008.) [OpenID.PAPE] のmax_auth_age要求パラメータに相当する）。

認証用の追加のプロパティを保持することを要求するために、追加のid_tokenパラメータが定義されるかもしれない (MAY) ということが予期される。例えば、ある認証ポリシーが適用されているかどうか（OpenID 2.0 PAPE (Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider Authentication Policy Extension 1.0,” December 2008.) [OpenID.PAPE]のauth_policies値と同等の考え）であったり、認証が指定したトラストフレームワークによって定義されたポリシーに従っているかどうかなどが考えられる。これらのパラメータは、拡張仕様によって定義されるかもしれない (MAY)。

id_tokenオブジェクトのすべてのメンバは任意 (OPTIONAL) である。他のメンバが存在しているかもしれない (MAY)。その場合、両当事者が理解すべきである (SHOULD)。


 TOC 

2.1.2.1.3.  "userinfo"と"id_token"メンバの"claims"メンバ

claimsメンバは、要求された各クレームのメンバを持つJSONオブジェクトである。メンバ名は、要求されたクレームの名前である。各クレームは、必須クレームか任意クレームのいずれかであるかもしれない (MAY)。デフォルトは任意である。

essentialとしてクレームを要求することによって、クライアントは、これらのクレームを開示することは、ユーザによって要求された特定のタスクのスムーズな認可を保証することをユーザに示す。ユーザがクレームの開示を認可しなかったか、クレームが存在しなかったことにより、クレームが利用できなかったとしても、認可サーバは必須クレームが返されないことによるエラーを生成してはならない (MUST NOT) ということに注意すること。

クライアントは、ユーザに提示する他のタスクを実行するために必要な追加のクレームを任意として要求するかもしれない。

メンバの値は、以下のいずれかかもしれない (MAY):

null
このクレームが、デフォルトの方法で要求されていることを示している。具体的に言うと、これは任意クレームである。
JSONオブジェクト
要求したクレームについて追加情報を提供するために使用される。当仕様では、以下のメンバについて定義する:
essential
任意。値がtrueに設定されている場合、要求しているクレームが必須クレームであることを示す。値がfalseに設定されている場合、任意クレームであることを示す。デフォルトはfalseである。
他のメンバは、要求されたクレームについての追加情報を提供するために定義されるかもしれない (MAY)。

クレームは複数の言語とスクリプトで表されるかもしれない (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として表現される漢字表記に対する発音に基づいたインデックスとして一般的に用いられる。

claimsオブジェクトのすべてのメンバは任意 (OPTIONAL) である。


 TOC 

2.1.3.  認可応答

認可応答は、RPによる認可要求に対する応答として、OPの認可エンドポイントから返されるメッセージである。

要求のresponse_typeがtokenの場合、認可応答はOAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の4.2.2節に定義されているパラメータを返さなければならない (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]のみをサポートする。OAuth 2.0の"token_type"応答パラメータは、"Bearer"に設定されなければならない (MUST)。

要求のresponse_typeがcodeの場合、認可応答はOAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の4.1.2節に定義されているパラメータを返さなければならない。

response_typeが他の値を含んでいる場合、登録で定義されたとおりに返さなければならない。id_tokenの返す型は、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]に定義されている。


 TOC 

2.1.4.  認可エラー応答

エンドユーザがアクセス要求を拒否するか、要求が失敗した場合、OP（認可サーバ）は、OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の4.1.2.1節と4.2.2.1節に定義されているパラメータを返すことによってRP（クライアント）に通知する。

OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の4.1.2.1節と4.2.2.1節に定義されているエラーコードに加え、当仕様では以下のエラーコードを定義する:

invalid_redirect_uri
認可要求のredirect_uriが、クライアントの事前登録されたredirect_urisのいずれにも一致しない。
interaction_required
認可サーバが、処理を続行するためには、何らかの形のエンドユーザ対話が必要である。このエラーは、認可サーバに対し、エンドユーザには一切のユーザインタフェースを表示すべきではないということを要求するために、認可要求のpromptパラメータをnoneに設定しているが、エンドユーザ対話のためのユーザインタフェースの表示なしには認可要求の処理を完了できない場合に返されるかもしれない (MAY)。
login_required
認可サーバは、エンドユーザの認証を必要としている。このエラーは、認可サーバに対し、エンドユーザには一切のユーザインタフェースを表示すべきではないということを要求するために、認可要求のpromptパラメータをnoneに設定しているが、ユーザ認証のためのユーザインタフェースの表示なしには認可要求の処理を完了できない場合に返されるかもしれない (MAY)。
session_selection_required
エンドユーザは、認可サーバでセッションを選択する必要がある。エンドユーザは異なる関連アカウントを持つ認可サーバで認証されるかもしれないが、エンドユーザはセッションを選択しなかった。 このエラーは、認可サーバに対し、エンドユーザには一切のユーザインタフェースを表示すべきではないということを要求するために、認可要求のpromptパラメータをnoneに設定しているが、使用するセッションを指示するためのユーザインタフェースの表示なしには認可要求の処理を完了できない場合に返されるかもしれない (MAY)。
consent_required
認可サーバは、エンドユーザの同意を必要としている。このエラーは、認可サーバに対し、エンドユーザには一切のユーザインタフェースを表示すべきではないということを要求するために、認可要求のpromptパラメータをnoneに設定しているが、ユーザ同意のためのユーザインタフェースの表示なしには認可要求の処理を完了できない場合に返されるかもしれない (MAY)。
invalid_request_uri
認可要求のrequest_uriが、エラーまたは無効なデータを返す。
invalid_openid_request_object
requestパラメータが、無効なOpenID要求オブジェクトを含んでいる。

登録済みのOAuth 2.0 response_typeによって定義されたとおりのエラーが返される。


 TOC 

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

RP（クライアント）は、アクセストークン、リフレッシュトークン (Refresh Token, and Access Token Lifetime)、IDトークン (ID Token)、その他の変数を含むかもしれない (MAY) アクセストークン応答を取得するために、トークンエンドポイントにアクセストークン要求を送信する。


 TOC 

2.2.1.  クライアント認証

クライアント登録時に、RP（クライアント）は、認証方法を登録するかもしれない (MAY)。何も方法が登録されなかった場合、client_secret_basicのデフォルトの方法が使用されなければならない (MUST)。

サポートされるオプションは以下の通り:

client_secret_basic
認可サーバからclient_secret値を受け取ったクライアントは、HTTP基本認証スキームを用いて、OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の3.2.1節に従い、認可サーバと認証を行う。
client_secret_post
認可サーバからclient_secret値を受け取ったクライアントは、要求ボディにクライアントクレデンシャルを含めて、OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の3.2.1節に従い、認可サーバと認証を行う。
client_secret_jwt
認可サーバからclient_secret値を受け取ったクライアントは、HMAC SHA-256のような、HMAC SHAアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2012.)を用いて、JWTを作成する。HMAC（ハッシュベースメッセージ認証コード）は、共有鍵としてclient_secretの値を用いて計算される。クライアント認証は、OAuth JWT Bearer Token Profiles (Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0,” May 2012.) [OAuth.JWT]の2.2節と、OAuth 2.0 Assertion Profile (Mortimore, C., Ed., Campbell, B., Jones, M., and Y. Goland, “OAuth 2.0 Assertion Profile,” May 2012.) [OAuth.Assertions]に従う。JWTは以下のクレームを含まなければならない (MUST):
iss
必須。iss (issuer)クレーム。これは、OAuthのクライアントのclient_idを含まなければならない (MUST)。
prn
必須。prn (principal)クレーム。これは、OAuthのクライアントのclient_idを含まなければならない (MUST)。
aud
必須。aud (audience)クレーム。対象聴衆として認可サーバを識別する値。 認可サーバは、トークンの対象聴衆であることを検証しなければならない(MUST)。 聴衆は、認可サーバのトークンエンドポイントのURLであるべきである (SHOULD)。
jti
必須。jti (JWT ID)クレーム。トークンの一意の識別子。 JWT IDはワンタイム使用のアサーションのメッセージ重複除外を必要とする実装によって使用されるかもしれない (MAY)。
exp
必須。JWTが使用可能な時間枠を制限するexp (expiration)クレーム。
iat
任意。JWTが発行された時刻を識別するiat (issued at) クレーム。
認証トークンは、client_assertionパラメータの値として送信されなければならない (MUST)。
client_assertion_typeパラメータの値は、"urn:ietf:params:oauth:client-assertion-type:jwt-bearer"でなければならない (MUST)。
private_key_jwt
公開鍵を登録したクライアントは、RSA鍵を登録していた場合はRSAアルゴリズムで、楕円曲線鍵を登録していた場合はECDSAでJWTを署名する（アルゴリズム識別子はJWA (Jones, M., “JSON Web Algorithms (JWA),” May 2012.) [JWA]を参照）。クライアント認証は、OAuth JWT Bearer Token Profiles (Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0,” May 2012.) [OAuth.JWT]の2.2節と、OAuth 2.0 Assertion Profile (Mortimore, C., Ed., Campbell, B., Jones, M., and Y. Goland, “OAuth 2.0 Assertion Profile,” May 2012.) [OAuth.Assertions]に従う。JWTは以下のクレームを含まなければならない (MUST):
iss
必須。iss (issuer)クレーム。これは、OAuthのクライアントのclient_idを含まなければならない (MUST)。
prn
必須。prn (principal)クレーム。これは、OAuthのクライアントのclient_idを含まなければならない (MUST)。
aud
必須。aud (audience)クレーム。対象聴衆として認可サーバを識別する値。 認可サーバは、アサーションの対象聴衆であることを検証しなければならない(MUST)。 聴衆は、認可サーバのトークンエンドポイントのURLであるべきである (SHOULD)。
jti
必須。jti (JWT ID)クレーム。トークンの一意の識別子。 トークンIDはワンタイム使用のアサーションのメッセージ重複除外を必要とする実装によって使用されるかもしれない (MAY)。
exp
必須。JWTが使用可能な時間枠を制限するexp (expiration)クレーム。
iat
任意。JWTが発行された時刻を識別するiat (issued at) クレーム。
認証トークンは、client_assertionパラメータの値として送信されなければならない (MUST)。
client_assertion_typeパラメータの値は、"urn:ietf:params:oauth:client-assertion-type:jwt-bearer"でなければならない (MUST)。

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

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

grant_type=authorization_code&
code=i1WsRn1uB1&
client_id=s6BhdRkqt3&
client_assertion_type=
    urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
client_assertion=PHNhbWxwOl...[omitted for brevity]...ZT


 TOC 

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

クライアントは、認可サーバでの認証と、そのアクセス許可を（認可コード、またはリフレッシュトークンの形で）提示することによって、アクセストークンを取得する。

これがリフレッシュトークン要求の場合、クライアント認証パラメータに加えて、クライアントは、OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の6節に規定されている追加のパラメータを送信しなければならない (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節で規定されているように、アクセストークンエンドポイントに対し要求パラメータを送信しなければならない (MUST)。


 TOC 

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

クライアントからの認可されたアクセストークン要求の受信と妥当性を検証の後、認可サーバは、アクセストークンとIDトークンを含む成功応答を返す。成功応答のパラメータは、OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の4.1.4節に定義されている。

当仕様はさらに、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]だけが、トークンエンドポイントで発行されるという制約を設ける。OAuth 2.0の"token_type"応答パラメータは、"Bearer"に設定されなければならない (MUST)。

grant_typeがauthorization_codeで、認可要求のscopeパラメータがopenidを含む場合、OAuth 2.0応答パラメータに加え、以下のパラメータが応答に含まれていなければならない (MUST):

id_token
認証セッションに関連付けられたIDトークン値。

grant_typeがauthorization_codeでない場合、id_tokenは返してはならない (MUST NOT) ことに注意。

以下は、参考例である: 

{
 "access_token": "SlAV32hkKG",
 "token_type": "Bearer",
 "refresh_token": "8xLOxBtZp8",
 "expires_in": 3600,
 "id_token": "eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso"
}

OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]のとおり、クライアントは、認識できない応答パラメータを無視すべきである (SHOULD)。


 TOC 

2.2.4.  トークンエラー応答

トークン要求が無効または未認可の場合、認可サーバは、エラー応答を作成する。トークンエラー応答のパラメータは、OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.) [OAuth2.0]の5.2節のように定義されている。


 TOC 

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

ユーザ情報エンドポイントは、認証されたエンドユーザに関するクレームを返す保護リソースである。クレームは、クレームの名前と値のペアのコレクションを含むJSONオブジェクトによって表される。


 TOC 

2.3.1.  ユーザ情報要求

クライアントは、エンドユーザの詳細情報を取得するためにユーザ情報エンドポイントに以降のパラメータを使用して要求を送るかもしれない (MAY)。

access_token
必須。アクセストークンは、OpenID Connectの認可要求から取得される。
schema
必須。返されるデータのスキーマ。 唯一の定義された値は openid であるｊ。
id
この識別子は予約されている。 これは、openid スキーマが使用されているときは、エンドポイントで無視しなければならない (MUST)。

 TOC 

2.3.2.  ユーザ情報応答

要求されたスキーマが openid の場合、応答は下記に定義されているクレームのフルセットまたはサブセットを含むJSONオブジェクトを返す必要がある (MUST)。（下記に示されていない）追加のクレームも返されるかもしれない (MAY)。

クレームが返されない場合、そのクレームの名前は、クレームのセットを表す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 として表現される漢字表記に対する発音に基づいたインデックスとして一般的に用いられる。


メンバ型説明
user_id 文字列 発行元内でエンドユーザを示す必須識別子。
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.5.2.2 (Claim Stability and Uniqueness) 参照)
profile 文字列 エンドユーザのプロファイルページのURL。
picture 文字列 エンドユーザのプロファイル画像のURL。
website 文字列 エンドユーザのウェブページまたはブログのURL。
email 文字列 エンドユーザの優先電子メールアドレス。RPは、この値の一意性に依存してはならない (MUST NOT)。 (Section 2.5.2.2 (Claim Stability and Uniqueness) 参照)
email_verified 真偽値 エンドユーザの電子メールアドレスが検証されている場合はtrue、それ以外の場合はfalse。
gender 文字列 エンドユーザの性別：この仕様で定義されている値は female と male である。 定義されている値のいずれも適用できない場合は他の値が使用されるかもしれない (MAY)。
birthday 文字列 エンドユーザの誕生日。MM/DD/YYYY形式の日付文字列として表される。省略されていることを示すため、年には 0000 が指定されるかもしれない (MAY)。
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.) [ISO639-€1] 言語コードの小文字表記と、 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.) [ISO3166-€1] 国コードの大文字表記である。例： 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] を推奨。 例： +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 。

表1: 予約済みメンバの定義

プライバシー上の理由から、OpenIDプロバイダはopenidスコープの一部として、いくつかのスキーマ要素の値を提供しないようにするかもしれない (MAY)。

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

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] で異なるフォーマットが規定されない限り、ユーザ情報エンドポイントは、JSONフォーマットでクレームを返さなければならない (MUST)。ユーザ情報エンドポイントは、署名および/または暗号化をされたJWT形式でクレームを返すかもしれない (MAY)。ユーザ情報エンドポイントは、フォーマットを示すためにContent-Typeヘッダーを返さなければならない (MUST)。以下は、受け入れられるコンテントタイプである。

Content-Type返されるフォーマット
application/json plain text JSON object
application/jwt JSON Web Token (JWT)

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

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

 TOC 

2.3.2.1.  住所クレーム

物理的な郵送先住所のコンポーネント。 実装では、入手可能な情報とエンドユーザのプライバシー設定に応じて、 addressのフィールドのサブセットのみを返すかもしれない (MAY)。たとえば、 countryやregionは、より詳細なアドレス情報なしで、返されるかもしれない。

実装では、formatted サブフィールド中に単一の文字列だけで完全なアドレスを返してもよい (MAY)、またはその他のサブフィールドを用いて、個々のコンポーネントのフィールドを返してもよい (MAY)、またはそれらの両方を返すかもしれない (MAY)。両方の変数が返された場合、formattedアドレスは複数のコンポーネントフィールドをどのように組み合わせるべき (SHOULD) かを示し、双方は同等のアドレスを示しているべきである (SHOULD)。

formatted
表示や宛名ラベルで使用するためにフォーマットされた完全な住所。このフィールドは改行を含むかもしれない (MAY)。 これは、このフィールドにおける、並べ替えやフィルタリングに用いられる際の最優先のサブフィールドである。
street_address
家番号、ストリート名、私書箱、複数行の拡張された住所情報を含むことができる完全な住所コンポーネント。 このフィールドは改行を含むかもしれない (MAY)。
locality
都市や地域のコンポーネント。
region
州、地方、県や地域のコンポーネント。
postal_code
ZIPコードまたは郵便番号コンポーネント。
country
国の名前のコンポーネント。


 TOC 

2.3.2.2.  クレームの不変性と一意性

user_id クレームは、2.1.1 (ID Token) 節の記述のとおり、ある特定のエンドユーザに対し、ローカルユニークでかつ、決して再割り当てされない (MUST) ため、クライアントが不変であるという前提を置ける唯一のクレームである。

したがって、ある特定のエンドユーザに対し、一意性が保証された唯一の識別子は、発行元の識別子と user_id クレームの組み合わせであり、preferred_usernameやemailなどの他のフィールドは、ある特定のエンドユーザに対する一意の識別子として使用してはならない (MUST NOT)。

他のすべてのクレームは、異なる発行元間で不変性またはユーザ間での一意性の保証はできない。そして発行元は、ローカルな制限とポリシーを適用することが許される。 たとえば、発行元は、異なる時点の異なるエンドユーザ間で、与えられたpreferred_usernameまたはemail アドレスクレームを再利用するかもしれない (MAY)。そして、ある特定のエンドユーザについて、主張したpreferred_usernameや電子メールアドレスが変わるかもしれない (MAY)。


 TOC 

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.) [OAuth.Bearer]の3.1節に定義されているエラーコードに加え、当仕様では以下のエラーコードを定義する:

invalid_schema
要求されたスキーマは無効またはサポートされていない。

 TOC 

2.4.  ユーザ識別子タイプ

プロバイダのディスカバリドキュメントは、user_id_types_supported要素で、サポートされている識別子のタイプをリストすべきである (SHOULD)。 配列にリストされたタイプが複数ある場合、クライアントは、登録時にuser_id_typeパラメータを使用して、望ましい識別子タイプを提供することを選ぶかもしれない (MAY)。当仕様でサポートされているタイプは以下のとおり:

public
これは、すべてのクライアントに同じuser_id値を提供する。プロバイダのディスカバリドキュメントにuser_id_types_supported要素がない場合のデフォルトである。
pairwise
ユーザの許可なしに、クライアントによるユーザの活動の名寄せを防ぐために、各クライアントに異なるuser_id値を提供する。

 TOC 

2.4.1.  仮名識別子のアルゴリズム

OpenIDプロバイダは、各セクタ識別子に対して一意のuser_id値を計算する必要がある。 user_idは、OpenIDプロバイダ以外の第三者によって可逆であってはならない (MUST NOT)。

pairwise user_id値を使用するプロバイダは、Dynamic Client Registration (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2012.) [OpenID.Registration]のsector_identifier_urlをサポートすべきである (SHOULD)。個々のドメイン名から独立して、pairwiseのuser_id値の一貫性を、単一の管理下にあるウェブサイトのグループに提供する。また、彼らの持つすべてのユーザにつ再登録なしで、redirect_uriドメインを変更するための方法も提供する。

クライアントが、Dynamic Client Registration (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2012.) [OpenID.Registration]でsector_identifier_url値を提供しなかった場合、仮名識別子の計算に用いられるセクタ識別子は、登録されたredirect_uriのホストコンポーネントである。登録されたredirect_urisに複数のホスト名がある場合、クライアントはsector_identifier_urlを登録しなければならない (MUST)。

sector_identifier_urlが提供されている場合、URLのホストコンポーネントが、仮名識別子の計算のためのセクタ識別子として用いられる。sector_identifier_urlの値は、redirect_uri値の配列が含まれたJSONファイルを示すHTTPS URLでなければならない。登録されたredirect_urisの値は、配列の要素に含まれている必要があるか、または登録失敗としなければならない (MUST)。

いくつかのアルゴリズムが、仮名識別子を計算するためにOpenIDプロバイダによって使用されるかもしれない (MAY)。当仕様は、3つの例が含まれている。

1. セクタ識別子は、ローカルアカウントIDおよびプロバイダによって秘密にされているソルト値と連結される。連結した文字列は適切なアルゴリズムによってハッシュ化される。

user_id = SHA-256 ( sector_identifier | local_account_id | salt ) を計算。

2. セクタ識別子は、ローカルアカウントIDおよびプロバイダによって秘密にされているソルト値と連結される。連結した文字列は適切なアルゴリズムによって暗号化される。

user_id = AES-128 ( sector_identifier | local_account_id | salt ) を計算。

3. 発行元は、セクタ識別子とローカルアカウントIDのタプルに対し、グローバル一意識別子 (GUID) を作成する。 これはテーブルに格納され、値は毎回検索される。


 TOC 

2.5.  クレームタイプ

ユーザ情報エンドポイントは、以下の3種類のクレームタイプを返すかもしれない (MAY):

通常クレーム
OpenIDプロバイダによって直接主張されているクレーム。
集約クレーム
OpenIDプロバイダ以外のクレームプロバイダによって主張されているが、OpenIDプロバイダによって返されるクレーム。
分散クレーム
OpenIDプロバイダ以外のクレームプロバイダによって主張されているが、OpenIDプロバイダによって参照として返されるクレーム。

ユーザ情報エンドポイントは、通常クレームをサポートしなければならない (MUST)。

集約および分散クレームのサポートは任意 (OPTIONAL) である。


 TOC 

2.5.1.  通常クレーム

通常クレームは、JSONオブジェクトのメンバとして表される。クレーム名はメンバ名で、クレーム値はメンバ値である。

以下は、 通常クレーム応答の参考例である: 

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

 TOC 

2.5.2.  集約および分散クレーム

集約および分散クレームは、クレームを含むJSONオブジェクトの特別な_claim_namesおよび_claim_sourcesメンバを使用して表される。

_claim_names
この値は、そのメンバ名が、集約および分散クレームのクレーム名であるJSONオブジェクトである。メンバ値は、実際のクレーム値を取得することができる_claim_sourcesメンバのメンバ名への参照である。
_claim_sources
この値は、メンバ名が_claim_namesメンバのメンバ値によって参照されているJSONオブジェクトである。メンバ値は、集約クレームまたは分散クレームの参照位置のセットを含んでいる。メンバ値は、集約または分散クレームを提供しているかどうかに応じて、以下のいずれかの形式を持つことができる。
集約クレーム
対応する_claim_sourcesメンバを参照する_claim_namesオブジェクト名にすべてのクレームを含まなければならない (MUST) JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT]を値として持つ、JWTメンバを含まなければならない (MUST) JSONオブジェクト。両当事者が解釈できる場合、他のメンバが存在するかもしれない (MAY)。
JWT
必須。JWT値。
分散クレーム
以下のメンバと値を含むJSONオブジェクト:
endpoint
必須。値は、関連付けられたクレームを取得するためのOAuth 2.0のリソースエンドポイントである。エンドポイントURLは、JWTとしてクレームを返さなければならない (MUST)。
access_token
任意。OAuth 2.0 Bearer (Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” June 2012.) [OAuth.Bearer]のスキームを用いてエンドポイントURLからクレームを取り出すことを可能にするアクセストークン。クレームは、Authorization要求ヘッダフィールドを用いて要求されるべきであり (SHOULD)、クレームソースはこの方法をサポートしなければならない (MUST)。アクセストークンが利用できない場合、クライアントは、アウトオブバンドでアクセストークンを取得するか、クレームソースとクライアント間の交渉により事前に取得したアクセストークンを使用するかもしれない (MAY)。または、クレームソースが、エンドユーザの再認証かつ／またはクライアントの再認可を行うかもしれない (MAY)。
両当事者が解釈できる場合、他のメンバが存在するかもしれない (MAY)。

以下は、 集約クレーム応答の参考例である: 

クレームプロバイダAは、Jane Doeに関して以下のクレームを収容している: 
{
 "address": {
   "street_address": "1234 Hollywood Blvd.",
   "locality": "Los Angeles",
   "region": "CA",
   "postal_code": "90210",
   "country": "US"},
 "phone_number": "+1 (310) 123-4567"
}

クレームプロバイダAはJSONクレームに署名をする。
その結果として署名されたJWTは以下である: 
jwt_header.jwt_part2.jwt_part3

認可サーバは、クレームプロバイダAからのJane Doeの集約クレームを返す: 
{
 "name": "Jane Doe",
 "given_name": "Jane",
 "family_name": "Doe",
 "birthday": "01/01/2001",
 "eye_color": "blue",
 "email": "janedoe@example.com",
 "_claim_names": {
  "address": "src1",
  "phone_number": "src1"
 },
 "_claim_sources": {
  "src1": {"JWT": "jwt_header.jwt_part2.jwt_part3"}
 }
}

以下は、 分散クレーム応答の参考例である: 

クレームプロバイダA （Jane Doeの銀行）は、
Jane Doeに関して以下のクレームを収容している: 
{
 "shipping_address": {
   "street_address": "1234 Hollywood Blvd.",
   "locality": "Los Angeles",
   "region": "CA",
   "postal_code": "90210",
   "country": "US"},
 "payment_info": "Some_Card 1234 5678 90123 4562",
 "phone_number": "+1 (310) 123-4567"
}

クレームプロバイダB （信用機関）は、
Jane Doeに関して以下のクレームを収容している: 
{
 "credit_score": "650"
}

認可サーバは、アクセストークンとクレーム取得先のURLを送信することにより、
クレームプロバイダAとBからの分散クレームと共に、Jane Doeのクレームを返す: 
{
 "name": "Jane Doe",
 "given_name": "Jane",
 "family_name": "Doe",
 "email": "janedoe@example.com",
 "birthday": "01/01/2001",
 "eye_color": "blue",
 "_claim_names": {
  "payment_info": "src1",
  "shipping_address": "src1",
  "credit_score": "src2"
 },
 "_claim_sources": {
  "src1": {"endpoint": "https://bank.example.com/claimsource"},
  "src2": {"endpoint": "https://creditagency.example.com/claimshere",
           "access_token": "ksj3n283dke"}
 }
}


 TOC 

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

パラメータ名と値は、JSON構造にシリアライゼーションされたJSONかもしれない (MAY)。


 TOC 

3.1.  JSONシリアライゼーション

パラメータは、最上位の構造レベルに各パラメータを追加することによってJSON構造にシリアライゼーションされる。パラメータ名と文字列値は、JSON文字列として含まれている。数値は、JSON数値として含まれている。各パラメータは、その値としてJSON構造を持っているかもしれない (MAY)。

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

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

 TOC 

4.  署名と暗号化

メッセージが送信されるときに通過するトランスポートに依存して、メッセージの完全性が保証されない場合があり、メッセージの発信者が認証されない場合がある。これらのリスクを低減するために、OpenID要求オブジェクト、トークン要求、IDトークン応答、ユーザ情報応答は、JSON Web Signature (JWS) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.) [JWS]を用いてコンテンツに署名することができる (MAY)。

メッセージの機密性を達成するため、OpenID要求オブジェクト、トークン要求、IDトークン応答、ユーザ情報応答は、JSON Web Encryption (JWE) (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.) [JWE]を用いてコンテンツを暗号化することができる (MAY)。

メッセージに署名と暗号化の両方を実施する場合、JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.)に規定されたのと同様の手法の入れ子処理を用いて、初めに署名、その後に暗号化 (Signing and Encryption order)を行わなければならない (MUST)。すべてのJWE暗号化方法は、完全性チェックを実施することに注意。


 TOC 

4.1.  サポートアルゴリズム

サーバは、ディスカバリドキュメントで、サポートされている署名と暗号化アルゴリズムを通知する。アルゴリズム識別子は、JWA (Jones, M., “JSON Web Algorithms (JWA),” May 2012.) [JWA]に規定されている。関連する要素は以下のとおり:

userinfo_algs_supported
ユーザ情報エンドポイントによってサポートされているJWSとJWEの署名および暗号化アルゴリズム [JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2012.) のリストを含むJSON配列。
id_token_algs_supported
IDトークン用に認可サーバによってサポートされているJWSとJWEの署名および暗号化アルゴリズム[JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2012.) のリストを含むJSON配列。
request_object_algs_supported
OpenID要求オブジェクト (OpenID Request Object)用に認可サーバによってサポートされているJWSとJWEの署名および暗号化アルゴリズム[JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2012.) のリストを含むJSON配列。サーバは、HS256をサポートすべきである (SHOULD)。
token_endpoint_auth_algs_supported
private_key_jwtメソッド用にトークンエンドポイントによってサポートされているJWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.) [JWS] の署名アルゴリズム [JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2012.) のリストを含むJSON配列。サーバは、RS256をサポートすべきである (SHOULD)。

クライアントは、以下の登録パラメータを使用して署名および暗号化のために、必要なアルゴリズムを登録する:

require_signed_request_object
任意。認可サーバによってOpenID要求オブジェクトのために要求されるJWS署名アルゴリズム [JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2012.)。このアルゴリズムで署名されていない場合、このclient_idからのすべてのOpenID要求オブジェクトは拒否されなければならない (MUST)。サーバは、RS256をサポートすべきである (SHOULD)。
userinfo_signed_response_alg
任意。ユーザ情報応答のために要求されるJWS署名アルゴリズム[JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2012.)。これが指定されていた場合、応答はJWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT] シリアライゼーションされるだろう。
userinfo_encrypted_response_alg
任意。ユーザ情報応答のために要求されるJWE algアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms,” May 2012.)。これが署名との組み合わせで要求された場合、応答は、最初に署名、その後に暗号化 (Signing and Encryption order)をされなければならない (MUST)。これが指定されていた場合、応答はJWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT] シリアライゼーションされるだろう。
userinfo_encrypted_response_enc
任意。ユーザ情報応答のために要求されるJWE encアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms,” May 2012.)。"userinfo_encrypted_response_alg"が指定されている場合、この値のデフォルトはA128CBCである。
userinfo_encrypted_response_int
任意。ユーザ情報応答のために要求されるJWE intアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2012.)。"userinfo_encrypted_response_alg"が指定され、"userinfo_encrypted_response_enc"がAEADアルゴリズムでなかった場合、この値のデフォルトはHS256である。
id_token_signed_response_alg
任意。このclient_idに対し発行するIDトークンに要求されるJWS署名アルゴリズム[JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2012.)。指定されていない場合のデフォルトはRS256である。署名を検証するための公開鍵は、ディスカバリの時のjwk_url要素またはx509_url要素からドキュメントを取得することによって得られる。
id_token_encrypted_response_alg
任意。このclient_idに対し発行するIDトークンに要求されるJWE algアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2012.)。これが要求された場合、応答は暗号化の後に署名される。指定されていない場合、デフォルトでは暗号化しない。
id_token_encrypted_response_enc
任意。このclient_idに対し発行するIDトークンに要求されるJWE encアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2012.)。"id_token_encrypted_response_alg"が指定されている場合、この値のデフォルトはA128CBCである。
id_token_encrypted_response_int
任意。このclient_idに対し発行するIDトークンに要求されるJWE intアルゴリズム[JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2012.)。"id_token_encrypted_response_alg"が指定され、"id_token_encrypted_response_enc"がAEADアルゴリズムでなかった場合、この値のデフォルトはHS256である。

 TOC 

4.2.  鍵

サーバは、ディスカバリドキュメントで、サポートされている署名と暗号化アルゴリズムを通知する。関連する要素は以下のとおり:

プロバイダは、以下の要素でディスカバリを通じて公開鍵を提供する:

jwk_url
JWTの署名で用いるサーバの署名鍵を含むOPのJSON Web Key (Jones, M., “JSON Web Key (JWK),” May 2012.) [JWK]ドキュメントのURL。x509_encryption_urlあるいはjwk_encryption_urlが省略された場合、サーバへのJWTを暗号化するのにクライアントによって用いられるかもしれない (MAY)。しかし、それは推奨しない。独立した暗号化鍵が使用されるべきである (SHOULD)。
jwk_encryption_url
サーバに対するJWTの暗号化のためにクライアントによって用いられるサーバの暗号化鍵を含むOPのJSON Web Key (Jones, M., “JSON Web Key (JWK),” May 2012.) [JWK]ドキュメントのURL。省略された場合、jwk_urlのURLと同じ値を用いる。
x509_url
JWTに署名するためにサーバによって使用されているPEM形式のOPのX.509証明書のURL。x509_encryption_urlが省略された場合、サーバへのJWTをJWE暗号化するのにクライアントによって用いられるかもしれない (MAY)。参照された証明書は、RFC 2459 (Housley, R., Ford, W., Polk, T., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and CRL Profile,” January 1999.) [RFC2459] によって規定されているように使用目的に対し有効であるべきである (SHOULD)。
x509_encryption_url
サーバに対するJWTの暗号化のためにクライアントによって用いられるサーバの暗号化鍵を含むPEM形式のOPのX.509証明書のURL。省略された場合、x509_urlのURLと同じ値を代わりに用いる。参照された証明書は、RFC 2459 (Housley, R., Ford, W., Polk, T., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and CRL Profile,” January 1999.) [RFC2459] によって規定されているように使用目的に対し有効であるべきである (SHOULD)。

クライアントは、以下の要素で登録を通じて公開鍵を提供する:

jwk_url
任意。要求オブジェクトの署名に用いる、クライアントのJSON Web Key (Jones, M., “JSON Web Key (JWK),” May 2012.) [JWK]ドキュメントのURL。jwk_encryption_urlが省略された場合、クライアントへのJWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT]を暗号化するのにサーバによって用いられるかもしれない。
jwk_encryption_url
任意。クライアントのJSON Web Key (Jones, M., “JSON Web Key (JWK),” May 2012.) [JWK]のURL。応答オブジェクトを暗号化するためにサーバによって用いられる。
x509_url
任意。クライアントのPEM形式のX.509証明書または証明書チェーンのURL。要求オブジェクトに署名するためにクライアントによって使用される。x509_encryption_urlが省略された場合、クライアントに対するJWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT]の暗号化のためにも用いられる。参照された証明書は、RFC 2459 (Housley, R., Ford, W., Polk, T., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and CRL Profile,” January 1999.) [RFC2459] によって規定されているように使用目的に対し有効であるべきである (SHOULD)。
x509_encryption_url
任意。クライアントに対するJWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT]の暗号化のために用いられる、クライアントのPEM形式のX.509証明書または証明書チェーンのURL。参照された証明書は、RFC 2459 (Housley, R., Ford, W., Polk, T., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and CRL Profile,” January 1999.) [RFC2459] によって規定されているように使用目的に対し有効であるべきである (SHOULD)。

鍵がX.509とJWKの両方の形式で指定されている場合、それらは同じ鍵でなければならない (MUST)。

楕円曲線署名および鍵共有のようなアルゴリズムは、セキュリティのため、署名と暗号化用に​​別のキーが必要となる。RSAでは、単一の鍵が、両方のために使用されるかもしれない (MAY) が、分離するのが良い習慣である。


 TOC 

4.3.  署名

署名実施者は、4.1節 (Supported Algorithms)の受信者のサポートアルゴリズムに基づいて署名アルゴリズムを選択しなければならない (MUST)。

非対称署名
RSAまたはECDSA署名を用いる場合、JWSヘッダのalgクレームは、JSON Web Algorithms (Jones, M., “JSON Web Algorithms (JWA),” May 2012.) [JWA]に定義されている適切なアルゴリズムを設定しなければならない (MUST)。秘密鍵は、4.2節 (Keys)で提供される公開署名鍵と関連付けられなければならない (MUST)。参照されているJWKドキュメントに鍵が複数ある場合、JWSヘッダでkidが指定されていなければならない (MUST)。参照されている証明書の場所に複数の証明書がある場合、JWSヘッダでx5tが指定されていなければならない (MUST)。各々の鍵の鍵使用目的は、署名をサポートしなければならない (MUST)。
対称署名
HMAC署名を用いる場合、JWSヘッダのalgクレームは、JSON Web Algorithms (Jones, M., “JSON Web Algorithms (JWA),” May 2012.) [JWA]に定義されている適切なアルゴリズムを設定しなければならない (MUST)。クライアントとサーバは、アウトオブバンドで共有秘密鍵を確立しなければならない (MUST)。

 TOC 

4.4.  暗号化

暗号化実施者は、4.1節 (Supported Algorithms)の受信者のサポートアルゴリズムに基づいて暗号化アルゴリズムを選択しなければならない (MUST)。全てのJWTは、発行元の検証を可能とするために、暗号化の前に署名されなければならない (MUST)。

非対称暗号化RSA
関連する鍵を取得するために4.2節 (Keys)で登録／ディスカバリされたリンクを用いる。jwk_encryption_urlまたはx509_encryption_urlが提供されていた場合、そのリンクを使用しなければならない (MUST)。参照されているJWKドキュメントに鍵が複数ある場合、JWEヘッダでkidが指定されていなければならない (MUST)。参照されている証明書の場所に複数の証明書がある場合、JWSヘッダでx5tが指定されていなければならない (MUST)。署名後のJWTを暗号化するのに用いるランダムなコンテンツマスター鍵を鍵ラップするために、サポートされているRSA鍵ラップアルゴリズムを使用する。各々の鍵の鍵使用目的は、暗号化を含んでいなければならない (MUST)。
非対称暗号化楕円曲線
JWEヘッダのepk要素のための一時的な楕円曲線公開鍵を作成する。関連する鍵を取得するために4.2節 (Keys)で登録／ディスカバリされたリンクを用いる。jwk_encryption_urlまたはx509_encryption_urlが提供されていた場合、そのリンクを使用しなければならない (MUST)。参照されているJWKドキュメントに鍵が複数ある場合、JWEヘッダでkidが指定されていなければならない (MUST)。参照されている証明書の場所に複数の証明書がある場合、JWSヘッダでx5tが指定されていなければならない (MUST)。署名後のJWTを暗号化するのに用いるランダムなコンテンツマスター鍵を鍵ラップするために、ECDH-ESアルゴリズムを使用する。各々の鍵の鍵使用目的は、暗号化をサポートしなければならない (MUST)。
対称暗号化
署名後のJWTを暗号化するのに用いるランダムなコンテンツマスター鍵を鍵ラップするために、左省略されたclient_secretのSHA-256ハッシュを使用する。

 TOC 

5.  確認


 TOC 

5.1.  認可要求の検証

認可要求の検証は、主に次の2つのステップからなる: (1) requestの値、またはrequest_uriのコンテンツの暗号化と署名の検証、(2) パラメータの検証。OpenID要求オブジェクトがrequestパラメータ、または参照としてrequest_uriパラメータで送信された場合、要求オブジェクトは、JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT]の中にエンコードされた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]として検証しなければならない (MUST)。


 TOC 

5.1.1.  暗号化された要求オブジェクト

認可サーバがディスカバリドキュメントのrequest_object_algs_supported要素でJWE暗号化アルゴリズムを通知した場合、それらがクライアントによってJWTの暗号化に使用される。

認可サーバは、JSON Web Encryption (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.) [JWE]仕様に従って、JWTをデコードしなければならない (MUST)。結果は、OpenID要求オブジェクトまたはJWS署名されたJWTのいずれであってもよい (MAY)。後者のケースでは、署名された要求オブジェクト (Signed Request Object)に定義されているとおりの署名検証を行わなければならない (MUST)。

復号エラーがある場合、認可サーバはエラーを返さなければならない (MUST)。


 TOC 

5.1.2.  署名された要求オブジェクト

署名検証を実施するために、JWSヘッダのalgパラメータは、クライアント登録 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2012.) [OpenID.Registration]の際に設定されたrequire_signed_request_objectの値か、他の手段で事前に登録された値と合致しなければならない (MUST)。

JSON Web Signature (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.) [JWS]仕様に従って、client_idとアルゴリズムに対応して登録された鍵に対して、署名は検証されなければならない。

署名検証エラーがある場合、認可サーバは、エラー認可応答を返さなければならない (MUST)。


 TOC 

5.1.3.  パラメータの検証

認可サーバは、OpenID要求オブジェクトおよびOAuth 2.0の認可要求パラメータから認可要求メッセージを構築しなければならない (MUST)。同一のパラメータが、OpenID要求オブジェクトおよびOAuth認可要求パラメータの両方に存在する場合、パラメータの値は正確に一致しなければならない (MUST)。 この認可要求メッセージを使用して、認可サーバは、以下の要求検証手順を実行する:

  1. 認可サーバは、サポートされていないクレームを除くすべてのパラメータを理解しなければならない (MUST)。サポートされていないクレームを除いて、理解していないパラメータがある場合は、エラー応答を返さなければならない (MUST)。
  2. 認可サーバは、OAuth 2.0に従って、全てのOAuth 2.0の変数を検証しなければならない (MUST)。
  3. 認可サーバは、必要なすべてのパラメータが存在していることを確認しなければならない (MUST)。
  4. id_token要素のメンバとしてuser_idクレームに特定の値が要求された場合、そのユーザが認可サーバとの間でアクティブなセッションを持っていれば、認可サーバは成功応答のみを送信しなければならない (MUST)。ユーザが認可サーバとの間でアクティブなセッションを持っていたとしても、認可サーバは、異なるユーザのIDトークンあるいはアクセストークンを返してはならない (MUST not)。
  5. acrクレームが、id_tokenメンバの必須クレームとしてパラメータ値が指定されている場合、認可サーバは、要求値のいずれかに一致するacrクレーム値を返さなければならない (MUST)。認可サーバは、要件を満たすために追加要素でユーザに再認証を求めてもよい (MAY)。これが必須のクレームであり、かつ要件を満たすことができない場合、認可サーバはエラーを返さなければならない (MUST)。クライアントは、acrクレーム要求に「"optional": true」を含むことによって、このクレームを任意としてもよい (MAY)。クレームが任意、かつユーザへの要求値が提供できない場合、認可サーバは、acrクレームの値としてセッションの現在のacrを返すべきである (SHOULD)。クレームが任意の場合、認可サーバはその応答に、このクレームを提供する必要はない。

認可サーバは、なんらかのエラーに遭遇した場合、エラー応答を返さなければならない (MUST)。


 TOC 

5.2.  IDトークンの検証

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

  1. クライアントが登録時に、id_token_encrypted_response_algパラメータを提供していた場合、登録時に指定した鍵ペアを用いて、id_token (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.) [JWE]を復号する。
  2. クライアントはaud (audience) クレーム内のclient_idが、iss (issuer)クレームの値によって識別される発行元が登録したものであることを検証する必要がある(MUST)。aud (audience)の値が発行元に対して有効でない場合は、IDトークンを拒絶しなければならない(MUST)。 (※訳注：client_idはIDトークンの発行元であるOpenIDプロバイダが個々のクライアントに対して払い出すため、クライアントが現在IDトークンをやり取りしているOpenIDプロバイダにとってのクライアント自身を表すclient_idが想定通りかどうかを検証するという意だと思われる。)
  3. id_tokenが、クライアントとトークンエンドポイント間の直接通信を介して受信された場合、トークンの署名確認の代わりに、TLSサーバの検証を発行元検証のために使用してもよい (MAY)。クライアントは、JWTヘッダのalgパラメータに指定されたアルゴリズムを用いて、JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.) [JWS]に従って他のIDトークンの全ての署名を検証しなければならない (MUST)。
  4. alg値はRS256のデフォルトまたは登録時にid_token_signed_response_algsパラメータでクライアントによって送信されたアルゴリズムであるべきである (SHOULD)。
  5. JWTヘッダのalgパラメータが、HS256、HS384、HS512のいずれかであった場合、aud (audience)クレームに含まれているclient_idに対応するclient_secretは、署名検証用の鍵として使用される。
  6. その他の署名アルゴリズムでは、クライアントは、発行元によるディスカバリの中で提供される署名キーを使用しなければならない (MUST)。発行元は、iss (issuer)クレームの値と正確に一致しなければならない。
  7. 現在の時刻は exp クレームの値より小さくなければならない。
  8. iat クレームは、攻撃対策のために保存しているナンスの保存時間の上限を制限するために、現在時刻からあまりにも大きく乖離しているときはトークンを拒絶したいといった場合に用いられることがある。許容範囲は、クライアント次第である。
  9. ナンス値が認可要求で送信されていた場合、nonceクレームの値が存在している、かつ認可要求で送信されたものと同じ値であることを確認するためにチェックしなければならない (MUST)。クライアントはリプレイ攻撃のためにnonce値をチェックすべきである (SHOULD)。リプレイ攻撃を検出するための詳細な方法は、クライアント固有のものである。
  10. acrクレームが要求された場合、クライアントは、主張されているクレームの値が適切であることを確認すべきである(SHOULD)。acrクレームの値の意味と処理は、この仕様の範囲外である。
  11. auth_timeクレームが要求されていた場合、クライアントは、最後のユーザ認証から経過した時間があまりに大きいと判断した場合、値の検証と再認証の要求を行うべきである(SHOULD)。

 TOC 

5.3.  ユーザ情報応答の検証

ユーザ情報応答の妥当性を検証するために、クライアントは以下を行わなければならない (MUST)。

  1. クライアントが登録時に、userinfo_encrypted_response_algパラメータを提供していた場合、登録時に指定した鍵ペアを用いて、id_token (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.) [JWE]を復号する。
  2. 応答が署名されていた場合、クライアントは、JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.) [JWS]に従って署名を検証すべきである (SHOULD)。
  3. 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サーバ証明書のチェックを通じて、応答しているOPが本当に意図しているOPかどうかをチェックする。

 TOC 

5.4.  アクセストークンの検証

インプリシットフローでIDトークンと共に発行されたアクセストークンの妥当性を検証するために、クライアントは以下を行うべきである (SHOULD)。

  1. IDトークンのJWSヘッダのalgパラメータで使用されるハッシュと同じ長さのSHA-2ファミリーのハッシュアルゴリズムを用いてaccess_tokenをハッシュする。
  2. ハッシュの左半分を取り、それをbase64urlエンコーディングする。
  3. at_hashがIDトークンに存在する場合、その値は、前段の手順で生成された値と一致しなければならない (MUST)。

 TOC 

5.5.  コードの検証

インプリシットフローでIDトークンと共に発行されたcodeの妥当性を検証するために、クライアントは以下を行うべきである (SHOULD)。

  1. IDトークンのJWSヘッダのalgパラメータで使用されるハッシュと同じ長さのSHA-2ファミリーのハッシュアルゴリズムを用いてcodeをハッシュする。
  2. ハッシュの左半分を取り、それをbase64urlエンコーディングする。
  3. c_hashがIDトークンに存在する場合、その値は、前段の手順で生成された値と一致しなければならない (MUST)。

 TOC 

6.  文字列操作

いくつかのOpenID Connectメッセージを処理すると、既知の値とメッセージの値を比較する必要がある。たとえば、ユーザ情報エンドポイントによって返されたクレームの名前は、user_id のような特定のクレームの名前と比較されることがある。しかし、Unicode文字列を比較すると、重要なセキュリティ上の影響がある。

そのため、JSON文字列や他のUnicode文字列の比較は以下のように実施しなければならない (MUST):

  1. Unicodeコードポイントの配列を生成するエスケープが適用されているJSONを削除する。
  2. Unicode Normalization (Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” 09 2009.) [USA15] は、JSON文字列とその比較対象の文字列のいずれにも適用されない (MUST NOT)。
  3. 二つの文字列の比較は、Unicodeコードポイントとしての等価比較を行わなければならない (MUST)。

いくつかの場所で、この仕様は、文字列のスペース区切りリストを使用します。 全てのそのようなケースで、ASCII空白文字(0x20)のみが、この目的のために使用されるかもしれません (MAY)。


 TOC 

7.  関連仕様

この仕様は、抽象的な仕様である。それは、実際に使用するプロトコルにバインドする必要がある。プロトコルバインディングの一例は、以下の通り:

以下の関連OpenID Connect仕様は、追加の機能を提供するために、任意 (OPTIONALLY) で当仕様と組み合わせて使用​​されるかもしれない (MAY):


 TOC 

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

OAuth 2.0 Threat Model and Security Considerations (Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” May 2012.) [OAuth.Threat]は、当仕様にも適用される脅威と対策の広範なリストを提供している。加えて、当仕様では、以下の追加の対策を提供する。


 TOC 

8.1.  要求露見

適切な措置が取られていない場合、セキュリティとプライバシー上の脅威を引き起こす攻撃者に要求が露見されるかもしれない。

[OAuth.Threat] (Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” May 2012.)の5.1.1節の記載に加えて、当標準では、requestまたはrequest_uriパラメータを用いて要求のエンドツーエンドの機密性を提供する方法を提供している。これらのパラメータでは、requestの中身が適切な鍵と暗号を用いて暗号化されたJWTである。これは間接要求の場合、侵入されたユーザエージェントに対しても有効に動作する。


 TOC 

8.2.  サーバなりすまし

悪意のあるサーバは、様々な手段を使用して、正当なサーバになりすますこともありうる。このような攻撃を検出するために、クライアントはサーバを認証する必要がある。

[OAuth.Threat] (Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” May 2012.)の5.1.2節の記載に加えて、当標準では、適切な鍵と暗号を用いて署名または暗号化されたJWTのいずれかを用いて、サーバを認証する方法を提供している。


 TOC 

8.3.  トークン製造／変更

攻撃者は偽のトークンを生成したり、既存の解析可能なトークンの内容（例えば、認証や属性文など）を変更したりするかもしれない。そして、RPにクライアントへの不適切なアクセス権を付与させることになる。たとえば、攻撃者は有効期間を延長する解析可能なトークンを修正するかもしれないし、クライアントは見ることができるべきではない情報へのアクセスが可能となるように解析可能なトークンを変更するかもしれない。

この攻撃を軽減するには、2つの方法がある:

  1. トークンはOPによってデジタル署名をすることができる。リライイングパーティは、それが正当なOPによって発行されたことを検証するためにデジタル署名をチェックすべきである (SHOULD)。
  2. トークンは、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.)のような保護チャネル上で送信することができる。悪意のある攻撃からトークンの完全性を保護するために、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]に従って、サーバは認証されなければならない (MUST)。当仕様では、トークンは常にTLS/SSLによる保護チャネル上で送信される。しかし、この措置はサードパーティ攻撃者にのみ適用され、クライアントが攻撃者である場合には適用されないことに注意すること。

 TOC 

8.4.  サーバ応答露見

サーバ応答は、機微なクライアント情報を含む認証と属性文が含まれることがある。応答内容の露見は、クライアントが他の種類の攻撃に対して脆弱になる可能性がある。

サーバ応答の露見は、以下の2つの方法で軽減することができる:

  1. code応答タイプを使用する。応答は、クライアントがclient_idとclient_secretによって認証された、TLS/SSLによる保護チャネル上で送信される。
  2. 他の応答タイプでは、署名付き応答は、適切な鍵と暗号を用いて暗号化されたJWTとして、クライアントの公開鍵または共有秘密鍵を用いて暗号化することができる。

 TOC 

8.5.  サーバ応答否認

適切な機構が含まれていない場合、応答はサーバによって否認されるかもしれません。例えば、サーバが応答にデジタル署名をしていない場合、サーバは自身のサービスによって生成されたものではないと主張することができる。

この脅威を軽減するために、否認防止をサポートした鍵を使用して、応答はサーバによってデジタル署名されるかもしれません。クライアントは、それが正当なサーバによって発行され、完全性が損なわれていないことを検証するためにデジタル署名をチェックすべきである (SHOULD)。


 TOC 

8.6.  要求否認

侵入されていたり悪意があるクライアントは、誤った相手に要求を送信する可能性があるため、ベアラトークンのみで認証されたクライアントは、いかなるトランザクションも否認することができる。

この脅威を軽減するために、否認防止をサポートした鍵を使用して、サーバは、クライアントにデジタル署名された要求を必須とするかもしれません (MAY)。サーバは、それが正当なクライアントによって発行され、完全性が損なわれていたことを検証するためにデジタル署名をチェックすべきである (SHOULD)。


 TOC 

8.7.  アクセストークンリダイレクト

攻撃者はあるリソースへのアクセス権を得るために、他のリソース用に生成されたアクセストークンを使用する。

この脅威を軽減するために、アクセストークンは、聴衆とスコープを制限するべきである。それを実装する1つの方法は、どの聴衆向けに生成されたかを識別するために、リソースの識別子を含めることである。リソースは、自身の識別子がトークンの聴衆として含まれているかを受信したトークンに対して検証する。


 TOC 

8.8.  トークン再利用

攻撃者は、意図されたリソースで一度使用されている認可コードのようなワンタイム利用のトークンを使用しようと試みる。

この脅威を軽減するために、トークンはタイムスタンプと短い有効期限を含むべきである (SHOULD)。リライイングパーティは、トークンが現在有効であることを確認するためにタイムスタンプと有効期限の値をチェックする。

その他の方法として、サーバは、トークンの使用状態を記録し、各要求のステータスを確認してもよい。


 TOC 

8.9.  認可コードの盗聴・漏洩 (セカンダリ認証子キャプチャ)

ユーザエージェントがマルウェアに感染している場合、OAuth SCの4.4.1.1に定義されている攻撃パターンに加え、TLSセッションが終端されるユーザエージェントでキャプチャされる可能性がある。

しかし、クライアント認証または応答の暗号化のいずれかを行っている限り、キャプチャしても有用ではない。


 TOC 

8.10.  トークン置換

ユーザは、トークンエンドポイントとクライアント間の通信チャネルを破壊することで、より権限のあるユーザになりすまそうと試みるかもしれない。例えば、より権限のあるユーザの代理として送信された認可付与であるとトークンエンドポイントに確信させるために、メッセージの並び替えを行う。

トークンと要求の両方がパケットの悪意のある並べ替えの検出と禁止を可能とするTLSによって保護されているとおり、トークン要求への応答は、HTTPのメッセージの順序によって対応する要求に関連付けられる。


 TOC 

8.11.  タイミング攻撃

タイミング攻撃は、復号の成功と署名メッセージの検証の失敗によって取得できるコードパス内の経過時間の差を通じて、不要に大量の情報の取得を攻撃者に可能にする攻撃である。これは、使用されている暗号の有効な鍵長を低減するために使用することができる。

実装はこの攻撃を回避するために、エラーを発見した時点で検証プロセスを終了すべきではなく、全てのオクテットの処理が完了するまで実行を継続すべきである。


 TOC 

8.12.  他の暗号化関連の攻撃

暗号化と署名／完全性チェックの使用方法に応じて可能となる、様々な暗号関連の攻撃がある。実装者は、JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.) [JWT]仕様のセキュリティに関する考慮事項や、これらの仕様で識別されている脆弱性を回避するために参照されている仕様を調査するべきである。


 TOC 

8.13.  署名および暗号化の順序

暗号化されたテキストに対する署名は、多くの国で有効とは見なされない。従って、完全性と否認防止のため、当仕様では、プレーンテキストのJSONクレームへの署名が必須である。


 TOC 

8.14.  発行元識別子 (Issuer Identifier)

OpenID Connectは、ホストとポートの組み合わせごとに複数の発行元をサポートしている。

ディスカバリによって返された発行元は、IDトークンのiss値と正確に一致しなければならない (MUST)。

発行元はホスト毎に一つだけ使用することが推奨される (RECOMMENDED)。Simple Web Discoveryは、ユーザ識別子の一部として、任意のURIのパスコンポーネントを取り扱う。


 TOC 

8.15.  TLSの要件

実装は、TLSをサポートしなければならない (MUST)。どのバージョンを実装すべきかは時間の経過とともに変化し、実装時の普及度や既知のセキュリティ脆弱性に依存している。この記事の記述時点では、TLS version 1.2 [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.)が最新バージョンであるが、実際の普及度は非常に低く、実装ツールキットですぐの利用はできないかもしれない。TLS version 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.)は最も広く普及していて、広範な相互運用性が確保できるだろう。

情報露見や改竄から保護するために、機密性と完全性保護を提供する暗号スイートと共にTLSを使用することによって、機密性は保護されなければならない (MUST)。


 TOC 

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

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

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

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

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


 TOC 

9.1.  リフレッシュトークンおよびアクセストークンの有効期間

アクセストークンの付与の、認可サーバによる取り消しはできない。アクセストークンの付与の有効期間は、一回限りの使用または非常に短い寿命に保たれるべきである (SHOULD)。

ユーザ情報エンドポイントまたは他の保護リソースへのアクセスが必要な場合、リフレッシュトークンを使用するべきである。クライアントは、トークンエンドポイントで、リフレッシュトークンをリソースへのアクセスに使用できる短寿命なアクセストークンに交換するかもしれない。

認可サーバは、認可時にユーザが長期の付与かどうかを明確に識別できるようにするべきである (SHOULD)。

認可サーバは、クライアントに付与されたリフレッシュトークンを取り消す、ユーザのための機構を提供しなければならない (MUST)。


 TOC 

10.  IANAに関する考慮事項

この文書ではIANAへの要求はない。


 TOC 

11.  文献


 TOC 

11.1. 規定文献

[E.164] International Telecommunication Union, “E.164 : The international public telecommunication numbering plan,” 2010.
[ISO29115] International Telecommunication Union and International Organization for Standardization, “ITU-T Recommendation X.1254 | ISO/IEC DIS 29115 -- Information technology - Security techniques - Entity authentication assurance framework,” ISO/IEC 29115, November 2011.
[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.
[JWA] Jones, M., “JSON Web Algorithms (JWA),” May 2012.
[JWE] Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.
[JWK] Jones, M., “JSON Web Key (JWK),” 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.
[LoA.Registry] Johansson, L., “An IANA registry for SAML 2.0 Level of Assurance Context Classes,” February 2012.
[OAuth.Assertions] Mortimore, C., Ed., Campbell, B., Jones, M., and Y. Goland, “OAuth 2.0 Assertion Profile,” May 2012.
[OAuth.Bearer] Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” June 2012.
[OAuth.JWT] Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0,” May 2012.
[OAuth.Responses] de Medeiros, B., Scurtescu, M., and P. Tarjan, “OAuth 2.0 Multiple Response Type Encoding Practices,” May 2012.
[OAuth.Threat] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” May 2012.
[OAuth2.0] Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.
[OpenID.Basic] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Profile 1.0,” June 2012.
[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” May 2012.
[OpenID.Implicit] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Implicit Client Profile 1.0,” June 2012.
[OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2012.
[OpenID.Session] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Session Management 1.0,” May 2012.
[OpenID.Standard] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” June 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).
[RFC2459] Housley, R., Ford, W., Polk, T., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and CRL Profile,” RFC 2459, January 1999 (TXT).
[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).
[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).
[USA15] Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” Unicode Standard Annex 15, 09 2009.
[zoneinfo] Public Domain, “The tz database,” June 2011.

 TOC 

11.2. 参考文献

[OpenID.2.0] specs@openid.net, “OpenID Authentication 2.0,” December 2007 (TXT, HTML).
[OpenID.PAPE] Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider Authentication Policy Extension 1.0,” December 2008 (TXT, HTML).

 TOC 

Appendix A.  謝辞

As a successor version of OpenID, this specification heavily relies on OpenID Authentication 2.0 (specs@openid.net, “OpenID Authentication 2.0,” December 2007.) [OpenID.2.0]. Please refer to Appendix C of OpenID Authentication 2.0 for the full list of the contributors for that specification.

This specification is largely compliant with OAuth 2.0 draft 20. Please refer to the OAuth 2.0 specification for the list of contributors.

In addition, the OpenID Community would like to thank the following people for the work they have done in the drafting and editing of this specification.

Anthony Nadalin (tonynad@microsoft.com), Microsoft

Andreas Akre Solberg (andreas.solberg@uninett.no), UNINET

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

Casper Biering (cb@peercraft.com), Peercraft

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

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

Johnny Bufu (jbufu@janrain.com), Janrain

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

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


 TOC 

Appendix B.  通知

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 C.  文書履歴

[[ To be removed from the final specification ]]

-12

  • Added preferred_username claim under profile scope
  • Added section on claim stability
  • Changed request_url to request_uri in Section 2.1.2.1

-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
  • Removed optional claim request parameter and added essential claim request parameter, per issue #577. We changed terminology from "optional" to "voluntary" and "required" to "essential" to better match privacy policy requirements.
  • Removed Check ID Endpoint, per issue #570
  • Added PAPE Reference to the Informative References, per issue #574
  • Added "id_token" response type as being MTI for OpenID Providers
  • 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
  • Changed default ID Token signing algorithm to RS256, per issue #571
  • Changed default OpenID Request Object signing algorithm to RS256, per issue #571
  • 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
  • Listed author of ISO29115 as "International Telecommunication Union and International Organization for Standardization", per issue #589
  • Added method of calculating signing and encryption keys for symmetric algorithms, per issue #578
  • Use standards track versions of JSON Web Token (JWT) and OAuth JWT Bearer Token Profiles specs (draft-ietf-oauth-json-web-token and draft-ietf-oauth-oauth-jwt-bearer)

-09

  • Added error interaction_required and removed user_mismatched, per issue #523
  • Changed invalid_request_redirect_uri to invalid_redirect_uri, per issue #553
  • Removed "embedded" display type, since its semantics were not well defined, per issue #514
  • Added optional id_token to authorization request parameters, per issue #535
  • Now requested claims add to those requested with scope values, rather than replacing them, per issue #547
  • Make changes to allow path in the issuer_identifier, per issue #513
  • Make changes to userinfo_encrypted_response_* and id_token_encrypted_response_* to match registration
  • Add hash and hash check of access_token and code to id_token, per issue #510
  • Updated Notices
  • Updated References

-08

  • Updated the version number and date
  • Fixed #551 Sec 2.1.2.1 to clarify the OpenID Request Object MUST NOT include "request" nor "request_uri"
  • Fixed #540 Sec 2.2.3 id_token MUST NOT be returned for grant_type=refresh
  • Fixed #542 Sec 2.1.2.1 required fields for request object to match Standard
  • Fixed Sec 2.2.1 to refer to client_secret value rather than Client Password
  • Fixed Sec 4.2, 4.3, 4.4 to replace requirement for using x.509 keyuse extension
  • Added reference to RFC2459
  • Fixed Sec 2.1.1.1.1 added rational for sector_identifier_url from registration
  • Fixed Sec 2.1.1.1.1 added examples of other ways to generate PPID
  • Added iat as a required claim in ID Tokens
  • Enumerated claims requested by the "profile" scope value
  • Fixed Sec 2.1.2 response_type references standard rather than repeating values that are binding specific
  • Fixed Sec 2.1.2 remove outdated language about openid scope requiring id_token to be returned with token response_type

-07

  • Removed definition and usage for assertion and claim object
  • Consistent use of End-User
  • Removed 'format' from userinfo and id_token object of the OpenID Request Object
  • email scope allows access to the 'verified' claim
  • ID Token 'audience' claim MUST be client_id
  • Rename artifact to authorization code
  • Removed language pertaining to custom userinfo schemas
  • Check ID Endpoint returns only JSON
  • Updated Check ID Response verification
  • Remove 'audience' parameter from Authorization Request
  • Moved display=none to prompt=none
  • Added additional display parameter options
  • Moved IANA considerations to Standard
  • Added error codes to Authorization Endpoint
  • Added client authentication section regarding various supported client authentication schemes and their validation. This includes symmetric and asymmetric authentication, JWT Bearer Token Profiles, OAuth 2.0 Assertion Profile
  • Updated Check ID Response verification
  • Added 'auth_time' to ID Token
  • Added validation for request object encryption and signature
  • Added explanation for user_id type and calculating pairwise identifiers
  • Added steps for signature and validation and encryption and decryption
  • Added verification of issuer identifier
  • Redefined 'nonce' in Authorization Request. Changed to REQUIRED parameter.
  • Changed usage of the word "approval" to "consent"
  • Use RFC 6125 to verify TLS endpoints
  • ID Token MUST be JWT
  • Access Tokens should include an audience claim for the Resource Server
  • Updated Security Considerations
  • OpenID Request Object parameters takes precedence over the same parameters in the Authorization Request
  • Allow other gender strings in UserInfo schema
  • Changed UserInfo claim 'locale' to 'preferred_locales' and changed it to be a list of values
  • Changed UserInfo claim 'user_id' to REQUIRED. Added requirement to compare user_id from userinfo endpoint to id_token
  • RECOMMENDED E.164 format for UserInfo 'phone_number' claim
  • Changed UserInfo Error Response to augment and return OAuth 2.0 Bearer Token Error Response
  • Expanded section regarding UserInfo 'address' claim
  • Added Privacy considerations
  • Added rational for signing then encrypting added to security considerations
  • Added section about string comparison rules needed
  • The Authorization Server MUST understand all the request parameters except for the unsupported claims.
  • Make openid scope provide user_id from userinfo endpoint
  • Added explanation of select_account
  • Check ID Endpoint uses ID Token as Access Token according to Bearer Token spec
  • Clients MUST verify client_id in ID Token
  • Bumped version + date
  • Update John Bradley email and affiliation for Implementer's Draft
  • Removed invalid_authorization_code, invalid_id_token error codes
  • Section 2.3 client MUST NOT send encrypted JWT to the Check ID Endpoint
  • Section 2.1.2.1.2 Added user_id claim and moved iso29115 to claims element of id_token member
  • Defined Authentication Context, Authentication Context Class Reference (acr), replaced iso29115 with acr.
  • Corrected instances of x509_url_encryption to x509_encryption_url and jwk_url_encryption to jwk_encryption_url

-06

  • Changed section 3.1.4.1 to say the errors are returned as defined by the response type not always as query parameters. per ticket #174.
  • Bumped version + date.
  • Fixed section 3.3.3 to refer to errors in Bearer Token.
  • Fixed 3.1.3 to ref the other response types ticket #173.
  • Included reference to multiple response types.
  • Fixed 3.1.2.1 to indicate default Claims in id_token.
  • Fixed section 3.2.2 to reference the access token response from the token endpoint 4.1.4.
  • Fixed section 3.2.1 to include refresh tokens.
  • Fixed section 3.1.1 to be clear on JWT being the token format per ticket #171.

-05

  • Changed check_session to check_id.
  • schema=openid now required when requesting UserInfo.
  • Removed issued_to, since not well defined.
  • Removed display values popup, touch, and mobile, since not well defined.

-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 Inc.
Email:  breno@google.com
  
  Chuck Mortimore
  Salesforce
Email:  cmortimore@salesforce.com
  
  Edmund Jay
  Illumila
Email:  ejay@mgi1.com
投稿者 時刻:
ラベル: ,

0 件のコメント:

コメントを投稿

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