OpenID Connect Implicit Client Implementer's Guide 1.0 - draft 20

Abstract

OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである. このプロトコルは, Client が Authorization Server の認証結果に基づいて End-User のアイデンティティを検証することを可能にする. また同時に End-User の必要最低限のプロフィール情報を, 相互運用可能かつ RESTful な形で取得することも可能にする.

本ドキュメント OpenID Connect Implicit Client Implementer's Guide 1.0 は, OpenID Connect Core 1.0 仕様のサブセットであり, OAuth 2.0 Implicit Flowを利用して Webベースの Relying Party を実装する際に読みやすいように構成されている. 本ドキュメントは Core 仕様と重複したコンテンツを含んでいるが, それは実装者が本仕様を読むだけで OAuth Implicit Flow を利用した Relying Party を実装できるよう意図したものである.

OpenID Provider および Web ベース以外のアプリケーションの実装者は, Core 仕様を参照のこと.

Table of Contents

1.  Introduction
    1.1.  Requirements Notation and Conventions
    1.2.  Terminology
    1.3.  Overview
2.  Protocol Elements
    2.1.  Implicit Flow
        2.1.1.  Client Prepares Authentication Request
            2.1.1.1.  Request Parameters
        2.1.2.  Client Sends Request to Authorization Server
        2.1.3.  Authorization Server Authenticates End-User
        2.1.4.  Authorization Server Obtains End-User Consent/Authorization
        2.1.5.  Authorization Server Sends End-User Back to Client
            2.1.5.1.  End-User Grants Authorization
            2.1.5.2.  End-User Denies Authorization or Invalid Request
            2.1.5.3.  Redirect URI Fragment Handling
    2.2.  ID Token
        2.2.1.  ID Token Validation
        2.2.2.  Access Token Validation
    2.3.  UserInfo Endpoint
        2.3.1.  UserInfo Request
        2.3.2.  Successful UserInfo Response
        2.3.3.  UserInfo Error Response
    2.4.  Scope Values
    2.5.  Standard Claims
        2.5.1.  Address Claim
        2.5.2.  Claims Languages and Scripts
        2.5.3.  Claim Stability and Uniqueness
3.  Self-Issued OpenID Provider
    3.1.  Self-Issued OpenID Provider Discovery
    3.2.  Self-Issued OpenID Provider Registration
        3.2.1.  Providing Information with the "registration" Request Parameter
    3.3.  Self-Issued OpenID Provider Request
    3.4.  Self-Issued OpenID Provider Response
    3.5.  Self-Issued ID Token Validation
4.  Serializations
    4.1.  Query String Serialization
    4.2.  Form Serialization
5.  String Operations
6.  TLS Version
7.  Implementation Considerations
    7.1.  Discovery and Registration
8.  Security Considerations
    8.1.  TLS Requirements
9.  Privacy Considerations
    9.1.  Personally Identifiable Information
    9.2.  Data Access Monitoring
    9.3.  Correlation
10.  IANA Considerations
11.  References
    11.1.  Normative References
    11.2.  Informative References
    11.3.  翻訳プロジェクト
Appendix A.  Acknowledgements
Appendix B.  Notices
Appendix C.  Document History
Appendix D.  翻訳者
§  Authors' Addresses

1.  Introduction

本ドキュメント OpenID Connect Implicit Client Implementer's Guide 1.0 は, OpenID Connect Core 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” August 2015.) [OpenID.Core] 仕様のサブセットであり, OAuth 2.0 [RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) Implicit Flowを利用して Webベースの Relying Party を実装する際に読みやすいように構成されている. 本ドキュメントは Core 仕様と重複したコンテンツを含んでいるが, それは実装者が本ドキュメントを読むだけで OAuth Implicit Flow を利用した Relying Party を実装できるよう意図したものである. 本実装者ガイドと OpenID Connect Core 仕様の間に齟齬がある場合は, Core 仕様を優先する.

OAuth authorization_code grant typeを利用する Webベース Relying Partyを実装する場合には, OpenID Connect Basic Client Implementer's Guide 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Implementer's Guide 1.0,” August 2015.) [OpenID.Basic] を参照のこと. OpenID Provider および Web ベース以外のアプリケーションの実装者は, Core 仕様を参照のこと. 本ガイドは OpenID Provider および Web ベース以外のアプリケーションに関する Implementation Considerations および Security Considerations を省略している.

OpenID Connect のベースとなる OAuth 2.0 Authorization Framework (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] と OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] は, 3rd-party アプリケーションが HTTP リソースへの限定的アクセス権を取得および行使するための全般的フレームワークを提供している. これらはリソースアクセスのための Access Token を取得および行使する方法は定義するが, アイデンティティ情報を提供するための標準的手段は定義しない. とりわけ, OAuth 2.0 のプロファイリングを行わずに End-User の認証に必要な情報を提供することは不可能である. 本ドキュメント読者は上記2つの仕様を理解していることが期待される.

OpenID Connect は OAuth 2.0 認可プロセスを拡張し, 認証目的で利用できるようにする. 本拡張を利用する場合, Client は openid scope を指定して Authorization Request を送信する. 本拡張を利用した Authorization Request は, Authentication Request と呼ばれる.

認証結果は ID Token (Section 2.2 (ID Token) 参照) と呼ばれる JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.) [JWT] として返される. OpenID Connect をサポートする OAuth 2.0 Authentication Server は, OpenID Provider (OP) とも呼ばれる. OpenID Connect を利用する OAuth 2.0 Client は Relying Party (RP) とも呼ばれる.

本ドキュメントでは, Relying Party は Authorization Endpoint, Token Endpoint 等を含む OpenID Provider の設定情報を既に得ているものとする. これらの情報は通常 OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” August 2015.) [OpenID.Discovery] にある Discovery を通じて得られるが, その他の手段で得られることもある.

また同様に, Relying Party は OpenID Provider 利用に必要なクレデンシャルを取得し, OP 利用に必要な情報を登録しているものとする. これの処理は通常 OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” August 2015.) [OpenID.Registration] にある Dynamic Registration を通じて行われるが, その他の手段で行われることもある.

1.1.  Requirements Notation and Conventions

本ドキュメント中の "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.) の定める通りである.

本ドキュメントの .txt バージョンでは, 表記そのままで利用される値についてはクオートで囲んでいる. このような値をプロトコルメッセージ中で用いる場合, クオートを含めてはならない (MUST NOT). HTML バージョンではクオートで囲う代わりに this fixed-width font を用いる.

JSON Web Signature (JWS) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS] を用いる場合, シリアライゼーションには JWS Compact Serialization を用いる. JWS JSON Serialization は利用しない.

本ドキュメント中の RFC 2119 に定義されるキーワードが OpenID Provider の挙動に言及する場合, それはあくまで Client 実装者が OpenID Provider の挙動を理解しやすいように用いられているに過ぎない.

1.2.  Terminology

本ドキュメントでは, OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] で定義された "Access Token", "Authorization Code", "Authorization Endpoint", "Authorization Grant", "Authorization Server", "Client", "Client Identifier", "Client Secret", "Protected Resource", "Redirection URI", "Refresh Token", "Resource Owner", "Resource Server", "Response Type", および "Token Endpoint" JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.) [JWT] で定義された "Claim Name", "Claim Value", "JSON Web Token (JWT)" および "JWT Claims Set", JSON Web Signature (JWS) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS] で定義された "Header Parameter" および "JOSE Header", RFC 7230 (Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing,” June 2014.) [RFC7230] で定義された "User Agent" という用語を用いる.

本ドキュメントはその他に以下の用語を用いる.

Authentication

提示された Identity と実際の Entity が紐づいているという十分な確信を得るためのプロセス.

Authentication Request

OpenID Connect が定める拡張パラメータおよびスコープを利用して, Authorization Server に End-User の認証を要求する OAuth 2.0 Authorization Request. このとき Authorization Server は OpenID Connect Provider, Client は OpenID Connect Relying Party となる.

Claim

Entity に関する情報の部分集合.

Claims Provider

Entity の Claim を返すサーバー.

End-User

一連のフローに参加する人間.

Entity

あるコンテキストの中で識別される, 他と独立した個. End-User は Entity の一例.

ID Token

Authentication イベントに関する Claim を含む JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.) [JWT]. その他の Claim を含むこともある (MAY).

Identifier

あるコンテキスト中で Entity をユニークに特徴づける値.

Issuer

Claim を発行する Entity.

Issuer Identifier

検証可能な Issuer の識別子. Issuer Identifier は, 大文字小文字を区別する URL である. この URL は https スキーム, ホスト, そして任意でポート番号およびパス要素からなり, クエリーとフラグメント要素は含まない.

OpenID Provider (OP)

End-User を Authenticate できる OAuth 2.0 Authorization Server. End-User の Authentication イベントに関する Claim を Relying Party に提供する.

Pairwise Pseudonymous Identifier (PPID)

ある Relying Party に対してのみ, ある Entity の識別子として提供される値. 他の Relying Party には, 当該 PPID を当該 Entity と関連づけることはできない.

Personally Identifiable Information (PII)

特定の人物に紐づき, 実際の人物の識別に用いることができる情報. もしくは特定の人物に直接および間接的にリンクされる可能性のある情報.

Relying Party (RP)

OpenID Provider に End-User Authentication と Claim を要求する OAuth 2.0 Client.

Self-Issued OpenID Provider

私有の self-hosted な OpenID Providerであり, 自己署名つきの ID Token を発行するもの.

Subject Identifier

Issuer にとって局地的にユニークで再利用されることのない End-User 識別子. この値は Client に利用されることを想定する.

UserInfo Endpoint

Protected Resource のひとつ. Access Token を提示する Client に対して, Authorization Grant に従って End-User に関する情報を提供する.

Validation

あるものごとの健全性および正当性を確立するためのプロセス.

Verification

ある事実や値の正確さを検査もしくは証明するためのプロセス.

Voluntary Claim

Client が End-User が要求するあるタスクを実行する際に, 有用ではあるが Essential ではないとを Client が指定した Claim.

IMPORTANT NOTE TO READERS: 上記の用語定義は本ドキュメントが定めるところであり, 本ドキュメントの実装においてはこれらの定義に従うこと. "Issuer Identifier" をはじめとして, 本ドキュメントで大文字表記されている用語はすべて上記の定義に従う. 本ドキュメント読者は必ずこれらの用語定義に従うこと.

1.3.  Overview

OpenID Connect プロトコルは, おおまかに言って以下のステップに従う.

1. RP (Client) が OpenID Provider (OP) にリクエストを送る.
2. OP は End-User を認証し, 認可を受ける.
3. OP は ID Token および (通常は) Access Token を返す.
4. RP は Access Token を添えて UserInfo Endpoint にリクエストを送る.
5. UserInfo Endpoint は End-User の Claim を返す.

これら一連のステップを以下に図示する.

+--------+                                   +--------+
|        |                                   |        |
|        |---------(1) AuthN Request-------->|        |
|        |                                   |        |
|        |  +--------+                       |        |
|        |  |        |                       |        |
|        |  |  End-  |<--(2) AuthN & AuthZ-->|        |
|        |  |  User  |                       |        |
|   RP   |  |        |                       |   OP   |
|        |  +--------+                       |        |
|        |                                   |        |
|        |<--------(3) AuthN Response--------|        |
|        |                                   |        |
|        |---------(4) UserInfo Request----->|        |
|        |                                   |        |
|        |<--------(5) UserInfo Response-----|        |
|        |                                   |        |
+--------+                                   +--------+

2.  Protocol Elements

Authentication Request は Authorization Code Flow, Implicit Flow および Hybrid Flow のいずれかのフローに従う. Authorization Code Flow は, Authorization Server と Client 自身との間でセキュアに Client Secret を管理できる Client 向けのフローである. それが不可能な Client は Implicit Flow を用いる. しかしながら, Client Secret をセキュアに保持できないにも関わらず, Refresh Token 取得のためにしばしば Native アプリケーションやその他の Client が Authorization Code flow を利用することもある. Hybrid Flow は Authorization Code Flow と Implicit Flow をあわせたものであり, Client が Authorization Server から直接 ID Token およびオプションで Access Token を受け取ることでレイテンシ低下を防ぎつつも, 後から Client が Token Endpoint にアクセスして各種トークン (特に Refresh Token) を取得できるようにするものである.

このドキュメントは Implicit Flow を利用する Client に対して必要十分な情報のみを提供する.

2.1.  Implicit Flow

Implicit Flow は以下のステップからなる.

1. Client は必要なリクエストパラメータを含んだ Authentication Request を構築する.
2. Client は Authorization Server にリクエストを送信する.
3. Authorization Server は End-User を認証する.
4. Authorization Server は End-User の Consent/Authorization を取得する.
5. Authorization Server は End-User を ID Token, およびもし要求されていれば Access Token とともに, Client に戻す.
6. Client はそれらのトークンを検証し, End-User の Subject Identifier を取得する.

2.1.1.  Client Prepares Authentication Request

RP が End-User を Authenticate したい, もしくは End-User が既に Authenticated であるかどうか知りたい場合, Client は Authorization Endpoint に Authorization Request を送る.

Authorization Endpoint との間の通信は TLS を利用しなければならない (MUST). TLS の詳細については Section 8.1 (TLS Requirements) を参照のこと.

Client は RFC 7231 (Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content,” June 2014.) [RFC7231] に定義される HTTP GET もしくは HTTP POST を利用できる (MAY).

HTTP GET を利用する場合, パラメータは Section 4.1 (Query String Serialization) にある Query String Serialization を用いてシリアライズされる. HTTP POST を利用する場合, パラメータは [W3C.REC‑html401‑19991224] (Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) にある application/x-www-form-urlencoded フォーマットを用いてエンティティボディ中に含まれる.

以下は Authentication Request URL の一例である. (改行は掲載上の都合による)

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

2.1.1.1.  Request Parameters

OpenID Connect は以下の OAuth 2.0 リクエストパラメータを利用する.

response_type

REQUIRED. 値は id_token および token を空白で区切ったリストである. これにより, Authorization Endpoint から Access Token および ID Token の両方が返される. 詳細は OAuth 2.0 Multiple Response Type Encoding Practices (de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.) [OAuth.Responses] 参照.

client_id

REQUIRED. Authorization Server における OAuth 2.0 Client Identifier の値.

scope

REQUIRED. OpenID Connect リクエストは scope に openid を含まねばならない (MUST). OPTIONAL な scope としては, profile, email, address, phone, および offline_access が定義されている. それぞれの scope 値についての詳細は Section 2.4 (Scope Values) を参照のこと.

redirect_uri

REQUIRED. レスポンスが返される Redirection URI. この URI は, Client が OpenID Provider に対して事前に登録済みの Redirection URI のいずれかと完全一致しなければならない (MUST). マッチングルールは [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) (Simple String Comparison) の Section 6.2.1 に従うこと. Redirection URI は http スキーマを使用してはならない (MUST NOT). ただし, Client がネイティブアプリケーションである場合は, http: スキーマをホスト部 localhost と組み合わせて使うことができる (MAY).

state

RECOMMENDED. リクエストとコールバックの間で維持されるランダムな値. 一般的に Cross-Site Request Forgery (CSRF, XSRF) 対策の目的で利用される, ブラウザ Cookie と紐づく暗号論的にセキュアな値を取る.

本ドキュメントは上記に加えて以下のリクエストパラメータを定義する.

nonce

REQUIRED. Client セッションと ID Token を紐づける文字列であり, リプレイアタック対策に用いられる. この値は Authentication Request で指定され, そのままの値で ID Token に含まれる. nonce 値には, 推測不可能なように十分なエントロピーを持たせること (MUST). この条件を満たすには, 暗号論的にセキュアな乱数を HTML5 ローカルストレージに保存し, その暗号論的ハッシュ値を nonce として利用するといった方法が考えられる. この場合, ID Token に含まれて返される nonce 値をローカルストレージに保存した値のハッシュ値と比較することで, 第三者によるリプレイアタックを検知することができる.

display

OPTIONAL. Authorization Server が認証および同意のためのユーザーインタフェースを End-User にどのように表示するかを指定するための ASCII　[RFC20] (Cerf, V., “ASCII format for Network Interchange,” October 1969.) 値. 以下の値が定義されている.

page

Authorization Server は認証および同意 UI を User Agent の全画面に表示すべきである (SHOULD). display パラメータが指定されていない場合, この値がデフォルトとなる.

popup

Authorization Server は認証および同意 UI を User Agent のポップアップウィンドウに表示すべきである (SHOULD). User Agent のポップアップウィンドウはログインダイアログに適切なサイズで, 親ウィンドウ全体を覆うことのないようにすべきである.

touch

Authorization Server は認証および同意 UI をタッチインタフェースを持つデバイスに適した形で表示すべきである (SHOULD).

wap

Authorization Server は認証および同意 UI を "feature phone" に適した形で表示すべきである (SHOULD).

Authorization Server は User Agent の機能を検知して適切な表示を行うようにしても良い (MAY).

prompt

OPTIONAL. Authorization Server が End-User に再認証および同意を再度要求するかどうか指定するための, スペース区切りの ASCII 文字列のリスト. 以下の値が定義されている.

none

Authorization Server はいかなる認証および同意 UI をも表示してはならない (MUST NOT). End-User が認証済でない場合, Client が要求する Claim 取得に十分な事前同意を取得済でない場合, またはリクエストを処理するために必要な何らかの条件を満たさない場合には, エラーが返される. 典型的なエラーコードは login_required, interaction_required である. この prompt 値は現在の認証状態, 同意状況を確認する為にも利用できる.

login

Authorization Server は End-User を再認証するべきである (SHOULD). 再認証が不可能な場合はエラーを返す (MUST). 典型的なエラーコードは login_required である.

consent

Authorization Server は Client にレスポンスを返す前に End-User に同意を要求するべきである (SHOULD). 同意要求が不可能な場合はエラーを返す (MUST). 典型的なエラーコードは consent_required である.

select_account

Authorization Server は End-User にアカウント選択を促すべきである (SHOULD). この prompt 値は, End-User が Authorization Server 上に複数アカウントを持っているとき, 現在のセッションに紐づくアカウントの中から一つを選択することを可能にする. End-User によるアカウント選択が不可能な場合はエラーを返す (MUST). 典型的なエラーコードは account_selection_required である.

prompt パラメータは Client に対して, End-User のセッションがアクティブであることを確認したり, End-User にリクエストに対する注意を促すことを可能にする. none がその他の値とともに用いられる場合はエラーとなる.

max_age

OPTIONAL. Authentication Age の最大値. End-User が OP によって明示的に認証されてからの経過時間の最大許容値 (秒). もし経過時間がこの値より大きい場合, OP は End-User を明示的に再認証しなければならない (MUST). max_age が指定された場合, 発行される ID Token は auth_time Claim を含まねばならない (MUST).

ui_locales

OPTIONAL. End-User の選好する UI の表示言語および文字種. スペース区切りの BCP47 (Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.) [RFC5646] 言語タグ値のリストとして表現され, 順序は選好順となる. 例えば "fr-CA fr en" という値が指定された場合, カナダで用いられるフランス語が第一選好となり, 次いで地域指定のないフランス語, そして英語と続く. 要求されたロケールがサポートされていない場合でも, OpenID Provider はエラーとするべきではない (SHOULD NOT).

claims_locales

OPTIONAL. End-User の選好する Claim の表示言語および文字種. スペース区切りの BCP47 (Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.) [RFC5646] 言語タグ値のリストとして表現され, 順序は選好順となる. 要求されたロケールがサポートされていない場合でも, OpenID Provider はエラーとするべきではない (SHOULD NOT).

id_token_hint

OPTIONAL. Authorization Server が以前発行した ID Token. Client が認証した End-User の現在もしくは過去のセッションに関するヒントとして利用される. もしこの ID Token に紐づく End-User が認証済, もしくはこのリクエスト中で認証された場合, Authorization Server はポジティブレスポンスを返す. さもなければ, Authorization Server はエラーを返す (SHOULD). prompt=none を利用する場合は, 可能であれば id_token_hint を指定するべきであり (SHOULD), さもなければ invalid_request を返しても良い (MAY). ただしサーバーはその場合可能な限りサクセスレスポンスを返すこと. id_token_hint 利用時は, ID Token の audience に Authorization Server 自身が含まれている必要はない.

login_hint

OPTIONAL. Authorization Server に対する End-User ログイン識別子のヒントとして利用される. RP が End-User に Email アドレス (もしくはその他の識別子) を要求し, それを Authorization Server にヒントとして送信することでヒントとする. Discovery に利用された値をヒントの値として利用することを推奨する (RECOMMENDED). この値は phone_number Claim に指定されるフォーマットに従った電話番号でもよい (MAY). このパラメータを利用するか否かは OP の判断にゆだねる.

acr_values

OPTIONAL. Authentication Context Class Reference リクエスト値. Authorization Server が認証リクエストを処理する際に要求される acr の値をスペース区切りで示した文字列. 認証処理が満たした Authentication Context Class は, Section 2.2 (ID Token) に示す acr Claim Value として返される. acr Claim はこのパラメータを用いることで Voluntary Claim としてリクエストされることになる.

registration

OPTIONAL. Client が自身の情報を Self-Issued OP に提供するために使用される. なお, 通常 Client は自身の情報を Dynamic Client Registration (Section 3.2.1 (Providing Information with the "registration" Request Parameter) 参照) を通じて OP に提供する.

2.1.2.  Client Sends Request to Authorization Server

Client は Authorization Endpoint に HTTPS で Authentication Request を送信する.

以下の例では Client が User Agent に HTTP 302 リダイレクトレスポンスを返し, User Agent に対して Authorization Endpoint に Authentication Request を送るよう指示している. (改行は掲載上の都合による)

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

User Agent は上記の Client からの HTTP 302 リダイレクトレスポンスに従い, Authorization Server に以下のようなリクエストを送る. (改行は掲載上の都合による)

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

2.1.3.  Authorization Server Authenticates End-User

Authorization Server は, リクエストパラメータ値に基づき, End-User をログインさせたり既にログイン済みであることを検証する. End-User とのインタラクションが HTTP で行われる場合は, Section 8.1 (TLS Requirements) に基づきTLS を用いること (MUST). 認証手段の詳細については, 本ドキュメントの定めるところではない.

2.1.4.  Authorization Server Obtains End-User Consent/Authorization

Authorization Server は要求された Claim に対する認可結果を得る. 認可取得には, End-User が何に同意をしようとしているのかを明示する同意ダイアログを用いることもあれば, その他の何らかの手段 (事前の管理者による同意等) を用いることもあろう.

openid scope 値は, その OAuth 2.0 リクエストが OpenID Connect リクエストであることを宣言する. その他の scope 値の利用は任意である (OPTIONAL).

2.1.5.  Authorization Server Sends End-User Back to Client

認可結果が得られると, Authorization Server はサクセスレスポンスまたはエラーレスポンスを返す.

2.1.5.1.  End-User Grants Authorization

End-User がアクセス権要求を承認した場合, Authorization Server は Access Token を発行し, OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の Section 4.2.2 および OAuth 2.0 Multiple Response Type Encoding Practices (de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.) [OAuth.Responses] に従い, 以下のパラメータを Redirection URI のフラグメント部に application/x-www-form-urlencoded フォーマットで付与して Client に渡す.

Implicit Flow では, OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の Section 4.2.2 に従い, レスポンスの全体が Redirection URI のフラグメント部に返される.

access_token

REQUIRED. UserInfo Endpoint アクセスのための Access Token.

token_type

REQUIRED. OAuth 2.0 Token Type 値. このサブセットを使う Clint について, この値は OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] に従い, Bearer でなければならない (MUST).

id_token

REQUIRED. ID Token.

state

OAuth 2.0 state 値. Authorization Request に state パラメータが含まれていた場合は必須 (REQUIRED). Clients は state 値が Authorization Request に含めた値と同一であることを検証しなければならない (MUST).

expires_in

OPTIONAL. レスポンス生成時点から Access Token の期限切れまでの時間を秒で表したもの.

Client はこの Access Token を用いて Resource Server 上の保護されたリソースにアクセスが可能である.

以下に例を示す. (改行は掲載上の都合による)

  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.1.5.2.  End-User Denies Authorization or Invalid Request

End-User が認可を拒否したり, End-User の認証に失敗した場合, Authorization Server は OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Section 4.2.2.1 に従ってエラーの Authorization Response を返さなければならない (MUST). (RFC 6749 に関係のないエラーは, 適切な HTTP ステータスコードを用いて User Agent に返すこと)

2.1.5.3.  Redirect URI Fragment Handling

レスポンスのパラメータは Redirection URI フラグメントで渡されるため, Client はフラグメントエンコードされた値を User Agent でパースして Client の処理ロジックに送る必要がある. 暗号 API に直接アクセス可能な User Agent では, 例えばすべての Client コードを JavaScript で書くことにより, 処理を User Agent 内で完結することができる.

しかし, Client 処理が User Agent 内で完結しない場合には, パラメータを Web Server Client へポストして検証する方法がある.

以下は Client が redirect_uri で提供する JavaScript ファイルの例である. このファイルは Authorization Server からのリダイレクトによって読み込まれる. フラグメント部分はパースされ, POST によって送信される先の URI で検証とユーザー情報の受信が行われる.

以下に Redirect 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, perform a redirect
        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.2.  ID Token

ID Token は, ある Client を利用するというコンテキスト中での, Authorization Server による End-User 認証に関する Claim を含んだセキュリティトークンである. 潜在的にはその他の Claim を含む可能性もある. ID Token は JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.) [JWT] である.

ID Token には以下の Claim が含まれる.

iss

REQUIRED. レスポンスを返した Issuer の Issuer Identifier. iss 値は, https スキーマで始まる大文字小文字を区別する URL であり, スキーマ, ホスト, そして任意でポート番号とパスを含む. クエリーとフラグメントは含まない.

sub

REQUIRED. Subject Identifier. Client に利用される前提で, Issuer のローカルでユニークであり再利用されない End-User の識別子. (例: 24400320 や AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4 等) この値は ASCII で255文字を超えてはならない (MUST NOT). sub 値は大文字小文字を区別する.

aud

REQUIRED. ID Token の想定されるオーディエンス (Audience). この値は Relying Party の OAuth 2.0 client_id を含まなければならない (MUST). 他のオーディエンスの識別子を含んでもよい (MAY). 一般的には aud は大文字小文字を区別した文字列の配列であるが, オーディエンスが単体の場合は aud 値を大文字小文字を区別した単一文字列としてもよい (MAY).

exp

REQUIRED. ID Token の有効期限. この有効期限以降に該当 ID Token を受け入れたり処理してはならない (MUST NOT). ある ID Token が有効期限内であるためには, この値が示す時刻より現在時刻が前でなければならない (MUST). 実装者は, 通常数分以内で, 時計のズレを考慮して多少の猶予期間を設けてもよい (MAY). この値は UTC 1970-01-01T00:00:00Z から該当時刻までの秒数を示す JSON [RFC7159] (Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format,” March 2014.) 数値である. 詳細は RFC 3339 (Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) [RFC3339] を参照のこと.

iat

REQUIRED. JWT 発行時刻. この値は UTC 1970-01-01T00:00:00Z から該当時刻までの秒数を示す JSON 数値である.

auth_time

End-User の認証が発生した時刻. この値は UTC 1970-01-01T00:00:00Z から該当時刻までの秒数を示す JSON 数値である. リクエストに max_age が含まれていた場合, この Claim は必須である (REQUIRED). その他の場合は任意 (OPTIONAL).

nonce

OPTIONAL. Client セッションと ID Token を紐づける文字列値. リプレイアタック防止のために用いられる. Authentication Request で指定されたままの値を ID Token に含める. Client は Authentication Request に含めた nonce 値が ID Token に含まれる nonce Claim Value と一致することを検証しなければならない (MUST). Authentication Request に nonce が含まれていた場合, Authorization Server は ID Token にそのままの値で nonce Claim を含めねばならない (MUST). nonce は大文字小文字を区別する文字列である.

at_hash

REQUIRED. Access Token のハッシュ値. Implicit Flow 内で ID Token が access_token とともに発行された場合 (この項で説明しているOpenID Connectのサブセットではこのケースに該当する), この Claim は必須である (REQUIRED). この値は, access_token の ASCII バイト列のハッシュ値の左半分を Basd64URL エンコードしたものであり, ハッシュアルゴリズムは ID Token の JOSE Header にある alg Header Parameter で用いられるハッシュアルゴリズムと同じものを用いる. 例えば alg が RS256 であれば, access_token の SHA-256 ハッシュ値を計算し, その左半分の128ビットを Base64URL エンコードする. at_hash は大文字小文字を区別する文字列である.

acr

OPTIONAL. Authentication Context Class Reference. 実施された認証処理が満たす Authentication Context Class を表す Authentication Context Class Reference 値を示す文字列. "0" という値は End-User 認証が ISO/IEC 29115 (International Organization for Standardization, “ISO/IEC 29115:2013 -- Information technology - Security techniques - Entity authentication assurance framework,” March 2013.) [ISO29115] の定める level 1 を満たさないことを意味する. 長期間有効なブラウザクッキーを用いた認証などが, "level 0" の例として挙げられる. 金銭にかかわるリソースへのアクセス認可要求時には, level 0 の認証を受け入れるべきではない (SHOULD NOT). acr 値には, 絶対 URL か RFC 6711 (Johansson, L., “An IANA Registry for Level of Assurance (LoA) Profiles,” August 2012.) [RFC6711] に登録された値を用いるべきである (SHOULD). RFC 6711 (Johansson, L., “An IANA Registry for Level of Assurance (LoA) Profiles,” August 2012.) [RFC6711] 登録済の値を用いる場合, RFC 6711 (Johansson, L., “An IANA Registry for Level of Assurance (LoA) Profiles,” August 2012.) [RFC6711] と異なる意味でそれを用いてはならない (MUST NOT). この値の意味するところはコンテキストによって異なる可能性があるため, この Claim を利用する場合は, 関係者間で値の意味するところについて合意しておくこと. acr は大文字小文字を区別する文字列である.

amr

OPTIONAL. Authentication Methods References. 認証時に用いられた認証方式を示す識別子文字列の JSON 配列. 例として, パスワードと OTP 認証が両方行われたことを示すといったケースが考えられる. amr Claim にどのような値を用いるかは本ドキュメントの定めるところではない. この値の意味するところはコンテキストによって異なる可能性があるため, この Claim を利用する場合は, 関係者間で値の意味するところについて合意しておくこと. amr は大文字小文字を区別する文字列である.

azp

OPTIONAL. ID Token 発行対象である認可された関係者 (authorized party). この Claim が存在する場合, その値は受け取り手の OAuth 2.0 Client ID でなければならない. この Claim は, ID Token のオーディエンス値が単一文字列であり, かつその値が azp の値と異なる場合にのみ必要となる. オーディエンスと azp 値が同値である場合にも, この Claim を含んでもよい (MAY). azp は大文字小文字を区別する文字列である.

sub_jwk

Section 3 (Self-Issued OpenID Provider) で定義されるとおり, Self-Issued OpenID Provider から発行された ID Token の署名検証に使われる公開鍵. 鍵は [JWK] (Jones, M., “JSON Web Key (JWK),” May 2015.) フォーマットのベア鍵である (X.509 証明書ではない). sub_jwk Claim の使用は, OP が Self-Issued OP の場合は必須 (REQUIRED) であり, そうでない場合は推奨されない (NOT RECOMMENDED). sub_jwk 値は JSON オブジェクトである.

ID Token はその他の Claim を含んでもよい (MAY). 解釈不可能な Claim は全て無視すること (MUST).

ID Token は JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS] を使って署名されなければならない (MUST). Client は ID Token を Section 2.2.1 (ID Token Validation) に従って検証しなければならない (MUST).

ID Token は JWS および JWE の x5u, x5c, jku, jwk ヘッダーフィールドを含むべきではない (SHOULD NOT). これらの代わりに事前の Discovery および Registration において, ID Token に用いる鍵を得ること.

以下は Base64URL デコードされた ID Token に含まれる Claims (the JWT Claims Set) の例である.

  {
   "iss": "https://server.example.com",
   "sub": "24400320",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "at_hash": "MTIzNDU2Nzg5MDEyMzQ1Ng"
  }

2.2.1.  ID Token Validation

本ドキュメントの定めるバリデーションが1つでも失敗した場合, バリデーションが失敗した情報を必要とする処理を全て中止し (MUST), バリデーションが失敗した情報を利用してはならない (MUST NOT).

Client は Authorization Response に含まれる ID Token を以下のようにバリデートしなければならない (MUST).

1. OpenID Provider の Issuer Identifier (これは通常 Discovery によって得られる) が iss (issuer) Claim と一致しなければならない (MUST).
2. aud Claim が, iss Claim に紐づく Issuer に登録されている Client 自身の client_id を含まなければならない (MUST). ID Token のオーディエンスに Client が含まれていなかったり, Client にとって信頼できない主体がオーディエンスに含まれている場合, その ID Token を拒絶しなければならない (MUST).
3. ID Token が複数のオーディエンスを含む場合, Client は azp Claim が存在することを検証すべきである (SHOULD).
4. azp Claim が存在する場合, Client はそれが自身の client_id と一致することを検証すべきである (SHOULD).
5. Client は ID Token の署名を, JOSE Header 中の alg Header Parameter で指定されたアルゴリズムを使い, JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS] に従って検証しなければならない (MUST). Client は Issuer によって提供された鍵を使わなければならない (MUST).
6. alg の値は RS256 であるべきである (SHOULD). 他の署名アルゴリズムを用いたトークン検証については OpenID Connect Core 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” August 2015.) [OpenID.Core] に記述されている.
7. 現在時刻が exp Claim より前でなければならない (MUST). (時計のズレを考慮した多少の猶予は許容される)
8. iat Claim が現在時刻からあまりにかけ離れている場合は, そのトークンを拒絶してもよい. これにより nonce の保存期間を制限することができる. 適切な閾値は, Client ごとにことなる.
9. nonce Claim の値が Authentication Request にて送られたものと一致することを確認しなければならない (MUST). Client は nonce の値をリプレイアタック対策のためにチェックすべきである (SHOULD). リプレイアタック検知方法の詳細は Client によって異なる.
10. acr Claim が要求されたならば, Client は主張された Claim の値が適切かどうかをチェックすべきである (SHOULD). acr Claim の値と意味は本ドキュメントの対象外である.
11. max_age が要求されたならば, Client は auth_time Claim の値をチェックし, もし最新のユーザー認証からあまりに長い時間が経過したと判定されたときは再認証を要求すべきである (SHOULD).

2.2.2.  Access Token Validation

Implicit Flow で ID Token とともに 発行された Access Token を検証するには, Client は以下を検証するべきである (SHOULD).

1. access_token の ASCII オクテット列のハッシュ値を求める. このとき用いるハッシュアルゴリズムは ID Token の JOSE Header にある alg Header Parameter に対応する JWA (Jones, M., “JSON Web Algorithms (JWA),” May 2015.) [JWA] で定められたものである. 例えば alg が RS256 であれば, ハッシュアルゴリズムは SHA-256である.
2. ハッシュ値の左半分を Base64URL エンコードする.
3. ID Token に at_hash が存在する場合は, その値は, 直前のステップで求めた値と一致しなければならない (MUST).

2.3.  UserInfo Endpoint

UserInfo Endpoint は, 認証された End-User に関する Claim を返す OAuth 2.0 Protected Resource である. UserInfo Endpoint は https スキーマの URL であり, ポート番号, パス, クエリーを含むことができる (MAY). Claim は JSON オブジェクトとして返される.

UserInfo Endpoint にアクセスする際には TLS は必須である (MUST). TLS 利用についての詳細は Section 8.1 (TLS Requirements) 参照.

2.3.1.  UserInfo Request

Client は, OpenID Connect Authentication で得られた Access Token を使って, UserInfo Endpoint に End-User の Claim をリクエストする. UserInfo Endpoint は 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., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Protected Resource である. このリクエストは HTTP GET で行われるべきであり (SHOULD), Access Token は Authorization ヘッダー経由で渡されるべきである (SHOULD).

以下に UserInfo Request の例を示す.

  GET /userinfo HTTP/1.1
  Host: server.example.com
  Authorization: Bearer SlAV32hkKG

2.3.2.  Successful UserInfo Response

UserInfo Claim は JSON オブジェクトのメンバーとして返される (MUST). レスポンスボディは UTF-8 [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.) エンコードされる (SHOULD). Section 2.5 (Standard Claims) に定義されている Claim に加え, そこに明記されていない Claim も返却可能である.

Claim が返されない場合, Claim Name は JSON オブジェクトから除かれるべきであり (SHOULD), 値を null や空文字列にした状態で該当 Claim を含めるべきではない (SHOULD NOT).

UserInfo Response には, 必ず sub Claim を含むこと (MUST).

注) トークン置換攻撃を考慮すると, UserInfo Response が必ずしも ID Token の sub Claim が示す End-User のものであるとは保証できない. そのため UserInfo Response に含まれる sub Claim が ID Token のそれと一致することを検証しなければならない (MUST). もし2つが一致しない場合, UserInfo Response を利用してはならない (MUST NOT).

Client はレスポンスを返した OP が意図した通りの OP であることを, 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 サーバー証明書チェックを通じて検証しなければならない (MUST).

2.3.3.  UserInfo Error Response

もし何らかのエラーが起こった場合, UserInfo Endpoint は OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] SEction 3 に示す Error Response を返す.

2.4.  Scope Values

OpenID Connect Client は OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Section 3.3 に従い, Access Token に要求されるアクセス権限を scope 値を通じて指定する. Access Tokens に紐づく scope は, そのトークンを使って OAuth 2.0 で保護されたエンドポイントにアクセスした際にどのようなリソースが得られるかを規定する. OpenID Connect では, scope は Claim Value として取得可能な情報セットを指定する為に利用できる. 本ドキュメントでは OpenID Connect で用いられる scope についてのみ述べる.

OpenID Connect は, ここで述べる scope 値以外の値を定義および利用することを制限しない. また実装が理解できない scope 値は無視されるべきである (SHOULD).

Authorization Server は, 以下の scope によって要求される Claim を Voluntary Claim として扱う.

OpenID Connect は以下の scope 値を定義する.

openid

REQUIRED. Client が Authorization Server に OpenID Connect リクエストを投げていることを示す. openid scope 値が存在しない場合の挙動は定義しない.

profile

OPTIONAL. この scope 値は, 以下に示す End-User のデフォルトプロフィール Claim へのアクセス要求に用いる. name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_at.

email

OPTIONAL. email および email_verified Claim へのアクセス要求に用いる.

address

OPTIONAL. address Claim へのアクセス要求に用いる.

phone

OPTIONAL. phone_number および phone_number_verified Claim へのアクセス要求に用いる.

offline_access

この scope 値は OpenID Connect Implicit Client Implementer's Guide 1.0 では使用してはならない (MUST NOT). Basic Client での使用については OpenID Connect Basic Client Implementer's Guide 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Implementer's Guide 1.0,” August 2015.) [OpenID.Basic] を参照のこと.

複数の scope 値は, スペース区切りの大文字小文字を区別した ASCII scope 値のリストによって指定することができる (MAY).

profile, email, address, および phone scope 値により要求される Claim は, Section 2.3.2 (Successful UserInfo Response) にある通り UserInfo Endpoint から返される.

End-User が OpenID Provider に対して RP に要求された情報の一部もしくは全ての提供を拒否することもある. End-User に要求する情報を最小化するために, RP は UserInfo Endpoint で提供される情報の一部のみをリクエストすることもできる.

以下に scope リクエスト例を示す.

  scope=openid profile email phone

2.5.  Standard Claims

OpenID Connect では以下に示す標準 Claim セットを定義する. これらは通常の OP からは UserInfo Response として, Self-Issued OP からは ID Token の中に返される.

以下に例を示す.

  {
   "sub": "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"
  }

Registration [OpenID.Registration] (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” August 2015.) において特に他フォーマットを指定されない限り, UserInfo Endpoint では Claim を JSON 形式で返し (MUST), Content-Type ヘッダーを用いてフォーマットを示すこと (MUST). 以下に許可されたコンテンツタイプを示す.

2.5.1.  Address Claim

Address Claim は物理的な郵送先住所である. End-User の登録済情報とプライバシー設定に基づいて, address の一部のみを返却することもある (MAY). 例えば country と region を返し, それ以外の詳細なアドレス情報を省略するなどが考えられる.

住所全体を整形済サブフィールドに1文字列として入れてもよいし (MAY), 他のサブフィールドに個別の要素として各住所要素を指定するだけでもよいし (MAY), 両方を含めてもよい (MAY). もし両方を含める場合, 整形済住所は住所の各要素の連結方法を示すものとし, 両方が同じアドレスを示すこと (SHOULD).

formatted

Full mailing address, formatted for display or use on a mailing label. This field MAY contain multiple lines, separated by newlines. Newlines can be represented either as a carriage return/line feed pair ("\r\n") or as a single line feed character ("\n").

street_address

Full street address component, which MAY include house number, street name, Post Office Box, and multi-line extended street address information. This field MAY contain multiple lines, separated by newlines. Newlines can be represented either as a carriage return/line feed pair ("\r\n") or as a single line feed character ("\n").

locality

City or locality component.

region

State, province, prefecture, or region component.

postal_code

Zip code or postal code component.

country

Country name component.

2.5.2.  Claims Languages and Scripts

Human-readable な Claim Value およびそれらへの参照は, 複数言語および複数文字種で表現することができる (MAY). 言語および文字種の指定には BCP47 (Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.) [RFC5646] 言語タグを # を区切り文字としてメンバー名に付与する. 例えば family_name#ja-Kana-JP は日本語のカタカナ表記の Family Name を示す. カタカナ表記の氏名は, 漢字表記 (family_name#ja-Hani-JP) の氏名の発音を示したりインデックス目的等で用いられることが多い. 他にも website が言語指定のない Web サイト, website#de がドイツ語の Web サイトを参照していることを示すといった例も挙げられる.

Claim Name は大文字小文字を区別するため, Claim Name 内の言語タグは IANA Language Subtag Registry (IANA, “Language Subtag Registry,” .) [IANA.Language] に登録されたままの表記とすることを強く推奨する (RECOMMENDED). 一般的に言語名は小文字, 地域名は大文字, 文字種は大文字小文字混合で表記されることが多い. しかしながら BCP47 言語タグ値は大文字小文字を区別しないため, 実装は言語タグを大文字小文字区別なく処理できるべきである (SHOULD).

BCP47 で推奨されるように, Claim の言語タグ値は必要な時にのみ指定すべきである (SHOULD). 例えばほとんどの場合 fr-CA や fr-FR でなく fr で十分である. 可能であれば OP は要求された Claim locale と自身が持つ Claim のマッチングを試みるべきである (SHOULD). 例えば Client が de (ドイツ語) の Claim を要求してきており, OP が de-CH (スイスのドイツ語) 表記の Claim は持つが地域指定無しの一般的ドイツ語表記の Claim を持たない場合, OP はスイスのドイツ語の値を返すのが適切である. (Client をできるかぎりシンプルに保つため, ここでは言語タグのマッチングが内包する複雑性をわざと OP に寄せている)

リクエスト中の claims_locales を使って, 返却される Claim の好ましい言語および文字種を指定することができる.

OP が claims_locales やその他の手段により End-User と Client が単一言語および文字種表記の Claim を要求していると特定した場合, 該当言語および文字種表記の Claim を返却する際には言語タグを付けずに返すことを推奨する (RECOMMENDED). また Client は言語タグ付きの Claim を処理可能なよう実装することを推奨する (RECOMMENDED).

2.5.3.  Claim Stability and Uniqueness

sub (subject) と iss (issuer) Claim のペアは, RP が End-User の不変な識別子として信頼できる唯一の Claim である. Section 2.2 (ID Token) で述べたように, sub は Issuer が End-User に割り振るローカルでユニークかつ再利用されない識別子でなければならない (MUST). 以上のことから, iss Claim と sub Claim のペアが, 唯一の保証された End-User の識別子となる.

その他の Claim に関しては, 時間経過や複数ユーザー間での不変性等は保証されず, Issuer は独自の制約やポリシーを適用してよい. 例えば Issuer は時系列上の異なるポイントにおいて, 同一の email Claim Value を異なるユーザーのために再利用してもよい (MAY). よって email アドレスは時間経過によって異なる End-User に紐づく可能性がある (MAY). 以上のことより, email, phone_number, preferred_username などの Claim を End-User のユニークな識別子として利用してはならない (MUST NOT).

3.  Self-Issued OpenID Provider

OpenID Connect は Self-Issued OpenID プロバイダー (私有の self-hosted な OpenID Provider であり, 自己署名つきの ID Token を発行するもの) をサポートしている. Self-Issued OP は https://self-issued.me という特別な Issuer 識別子を使用する.

3.1.  Self-Issued OpenID Provider Discovery

ディスカバリプロセスで入力された識別子が 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"]
   }

注記: OpenID ファウンデーションは https://self-issued.me/ という OpenID プロバイダーサイトを提供することを計画している. その場合は WebFinger サービスも提供され, ディスカバリを実行すると上記の静的なディスカバリ情報を返すため, RP は Self-Issued OP のディスカバリのために特別な処理を行う必要はない. このサイトは実験的に提供される予定である. プロダクション環境を実装する際は, OpenID ファウンデーションが当該サイトをプロダクション用途を想定して提供するまでその環境に依存すべきではない.

3.2.  Self-Issued OpenID Provider Registration

Self-Issued OP を使う際は登録は必要ない. Client は登録しなくても OP に登録したかのように振る舞い, 以下の Client Registration Response を得る.

client_id

Client の redirect_uri 値.

client_secret_expires_at

0

注記: OpenID ファウンデーションは https://self-issued.me/registration/1.0/ という (ステートレスな) エンドポイントを提供することを計画しており, そのエンドポイントは上記レスポンスを返すため, RP は Self-Issued OP の登録のために特別な処理を行う必要はない. このサイトは実験的に提供される予定である. プロダクション環境を実装する際は, OpenID ファウンデーションが当該サイトをプロダクション用途を想定して提供するまでその環境に依存すべきではない.

3.2.1.  Providing Information with the "registration" Request Parameter

OpenID Connect は Client が Self-Issued OpenID プロバイダーに追加の登録情報を提供することが出来るようにするために以下の認可リクエストパラメータを定義している.

registration

任意 (OPTIONAL). このパラメータは通常, Dynamic Client Registration の間に Client が自身の情報を Self-Issued OP に提供する際に利用される. この値は OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” August 2015.) [OpenID.Registration] 仕様の Section 2.1 で定義されている Client メタデータの値を含む JSON オブジェクトである. registration パラメータは OP が Self-Issued OP ではないときは利用すべきではない (SHOULD NOT).

この情報の中で Self-Issued OP により必須 (REQUIRED) なものはなく, このパラメータの利用は任意 (OPTIONAL) である.

registration パラメータの値は OAuth 2.0 リクエストの中で UTF-8 エンコードされた JSON として表わされる. (OAuth パラメータとして渡される際, form-urlencoded される).

Self-Issued OP へのリクエストの中で典型的に利用する登録パラメータは以下である. policy_uri, tos_uri, and logo_uri. Client が一つ以上の Redirection URI を使用する際, それらを登録するために redirect_uris パラメータを利用する.

3.3.  Self-Issued OpenID Provider Request

Client は Authorization Endpoint へ以下のパラメータを付けて Authentication Request を送信する.

response_type

必須 (REQUIRED). 固定の文字列 id_token.

client_id

必須 (REQUIRED). Client の Client ID, この場合は Client の redirect_uri の値を含む. Client の redirect_uri URI の値は Client ID として送信されるので, redirect_uri パラメータをリクエストの中に含む必要はない (NOT REQUIRED).

scope

必須 (REQUIRED). Section 2.1.1.1 (Request Parameters) で定義されている scope パラメータの値.

id_token_hint

任意 (OPTIONAL). Section 2.1.1.1 (Request Parameters) で定義されている id_token_hint パラメータの値.

registration

任意 (OPTIONAL). このパラメータは, 通常 Dynamic Client Registration (Section 3.2.1 (Providing Information with the "registration" Request Parameter) 参照) を通じて提供される Client 自身に関する情報を, Client が Self-Issued OP に提供する際に利用される.

他のパラメータも送ってもよい (MAY). すべての Claim は ID Token の中で返されることに留意すること.

全体 URL 長は ASCII で 2048 文字を超えてはならない (MUST NOT).

以下は, User Agent が Self-Issued OpenID プロバイダーに対して Authentication Request を生成するためのトリガーとなる, Client による HTTP 302 リダイレクトレスポンスの参考例である. (改行は掲載上の都合による)

  HTTP/1.1 302 Found
  Location: openid://
    ?response_type=id_token
    &client_id=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj
    &registration=%7B%22logo_uri%22%3A%22https%3A%2F%2F
      client.example.org%2Flogo.png%22%7D

3.4.  Self-Issued OpenID Provider Response

Self-Issued OpenID プロバイダーのレスポンスは, 通常の Implicit フローのレスポンスに以下の改変をしたものと同じである. Implicit フローのレスポンスなので, レスポンスパラメータは URL フラグメントコンポーネントの中で返される.

1. iss (issuer) Claim の値が https://self-issued.me である.
2. sub_jwk Claim が存在し, その値が ID Token の署名を検証するための公開鍵となっている.
3. sub (subject) Claim の値は sub_jwk Claim に含まれる鍵の Thumbprint の Base64URL エンコード値である. この Thumbprint は, JWK のメンバーのうち REQUIRED なもののみをそのメンバー名の辞書順にソートし, 空白や改行なしで結合した UTF-8 表現のオクテットを生成し, その SHA-256 ハッシュを計算することで求める. kty の値が RSA である時, キーの値は n と, e が順に結合されたものである. kty の値が EC である時, キーの値は crv と, x と, y が順に結合されたものである. これは JWK Thumbprint [JWK.Thumbprint] (Jones, M. and N. Sakimura, “JSON Web Key (JWK) Thumbprint,” July 2015.) に定義されている.
4. UserInfo エンドポイントへアクセスするための Access Token は返されないため, すべての Claim は ID Token の中で返されなければならない (MUST).

3.5.  Self-Issued ID Token Validation

返された ID Token の検証を行うため, Client は以下のことを実施しなくてはならない (MUST).

1. Client は, iss (issuer) Claim の値が https://self-issued.me であることを検証しなければならない (MUST). もし iss が別の値を含んでいた場合, その ID Token は Self-Issued ではないので, Section 2.2.1 (ID Token Validation) に沿って検証されなければならない (MUST).
2. Client は, Client が認証リクエストで送信した redirect_uri の値が, aud Claim にオーディエンスとして含まれていることを検証しなければならない (MUST).
3. Client は, JOSE Header の alg Header Parameter に指定されたアルゴリズムを使い JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS] に沿って ID Token の署名を検証しなければならない (MUST). その際, sub_jwk Claim の中の鍵を使用する; 鍵は JWK フォーマットの鍵である (X.509 証明書ではない).
4. alg の値はデフォルトとしては RS256 であるべきである (SHOULD). この値は ES256 であってもよい (MAY).
5. Client は sub Claim が sub_jwk Claim に含まれる鍵の Thumbprint の Base64URL エンコード値であることを検証しなければならない (MUST). Section 3.4 (Self-Issued OpenID Provider Response) 参照.
6. 現在時刻が exp Claim より前でなければならない (MUST). (時計のズレを考慮した多少の猶予は許容される)
7. iat Claim が現在時刻からあまりにかけ離れている場合は, そのトークンを拒絶してもよい. これにより nonce の保存期間を制限することができる. 適切な閾値は, Client ごとにことなる.
8. nonce が Authentication Request で送られた場合, nonce Claim が存在し, その値は Authentication Request で送られたものと同じ値であることを検証されなくてはならない (MUST). Client はリプレイアタックを防ぐため nonce の値を検証すべきである (SHOULD). リプレイアタックを検知するための詳細は方法は Client ごとに固有である.

以下は Self-Issued ID Token を Base64URL デコードした参考例である. (改行は掲載上の都合による)

  {
   "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.  Serializations

リクエストメッセージは以下のいずれかの方法でシリアライズできる (MAY).

1. Query String Serialization
2. Form Serialization

4.1.  Query String Serialization

Query String Serialization を使ってパラメータをシリアライズするためには, Client は [W3C.REC‑html401‑19991224] (Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) で定義された application/x-www-form-urlencoded フォーマットを使いパラメータと値をクエリコンポーネントへ追加することで文字列を構成する. Query String Serialization は一般的に HTTP GET リクエストで使用される. 同じシリアライズ手法は URL のフラグメントコンポーネントにパラメータを追加する際にも使用される.

以下はシリアライズの参考例である. (改行は掲載上の都合による)

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

4.2.  Form Serialization

パラメータやその値は, HTTP リクエストのエンティティボディに [W3C.REC‑html401‑19991224] (Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) に定義されているように application/x-www-form-urlencoded フォーマットでパラメータ名とその値を追加することで Form Serialize される. Form Serialization は一般的には HTTP POST リクエストで利用される.

以下はシリアライズの参考例である. (改行は掲載上の都合による)

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

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

5.  String Operations

いくつかの OpenID Connect メッセージを処理する際にはメッセージの中の値を既知の値を比較することが求められる. 例えば, UserInfo エンドポイントから返された Claim Name は sub などの特定の Claim Name と比較される. よって Unicode [UNICODE] (The Unicode Consortium, “The Unicode Standard,” .) 文字列比較処理はセキュリティ上重要な意味を持つ.

したがって, JSON 文字列を他の Unicode 文字列と比較する際は下記の通り実施しなければならない (MUST).

1. JSON に適用されたすべてのエスケープ処理を取り除き Unicode コードポイントの配列を生成する.
2. Unicode Normalization [USA15] (Davis, M. and K. Whistler, “Unicode Normalization Forms,” 06 2015.) を JSON 文字列, もしくは比較対象文字列に対していかなる時点であっても適用してはならない (MUST NOT).
3. 二つの文字列の比較は, Unicode コードポイント同士の等値比較として実施されなければならない (MUST).

いくつかの箇所において, 本ドキュメントはスペースで区切られた文字列のリストを使用している. そのようないかなる場合においても, この目的では ASCII のスペース文字 (0x20) のみを使用しなければならない (MUST).

6.  TLS Version

本ドキュメントでは Transport Layer Security (TLS) が用いられるが, 実際に広く使われているかどうかや既知のセキュリティ脆弱性に依存して, TLS の適切なバージョンはその時々で異なりうる. 本ドキュメント執筆時には, TLS バージョン 1.2 [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.)　が最新であるが, 実装が限定されており, すぐに各実装で利用可能とはいえないかもしれない. TLS バージョン 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) は現在もっとも広く利用されているバージョンで, 最も広範な相互運用性を提供するであろう.

7.  Implementation Considerations

本ドキュメントでは Relying Party が, OAuth Implicit Flow で利用する機能を定義する. Relying Parties は本ドキュメント内で "REQUIRED" であると記載されている, もしくは "MUST" 付きで説明されている機能を実装しなければならない (MUST).

7.1.  Discovery and Registration

OpenID Connect 環境によっては, あらかじめ設定された OpenID Provider や Relying Party を利用することができる. その場合, アイデンティティ情報やサービス情報の Discovery や Client の Dynamic Registration をサポートする必要はないかもしれない.

しかしながら, 事前の信頼構築を前提とせず, Relying Party と OpenID Provider の間での事前予測不可能な形でのインタラクションをサポートする場合には, OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” August 2015.) [OpenID.Discovery] と OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” August 2015.) [OpenID.Registration] によってこれを実現すべきである (SHOULD).

8.  Security Considerations

以下に挙げたもの以外のセキュリティ上の考慮点については, OpenID Connect Core 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” August 2015.) [OpenID.Core] 仕様を参照すること.

8.1.  TLS Requirements

実装する際は TLS をサポートしなくてはならない (MUST). どのバージョンを実装するかは時期によって異なり, 実装時に広く使われているかと既知のセキュリティ上の脆弱性に依存する. 本仕様を執筆している段階では TLS バージョン 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).

TLS を使用する際は, 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 サーバ証明書を検証しなければならない (MUST).

9.  Privacy Considerations

9.1.  Personally Identifiable Information

UserInfo Response は一般的には Personally Identifiable Information (PII) を含む. したがって, 特定の目的のための情報の開示に関する End-User の同意は, 関連する法律に従い, 認可時もしくは認可時に先立って取得されるべきである (SHOULD). 利用目的は一般的には redirect_uris とともに登録される.

必要な UserInfo データだけが Client 側に保管されるべきであり, Client は受信したデータを告知した利用目的と関連づけるべきである (SHOULD).

9.2.  Data Access Monitoring

Resource Server は End-User に対して, 誰が自分のデータにアクセスしたかを監視できよう, 自身の UserInfo へのアクセスログを閲覧可能にべきである (SHOULD).

9.3.  Correlation

Client 間での名寄せの可能性からエンドユーザを保護するため, Pairwise Pseudonymous Identifier (PPID) を sub (subject) として使用することを検討すべきである (SHOULD).

10.  IANA Considerations

This document makes no requests of IANA.

11.  References

11.1. Normative References

11.2. Informative References

11.3. 翻訳プロジェクト

Appendix A.  Acknowledgements

The OpenID Community would like to thank the following people for their contributions to this document:

Naveen Agarwal (naa@google.com), Google

Casper Biering (cb@peercraft.com), Peercraft

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

Tim Bray (tbray@textuality.com), Google

Johnny Bufu (jbufu@janrain.com), Janrain

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

Pamela Dingle (pdingle@pingidentity.com), Ping Identity

George Fletcher (george.fletcher@corp.aol.com), AOL

Roland Hedberg (roland.hedberg@adm.umu.se), University of Umea

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

Edmund Jay (ejay@mgi1.com), Illumila

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

Torsten Lodderstedt (t.lodderstedt@telekom.de), Deutsche Telekom

Nov Matake (nov@matake.jp), Independent

Chuck Mortimore (cmortimore@salesforce.com), Salesforce

Anthony Nadalin (tonynad@microsoft.com), Microsoft

Hideki Nara (hdknr@ic-tact.co.jp), Tact Communications

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

David Recordon (dr@fb.com), Facebook

Justin Richer (jricher@mitre.org), MITRE

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

Luke Shepard (lshepard@fb.com), Facebook

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

Paul Tarjan (pt@fb.com), Facebook

Appendix B.  Notices

Copyright (c) 2015 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.  Document History

[[ To be removed from the final document ]]

-20

• Referenced completed RFCs.
• Added missing URLs in references.
• Corrected a typo in the spelling of self-issued.me.
• Tracked terminology changes made in the referenced IETF specs since errata set 1.
• Updated the RFC 2616 references to RFC 7230 or RFC 7231, as appropriate.

-19

• Referenced specification versions incorporating errata set 1.

-18

• Fixed #947 - Added "kty":"EC" case back to Self-Issued OpenID Provider Response.
• Fixed #954 - Added "NOT RECOMMENDED" to the list of RFC 2119 terms.

-17

• Changed the JWK Thumbprint reference from being normative to informative.
• Updated dates for specs containing errata updates.
• Updated references to pre-final IETF specs.
• Replaced uses of the terms JWS Header, JWE Header, and JWT Header with the JOSE Header term that replaced them in the JOSE and JWT specifications.

-16

• Fixed #926 - Typo in Self-Issued ID Token Validation.
• Fixed #920 - Attack identified against self-issued "sub" values.
• Changed uses of "this specification" to "this document".

-15

• Updated dates for final OpenID Connect specifications.

-14

• Fixed #896 - Replaced the term Authorization Request with Authentication Request, where applicable.
• Incorporated terms defined by the JWT specification.
• Applied proofreading corrections by Michael B. Jones.

-13

• Updated the response_type language.
• Fixed #878 - Generalized description of errors that can be returned when id_token_hint" is used.
• Provided more context in the introduction.
• Expanded the Authentication Request example to show both the 302 redirect response by the Client and the resulting HTTP GET request sent by the User Agent.

-12

• Tracked editorial changes applied to OpenID Connect Core.
• Fixed #862 - Clarified azp definition.
• Fixed #878 - Defined negative response for "id_token_hint".
• Updated the description of the plans to host the site https://self-issued.me/, per tasks #879 and #880.
• Replaced uses of the OpenID Connect Messages and OpenID Connect Standard specifications with OpenID Connect Core.
• Fixed #884 - Changed the descriptions of Basic and Implicit from being profiles to being implementer's guides containing subsets of OpenID Connect Core.

-11

• Fixed #847 - Corrected type of updated_at to number.
• Stated that redirect_uri matches must be exact, with matching performed as described in Section 6.2.1 of RFC 3986 (Simple String Comparison).
• Fixed #854 - Clarified that the acr_values values are in order of preference and that acr_values requests the acr Claim as a Voluntary Claim.
• Fixed #858 - Incorporated elements of the Issuer Identifier definition into the iss Claim description.
• Fixed #859 - Added IMPORTANT NOTE TO READERS about the terminology definitions being a normative part of the specification.

-10

• Stated that sufficient entropy must be present in nonce values to prevent attackers from guessing values.
• Stated that the Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value.
• Restricted the meaning of the azp (authorized party) Claim to simply be the single party to which the ID Token was issued.
• Changed from using the term "byte" to either "octet" or "character".
• Stated that the JWS Compact Serialization is always used for JWS data structures.

-09

• Fixed #825 - Replaced updated_time, which used the RFC 3339 textual time format, with updated_at, using the numeric time format used by iat, etc.
• Fixed #829 - Stated that additional scope values can be defined and used and that scope values that are not understood should be ignored.
• Fixed #831 - Stated that JWS and JWE header parameters used to communicate key values and key references should not be used in ID Tokens, since these are communicated in advance using Discovery and Registration parameters.
• Fixed #712 and #830 - Clarified the azp description and made azp multi-valued, like aud.

-08

• Fixed #802 - Clarified recommendations and responsibilities for producing and consuming Claims with and without language tags.
• Fixed #797 - Clarified the intended semantics of e-mail verification and that the precise verification rules are context-specific.
• Fixed #806 - Added phone_number_verified Claim.
• Fixed #800 - Specified that phone number extensions are to be represented using RFC 3966 extension syntax.
• Fixed #795 - Specified that e-mail addresses must conform to the RFC 5322 addr-spec syntax.
• Fixed #808 - Specified that phone numbers may be used as login_hint values.
• Fixed #801 - Removed schema and id parameters to UserInfo Endpoint. Also fixed related issue #791 - Removed invalid_schema error.
• Fixed #793, #796, and #799 - Allow name Claims to contain multiple space-separated names.
• Fixed #794 - Required picture to refer to an image file that is a picture of the End-User.
• Fixed #811 - Specify that language tag components should be spelled using the character cases registered in the IANA Language Subtag Registry.
• Fixed #812 - Clarified that language tag values used need not be unnecessarily specific.
• Fixed #816 - Changed "must understand" language to "MUST be ignored if not understood".

-07

• Fixed #711 - Awkward phrase "The following Claims are REQUIRED and OPTIONAL".
• Fixed #712 - "azp" definition clarification.
• Fixed #713 - Explicitly require "sub" claim to be returned from UserInfo endpoint.
• Fixed #716 - Client/server 2119 blurriness.
• Fixed #722 - Text on "id_token_hint" needs to be clarified.
• Fixed #718 - Text on re-encrypting should be clearer.
• Fixed #732 - Capitalize name of "Bearer" authentication scheme.
• Fixed #738 - Behavior when "openid" scope is omitted.
• Added Security Considerations section about TLS version requirements and usage.
• Removed language about clients that do not support TLS. Also removed language about supporting other transport-layer mechanisms with equivalent security to TLS.
• State that when any validations fail, any operations requiring the information that failed to correctly validate MUST be aborted and the information that failed to validate MUST NOT be used.
• Added id_token_hint parameter to Implicit, since it SHOULD be present when prompt=none is used.
• Removed vestigial encryption text that had been copied over from Standard, since encryption is not part of the Implicit profile.
• Fixed #742 - Added new ui_locales parameter.
• Fixed #743 - Added claims_locales parameter.
• Fixed #744 - Added max_age parameter.
• Fixed #765 - Added new acr_values parameter.
• Fixed #597 - Changed representation of omitted year in birthdate from 9999 to 0000.
• Fixed #739 - Added registration parameter and members of registration object.
• Deleted top-level policy_url parameter from the Self-Issued case, since it is already a registration parameter member.
• Fixed #778 - Added registration parameter to Self-Issued request example.
• Fixed #782 - Changed uses of "_url" in identifiers to "_uri".
• Consolidated the x509_encryption_uri and jwk_encryption_uri parameters into a combined jwk_uri parameter (per other changes related to #703).
• Fixed #786 - Changed the name of jwk_uri to jwks_uri.
• Clarified when the http scheme can and can not be used in redirect_uri values.
• Stated that the azp Claim is only needed when the party requesting the ID Token is different than the audience of the ID Token.
• Use legal acr values in examples.
• Fixed #789 - Added amr (authentication methods references) Claim.

-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 MUST 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)

Appendix D.  翻訳者

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

• Kaoru Maeda (Lepidum Co. Ltd.)
• Naohiro Fujie (Itochu Techno Solutions)

Authors' Addresses