OpenID Connect Basic Client Implementer's Guide 1.0 - draft 37

Abstract

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

本ドキュメント OpenID Connect Basic Client Implementer's Guide 1.0 は, OpenID Connect Core 1.0 仕様のサブセットであり, OAuth Authorization Code Flow を利用して Web ベースの Relying Party を実装する際に読みやすいように構成されている. 本ドキュメントは Core 仕様と重複したコンテンツを含んでいるが, それは実装者が本ドキュメントを読むだけで OAuth Authorization Code 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.  Code 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.6.  Client Obtains ID Token and Access Token
            2.1.6.1.  Client Sends Code
            2.1.6.2.  Client Receives Tokens
    2.2.  ID Token
        2.2.1.  ID 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.  Serializations
    3.1.  Query String Serialization
    3.2.  Form Serialization
4.  String Operations
5.  TLS Version
6.  Implementation Considerations
    6.1.  Discovery and Registration
7.  Security Considerations
    7.1.  TLS Requirements
8.  Privacy Considerations
    8.1.  Personally Identifiable Information
    8.2.  Data Access Monitoring
    8.3.  Correlation
    8.4.  Offline Access
9.  IANA Considerations
10.  References
    10.1.  Normative References
    10.2.  Informative References
    10.3.  翻訳プロジェクト
Appendix A.  Acknowledgements
Appendix B.  Notices
Appendix C.  Document History
Appendix D.  翻訳者
§  Authors' Addresses

1.  Introduction

本ドキュメント OpenID Connect Basic 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.) Authorization Code Flow を利用して Web ベースの Relying Party を実装する際に読みやすいように構成されている. 本ドキュメントは Core 仕様と重複したコンテンツを含んでいるが, それは実装者が本ドキュメントを読むだけで OAuth Authorization Code Flow を利用した Relying Party を実装できるよう意図したものである. 本実装者ガイドと OpenID Connect Core 仕様の間に齟齬がある場合は, Core 仕様を優先する.

OAuth Implicit Flow を利用する Web ベースの Relying Party を実装する場合には, OpenID Connect Implicit Client Implementer's Guide 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Implicit Client Implementer's Guide 1.0,” July 2015.) [OpenID.Implicit] を参照のこと. OpenID Provider および Web ベース以外のアプリケーションの実装者は, Core 仕様を参照のこと. 本ガイドは OpenID Provider および Web ベース以外のアプリケーションに関する Implimentation Consideration および 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 Authentication", "Client Identifier", "Client Secret", "Grant Type", "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.

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) を取得できるようにするものである.

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

2.1.  Code Flow

Code 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 を code とともに Client に戻す.
6. Client は code を Token Endpoint に送信し, Access Token と ID Token を受け取る.
7. Client はそれらのトークンを検証し, End-User の Subject Identifier を取得する.

2.1.1.  Client Prepares Authentication Request

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

Authorization Endpoint との間の通信は TLS を利用しなければならない (MUST). TLS の詳細については Section 7.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 3.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=code
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj

2.1.1.1.  Request Parameters

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

response_type

REQUIRED. 値は code とすること (MUST). これにより Authorization Endpoint から返される code と交換で, Access Token および ID Token が Token Endpoint から返されることになる.

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 は https スキーマを利用することが望まれる (SHOULD) が, Client Type が confidential であり, かつ OP が http の利用を容認する場合に限り, http スキーマを利用してもよい (MAY). Client Type 等の定義については OAuth 2.0 の Section 2.1 を参照のこと. Redirection URI には, ネイティブアプリケーションにコールバックを送る目的などで, 上記以外のスキーマを利用することもできる.

state

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

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

nonce

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

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 としてリクエストされることになる.

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=code
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj

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

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

2.1.3.  Authorization Server Authenticates End-User

Authorization Server は, リクエストパラメータ値に基づき, End-User をログインさせたり既にログイン済みであることを検証する. End-User とのインタラクションが HTTP で行われる場合は, Section 7.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 は code を発行し, OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の Section 4.1.2 に従い, 以下のクエリパラメータを Redirection URI のクエリー部に application/x-www-form-urlencoded フォーマットで付与して Client に渡す.

code

REQUIRED. OAuth 2.0 Authorization Code.

state

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

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

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    code=SplxlOBeZQQYbYS6WxSbIA
    &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.1.2.1 に従ってエラーの Authorization Response を返さなければならない (MUST). (RFC 6749 に関係のないエラーは, 適切な HTTP ステータスコードを用いて User Agent に返すこと)

2.1.6.  Client Obtains ID Token and Access Token

次に Client は, 以下のように Token Endpoint に対して Authorization Code を付与した形で Access Token Request を送る.

2.1.6.1.  Client Sends Code

Client は OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の Section 4.1.3 にあるように, Token Endpoint に対して Form Serialization (Section 3.2 (Form Serialization)) を用いてリクエストを送る. ここで Client は OAuth 2.0 の Section 2.3.1 に従い, 自身の Client Credentials を HTTP Basic 方式で Authorization ヘッダーに付与して認証を行う. (この方法は OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” August 2015.) [OpenID.Discovery] において client_secret_basic と呼ばれているものである)

Token Endpoint との通信は TLS を用いること (MUST). TLS の利用についての詳細は Section 7.1 (TLS Requirements) を参照.

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

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

  grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

2.1.6.2.  Client Receives Tokens

Client は OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Section 4.1.4 にあるように, 以下のパラメーターをレスポンスとして受け取る. レスポンスは UTF-8 エンコード [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.) とすること (SHOULD).

access_token

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

token_type

REQUIRED. OAuth 2.0 Token Type 値. この値は Clients が 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.

expires_in

OPTIONAL. Access Token が生成されてから期限切れになるまでの秒数.

refresh_token

OPTIONAL. Refresh Token.

次に Client は Access Token を使って Resource Server 上の保護リソースにアクセスする.

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

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

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

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

OPTIONAL. Access Token のハッシュ値. ID Token が Token Endpoint から発行される場合には, 任意 (OPTIONAL) であるが, その場合にも at_hash Claim を含めてもよい (MAY). この値は, access_token の ASCII オクテット列のハッシュ値の左半分を Basd64URL エンコードしたものであり, ハッシュアルゴリズムは ID Token の JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS] ヘッダーにある alg で用いられるハッシュアルゴリズムと同じものを用いる. 例えば 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 は大文字小文字を区別する文字列である.

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

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

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

  {
   "iss": "https://server.example.com",
   "sub": "24400320",
   "aud": "s6BhdRkqt3",
   "exp": 1311281970,
   "iat": 1311280970
  }

2.2.1.  ID Token Validation

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

Client は Token Response に含まれる ID Token をバリデートしなければならない (MUST). ID Token のバリデーションの為に, Client は ID Token をピリオド (".") で分割し, 2番目のセグメントを Base64URL デコードして ID Token Claim を含む JSON オブジェクトを取得する. この JSON オブジェクトのバリデーションは以下の通りとする (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. 現在時刻が exp Claim より前でなければならない (MUST). (時計のズレを考慮した多少の猶予は許容される)
6. iat Claim が現在時刻からあまりにかけ離れている場合は, そのトークンを拒絶してもよい. これにより nonce の保存期間を制限することができる. 適切な閾値は, Client ごとにことなる.
7. acr Claim がリクエストに含まれていた場合, Client は ID Token の acr Claim が適切かどうか検証すべきである (SHOULD). acr Claim Value とその意味は, 本ドキュメントの定めるところではない.
8. max_age Claim がリクエストに含まれていた場合, Client は ID Token の auth_time Claim をチェックし, 最後の End-User 認証からあまりに時間が経過している場合には再認証を要求すべきである (SHOULD).

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 7.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 エンコードされる (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

OPTIONAL. OAuth 2.0 Refresh Token 発行要求に用いる. Refresh Token は End-User とのインタラクションを介さずに UserInfo Endpoint にアクセスするための Access Token を発行する為に用いる.

複数の 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 セットを定義する. これらは UserInfo Response として返される.

以下に例を示す.

  {
   "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] (IANA, “Language Subtag Registry,” .) に登録されたままの表記とすることを強く推奨する (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.  Serializations

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

1. Query String Serialization
2. Form Serialization

3.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 リクエストで使用される.

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

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

3.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=code
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

4.  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).

5.  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.) は現在もっとも広く利用されているバージョンで, 最も広範な相互運用性を提供するであろう.

6.  Implementation Considerations

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

6.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).

7.  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] 仕様を参照すること.

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

8.  Privacy Considerations

8.1.  Personally Identifiable Information

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

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

8.2.  Data Access Monitoring

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

8.3.  Correlation

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

8.4.  Offline Access

オフラインアクセスにより, ユーザが居合せない場合でも Claims にアクセスできるようになるが, これはユーザーが居合わせる場合の Claim アクセスよりも大きなプライバシー上のリスクをもたらす. したがって, リソースへのオフラインアクセスを行う場合には明示的な同意を得ることが賢明である. 本ドキュメントでは, リクエストが各法域 (jurisdiction: 法律用語, ある法律が適用される地域のこと) において処理可能な条件を満たしていることが既知でない場合には, 同意を得るために prompt パラメータを利用することを要求する.

Access Token がフロントチャネルから返って来た時に, トークンが攻撃者にさらされている危険性はおおいにあり, その場合, 攻撃者は後でトークンを使って UserInfo エンドポイントにアクセスできる. Access Token がオフラインアクセスを許可しておらず, Client から送られてきたリクエストがオフラインかオンラインかをサーバが区別することができれば, リスクは十分に軽減できる. したがって本ドキュメントでは, Access Token がフロントチャネルを通して送られてきた場合にはオフラインアクセスのリクエストを無視することを要求する. サーバ側でオンラインとオフラインを区別することは, 特にネイティブクライアントの時は難しいかもしれないことには注意が必要である. サーバ側では試行錯誤が必要になるかもしれない. また, Response Types が code token もしくは token の場合にもフロントチャネルを経由したAccess Tokenのさらされる危険性は同じである. したがって, 実装はどのようなチャネルで Access Token が発行されたかを検知できるよう準備し, トークンがフロントチャネル経由で発行された場合にはオフラインアクセスを拒否するべきである.

これらの規定では prompt パラメータを使って明示的な同意ダイアログを要求するが, ユーザが "accept" ボタンを押したなどの単なる事実では, 有効な同意とみなされないかもしれないことに注意が必要である. 開発者は, 一般的に同意の行為が有効であるためには, 同意項目の影響が End-User によって理解されなければならないこと, 同意は (例えば, 他のオプションが選択可能であるなど) 強制ではなく自由意志でなされなければならないこと, そして同意項目は公正かつ衡平でなければならないことに注意すべきである. 一般的にはサービスは各々の法域で要求されるプライバシー指針に従うこと, そしてリクエストを処理するのに, オンラインのセルフサービスの "explicit consent" は法域によっては有効な同意を形成しないので, 単に明示的な同意以外に依拠することが推奨される.

9.  IANA Considerations

This document makes no requests of IANA.

10.  References

10.1. Normative References

10.2. Informative References

10.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 ]]

-37

• Referenced completed RFCs.
• Added missing URLs in references.
• Changed to use "Cache-Control: no-cache, no-store" and "Pragma: no-cache" in examples.
• 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.

-36

• Referenced specification versions incorporating errata set 1.

-35

• 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.
• Fixed #954 - Added "NOT RECOMMENDED" to the list of RFC 2119 terms.

-34

• Fixed #918 - Wording inconsistency in Token Request language.
• Changed uses of "this specification" to "this document".

-33

• Updated dates for final OpenID Connect specifications.

-32

• Editorial corrections.

-31

• 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.

-30

• 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.

-29

• Tracked editorial changes applied to OpenID Connect Core.
• Fixed #862 - Clarified azp definition.
• Fixed #878 - Defined negative response for "id_token_hint".
• 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.

-28

• 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.

-27

• Fixed #834 - Described how to optionally use nonce values in the Basic specification.
• Fixed #833 - Stated that an at_hash Claim MAY be present in the ID Token.
• 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.
• Stated that the JWS Compact Serialization is always used for JWS data structures.

-26

• 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.

-25

• 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".

-24

• 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 #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 Basic, since it SHOULD be present when prompt=none is used.
• 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 #726 - Client authentication clarifications.
• 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.

-23

• Fixed #620 - Update Section 2.2.6.2. to allow for other token types, but make bearer mandatory to support for basic clients.
• Added Implementation Considerations section.
• Fixed #698 - Inconsistent use of articles.
• Added auth_time definition to ID Token schema.
• Fixed #655 - Specify UTF-8 as encoding scheme whenever necessary.

-22

• 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 #539 - Add scope for offline access.
• Fixed #689 - added caution about unrecognized audiences.
• Fixed #693 Added login_hint
• Updated scopes text.

-21

• added informative definition of nonce in 2.2.1
• Clarified that the client MUST check that the issuer is valid for the token endpoint
• RE #607 add example decoded id_token for non self-issued.
• 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.

-20

• Added preferred_username claim under profile scope
• Added ID Token section to describe required claims
• Added section on claim stability

-19

• Fixed Section 2.2.5.1 to return code in a query parameter rather than a fragment
• Removed claims_in_id_token scope value, per decision on June 15, 2012 special working group call

-18

• Use "code" response_type instead of "token id_token" in Basic Profile, per issue #567
• Changed verified to email_verified, per issue #564
• Removed Check ID Endpoint, per issue #570
• Removed requirement for ID Token signature validation from Basic Profile, per issue #568
• Removed use of nonce from Basic Profile, per issue #569
• 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)

-17

• Removed "embedded" display type, since its semantics were not well defined, per issue #514
• Add hash and hash check of access_token and code to id_token, per issue #510
• Add example JS code for client
• Updated Notices
• Updated References

-16

• Added iat as a required claim in ID Tokens
• Enumerated claims requested by the "profile" scope value
• Added text about implicit flow to Abstract

-15

• Removed definition and usage for assertion and claim object
• email scope allows access to the 'verified' claim
• Removed language pertaining to custom userinfo schemas
• Moved display=none to prompt=none
• Added additional 'display' parameter options
• Redefined 'nonce' in Authorization Request. Changed to REQUIRED parameter.
• Changed usage of "approval" to "consent"
• Use RFC 6125 to verify TLS endpoints
• Allow other gender strings in UserInfo schema
• ID Token MUST be JWT
• RECOMMENDED E.164 format for UserInfo 'phone_number' claim
• Changed UserInfo Error Response to augment and return OAuth 2.0 Bearer Token Error Response
• Check ID Endpoint SHOULD use POST
• Added section about string comparison rules needed
• Added Response Encoding according to Multiple Response Types spec
• Make openid scope provide user_id from userinfo endpoint
• Changed Security Considerations to refer to corresponding section in Standard
• Check ID Endpoint uses ID Token as Access Token according to Bearer Token spec
• Update John Bradley email and affiliation for Implementer's Draft
• Removed invalid_id_token error codes
• Replace queryString with postBody variable in example JS

-14

• Changed section 3.2.1 to refer to access_token ticket #134.
• Bumped version + date.
• Changed 7.4 in security considerations to show none is REQUIRED.
• Changed 3.2.4.1 User Info to UserInfo per Ticket #137.
• Changed formatting of 7.1 per ticket #140.

-13

• 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.

-12

• Ticket #48 Changed Check Session to take the id_token as a parameter.

-11

• Renamed from "Lite" to "Basic Client".
• Numerous cleanups, including updating references.

-10

• Add back id_token to the response type per issue 27.
• Changed endpoint name in example from id_token to check_session.
• Added token_type to the response and explanations of the optional parameters.

-09

• Clean up typos.
• Clean up scope explanation.
• Fix 3.2.4.1 to include id_token in response.

-08

• Added note about OP needing to read the full spec.
• Reverted back to GET for introspection based on Google feedback.
• Changed scopes to openid, profile, address, and email to make them additive.
• Changed introspection to Check Session Endpoint to be consistent with session management.
• Changed validation rules, the Check session endpoint will return an error for expired or invalid tokens, so the Client doesn't need to check expiration.
• Added explanation of why an id_token is used to verify identity rather than the userinfo Access Token.

-07

• Changed introspection to post
• Changed userinfo from id to user_id to be consistent with introspection endpoint.
• Fixed introspection example to use id_token rather than access token.
• Removed asking for id_token in response type.
• Fixed Section 3 to be clear it is client secret that is maintained between the client and the OP.

-06

• Only require the token flow in Lite. Removed code flow.
• Make id_token required. The id_token is treated as opaque.
• Rearranged sections for readability.
• Dropped the schema parameter to the Introspection endpoint, which was formerly a string with the value user_id. This is unnecessary since the id_token parameter already can be used to disambiguate the intended uses(s) of the endpoint.
• Dropped the requested audience from the Lite spec, which was formerly the identifier of the target audience of the response. This could be part of the Standard spec, but is an advanced scenario, and so not appropriate for Lite.
• Reference the Discovery and Registration specs, since they're needed for interaction between non-pre-configured parties (so that OpenID Connect installations can be Open).

-05

• Corrected issues raised by Casper Biering.
• Created the OpenID Connect Lite specification.

-04

• Correct issues raised by Pam Dingle and discussed on the mailing list after the 7-Jul-11 working group call.
• Adopted long_names.

-03

• Correct issues raised by Johnny Bufu and discussed on the 7-Jul-11 working group call.

-02

• Consistency and cleanup pass, including removing unused references.

-01

• Initial draft

Appendix D.  翻訳者

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

• Nov Matake
• Yutaka Obuchi (Hitachi Solutions)

Authors' Addresses