OpenID Connect Core 1.0 incorporating errata set 1

Abstract

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

この仕様は, OpenID Connect の主要な機能である OAuth 2.0 上で End-User の情報伝達のために Claim を用いる認証機能 を定義する. この仕様はまた, OpenID Connect を利用するための Security, Privacy Considerations を説明する.

Table of Contents

1.  Introduction
    1.1.  Requirements Notation and Conventions
    1.2.  Terminology
    1.3.  Overview
2.  ID Token
3.  Authentication
    3.1.  Authentication using the Authorization Code Flow
        3.1.1.  Authorization Code Flow Steps
        3.1.2.  Authorization Endpoint
            3.1.2.1.  Authentication Request
            3.1.2.2.  Authentication Request Validation
            3.1.2.3.  Authorization Server Authenticates End-User
            3.1.2.4.  Authorization Server Obtains End-User Consent/Authorization
            3.1.2.5.  Successful Authentication Response
            3.1.2.6.  Authentication Error Response
            3.1.2.7.  Authentication Response Validation
        3.1.3.  Token Endpoint
            3.1.3.1.  Token Request
            3.1.3.2.  Token Request Validation
            3.1.3.3.  Successful Token Response
            3.1.3.4.  Token Error Response
            3.1.3.5.  Token Response Validation
            3.1.3.6.  ID Token
            3.1.3.7.  ID Token Validation
            3.1.3.8.  Access Token Validation
    3.2.  Authentication using the Implicit Flow
        3.2.1.  Implicit Flow Steps
        3.2.2.  Authorization Endpoint
            3.2.2.1.  Authentication Request
            3.2.2.2.  Authentication Request Validation
            3.2.2.3.  Authorization Server Authenticates End-User
            3.2.2.4.  Authorization Server Obtains End-User Consent/Authorization
            3.2.2.5.  Successful Authentication Response
            3.2.2.6.  Authentication Error Response
            3.2.2.7.  Redirect URI Fragment Handling
            3.2.2.8.  Authentication Response Validation
            3.2.2.9.  Access Token Validation
            3.2.2.10.  ID Token
            3.2.2.11.  ID Token Validation
    3.3.  Authentication using the Hybrid Flow
        3.3.1.  Hybrid Flow Steps
        3.3.2.  Authorization Endpoint
            3.3.2.1.  Authentication Request
            3.3.2.2.  Authentication Request Validation
            3.3.2.3.  Authorization Server Authenticates End-User
            3.3.2.4.  Authorization Server Obtains End-User Consent/Authorization
            3.3.2.5.  Successful Authentication Response
            3.3.2.6.  Authentication Error Response
            3.3.2.7.  Redirect URI Fragment Handling
            3.3.2.8.  Authentication Response Validation
            3.3.2.9.  Access Token Validation
            3.3.2.10.  Authorization Code Validation
            3.3.2.11.  ID Token
            3.3.2.12.  ID Token Validation
        3.3.3.  Token Endpoint
            3.3.3.1.  Token Request
            3.3.3.2.  Token Request Validation
            3.3.3.3.  Successful Token Response
            3.3.3.4.  Token Error Response
            3.3.3.5.  Token Response Validation
            3.3.3.6.  ID Token
            3.3.3.7.  ID Token Validation
            3.3.3.8.  Access Token
            3.3.3.9.  Access Token Validation
4.  Initiating Login from a Third Party
5.  Claims
    5.1.  Standard Claims
        5.1.1.  Address Claim
        5.1.2.  Additional Claims
    5.2.  Claims Languages and Scripts
    5.3.  UserInfo Endpoint
        5.3.1.  UserInfo Request
        5.3.2.  Successful UserInfo Response
        5.3.3.  UserInfo Error Response
        5.3.4.  UserInfo Response Validation
    5.4.  Requesting Claims using Scope Values
    5.5.  Requesting Claims using the "claims" Request Parameter
        5.5.1.  Individual Claims Requests
            5.5.1.1.  Requesting the "acr" Claim
        5.5.2.  Languages and Scripts for Individual Claims
    5.6.  Claim Types
        5.6.1.  Normal Claims
        5.6.2.  Aggregated and Distributed Claims
            5.6.2.1.  Example of Aggregated Claims
            5.6.2.2.  Example of Distributed Claims
    5.7.  Claim Stability and Uniqueness
6.  Passing Request Parameters as JWTs
    6.1.  Passing a Request Object by Value
        6.1.1.  Request using the "request" Request Parameter
    6.2.  Passing a Request Object by Reference
        6.2.1.  URL Referencing the Request Object
        6.2.2.  Request using the "request_uri" Request Parameter
        6.2.3.  Authorization Server Fetches Request Object
        6.2.4.  "request_uri" Rationale
    6.3.  Validating JWT-Based Requests
        6.3.1.  Encrypted Request Object
        6.3.2.  Signed Request Object
        6.3.3.  Request Parameter Assembly and Validation
7.  Self-Issued OpenID Provider
    7.1.  Self-Issued OpenID Provider Discovery
    7.2.  Self-Issued OpenID Provider Registration
        7.2.1.  Providing Information with the "registration" Request Parameter
    7.3.  Self-Issued OpenID Provider Request
    7.4.  Self-Issued OpenID Provider Response
    7.5.  Self-Issued ID Token Validation
8.  Subject Identifier Types
    8.1.  Pairwise Identifier Algorithm
9.  Client Authentication
10.  Signatures and Encryption
    10.1.  Signing
        10.1.1.  Rotation of Asymmetric Signing Keys
    10.2.  Encryption
        10.2.1.  Rotation of Asymmetric Encryption Keys
11.  Offline Access
12.  Using Refresh Tokens
    12.1.  Refresh Request
    12.2.  Successful Refresh Response
    12.3.  Refresh Error Response
13.  Serializations
    13.1.  Query String Serialization
    13.2.  Form Serialization
    13.3.  JSON Serialization
14.  String Operations
15.  Implementation Considerations
    15.1.  Mandatory to Implement Features for All OpenID Providers
    15.2.  Mandatory to Implement Features for Dynamic OpenID Providers
    15.3.  Discovery and Registration
    15.4.  Mandatory to Implement Features for Relying Parties
    15.5.  Implementation Notes
        15.5.1.  Authorization Code Implementation Notes
        15.5.2.  Nonce Implementation Notes
        15.5.3.  Redirect URI Fragment Handling Implementation Notes
    15.6.  Compatibility Notes
        15.6.1.  Pre-Final IETF Specifications
        15.6.2.  Google "iss" Value
    15.7.  Related Specifications and Implementer's Guides
16.  Security Considerations
    16.1.  Request Disclosure
    16.2.  Server Masquerading
    16.3.  Token Manufacture/Modification
    16.4.  Access Token Disclosure
    16.5.  Server Response Disclosure
    16.6.  Server Response Repudiation
    16.7.  Request Repudiation
    16.8.  Access Token Redirect
    16.9.  Token Reuse
    16.10.  Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)
    16.11.  Token Substitution
    16.12.  Timing Attack
    16.13.  Other Crypto Related Attacks
    16.14.  Signing and Encryption Order
    16.15.  Issuer Identifier
    16.16.  Implicit Flow Threats
    16.17.  TLS Requirements
    16.18.  Lifetimes of Access Tokens and Refresh Tokens
    16.19.  Symmetric Key Entropy
    16.20.  Need for Signed Requests
    16.21.  Need for Encrypted Requests
17.  Privacy Considerations
    17.1.  Personally Identifiable Information
    17.2.  Data Access Monitoring
    17.3.  Correlation
    17.4.  Offline Access
18.  IANA Considerations
    18.1.  JSON Web Token Claims Registration
        18.1.1.  Registry Contents
    18.2.  OAuth Parameters Registration
        18.2.1.  Registry Contents
    18.3.  OAuth Extensions Error Registration
        18.3.1.  Registry Contents
19.  References
    19.1.  Normative References
    19.2.  Informative References
Appendix A.  Authorization Examples
    A.1.  Example using response_type=code
    A.2.  Example using response_type=id_token
    A.3.  Example using response_type=id_token token
    A.4.  Example using response_type=code id_token
    A.5.  Example using response_type=code token
    A.6.  Example using response_type=code id_token token
    A.7.  RSA Key Used in Examples
Appendix B.  Acknowledgements
Appendix C.  Notices
§  Authors' Addresses

1.  Introduction

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

OpenID Connect Core 1.0 仕様は, OpenID Connect の主要な機能である OAuth 2.0 上で End-User の情報伝達のために Claim を用いる認証機能 を定義する. この仕様はまた, OpenID Connect を利用するための Security, Privacy 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 を送信する. 認証結果は ID Token (Section 2 (ID Token) 参照) と呼ばれる JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.) [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,” November 2014.) [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,” November 2014.) [OpenID.Registration] にある Dynamic Registration を通じて行われるが, その他の手段で行われることもある.

1.1.  Requirements Notation and Conventions

本ドキュメント中の "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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),” July 2014.) [JWS] と JSON Web Encryption (JWE) (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2014.) [JWE] を用いる場合, シリアライゼーションには JWS Compact Serialization と JWE Compact Serialization を用いる. JWS JSON Serialization と JWE JSON Serialization は利用しない.

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),” July 2014.) [JWT] で定義された "Claim Name", "Claim Value", "JSON Web Token (JWT)", "JWT Claims Set", および "Nested JWT", JSON Web Signature (JWS) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.) [JWS] で定義された "Header Parameter" および "JOSE Header", RFC 2616 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] で定義された "User Agent", 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] で定義された "Response Mode" という用語を用いる.

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

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 となる.

Authentication Context

認証応答に関する意思決定を行う前に Relying Party が要求できる情報. そのようなコンテキストは実際に用いられた認証方式や ISO/IEC 29115 (International Organization for Standardization, “ISO/IEC 29115:2013 -- Information technology - Security techniques - Entity authentication assurance framework,” March 2013.) [ISO29115] entity authentication assurance level のような保障レベルを含むが, これに限定されるものではない.

Authentication Context Class

特定のコンテキストで互いに等しいと考えられる認証方式もしくは手続きの集合.

Authentication Context Class Reference

Authentication Context Class の識別子.

Authorization Code Flow

Authorization Code が Authorization Endpoint から返され, 全てのトークンが Token Endpoint から返されるOAuth 2.0 のフロー.

Authorization Request

[RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) にて定義された OAuth 2.0 Authorization Request.

Claim

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

Claim Type

Claim の値を表現する構文. 本仕様では Normal, Aggregated, および Distributed という Claim Type を定義する.

Claims Provider

Entity の Claim を返すサーバー.

Credential

Identity や他のリソースを使用する権利があることの証拠として提示されるデータ.

End-User

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

Entity

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

Essential Claim

Client により指定される Claim. End-User により要求された特定のタスクに対して円滑な認可処理を確保するために必要とされている.

Hybrid Flow

Authorization Code といくつかのトークンが Authorization Endpoint から返され, その他のトークンが Token Endpoint から返される OAuth 2.0 のフロー.

ID Token

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

Identifier

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

Identity

Entity に関する属性の集合.

Implicit Flow

全てのトークンが Authorization Endpoint から返され, Token Endpoint も Authorization Code も利用されない OAuth 2.0 のフロー.

Issuer

Claim の集合を発行する Entity.

Issuer Identifier

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

Message

OpenID Relying Party と OpenID Provider の間でやりとりされるリクエストもしくはレスポンス.

OpenID Provider (OP)

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

Request Object

Claim としてリクエストパラメータを含む JWT.

Request URI

Request Object を含むリソースを参照する URL. Request URI のコンテンツは Authorization Server から取得可能でなければならない (MUST).

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.

Sector Identifier

Relying Party により利用される URL のホスト要素. Relying Party に対する Subject Identifier 計算の入力となる.

Self-Issued OpenID Provider

自己署名の ID Token を発行する, 個人的で self-hosted な OpenID Provider.

Subject Identifier

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

UserInfo Endpoint

Protected Resource のひとつ. Access Token を提示する Client に対して, Authorization Grant に従って End-User に関する情報を提供する. URLは https scheme を利用しなければならず (MUST), ポート番号, パス, クエリパラメータの要素を含むことがある (MAY).

Validation

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

Verification

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

Voluntary Claim

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

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

利用される用語の一部分の詳細を知るために, Internet Security Glossary, Version 2 (Shirey, R., “Internet Security Glossary, Version 2,” August 2007.) [RFC4949], ISO/IEC 29115 Entity Authentication Assurance (International Organization for Standardization, “ISO/IEC 29115:2013 -- Information technology - Security techniques - Entity authentication assurance framework,” March 2013.) [ISO29115], および ITU-T X.1252 (International Telecommunication Union, “ITU-T Recommendation X.1252 -- Cyberspace security -- Identity management -- Baseline identity management terms and definitions,” November 2010.) [X.1252] を参照すること.

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.  ID Token

End-User の認証を可能にするために OpenID Connect が OAuth 2.0 に追加する最大の拡張機能は ID トークンデータ構造である. 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),” July 2014.) [JWT] である.

OpenID Connect で使用されている全ての OAuth 2.0 のフローで ID Token が利用され, その 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-01T0:0:0Z から該当時刻までの秒数を示す JSON 数値である. 詳細は RFC 3339 (Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) [RFC3339] を参照のこと.

iat

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

auth_time

End-User の認証が発生した時刻. この値は UTC 1970-01-01T0:0:0Z から該当時刻までの秒数を示す JSON 数値である. リクエストに max_age が含まれていた場合, この Claim は必須である (REQUIRED). その他の場合は任意 (OPTIONAL). (auth_time Claim は, OpenID 2.0 PAPE (Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider Authentication Policy Extension 1.0,” December 2008.) [OpenID.PAPE] auth_time レスポンスパラメーターに相当する)

nonce

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

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). (OpenID 2.0 PAPE (Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider Authentication Policy Extension 1.0,” December 2008.) [OpenID.PAPE] nist_auth_level 0 に相当する) 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). この仕様によって定義される追加の Claim のための 3.1.3.6 (ID Token), 3.3.2.11 (ID Token), 5.1 (Standard Claims) と 7.4 (Self-Issued OpenID Provider Response) セクションを参照すること.

ID Token は JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.) [JWS] を使って署名されなければならない (MUST). また任意で JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.) [JWS] によって署名し, JWE (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2014.) [JWE] によって暗号化することもできる. これにより, 認証, 完全性, 否認防止, および任意で機密性を提供する (Section 16.14 (Signing and Encryption Order) 参照). ID Token を暗号化する場合は, 署名を行った後に暗号化しなければならない (MUST). 署名後に暗号化することにより, [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.) にある Nested JWT が生成される. ID Token には, alg として none を用いてはならない (MUST NOT). ただし Response Type が Authorization Endpoint から ID Token を返すものでない場合 (Authorization Code Flow 等) で, かつ Client が明示的に Registration 時に none の利用を要求した場合には, この限りではない.

ID トークンは JWS あるいは JWE の x5u, x5c, jku と jwk ヘッダーパラメーターフィールド を使用すべきではない (SHOULD NOT). 代わりに, 使用される鍵への参照を Discovery と Registration parameters を用いて事前に伝えること. (Section 10 (Signatures and Encryption) 参照)

以下は ID トークン中の Claim Set (JWT Claim Set) の一例である.

  {
   "iss": "https://server.example.com",
   "sub": "24400320",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "auth_time": 1311280969,
   "acr": "urn:mace:incommon:iap:silver"
  }

3.  Authentication

OpenID Connect では, End-User をログインさせる, もしくは既にログイン済みであることを確認するため, 認証が行われる. OpenID Connect は Server が実施した Authentication の結果が Client にセキュアな方法で返されるため, Client はその結果を信頼する (rely) ことができる. このような背景から, OpenID Connect では Client のことを Relying Party (RP) と呼ぶ.

Authentication 結果は ID Token に含まれて返却される. (Section 2 (ID Token) 参照) ID Token には Issuer, Subject Identifier, 認証の有効期限などを表す Claim が含まれる.

認証フローには, Authorization Code Flow (response_type=code), Implicit Flow (response_type=id_token token もしくは response_type=id_token) および Hybrid Flow (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] で定義される他のレスポンスタイプ値) の3種類が存在する. 各フローによって, ID Token と Access Token がどのように Client へ返却されるかが異なる.

3つのフローの特徴を以下の参考表に記載する. この表は, 特定のコンテキストにおいてどのフローを選択すればよいかの指針を示すものである.

どのフローを利用するかは, Authorization リクエスト中の response_type 値によって決定される. それぞれの response_type 値とフローの対応を以下に示す.

OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] で定義されている code 以外の Response Type 値は, 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] に定義される. 注) OAuth 2.0 は Implicit Flow に Response Type token という値を定義してはいるが, その場合 ID Token が返却できないため, OpenID Connect ではこの Response Type は利用しない.

3.1.  Authentication using the Authorization Code Flow

この章では Authorization Code Flow での認証フローについて述べる. Authorization Code Flow を利用する場合, 全てのトークンは Token Endpoint から返される.

Authorization Code Flow では Client に Authorization Code を返却し, Client はそれを直接 ID Token および Access TOken と交換する. これにより, User Agent や User Agent 上の他の不正アプリケーションなどにトークンも露呈することがない. Authorization Server は, Authorization Code を Access Token と交換する前に Client を認証することもできる. Authorization Code Flow は, Client Secret を Client と Authorization Server の間でセキュアに保てる Client に適している.

3.1.1.  Authorization Code Flow Steps

Authorization Code Flow の流れは以下通りである.

1. Client は必要なパラメータを含む Authentication Request を用意する.
2. Client は Authorization Server にリクエストを送信する.
3. Authorization Server は End-User を Authenticate する.
4. Authorization Server は End-User の Consent/Authorization を得る.
5. Authorization Server は Authorization Code を添えて End-User を Client に戻す.
6. Client は Token Endpoint へ Authorization Code を送信する.
7. Client は ID Token と Access Token をレスポンスボディに含むレスポンスを受け取る.
8. Client は ID Token を検証し, End-User の Subject Identifier を取得する.

3.1.2.  Authorization Endpoint

Authorization Endpoint は End-User の認証を実行する. この処理は, OAuth 2.0 で定義された要求パラメータ及び OpenID Connect で定義された追加されたパラメータとパラメータ値を使用して, 認証及び認可のためにユーザーエージェントを Authorization Server の Authorization Endpoint に送ることで行われる.

Authorization Endpoint との通信は TLS を用いなければならない (MUST). TLSの利用についての詳細な情報は Section 16.17 (TLS Requirements) を参照すること.

3.1.2.1.  Authentication Request

Authentication Request は Authorization Server による End-User の認証を要求する OAuth 2.0 の Authorization Request である.

Authorization Server は Authorization Endpoint において RFC 2616 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] で定義された HTTP GET メソッドと HTTP POST メソッドをサポートしなければならない (MUST). クライアントは Authorization Server への Authorization Request の送信に HTTP GET メソッドか HTTP POST メソッドを使用できる (MAY). HTTP GET メソッドを使用する場合, リクエストパラメータは URI Query String Serialization ( Section 13.1 (Query String Serialization) ) に従ってシリアライズされる. HTTP POST メソッドを使用する場合, リクエストパラメータは Form Serialization ( Section 13.2 (Form Serialization) ) に従ってシリアライズされる.

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

scope

REQUIRED. OpenID Connect リクエストは scope に openid を含まねばならない (MUST). openid scope 値が存在しない場合の挙動は定義しない. 他の scope 値が存在していても良い (MAY). 使用された scope 値で, 実装によって理解されないものは無視されるべきである (SHOULD). 本仕様によって定義される追加の scope 値については 5.4 (Requesting Claims using Scope Values) と 11 (Offline Access) セクションを参照すること.

response_type

REQUIRED. 使用する認証処理フローを決定する OAuth 2.0 Response Type 値. この値により, どのエンドポイントからどのようなパラメータが返されるのかなどが決定される. Authorization Code Flow を使用する場合, この値は code となる.

client_id

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

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 と紐づく暗号論的にセキュアな値を取る.

OpenID Connect は上記に加えて 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] で定義された以下の OAuth 2.0 リクエストパラメータを利用する.

response_mode

OPTIONAL. Authorization Endpoint からパラメータを返す手段を Authorization Server に通知する. 要求される Response Mode が Response Type で指定されるデフォルトの場合, このパラメータの使用は推奨されない (NOT RECOMMENDED).

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

nonce

OPTIONAL. Client セッションと ID Token を紐づける文字列であり, リプレイアタック対策に用いられる. この値は Authentication Request で指定され, そのままの値で ID Token に含まれる. nonce 値には, 推測不可能なように十分なエントロピーを持たせること (MUST). 実装の注意事項については Section 15.5.2 (Nonce Implementation Notes) を参照すること.

display

OPTIONAL. Authorization Server が認証および同意のためのユーザーインタフェースを End-User にどのように表示するかを指定するための ASCII 値. 以下の値が定義されている.

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 であり, その他のコードは Section 3.1.2.6 (Authentication Error Response) で定義されている. これは既存の認証と同意の両方, またはいずれかを確認する方法として使用できる.

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 リクエストパラメータは OpenID 2.0 PAPE (Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider Authentication Policy Extension 1.0,” December 2008.) [OpenID.PAPE] の max_auth_age リクエストパラメータに相当する) 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).

id_token_hint

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

id_token_hint として使用するために RP によって受信された OP からの ID Token が暗号化されていた場合, クライアントは暗号化された ID Token を含んだ署名済みの ID Token を復号しなければならない (MUST). クライアントは Authentication Server に送信する署名済みの ID Token をサーバーが ID Token を復号できる鍵を用いて再暗号化し, id_token_hint の値として使用してもよい (MAY).

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

他のパラメータを送ってもよい (MAY). 本仕様で定義される追加の Authorization Request Parameter とパラメータ値については 3.2.2 (Authorization Endpoint), 3.3.2 (Authorization Endpoint), 5.2 (Claims Languages and Scripts), 5.5 (Requesting Claims using the "claims" Request Parameter), 6 (Passing Request Parameters as JWTs) と, 7.2.1 (Providing Information with the "registration" Request Parameter) セクションを参照すること.

以下の例では 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
    &scope=openid%20profile%20email
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

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

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

3.1.2.2.  Authentication Request Validation

Authorization Server は, 以下のように受信した要求を検証しなければならない (MUST).

1. Authorization Server は, 全ての OAuth 2.0 パラメータを OAuth 2.0 仕様に従って検証しなければならない (MUST).
2. scope パラメータが存在することと, openid scope 値を含んでいることを検証. (もし openid scope 値が存在しなかった場合, その要求は OpenID Connect の要求ではないが, 有効な OAuth 2.0 の要求である可能性がある.)
3. Authorization Server は, 全ての必須 (REQUIRED) パラメータが存在するか, そしてそれらの使用方法が当仕様に従っているかを検証しなければならない (MUST).
4. ID Token の sub (subject) Claim に値が指定されて要求された場合, Authorization Server は, sub 値で識別される End-Userが, Authorization Server 上にアクティブなセッションを持っているか, またはその要求の結果として認証された場合のみ, 成功応答を送信しなければならない (MUST) . End-User が Authorization Server 上にアクティブなセッションを持っていたとしても, Authorization Server は, 異なるユーザの ID Token や Access Token を応答してはならない (MUST NOT) . このような要求は, id_token_hint パラメータを用いるか, もしくは実装が claims パラメータをサポートしていれば, Section 5.5.1 (Individual Claims Requests) に記述されているように特定の Claim Value を要求することによって実現することができる.

OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の規定どおり, Authorization Server は認識できない要求パラメータを無視すべきである (SHOULD) .

Authorization Server はなんからのエラーに遭遇した場合, Section 3.1.2.6 (Authentication Error Response) に従い, 失敗応答を返さなければならない (MUST) .

3.1.2.3.  Authorization Server Authenticates End-User

要求が妥当であった場合, Authorization Server は使用された要求パラメータに応じて, End-User を 認証するか, End-User が認証済かの確認を試みる. Authorization Server によって用いられる End-User の認証方式 (例えば, ユーザ名とパスワード, セッションクッキー等) については当仕様の規定範疇外である. 使用された要求パラメータの値や使用された認証方式に応じ, Authorization Server は認証ユーザーインタフェースを表示するかもしれない (MAY).

Authorization Server は以下のケースのとき, End-User の認証を試みなければならない (MUST).

• End-User はまだ認証されていない.
• Authentication Request は, login という値を持つ prompt パラメータを含んでいる. このケースでは, End-User が既に認証されていたとしても, Authorization Server は End-User を再認証しなければならない (MUST).

Authorization Server は以下のケースのとき, End-User と対話を行ってはならない (MUST NOT).

• Authentication Request は, none という値を持つ prompt パラメータを含んでいる. このケースでは, End-User がまだ認証されていなかったり, 対話なしに認証することができない場合, Authorization Server は エラーを返さなければならない (MUST).

End-User と対話を行うとき, OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の Section 10.12 と 10.13 に記述されている通り, Authorization Server は, Cross-Site Request Forgery や Clickjacking に対する適切な対策を行わなければならない (MUST).

3.1.2.4.  Authorization Server Obtains End-User Consent/Authorization

End-User を認証した後, Authorization Server は, Relying Party に 情報を送る前に認可決定を取得しなければならない (MUST). 使用された要求パラメータによって許可されている場合, 同意事項を明確にした End-User 対話を通じてか, 要求の処理やその他の手法 (例えば, 管理機能を用いた事前同意) による同意の確立によって, この認可決定は行われるかもしれない (MAY). Sections 2 (ID Token) と 5.3 (UserInfo Endpoint) で, 情報の送出機構について述べる.

3.1.2.5.  Successful Authentication Response

Authentication Response は, RP により送られた Authorization Request メッセージに応じて OP の Authorization Endpoint から返される OAuth 2.0 Authorization Response メッセージである.

Authorization Code Flow を利用するとき, Authorization Response は OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の Section 4.1.2 にて定義されるパラメータを Authorization Request 中で指定された redirect_uri にクエリパラメータとして加え, 異なる Response Mode が指定されない限りは application/x-www-form-urlencoded フォーマットを用いて返さなければならない (MUST).

以下にこのフローを用いた成功レスポンスの例を示す. (改行は掲載上の都合による)

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    code=SplxlOBeZQQYbYS6WxSbIA
    &state=af0ifjsldkj

Authorization Code の内容についての実装メモは Section 15.5.1 (Authorization Code Implementation Notes) を参照のこと.

3.1.2.6.  Authentication Error Response

Authentication Error Response は, RP により送られた Authorization Request メッセージに応じて OP の Authorization Endpoint から返される OAuth 2.0 Authorization Error Response メッセージである.

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

Redirection URI が無効でない限り, Authorization Server は適切なエラーと state パラメータで Authorization Request にて指定された Redirection URI に Client を返す.

OAuth 2.0 の Section 4.1.2.1 に定義されているエラーコードに加え, この仕様では次のようなエラーコードを定義する:

interaction_required

Authorization Server は処理を進めるためにいくつかの End-User interaction を必要とする. Authentication Request 中の prompt パラメータが none であるが, End-User interaction のためのユーザーインターフェースの表示なしには Authentication Request が完了できない時にこのエラーが返される.

login_required

Authorization Server は End-User の認証を必要とする. Authentication Request 中の prompt パラメータが none であるが, End-User の認証のためのユーザーインターフェースの表示なしには Authentication Request が完了できない時にこのエラーが返される.

account_selection_required

End-User は Authorization Server にてセッションの選択を必要とされる (REQUIRED). End-User は Authorization Server にて異なるアカウントで認証されているが, セッションを選択していないかもしれない (MAY). Authentication Request 中の prompt パラメータが none であるが, 利用するセッションを選択するためのユーザーインターフェースの表示なしには Authentication Request が完了できない時にこのエラーが返される.

consent_required

Authorization Server は End-User の同意を必要とする. Authentication Request 中の prompt パラメータが none であるが, End-User の同意のためのユーザーインターフェースの表示なしには Authentication Request が完了できない時にこのエラーが返される.

invalid_request_uri

Authorization Request 中の request_uri はエラーを返すか, 無効なデータを含む.

invalid_request_object

request パラメータが無効な Request Object を含む.

request_not_supported

OP は Section 6 (Passing Request Parameters as JWTs) にて定義されている request パラメータをサポートしていない.

request_uri_not_supported

OP は Section 6 (Passing Request Parameters as JWTs) にて定義されている request_uri パラメータをサポートしていない.

registration_not_supported

OP は Section 7.2.1 (Providing Information with the "registration" Request Parameter) で定義されている registration パラメータをサポートしていない.

エラーレスポンスパラメータは以下のようになる.

error

REQUIRED. エラーコード.

error_description

OPTIONAL. 人間が読める ASCII エンコードされたエラーの説明文.

error_uri

OPTIONAL. エラーについての追加情報を含むWebページのURI.

state

OAuth 2.0 の state の値. Authorization Request が state パラメータを含む場合は REQUIRED. Client から受け取った値をセットする.

Authorization Code Flow を利用するとき, エラーレスポンスパラメータは異なる Response Mode が指定されない限り Redirection URI のクエリ要素に付加される.

以下にこのフローを用いたエラーレスポンスの例を示す. (改行は掲載上の都合による)

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    error=invalid_request
    &error_description=
      Unsupported%20response_type%20value
    &state=af0ifjsldkj

3.1.2.7.  Authentication Response Validation

Authorization Code Flow を利用するとき, Client は RFC 6749, 特に Section 4.1.2 と Section 10.12 に従ってレスポンスを検証しなければならない (MUST).

3.1.3.  Token Endpoint

Access Token と ID Token , そしてオプションの Refresh Token の取得には, Authorization Code Flowを使用する場合, OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の Section 3.2 に記載の通り, RP (Client) は Token Endpoint へ Token Request を送信し, Token Responseを取得する.

Token Endpoint と通信する際は TLS を利用しなければならない (MUST). TLS の使用に関するより詳細な情報を得る場合, Section 16.17 (TLS Requirements) を参照すること.

3.1.3.1.  Token Request

OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の Section 4.1.3に記載の通り, grant_type の値に authorization_code を指定し, (Authorization Code の形で) Authorization Grant を Token Endpoint に提示することで, Client は Token Request を生成する. Client が Confidential Client の場合, Section 9 (Client Authentication) に記載の通り, 自身の client_id 用に登録された認証方式を用いて, Token Endpoint に対して認証を行わなければならない (MUST).

OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の Section 4.1.3 に記載の通り, Client は, HTTP POST メソッドと Section 13.2 (Form Serialization) による Form Serialization を用いて, Token Endpoint にパラメータを送信する.

以下に Token Request の一例を示す. (表示の都合上の改行を含む)

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

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

3.1.3.2.  Token Request Validation

Authorization Server は, Token Request を以下のように検証しなければならない (MUST).

• Section 9 (Client Authentication) により, Client Credential を発行していた場合や, その他の Client Authentication 方式を用いる場合, Client を認証.
• Authorization Code が認証された Client 向けに発行されたものかを確認.
• Authorization Code の有効性を検証.
• 可能な場合, その Authorization Code が以前に使用されていないものであることを検証.
• redirect_uri パラメータの値が, 最初の Authorization Request に含まれていた redirect_uri パラメータの値と同一であることを確認. 登録されている redirect_uri の値が一つだけであり, redirect_uri パラメータの値が存在していない場合, Authorization Server は, (Clientはそのパラメータを含むべきであるため) エラーを返すかもしれないし (MAY), (OAuth 2.0ではこのようなケースではパラメータの省略を許可しているため) エラーなしで処理を進めるかもしれない (MAY).
• (ID Token を Token Endpoint から返却できるように) その使用された Authorization Code が OpenID Connect Authentication Request に対する応答として発行されたものであることを検証.

3.1.3.3.  Successful Token Response

Client から Token Request を受け取り, リクエストの検証を行った後, Authorization Server はサクセスレスポンスを返す. このレスポンスには ID Token と Access Token を含む. サクセスレスポンス中のパラメータは OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Section 4.1.4 で定義される. レスポンスメディアタイプは application/json とする.

OAuth 2.0 token_type レスポンスパラメータは, 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). ただし他の Token Type が Client との間でネゴシエートされている場合は, その限りではない. Server は Bearer Token Type をサポートすべきである (SHOULD). その他の Token Type の利用に関しては, 本仕様の定めるところではない.

OAuth 2.0 で定義されるパラメータに加え, 以下のパラメータをレスポンスに含めること (MUST).

id_token

認証セッションに紐づいた ID Token 値.

トークン, 鍵, その他のセンシティブ情報を含む全ての Token Response には, 以下の HTTP レスポンスヘッダーを指定しなければならない (MUST).

以下はサクセス Token Response の例である. ID Token の署名は Appendix A.7 (RSA Key Used in Examples) にある鍵で検証可能である.

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

  {
   "access_token": "SlAV32hkKG",
   "token_type": "Bearer",
   "refresh_token": "8xLOxBtZp8",
   "expires_in": 3600,
   "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
     yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
     NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
     fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
     AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
     Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
     NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
     QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
     K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
     XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
  }

OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] にあるように, Client は理解できないレスポンスパラメータを無視すべきである (SHOULD).

3.1.3.4.  Token Error Response

Token Request が不正もしくは未認可な場合, Authorization Server はエラーレスポンスを返す. Token Error Response のパラメータは OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Section 5.2 で定義されている. HTTP レスポンスボディのメディアタイプは application/json であり, HTTP レスポンスコードは400とする.

以下に Token Error Response の例を示す.

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

  {
   "error": "invalid_request"
  }

3.1.3.5.  Token Response Validation

Client は以下の手順に従い Token Response を検証すること (MUST).

1. RFC 6749 (特に Sections 5.1 および 10.12) のバリデーションルールに従う.
2. ID Token バリデーションルールに関しては Section 3.1.3.7 (ID Token Validation) に従う.
3. Access Token バリデーョンルールに関しては Section 3.1.3.8 (Access Token Validation) に従う.

3.1.3.6.  ID Token

ID Token のコンテンツに関しては Section 2 (ID Token) を参照のこと. Authorization Code Flow を利用する場合, 以下に示すように, いくつかの ID Token Claim に追加要件が適用される.

at_hash

OPTIONAL. Access Token のハッシュ値. この値は, access_token の ASCII オクテット列のハッシュ値の左半分を base64url エンコードしたものであり, ハッシュアルゴリズムは ID Token の JOSE Header にある alg Header Parameter で用いられるハッシュアルゴリズムと同じものを用いる. 例えば alg が RS256 であれば, access_token の SHA-256 ハッシュ値を計算し, その左半分の128ビットを base64url エンコードする. at_hash は大文字小文字を区別する文字列である.

3.1.3.7.  ID Token Validation

Client は Token Response 内の ID Token を確認しなければならない (MUST).

1. ID Token が 暗号化されているならば, Client が Registration にて指定し OP が ID Token の暗号化に利用した鍵とアルゴリズムを用いて復号する. Registration 時に OP と暗号化が取り決められても ID Token が暗号化されていなかったときは, RP はそれを拒絶するべき (SHOULD).
2. (一般的に Discovery を通して取得される) OpenID Provider の Issuer Identifier は iss (issuer) Claim の値と正確に一致しなければならない (MUST).
3. Client は aud (audience) Claim が iss (issuer) Claim で示される Issuer にて登録された, 自身の client_id をオーディエンスとして含むことを確認しなければならない (MUST). aud (audience) Claim は複数要素の配列を含んでも良い (MAY). ID Token が Client を有効なオーディエンスとして記載しない, もしくは Client から信用されていない追加のオーディエンスを含むならば, そのID Token は拒絶されなければならない.
4. ID Token が複数のオーディエンスを含むならば, Client は azp Claim があることを確認すべき (SHOULD).
5. azp (authorized party) Claim があるならば, Client は Claim の値が自身の client_id であることを確認すべき (SHOULD).
6. (このフローの中で) ID Token を Client と Token Endpoint の間の直接通信により受け取ったならば, トークンの署名確認の代わりに TLS Server の確認を issuer の確認のために利用してもよい (MAY). Client は JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.) [JWS] に従い, JWT alg Header Parameter を用いて全ての ID Token の署名を確認しなければならない (MUST). Client は Issuer から提供された鍵を利用しなければならない (MUST).
7. alg の値はデフォルトの RS256 もしくは Registration にて Client により id_token_signed_response_alg パラメータとして送られたアルゴリズムであるべき (SHOULD).
8. JWT alg Header Parameter が HS256, HS384 および HS512 のような MAC ベースのアルゴリズムを利用するならば, aud (audience) Claim に含まれる client_id に対応する client_secret の UTF-8 表現バイト列が署名の確認に用いられる. MAC ベースのアルゴリズムについて, aud が複数の値を持つとき, もしくは aud の値と異なる azp の値があるときの振る舞いは規定されない.
9. 現在時刻は exp Claim の時刻表現より前でなければならない (MUST).
10. iat Claim は現在時刻からはるか昔に発行されたトークンを拒絶するために利用でき, 攻撃を防ぐために nonce が保存される必要がある期間を制限する. 許容できる範囲は Client の仕様である.
11. nonce の値が Authentication Request にて送られたならば, nonce Claim が存在し, その値が Authentication Request にて送られたものと一致することを確認するためにチェックされなければならない (MUST). Client は nonce の値を リプレイアタックのためにチェックすべき (SHOULD). リプレイアタックを検知する正確な方法は Client の仕様である.
12. acr Claim が 要求されたならば, Client は主張された Claim の値が適切かどうかをチェックすべきである (SHOULD). acr Claim の値と意味はこの仕様の対象外である.
13. auth_time Claim が要求されたならば, この Claim のための特定のリクエストもしくは max_age パラメータを用いて Client は auth_time Claim の値をチェックし, もし最新のユーザー認証からあまりに長い時間が経過したと判定されたときは再認証を要求すべきである (SHOULD).

3.1.3.8.  Access Token Validation

Authorization Code Flow を利用し, ID Token が at_hash Claim を含むときには Section 3.2.2.9 (Access Token Validation) にある Implicit Flow と同様に, Client はそれを Token Endpoint から返された ID Token と Access Token を用いて Access Token の確認に利用してもよい (MAY).

3.2.  Authentication using the Implicit Flow

この章では Implicit Flow での認証フローについて述べる. Implicit Flow を利用する場合, Token Endpoint は使用されず, 全てのトークンは Authorization Endpoint から返される.

Implicit Flow は主にスクリプト言語を用いて実装されブラウザ上で動作する Client によって使用される. Access Token と ID Token は, Client に直接返却され, その Access Token と ID Token は, End-User と End-User の User Agent にアクセスするアプリケーションに露出する可能性がある. Authorization Server は Client Authentication を行わない.

3.2.1.  Implicit Flow Steps

Implicit Flow の流れは以下通りである.

1. Client は必要なパラメータを含む Authentication Request を用意する.
2. Client は Authorization Server にリクエストを送信する.
3. Authorization Server は End-User を Authenticate する.
4. Authorization Server は End-User の Consent/Authorization を得る.
5. Authorization Server は ID Token, および要求があれば Access Token を添えて End-User を Client に戻す.
6. Client は ID Token を検証し, End-User の Subject Identifier を取得する.

3.2.2.  Authorization Endpoint

Implicit Flow では, 本章で述べる相違点以外は, Authorization Code Flow と同様の方法 (Section 3.1.2 (Authorization Endpoint) 参照) で Authorization Endpoint を利用する.

3.2.2.1.  Authentication Request

Authentication Request 構築方法は, 以下の Authentication Request パラメータ以外は Section 3.1.2.1 (Authentication Request) に従う.

response_type

REQUIRED. 使用する認証処理フローを決定する OAuth 2.0 Response Type 値. この値により, どのエンドポイントからどのようなパラメータが返されるのかなどが決定される. Implicit Flow を使用する場合, この値は id_token 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] を参照すること. id_token を利用する場合, Access Token は返されない.

注) OAuth 2.0 は Implicit Flow に Response Type token という値を定義してはいるが, その場合 ID Token が返却できないため, OpenID Connect ではこの Response Type は利用しない.

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 に従うこと. このフローを使用する場合, Client がネイティブアプリケーションでない限り, Redirection URI に http スキーマを利用してはならない (MUST NOT). Client がネイティブアプリケーションの場合は, ホスト名に localhost とした上で http: スキーマを利用してもよい (MAY).

nonce

REQUIRED. Client セッションと ID Token を紐づける文字列であり, リプレイアタック対策に用いられる. この値は Authentication Request で指定され, そのままの値で ID Token に含まれる. nonce 値には, 推測不可能なように十分なエントロピーを持たせること (MUST). 実装の注意事項については Section 15.5.2 (Nonce Implementation Notes) を参照すること.

以下に Implicit Flow の例を示す. 以下の例では Client から HTTP 302 リダイレクトレスポンスを受け取った User Agent が 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

3.2.2.2.  Authentication Request Validation

Implicit Flow では, Authorization Code Flow と同様の方法 (Section 3.1.2.2 (Authentication Request Validation) 参照) で Authentication Request を検証する.

3.2.2.3.  Authorization Server Authenticates End-User

Implicit Flow では, Authorization Code Flow と同様の方法 (Section 3.1.2.3 (Authorization Server Authenticates End-User) 参照) で End-User Authentication を行う.

3.2.2.4.  Authorization Server Obtains End-User Consent/Authorization

Implicit Flow では, Authorization Code Flow と同様の方法 (Section 3.1.2.4 (Authorization Server Obtains End-User Consent/Authorization) 参照) で End-User Consent を取得する.

3.2.2.5.  Successful Authentication Response

Implicit Flow では, このセクションで指定された点を除いては, Authorization Code Flow と同様の手順で Authentication Response を構築する. (Section 3.1.2.5 (Successful Authentication Response) 参照)

Implicit Flow では, 異なる Response Mode が指定されない限り, 全てのレスポンスパラメータは 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 のフラグメント要素に加えられる.

以下のパラメータは Authorization Endpoint から返される.

access_token

OAuth2.0 の Access Token. response_type の値が id_token でない限り, これは返される.

token_type

OAuth 2.0 の Token Type の値. この値は Bearer もしくは Client が Authorization Server と交渉した他の token_type の値でなければならない (MUST). このプロファイルを実装している Client は OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] の仕様をサポートしなければならない (MUST). このプロファイルは bearer token の利用のみを述べる. これは access_token と同時に返される.

id_token

REQUIRED. ID Token.

state

OAuth 2.0 の state の値. state パラメータが Authorization Request にある場合は必須 (REQUIRED). Client は state の値が Authorization Request 中の state パラメータと等しいことを確認しなければならない (MUST).

expires_in

OPTIONAL. Access Token の有効期限である, レスポンスが生成されてからの秒数.

OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の Section 4.2.2 により, Implicit Flow を用いるときに code は返されない.

以下に Implicit Flow を用いた成功レスポンスの例を示す. (改行は掲載上の都合による)

  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

3.2.2.6.  Authentication Error Response

Implicit Flow を用いるとき, Authorization Error Responses はこのセクションで指定される違いを除いて Section 3.1.2.6 (Authentication Error Response) で定義されている Authorization Code Flow と同様に作成される.

End-User がリクエストを拒絶または End-User の認証に失敗したとき, 異なる Response Mode が指定されないかぎり Authorization Server は Error Authorization Response を OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の 4.2.2.1 と 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 のフラグメント要素にて返さなければならない (MUST).

3.2.2.7.  Redirect URI Fragment Handling

レスポンスパラメータが Redirection URI のフラグメントの値で返されるため, Client は フラグメントエンコードされた値をパースしてそれを消費する Client の処理ロジックに渡す User Agent を持つことを必要とする. URIフラグメントのハンドリングは Section 15.5.3 (Redirect URI Fragment Handling Implementation Notes) を参照すること.

3.2.2.8.  Authentication Response Validation

Implicit Flow を用いるとき, Client は 以下のようにレスポンスを確認しなければならない (MUST).

1. レスポンスが [OAuth.Responses] (de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.) の Section 5 に従うことを検証する.
2. RFC 6749, 特に Sections 4.2.2 と 10.12の確認規則に従う.
3. Section 3.2.2.11 (ID Token Validation) の ID Token 確認規則に従う.
4. response_type の値が id_token を利用しない限り, Section 3.2.2.9 (Access Token Validation) の Access Token 確認規則に従う.

3.2.2.9.  Access Token Validation

Authorization Endpoint から ID Token とともに発行された Access Token を確認するため, Client は次のことを行うべきである (SHOULD).

1. ID Token の JOSE Header 中の alg Header Parameter のために JWA (Jones, M., “JSON Web Algorithms (JWA),” July 2014.) [JWA] にて指定されているハッシュアルゴリズムにて access_token の ASCII バイト列をハッシュする. 例えば alg が RS256 であれば, ハッシュアルゴリズムは SHA-256 となる.
2. ハッシュの左半分を取り出し, それを base64url エンコードする.
3. ID Token の at_hash の値が直前のステップで生成された値と等しくなければならない (MUST).

3.2.2.10.  ID Token

ID Token の内容は Section 2 (ID Token) で述べられている. Implicit Flow を使用する場合, 以下の ID Token Claims に対する追加要件が適用される:

nonce

このフローでは nonce Claim の使用は必須である (REQUIRED).

at_hash

Access Token のハッシュ値. この値は, access_token の ASCII バイト列のハッシュ値の左半分を base64url エンコードしたものであり, ハッシュアルゴリズムは ID Token の JOSE Header にある alg Header Parameter で用いられるハッシュアルゴリズムと同じものを用いる. 例えば alg が RS256 であれば, access_token の SHA-256 ハッシュ値を計算し, その左半分の128ビットを base64url エンコードする. at_hash は大文字小文字を区別する文字列である.

ID Token が access_token とともに Authorization Endpoint から発行された場合(response_type 値が id_token token である場合に該当する), この Claim は必須である (REQUIRED). Access Token が発行されない場合(response_type 値が id_token である場合に該当する), この Claim は使用されなくてもよい (MAY NOT).

3.2.2.11.  ID Token Validation

Implicit Flow では, このセクションで指定された違いを除いて, Authorization Code Flow と同様の手順で ID Token の内容を検証されなければならない (MUST). (Section 3.1.3.7 (ID Token Validation) 参照)

1. Clientは ID Token の署名を, JOSE Header 中の alg Header Parameter で指定されたアルゴリズムを使い, JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.) [JWS] に従って検証しなければならない (MUST).
2. nonce Claim の値が Authentication Request にて送られたものと一致することを確認しなければならない (MUST). Clientは nonce の値をリプレイアタック対策のためにチェックすべきである (SHOULD). リプレイアタック検知方法の詳細はClientによって異なる.

3.3.  Authentication using the Hybrid Flow

このセクションは Hybrid Flow を用いて認証を行う方法について述べる. Hybrid Flow を使用する場合, いくつかのトークンは Authorization Endpoint から返され, その他のトークンは Token Endpoint から返される. Hybrid Flow でのトークン返却の仕組みは 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] で指定されている.

3.3.1.  Hybrid Flow Steps

Hybrid Flow は以下の手順に従う:

1. Clientは必要なリクエストパラメータを含んだ Authentication Request を構築する.
2. Clientは Authorization Server にリクエストを送信する.
3. Authorization Server は End-User を認証する.
4. Authorization Server は End-User の同意/認可を取得する.
5. Authorization Server は End-User を Authorization Code と, レスポンスタイプに応じた1つ以上の追加パラメータとともにClientに戻す.
6. Clientは Token Endpoint で Authorization Code を使用してレスポンスを要求する.
7. Clientは ID Token と Access Token をレスポンスボディに含んだレスポンスを受け取る.
8. Clientは ID Token をトークンを検証し, End-User の Subject Identifier を取得する.

3.3.2.  Authorization Endpoint

Hybrid Flow では, このセクションで指定された違いを除いて, Authorization Code Flow と同様の方式で Authorization Endpoint を利用する. (Section 3.1.2 (Authorization Endpoint) 参照)

3.3.2.1.  Authentication Request

Authentication Request 構築方法は, 以下の Authentication Request パラメータ以外は Section 3.1.2.1 (Authentication Request) に従う.

response_type

REQUIRED. 使用する認証処理フローを決定する OAuth 2.0 Response Type 値. この値により, どのエンドポイントからどのようなパラメータが返されるのかなどが決定される. Hybrid Flow を使用する場合, この値はcode id_token, code token, code id_token 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] を参照すること.

以下に Hybrid Flow の例を示す. ここでは Client からの HTTP 302 リダイレクトレスポンスを受け取った User Agent が Authorization Server にリクエストを送っている. (改行は掲載上の都合による)

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

3.3.2.2.  Authentication Request Validation

Hybrid Flow では, Authorization Code Flow と同様の方法 (Section 3.1.2.2 (Authentication Request Validation) 参照) で Authentication Request を検証する.

3.3.2.3.  Authorization Server Authenticates End-User

Hybrid Flow では, Authorization Code Flow と同様の方法 (Section 3.1.2.3 (Authorization Server Authenticates End-User) 参照) で End-User Authentication を行う.

3.3.2.4.  Authorization Server Obtains End-User Consent/Authorization

Hybrid Flow では, Authorization Code Flow と同様の方法 (Section 3.1.2.4 (Authorization Server Obtains End-User Consent/Authorization) 参照) で End-User Consent を取得する.

3.3.2.5.  Successful Authentication Response

Hybrid Flow では, このセクションで指定される違いを除いて, Implicit Flow と同様の方法で Authorization Responses を構築する. (Section 3.2.2.5 (Successful Authentication Response) 参照)

これらのAuthorization Endpoint の結果は, 以下のように使用される.

access_token

OAuth2.0のAccess Token. response_type の値が, code token か, code id_token token の場合に返される. (token_type も同様に返される)

id_token

ID Token. response_type の値が, code id_token か code id_token token の場合に返される.

code

Authorization Code. Hybrid Flow では常に返される.

以下に Hybrid Flow のサクセスレスポンス例を示す. (改行は掲載上の都合による)

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    code=SplxlOBeZQQYbYS6WxSbIA
    &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    &state=af0ifjsldkj

3.3.2.6.  Authentication Error Response

Hybrid Flow では, このセクションで指定される違いを除いて, Authorization Code Flow と同様の方法で Authorization Error Responses を構築する. (Section 3.1.2.6 (Authentication Error Response) 参照)

もしエンドユーザがリクエストを拒否または認証に失敗した場合, 認可サーバは, 異なるResponse Modeが定義されていない限り, OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の Section 4.2.2.1 と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] に定義されるように, Redirect URI のフラグメントコンポーネントに含めて, エラー Authorization Response を返却しなければならない (MUST).

3.3.2.7.  Redirect URI Fragment Handling

Hybrid Flow では Implicit Flow 同様 Redirect URI のフラグメントを利用するため, Section 3.2.2.7 (Redirect URI Fragment Handling) と同様の要件が求められる. 実装時の注意点は Section 15.5.3 (Redirect URI Fragment Handling Implementation Notes) を参照のこと.

3.3.2.8.  Authentication Response Validation

Hybrid Flow を使用する場合, Client は以下の通りレスポンスを検証しなければならない (MUST).

1. レスポンスが [OAuth.Responses] (de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.) の Section 5 に準拠していることを検証する.
2. 検証ルールは, RFC 6949 の特に Section 4.2.2 と 10.12 に従うこと.
3. 使用される response_type の値が, code id_token か code id_token token の場合, ID Token の検証ルールは, Section 3.3.2.12 (ID Token Validation) に従うこと.
4. 使用される response_type の値が, code token か code id_token token の場合, Access Token の検証ルールは, Section 3.3.2.9 (Access Token Validation) に従うこと.
5. 使用される response_type の値が, code id_token または code id_token token の場合, Authorization Code の検証ルールは, Section 3.3.2.10 (Authorization Code Validation) に従うこと.

3.3.2.9.  Access Token Validation

Hybrid Flow では, Authorization Endpoint から返される Access Token に対して Implicit Flow と同様の検証処理を行うこと. (Section 3.2.2.9 (Access Token Validation) 参照)

3.3.2.10.  Authorization Code Validation

Authorization Endpoint で ID Token と一緒に発行された Authorization Code を検証するために, Client は以下を行うべきである (SHOULD).

1. code の ASCII オクテットのハッシュ値を計算する. ハッシュアルゴリズムは, ID Token の JOSE Header に含まれる alg Header Parameter で利用されるものを利用する. 各 alg Header Parameter に対応するハッシュアルゴリズムは JWA (Jones, M., “JSON Web Algorithms (JWA),” July 2014.) [JWA] で定義されている. たとえば, alg が RS256 であれば, 使用されるハッシュアルゴリズムは SHA-256 である.
2. ハッシュの左半分を取得し, base64url エンコードする.
3. ID Token に c_hash が含まれる場合, その値は前述のプロセスにより計算された値と ID Token 中の c_hash が一致しなければならない (MUST).

3.3.2.11.  ID Token

ID Token に含まれるコンテンツについては, Section 2 (ID Token) に記載されている. Hybrid Flow を用いる際には, Authorization Endpoint から返される ID Token に対して, 以下に挙げる ID Token Claim 各々に追加の要件が適用される.

nonce

このフローでは nonce Claim の使用は必須である (REQUIRED).

at_hash

Access Token のハッシュ値. この値は, access_token の ASCII オクテット列のハッシュ値の左半分を base64url エンコードしたものであり, ハッシュアルゴリズムは ID Token の JOSE Header にある alg Header Parameter で用いられるハッシュアルゴリズムと同じものを用いる. 例えば alg が RS256 であれば, access_token の SHA-256 ハッシュ値を計算し, その左半分の128ビットを base64url エンコードする. at_hash は大文字小文字を区別する文字列である.

response_type の値が code id_token token の時のように, Authorization Endpoint から ID Token が access_token と共に発行される場合は必須 (REQUIRED). それ以外の場合, 任意 (OPTIONAL).

c_hash

Code のハッシュ値. この値は, code の ASCII オクテット列のハッシュ値の左半分を base64url エンコードしたものであり, ハッシュアルゴリズムは ID Token の JOSE Header にある alg Header Parameter で用いられるハッシュアルゴリズムと同じものを用いる. 例えば alg が RS256 であれば, code の SHA-256 ハッシュ値を計算し, その左半分の128ビットを base64url エンコードする. c_hash は大文字小文字を区別する文字列である.

response_type の値が code id_token や code id_token token の時のように, Authorization Endpoint から ID Token が code と共に発行される場合は必須 (REQUIRED). それ以外の場合, 任意 (OPTIONAL).

3.3.2.12.  ID Token Validation

Hybrid Flow では, Authorization Endpoint から返される ID Token は Implicit Flow と同様の方法 (Section 3.2.2.11 (ID Token Validation) 参照) で検証すること (MUST).

3.3.3.  Token Endpoint

Hybrid Flow では, 本章で述べる相違点以外は, Authorization Code Flow と同様の方法 (Section 3.1.3 (Token Endpoint) 参照) で Token Endpoint を利用する.

3.3.3.1.  Token Request

Hybrid Flow では, Authorization Code Flow と同様の方法 (Section 3.1.3.1 (Token Request) 参照) で Token Request を構築する.

3.3.3.2.  Token Request Validation

Hybrid Flow では, Authorization Code Flow と同様の方法 (Section 3.1.3.2 (Token Request Validation) 参照) で Token Request を検証する.

3.3.3.3.  Successful Token Response

Hybrid Flow では, Authorization Code Flow と同様の方法 (Section 3.1.3.3 (Successful Token Response) 参照) で Token Response を構築する.

3.3.3.4.  Token Error Response

Hybrid Flow では, Authorization Code Flow と同様の方法 (Section 3.1.3.4 (Token Error Response) 参照) で Token Error Response を構築する.

3.3.3.5.  Token Response Validation

Hybrid Flow では, Authorization Code Flow と同様の方法 (Section 3.1.3.5 (Token Response Validation) 参照) で Token Response を検証する.

3.3.3.6.  ID Token

Hybrid Flow を使用する場合, このセクションで指定された違いを除いて, Token Endpoint から返された ID Token の内容は Section 3.3.2.11 (ID Token) で述べた Authorization Endpoint から返される ID Token と同一である.

ID Token が Authorization Endpoint と Token Endpoint の両方から返される場合 (response_type 値が code id_token もしくは code id_token token である場合), iss Claim と sub Claim は両方の ID Token で同一でなければならない (MUST). Authentication イベントに関する Claim については, 片方にその Claim を含めるのであれば, もう片方にも同じ Claim を含めるべきである (SHOULD). End-User に関する Claim については, それらが両方に存在するのであれば, その値は同値であるべきである (SHOULD). なお, プライバシー上の理由などにより, OP は Authorization Endpoint から返す End-User の Claim を, Token Endpoint から返すそれより少なくしてもよい (MAY). たとえ Authorization Endpoint から返される ID Token に at_hash および c_hash Claim が含まれていたとしても, Token Endpoint から返される ID Token ではそれらの Claim は省略可能である (MAY). Token Endpoint から返される ID Token と Access Token は, 既に Token Endpoint における TLS 暗号化により暗号論的に紐づけられている.

3.3.3.7.  ID Token Validation

Hybrid Flow を使用する場合, Token Endpoint で返される ID Token の内容は, Section 3.1.3.7 (ID Token Validation) に従い Authorization Code Flow と同じ方法で検証すること (MUST).

3.3.3.8.  Access Token

Access Token が Authorization Endpoint と Token Endpoint の両方から返される場合 (response_type 値が code token もしくは code id_token token である場合), それぞれの値は同一としてもよく (MAY), 異なる値としてもよい (MAY). 2つのエンドポイントでの異なるセキュリティ特性によって異なる Access Token が返されるかもしれず, 有効期限と承認されたリソースへのアクセス権も異なる可能性があることに注意.

3.3.3.9.  Access Token Validation

Hybrid Flow を使用する場合, Token Endpoint で返される Access Token は, Section 3.1.3.8 (Access Token Validation) に従い Authorization Code Flow と同じ方法で検証すること.

4.  Initiating Login from a Third Party

場合によっては, ログインフローは Relying Party ではなく OpenID Provider やその他の Party によって開始されることもある. その場合, ログインフローを開始する主体は, ユーザーを RP のログイン開始エンドポイントにリダイレクトさせ, RP に特定の OP に Authentication Request を送るよう要求する. このログイン開始エンドポイントは RP のデフォルトのランディングページではなく deep link でもよい. OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.) [OpenID.Registration] をサポートする RP は initiate_login_uri Registration パラメータを使ってこのエンドポイントを登録することができる.

ログインリクエストを開始する Party は, 以下のパラメーターを付与してユーザーを RP のログイン開始エンドポイントにリダイレクトさせることでフローを開始する:

iss

REQUIRED. RP が Authentication Request を送信する OP を示す Issuer Identifier. その値は https スキームを用いた URL でなければならない (MUST).

login_hint

OPTIONAL. Authorization Server に対して, ログインさせたい End-User を示す, ログイン識別子に関するヒント情報. Client がこの文字列値パラメーターを受け取った場合, それを Authentication Request に login_hint パラメーター値として含めなければならない (MUST).

target_link_uri

OPTIONAL. 認証後, RP がリダイレクトするよう要求された URL. RP は外部サイトへのオープンリダイレクターとして使用されることを防ぐために target_link_uri の値を検証しなければならない(MUST).

パラメーターは HTTP GET メソッドを用いたクエリパラメーターとして渡す, もしくは User Agent で自動送信される HTML フォーム値として HTTP POST メソッドで渡すことができる.

拡張によって他のパラメーターが定義される場合, それらが送られてもよい (MAY). Client は, 理解できないパラメーターが送られた場合, それらを無視しなければならない (MUST).

Clients は, Clickjacking などの攻撃を通じて End-User が 3rd-party サイトに無意識にログインさせられるような攻撃を防ぐため, フレームバスティングやその他の技術を採用すべきである (SHOULD). 詳細は [RFC6819] (Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.) の Section 4.4.1.9 を参照.

5.  Claims

この章では, Client が End-User と Authentication イベントについての Claims をどのように取得するかについて定義する. また同時に Basic Profile Claims の標準セットも定義する. 特定の scope 値を用いて事前に定義された Claims のセットを要求することもできるし, claims リクエストパラメーターを用いて個々の Claims を要求することもできる. これらの Claims は, OpenID Provider から直接取得することもできるし, 分散されたデータソースから個別に取得することもできる.

5.1.  Standard Claims

ここでは標準 Claims のセットを定義する. これらは Section 5.3.2 (Successful UserInfo Response) に示す UserInfo Response, あるいは Section 2 (ID Token) に示す ID Token のどちらかに含めて返却するように要求できる.

5.1.1.  Address Claim

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

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

formatted

表示や宛名ラベルで使用するために整形された完全な郵送先住所. このフィールドは改行で区切られた複数の行を含んでもよい (MAY). 改行は, 復帰/行送りのペア ("\r\n") か, または単一の行送り文字 ("\n") によって表現される.

street_address

家番号, ストリート名, 私書箱, 複数行からなる拡張された住所情報を含むことができる (MAY) 完全な住所を示す要素. このフィールドは改行で区切られた複数の行を含んでもよい (MAY). 改行は, 復帰/行送りのペア ("\r\n") か, または単一の行送り文字 ("\n") によって表現される.

locality

市町村などを表す city, locality を示す要素.

region

都道府県などを表す state, province, prefecture, region を示す要素.

postal_code

郵便番号を表す ZIP code, postal code を示す要素.

country

国名を示す要素.

5.1.2.  Additional Claims

当仕様では標準 Claim として小さなセットの Claim のみを定義しているが, その他の Claim を標準 Claim と同時に使用してもよい (MAY). このような Claim を用いる際は, JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.) [JWT] 仕様に記載の通り, 衝突耐性のある名称を Claim Name に用いることを推奨する (RECOMMENDED). あるいは, JWT 仕様に記載の通り, 名前衝突が発生する可能性が低い場合は, Private Claim Name を安全に利用できるだろう. もしくは, JWT 仕様に記載の通り, 追加の Claim が広く一般的に適用可能であれば, Registered Claim Name として登録も可能だろう.

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 (Internet Assigned Numbers Authority (IANA), “Language Subtag Registry,” 2005.) [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 に寄せている)

返却される Claim の好ましい言語および文字種の指定を可能とするため, OpenID Connect では, 以下の Authorization Request パラメータを定義している:

claims_locales

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

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

5.3.  UserInfo Endpoint

UserInfo Endpoint は, 認証された End-User に関する Claim を返す OAuth 2.0 Protected Resource である. 要求された End-User の Claim を取得するため, Clientは OpenID Connect Authentication を通して得られた Access Token を用いて UserInfo Endpoint に要求する. これらの Claim は通常, Claim の名前と値のペアのコレクションを含んだ JSON オブジェクトで表現される.

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

UserInfo Endpoint は RFC 2616 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] で定義された HTTP GET メソッドと HTTP POST メソッドをサポートしなければならない (MUST).

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] の Access Token を受け入れなければいけない (MUST).

UserInfo Endpoint は Java Scipt Clientが Endpoint にアクセスできるように Cross Origin Resource Sharing (CORS) (Opera Software ASA, “Cross-Origin Resource Sharing,” July 2010.) [CORS] や 必要に応じて他の方法をサポートすべきである (SHOULD).

5.3.1.  UserInfo Request

Clientは HTTP GET か HTTP POST のいずれかを用いて UserInfo Request を送信する. OpenID Connect Authentication Request で得られた Access Token は OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] の Section 2 に従って, Bearer Token として送信されなければいけない (MUST).

このリクエストでは, HTTP GET メソッドを用いて, Access Token を Authorization ヘッダフィールドに含めて送信すべきである (SHOULD).

以下に UserInfo Request の一例を示す:

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

5.3.2.  Successful UserInfo Response

Client の登録時に署名または暗号化されたレスポンスが要求されていない限り, UserInfo Claim は JSON オブジェクトのメンバーとして返される (MUST). Section 5.1 (Standard Claims) に定義されている Claim に加え, そこに明記されていない Claim も返却可能である.

プライバシー上の理由により, OpenID Provider はいくつかの要求された Claim の値を返さなくてもよい (MAY).

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

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

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

登録 [OpenID.Registration] (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.) 時に別の形式が指定された場合を除き, UserInfo Request を受信すると UserInfo Endpoint は Section 13.3 (JSON Serialization) のように, UserInfor Response の JSON Serialization を HTTP レスポンスボディで返さなければならない (MUST). UserInfo Endpoint は Content-Type ヘッダーを用いてフォーマットを示すこと (MUST). レスポンスボディがテキスト JSON オブジェクトである場合, HTTP レスポンスの Content-Type は application/json でなければならず (MUST), レスポンスボディは UTF-8 エンコードとすること (SHOULD).

UserInfo Response が署名や暗号化をされている場合, Claim は JWT で返され, Content-Type は application/jwt でなければならない (MUST). レスポンスは署名無しに暗号化をしてもよい (MAY). 署名と暗号化の両方が要求された場合, レスポンスは [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.) で定義されているように, 結果はネストされた JWT となり, 署名した後に暗号化しなければならない (MUST).

署名する場合, UserInfo Response は メンバーとして iss (issuer) Claim と aud (audience) Claim を含むべきである (SHOULD). iss は OP の Issuer Identifier URL であるべきである (SHOULD). aud は RP の Client ID の値とするか, 値を含むべきである (SHOULD).

以下に UserInfo Response の一例を示す:

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

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

5.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 を返す. (RFC 6750 に関係のないエラーは, 適切な HTTP ステータスコードを用いて User Agent に返すこと)

以下に UserInfo Error Response の一例を示す:

  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: error="invalid_token",
    error_description="The Access Token expired"

5.3.4.  UserInfo Response Validation

Client は UserInfo Response を以下の手順で検証しなければならない (MUST).

1. レスポンスを返した 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 サーバー証明書チェックを通じて検証する.
2. Client が Registration 時に userinfo_encrypted_response_alg パラメータを提供した場合, Registration 時に指定した鍵を使用して UserInfo Response を復号する.
3. レスポンスが署名されている場合, Clientは JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.) [JWS] に従って署名を検証すべきである (SHOULD).

5.4.  Requesting Claims using 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 で保護されたエンドポイントにアクセスした際にどのようなリソースが得られるかを規定する. Protected Resource エンドポイントは, Access Token 要求時に指定された scope 値やその他のパラメータに基づき, 異なる動作をしたり, 異なる情報を返却したりしてもよい (MAY).

OpenID Connect では, scope は Claim Value として取得可能な情報セットを指定する為に利用できる. 本仕様では OpenID Connect で用いられる scope についてのみ述べる.

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

OpenID Connect は, Claim を要求する際に用いられる以下の 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 へのアクセス要求に用いる.

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

処理の結果として Access Token が発行される response_type を使用したとき, profile, email, address, および phone scope 値により要求される Claim は, Section 5.3.2 (Successful UserInfo Response) にある通り UserInfo Endpoint から返される. しかし, (response_type 値が id_token であるケースのように) Access Token が発行されない場合, 結果 Claim はID Token 内で返却される.

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

以下に符号化されていない scope リクエスト例を示す.

  scope=openid profile email phone

5.5.  Requesting Claims using the "claims" Request Parameter

OpenID Connect では, 個々の Claim の要求や, 要求された Claim に適用されるパラメータの指定を可能とするために, 以下の Authorization Request パラメータを定義する:

claims

OPTIONAL. 当パラメータは, 特定の Claim の返却を要求するのに用いられる. 値は要求する Claim をリスト化した JSON オブジェクトである.

claims Authentication Request パラメータは, 特定の Claim を UserInfo Endpoint から, かつ/または ID Token 内で, 返却することを要求する. これは要求する Claim のリストを含む JSON オブジェクトとして表される. 要求する Claim のプロパティが指定されていてもよい (MAY).

claims パラメータのサポートは任意である (OPTIONAL). 当パラメータをサポートしない OP に対して RP が当パラメータを使用したとき, OP は 適切と思われるヒューリスティックな方法を用いて, RP と End-User にとって有益と思われる Claim のセットを返すべきである (SHOULD). Discovery で得られる claims_parameter_supported は, OP が当パラメータをサポートしているかどうかを示す.

claims パラメータ値は, OAuth 2.0 要求の中で, UTF-8 でエンコードされた JSON として表される (最終的には OAuth パラメータとして受け渡されるときに form-urlencoded される). Request Object 値として使用される際は, Section 6.1 (Passing a Request Object by Value) により, JSON が claims メンバーの値として使用される.

Claim 要求 JSON オブジェクトのトップレベルメンバーは以下の通り:

userinfo

OPTIONAL. UserInfo Endpoint へ返却を要求する個々の Claim のリストを示す. 当メンバーが存在した場合, scope 値で要求された Claim に加え, 当メンバーでリストされた Claim も返却される. 当メンバーが存在しなかった場合, scope 値で要求された Claim のみが返却される.

userinfo メンバーを指定する際は, UserInfo Endpoint を使用するために, response_type に対し, Access Token を Client に発行するタイプの値を指定しなければならない (MUST).

id_token

OPTIONAL. ID Token 内に格納して返却を要求する個々の Claim のリストを示す. 当メンバーが存在した場合, デフォルトの Claim に加え, 当メンバーでリストされた Claim も返却される. 当メンバーが存在しなかった場合, デフォルトの Claim のみが返却される. デフォルトの Claim 等の ID Token の定義については Section 2 (ID Token)を, フロー毎の ID Token 要件については Section 3.1.3.6 (ID Token), 3.2.2.10 (ID Token), 3.3.2.11 (ID Token), 3.3.3.6 (ID Token) を参照すること.

上記以外のメンバーが存在してもよい (MAY). 認識できないメンバーが使用された場合は無視しなければならない (MUST).

Claim 要求の例を以下に示す:

  {
   "userinfo":
    {
     "given_name": {"essential": true},
     "nickname": null,
     "email": {"essential": true},
     "email_verified": {"essential": true},
     "picture": null,
     "http://example.info/claims/groups": null
    },
   "id_token":
    {
     "auth_time": {"essential": true},
     "acr": {"values": ["urn:mace:incommon:iap:silver"] }
    }
  }

5.5.1.  Individual Claims Requests

claims request の userinfo メンバーと id_token メンバーは, 要求される個別の Claim の名前をメンバー名とする JSON オブジェクトである. メンバーの値は以下のいずれかの値でなければならない (MUST).

null

この Claim はデフォルトの形式で要求されていることを示す. 具体的に言うと, Voluntary Claim である. 例えば, Claim request:

  "given_name": null

は given_name Claim をデフォルトの形式で要求する.

JSON Object

要求されている Claim の追加情報を提供するために使用する. 本仕様は下記のメンバーを定義する:

essential

OPTIONAL. 要求されている Claim が Essential Claim であるかどうかを示す. 値が true である場合, Claim が Essential Claim であることを示す. 例えば, Claim request:

  "auth_time": {"essential": true}

は auth_time Claim の値を返すために Essential であることを指定するために使われる.

false である場合, Voluntary Claim であることを示す. デフォルトは false である.

Essential Claim として Claim を要求することで, RP は End-User に対して, End-User が要求する処理に際した円滑な認可処理にこれらの Claim の開示が必要であることを示すことができる. End-User が認可しなかったりそもそも情報が存在しないなどの理由で Claim が利用できない場合であっても, 特定の Claim の記述で特別に指定されない限り, Claim が Essential か Voluntary であるかどうかに関わらず Authorization Server はエラーを生成してはならない (MUST NOT) ことに注意.

value

OPTIONAL. 特定の値とともに返される Claim を要求する. 例えば Claim request:

  "sub": {"value": "248289761001"}

は要求が Subject Identifier 248289761001 を持つ End-User に適用されることを指定するために使われる.

value メンバーの値は要求されている Claim に対して有効な値でなければならない (MUST). 各 Claim の定義においては, 当該 Claim を要求する際の value 修飾子の利用方法や, そもそも利用すべきかどうかを定めることもできる.

values

OPTIONAL. 優先順になっている値の集合の内のいずれかで返される Claim を要求する. 例えば, Claim request:

  "acr": {"essential": true,
          "values": ["urn:mace:incommon:iap:silver",
                     "urn:mace:incommon:iap:bronze"]}

は urn:mace:incommon:iap:silver か urn:mace:incommon:iap:bronze のいずれかの acr Claim が Essential であることを指定する.

values メンバー配列の値は要求されている Claim に対して有効な値でなければならない (MUST). 各 Claim の定義においては, 当該 Claim を要求する際の values 修飾子の利用方法や, そもそも利用すべきかどうかを定めることもできる.

要求される Claim の追加情報を提供するために他のメンバーを定義してもよい (MAY). 解釈不可能なメンバーは全て無視すること (MUST).

claims リクエストパラメータがサポートされている場合, Claim を要求する scope の値は, Section 5.4 (Requesting Claims using Scope Values) で述べられているように, 効果的に簡略化された個別の Claims の集合を要求するための方法となることに注意. 例えば, openid email scope 値と Access Token を返す response_type を使用することは openid scope 値と個別の Claims に対する下記のリクエストを使用することと同じである.

下記のリクエストは email scope 値を使用した場合と同じ結果となる:

  {
   "userinfo":
    {
     "email": null,
     "email_verified": null
    }
  }

5.5.1.1.  Requesting the "acr" Claim

acr Claim が特定の Authentication Context Class Reference 値と claims パラメータをサポートする実装を要求する values パラメータとともに ID Token の Essential Claim として要求される場合, Authorization Server は要求された値のいずれかに一致する acr Claim を返さなければいけない (MUST). Authorization Server は要求を満たす追加の要素を再認証するために End-User にたずねてもよい (MAY). この Claim が Essential Claim であり要求を満たすことが出来ない場合, Authorization Server は認証の試行に失敗したものとして扱わなければいけない (MUST).

RP は acr_values request パラメータを使用して, もしくは個別の acr Claim リクエストで "essential": true を含まないことにより Voluntary Claim として acr Claim を要求してもよい (MAY). Claim が Essential でなく, 要求された値が提供できない場合, Authorization Server は acr Claim の値としてセッションの現在の acr を返すべきである (SHOULD). Claim が Essential でない場合, Authorization Server はレスポンスにおいてこの Claim を提供する必要はない.

Clientが acr_values リクエストパラメータと ID Token のために要求する特定の値をリストにした個別の acr Claim リクエストの両方を用いて acr Claim を要求する場合, その結果の振る舞いは規定されていない.

5.5.2.  Languages and Scripts for Individual Claims

Section 5.2 (Claims Languages and Scripts) で述べられているように, Human-readable な Claim Value およびそれらへの参照は, 複数言語および複数文字種で表現することができる (MAY). 個別の Claim の要求を行う際に, 特定の Claim に対して Section 5.2 (Claims Languages and Scripts) で指定された Claim 名の構文を用いて Claim 要求に # で区切られた BCP47 (Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.) [RFC5646] 言語タグ付きの Claim 名を含めることで, 当該 Claim に対して言語や文字種を指定して要求することができる (MAY). 例えば, 日本語のカタカナでの姓名は Claim　名 family_name#ja-Kana-JP を用いて要求することができ, 日本語の漢字表記の姓名は Claim　名 family_name#ja-Hani-JP を用いて要求することができる. ドイツ語の Web サイトは Claim　名 website#de で要求することができる.

OP が保持していない言語および文字種での Human-readable な Claim の要求を受け取った場合, 返される Claim のいずれかのバージョンは Claim 名に要求された言語および文字種を使わず言語タグを使用するべきである (SHOULD).

5.6.  Claim Types

本仕様では以下の3つの Claim Value 表現形式を定義する.

Normal Claims

OpenID Provider によって直接アサートされた Claim.

Aggregated Claims

OpenID Provider 以外の Claims Provider によってアサートされた Claim であるが, OpenID Provider から返却される Claim.

Distributed Claims

OpenID Provider 以外の Claims Provider によってアサートされた Claim であり, OpenID Provider からはその参照だけが返却される Claim.

Normal Claims はサポートしなければならない (MUST). Aggregated Claims と Distributed Claims のサポートは任意である (OPTIONAL).

5.6.1.  Normal Claims

Normal Claims は JSON オブジェクトの中にメンバーとして表記される. Claim 名はそのメンバー名で, Claim Value はそのメンバーの値である.

以下は Normal Claims を含んでいるレスポンスの一例である:

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

5.6.2.  Aggregated and Distributed Claims

Aggregated と Distributed Claims は, Claims を含む JSON オブジェクト中で, _claim_names および _claim_sources という特殊なメンバーを用いて表記される.

_claim_names

Aggregated Claims および Distributed Claims として返される Claim Name をメンバーとして含む JSON オブジェクトである. そのメンバーの値は, 実際の Claim Value が取り出せる _claim_sources メンバーの中にあるメンバー名への参照である.

_claim_sources

_claim_names メンバー値によって 参照されるメンバー名を持つ JSON オブジェクトである. メンバー値は Aggregated Claims のセットもしくは Distributed Claims の参照場所を含む. Aggregated Claims か Distributed Claims かに応じて, メンバー値は以下のフォーマットの1つを持つことができる:

Aggregated Claims

JWT を値として持つ JWT メンバーを含んだ JSON オブジェクトでなければならない (MUST). 当該 JWT は _claim_sources メンバーへの参照となった _claim_names オブジェクトに含まれる, 全 Claim を含まなければならない (MUST). 他のメンバーが存在してもよい (MAY). 理解できないメンバーは無視しなければならない (MUST).

JWT

REQUIRED. Claim Value を含んでいる JWT.

この JWT は, sub 値が Claims Provider に置ける End-User の識別子でない限り, sub (subject) Claim を含むべきでない (SHOULD NOT). (また OpenID Provider あるいは他の Party が利用するために sub 値を提供すべきでもない) 一般的にこれは sub Claim が提供されるべきではないということを意味している.

Distributed Claims

以下のメンバーと値を含む JSON オブジェクトである:

endpoint

REQUIRED. 関連した Claim を取り出すことができる OAuth 2.0 リソースエンドポイント. エンドポイント URL は JWT として Claim を返却しなければならない (MUST).

access_token

OPTIONAL. OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] プロトコルに従ってエンドポイント URL から Claim を取得する際に利用する Access Token. Access Token は Authorization Request ヘッダーフィールドを用いて送信しなければならず (MUST), Claims Provider はこの方法をサポートしなければならない (MUST). Access Token が使用可能でない場合, RP は out-of-band な方法で Access Token を取得したり, 事前に Claims Provider との間で合意した Access Token を使用する必要があることもある (MAY). Claims Provider は End-User を再認証したり RP を再認可することもある (MAY).

この JWT は, sub 値が Claims Provider に置ける End-User の識別子でない限り, sub (subject) Claim を含むべきでない (SHOULD NOT). (また OpenID Provider あるいは他の Party が利用するために sub 値を提供すべきでもない) 一般的にこれは sub Claim が提供されるべきではないということを意味している.

一般的に, どのような時に Aggregated Claims と Distributed Claims の利用が適切かは, OP 次第である. 場合によっては, どの Claim Type をいつ使うべきかについて, RP と OP の間で out-of-band な方法で合意されることもある.

5.6.2.1.  Example of Aggregated Claims

以下の例では, Claims Provider A からの Claim と OpenID Provider によって保有される他の Claims が同時に返却されている. また Claims Provider A からの Claim は, Aggregated Claims となっている.

以下の Claim は Claims Provider A によって発行された Jane Doe についての Claims である:

  {
   "address": {
     "street_address": "1234 Hollywood Blvd.",
     "locality": "Los Angeles",
     "region": "CA",
     "postal_code": "90210",
     "country": "US"},
   "phone_number": "+1 (310) 123-4567"
  }

Claims Provider A は JSON Claims に署名し, Signed JWT でそれらを表現する: jwt_header.jwt_part2.jwt_part3. この JWT は OpenID Provider によって使用される.

この例では, Claims Provider A からの Jane Doe の Aggregated Claims を含んだ JWT が他の Normal Claims と組み合わせられ, 以下の Claims セットとして返却される:

  {
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "birthdate": "0000-03-22",
   "eye_color": "blue",
   "email": "janedoe@example.com",
   "_claim_names": {
     "address": "src1",
     "phone_number": "src1"
   },
   "_claim_sources": {
     "src1": {"JWT": "jwt_header.jwt_part2.jwt_part3"}
   }
  }

5.6.2.2.  Example of Distributed Claims

以下の例では, OpenID Provider は Claims Provider B と C が保有する Claim を Normal Claims と合わせて返却する. B と C が保有する Claim は Distributed Claims として参照を含めた形で提供される.

以下の Claim は Claims Provider B (Jane Doe's bank) が保持する Jane Doe についての Claims である:

  {
   "shipping_address": {
     "street_address": "1234 Hollywood Blvd.",
     "locality": "Los Angeles",
     "region": "CA",
     "postal_code": "90210",
     "country": "US"},
   "payment_info": "Some_Card 1234 5678 9012 3456",
   "phone_number": "+1 (310) 123-4567"
  }

また以下は, Claims Provider C (a credit agency) が保持する Jane Doe についての Claims である:

  {
   "credit_score": 650
  }

OpenID Provider は, Jane Doe の Claim を返却する際に, Claims Provider B および C に対する参照を添える. この参照には Distributed Claims を取得するための Access Token と URL を含む.

  {
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "email": "janedoe@example.com",
   "birthdate": "0000-03-22",
   "eye_color": "blue",
   "_claim_names": {
     "payment_info": "src1",
     "shipping_address": "src1",
     "credit_score": "src2"
    },
   "_claim_sources": {
     "src1": {"endpoint":
                "https://bank.example.com/claim_source"},
     "src2": {"endpoint":
                "https://creditagency.example.com/claims_here",
              "access_token": "ksj3n283dke"}
   }
  }

5.7.  Claim Stability and Uniqueness

Section 2 (ID Token) にあるように, sub (subject) Claim は特定の Issuer 内でローカルに一意かつ決して再割り当てされない値でなければならず (MUST), それにより sub (subject) と iss (issuer) の組み合わせは RP が End-User の安定的な識別子として依存できる唯一の Claim となる. よって特定の End-User に対する唯一の保証されたユニークな識別子は, iss Claim と sub Claim の組み合わせとなる.

他の全ての Claims に関しては, 長期的な安定性やユーザー間の一意性に関して, 異なる Issuer をまたいで上記のような保証を行うことはできず, Issuer はローカルの制限やポリシーを適用することが許されている. 例えば, Issuer は異なる時点で異なる End-Users 間で email Claim 値を再利用するかもしれず (MAY), 特定の End-User の email Claim は時間の経過とともに変わりうる (MAY). ゆえに, email, phone_number, preferred_username のような他の Claims は End-User の一意な識別子として使用してはいけない (MUST NOT).

6.  Passing Request Parameters as JWTs

OpenID Connect では, Authorization Request に署名および暗号化を可能にするため, 以下の Authorization Request パラメータを定義する.

request

OPTIONAL. このパラメータにより, OpenID Connect リクエストを単一の self-contained なパラメータとすることができ, 任意で署名および暗号化を施せるようになる. パラメータ値は Request Object 値である (Section 6.1 (Passing a Request Object by Value) 参照). Request Object は, 各 Claim がリクエストパラメータとなる JWT である.

request_uri

OPTIONAL. このパラメータにより, 値そのものではなく参照を送ることが可能になる. request_uri 値は https スキーマで始まる URL であり, Request Object 値を含むリソースへの参照となる. 参照先の Request Object は, リクエストパラメータを含む JWT である.

これらのパラメータを利用したリクエストは JWT として表現され, その値もしくは参照が送信される. リクエストを参照渡しすることで, 長大なリクエストを扱いやすくなる. 上記のパラメータのいずれかを利用する場合は, 同一リクエスト中で他方を利用してはならない (MUST NOT).

6.1.  Passing a Request Object by Value

request Authorization Request パラメータにより, OpenID Connect リクエストを単一の self-contained なパラメータとすることができ, 任意で署名および暗号化を施せるようになる. このパラメータは, 各 Claim がリクエストパラメータとなる JWT である (Section 3.1.2 (Authorization Endpoint) 参照). この JWT は Request Object と呼ばれる.

request パラメータのサポートはオプションである (OPTIONAL). Discovery 結果の request_parameter_supported により, OP がこのパラメータをサポートしていることを知ることができる. OP がこのパラメータをサポートしていないにも関わらず RP がこれを利用する場合, OP は request_not_supported エラーを返すこと (MUST).

request を利用する際には, JWT に含まれる OpenID Connect パラメータ値が OAuth 2.0 リクエストシンタックスで送信されるパラメータに取って代わる. しかしながら, Request Object を利用する場合にでも, パラメータを OAuth 2.0 リクエストシンタックスでも送信することができる (MAY). こうすることで, キャッシュ可能で署名済 (および暗号化済) の Request Object 値に静的なリクエストパラメータを含め, リクエストごとに可変パラメータ (state, nonce 等) を OAuth 2.0 パラメータとして送信することなどが可能になる.

リクエスト自体を有効な OAuth 2.0 Authorization Request とするため, response_type および client_id パラメータは OAuth 2.0 リクエストシンタックスでリクエストに含まねばならない (MUST). これは OAuth 2.0 で必須とされている (REQUIRED). もし Request Object にもこれらと同じパラメータが含まれている場合は, 2つのパラメータは一致しなければならない (MUST).

scope パラメータが Request Object に含まれる場合でも, scope パラメータは OAuth 2.0 リクエストシンタックスで openid scope を含んだ形で送信しなければならない (MUST). これにより下位レイヤーの OAuth 2.0 処理系に, 当該リクエストが OpenID Connect リクエストであることを明示することができる.

Request Object は, 署名付きでも良いし, 署名無しの平文でも良い. 平文の場合, JWS ヘッダーに none アルゴリズム ([JWA] (Jones, M., “JSON Web Algorithms (JWA),” July 2014.) 参照) を指定すること. 署名付きの場合, Request Object は iss (issuer) および aud (audience) を含むべきである (SHOULD). RP 以外の主体に署名されているのでない限り, iss 値は RP の Client ID とすべきである (SHOULD). aud 値には OP の Issuer Identifier URL を含めるべきである (SHOULD).

Request Object は JWE (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2014.) [JWE] を用いて暗号化することもできる (MAY). また署名無しで暗号化のみを適用することもできる (MAY). 署名と暗号化を同時に利用する場合は, 署名後に暗号化すること (MUST). これは Nested JWT となる ([JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.) 参照).

request および request_uri パラメータは, Request Object 中に含んではならない (MUST NOT).

以下は base64url エンコードと署名を施す前段階の, Request Object 中の Claim の例である.

  {
   "iss": "s6BhdRkqt3",
   "aud": "https://server.example.com",
   "response_type": "code id_token",
   "client_id": "s6BhdRkqt3",
   "redirect_uri": "https://client.example.org/cb",
   "scope": "openid",
   "state": "af0ifjsldkj",
   "nonce": "n-0S6_WzA2Mj",
   "max_age": 86400,
   "claims":
    {
     "userinfo":
      {
       "given_name": {"essential": true},
       "nickname": null,
       "email": {"essential": true},
       "email_verified": {"essential": true},
       "picture": null
      },
     "id_token":
      {
       "gender": null,
       "birthdate": {"essential": true},
       "acr": {"values": ["urn:mace:incommon:iap:silver"]}
      }
    }
  }

RS256 アルゴリズムで上記 Request Object に署名した結果の Request Object 値は以下のようになる. (改行は掲載上の都合による)

  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
  F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
  c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
  JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
  bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
  Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
  ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
  ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
  Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
  wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
  ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
  sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
  dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
  luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
  F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
  KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
  0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
  ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
  iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw

以下の JWK フォーマットで表現された RSA 公開鍵で, 上記 Request Object の署名検証を行える. 以降の Request Object 署名例でも, 同じ鍵を用いる. (改行は掲載上の都合による)

  {
   "kty":"RSA",
   "kid":"k2bdc",
   "n":"y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE5P
        7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5OaaXDF
        I6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVjdEFgZa
        ZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghLL0HzOuYR
        adBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUGsqkNA9b3xV
        W53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw",
   "e":"AQAB"
  }

6.1.1.  Request using the "request" Request Parameter

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

以下は request パラメータを使った Authorization Request の例である. (改行は掲載上の都合による)

  https://server.example.com/authorize?
    response_type=code%20id_token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj
    &request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiA
    iczZCaGRSa3F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmN
    vbSIsDQogInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWV
    udF9pZCI6ICJzNkJoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8
    vY2xpZW50LmV4YW1wbGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiA
    ic3RhdGUiOiAiYWYwaWZqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWo
    iLA0KICJtYXhfYWdlIjogODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXN
    lcmluZm8iOiANCiAgICB7DQogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWw
    iOiB0cnVlfSwNCiAgICAgIm5pY2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjo
    geyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJ
    lc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgInBpY3R1cmUiOiBudWxsDQogICAgfSw
    NCiAgICJpZF90b2tlbiI6IA0KICAgIHsNCiAgICAgImdlbmRlciI6IG51bGwsDQo
    gICAgICJiaXJ0aGRhdGUiOiB7ImVzc2VudGlhbCI6IHRydWV9LA0KICAgICAiYWN
    yIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOmluY29tbW9uOmlhcDpzaWx2ZXIiXX0
    NCiAgICB9DQogIH0NCn0.nwwnNsk1-ZkbmnvsF6zTHm8CHERFMGQPhos-EJcaH4H
    h-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyFKzuMXZFSZ3p6Mb8dkxtVyjoy2
    GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx0GxFbuPbj96tVuj11pTnmFC
    UR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8Kol-cSLWoYE9l5QqholImz
    jT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPGiyon_-Te111V8uE83Il
    zCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw

6.2.  Passing a Request Object by Reference

request_uri Authorization Request パラメータにより, OpenID Connect リクエストを参照渡し可能になる. このパラメータは, Request Object そのものが値として渡されるのではなく, Request Object が指定された URL から取得されるという点以外は, request パラメータと同等である.

Discovery 結果の request_uri_parameter_supported により, OP がこのパラメータをサポートしていることを知ることができる. OP がこのパラメータをサポートしていないにも関わらず RP がこれを利用する場合, OP は request_uri_not_supported エラーを返すこと (MUST).

request_uri パラメータを利用する際には, 参照先の JWT に含まれる OpenID Connect パラメータ値が OAuth 2.0 リクエストシンタックスで送信されるパラメータに取って代わる. しかしながら, request_uri を利用する場合にでも, パラメータを OAuth 2.0 リクエストシンタックスでも送信することができる (MAY). こうすることで, キャッシュ可能で署名済 (および暗号化済) の Request Object 値に静的なリクエストパラメータを含め, リクエストごとに可変パラメータ (state , nonce 等) を OAuth 2.0 パラメータとして送信することなどが可能になる.

リクエスト自体を有効な OAuth 2.0 Authorization Request とするため, response_type および client_id パラメータは OAuth 2.0 リクエストシンタックスでリクエストに含まねばならない (MUST). これは OAuth 2.0 で必須とされている (REQUIRED). もし Request Object にもこれらと同じパラメータが含まれている場合は, 2つのパラメータは一致しなければならない (MUST).

scope パラメータが Request Object に含まれる場合でも, scope パラメータは OAuth 2.0 リクエストシンタックスで openid scope を含んだ形で送信しなければならない (MUST). これにより下位レイヤーの OAuth 2.0 処理系に, 当該リクエストが OpenID Connect リクエストであることを明示することができる.

サーバーは Request URI 参照先のコンテンツをキャッシュしても良い (MAY). もし参照先のリソースが可変の場合は, URI フラグメントとしてコンテンツの SHA-256 ハッシュの Base64URL エンコード値を含めるべきである (SHOULD). もし URI フラグメント値が変わった場合は, 古いフラグメント値を含む URI に紐づいたキャッシュ値はもはや有効でない.

Client が OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.) [OpenID.Registration] Section 2.1 で定義される request_uris パラメータを用いて request_uri を事前登録することも可能である (MAY). OP は, 事前登録済の request_uri 値以外の利用を許可しないということを, require_request_uri_registration ディスカバリパラメータで示すことができる.

Request URI は全体で 512 ASCII 文字を超えてはならない (MUST NOT).

URL 参照先のリソースは, Request Object でなければならない (MUST). Request Object が Authorization Server に検証可能な方法で署名されていない限り, request_uri のスキーマは https でなければならない (MUST). request_uri 値は Authorization Server が到達可能でなければならず (MUST), Client にも到達可能であるべきである (SHOULD).

以下は request_uri 参照先の Request Object の例である. (改行は掲載上の都合による)

  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
  F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
  c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
  JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
  bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
  Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
  ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
  ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
  Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
  wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
  ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
  sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
  dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
  luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
  F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
  KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
  0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
  ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
  iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw

6.2.1.  URL Referencing the Request Object

Client は Request Object をローカルもしくはリモートの Server にアクセス可能な URL に配置する. この URI が Request URI (request_uri) である.

Request Object が Claim リクエストを含む場合, その Request Object は Authorization Server 以外の何者にも知られてはならない (MUST NOT). 例えば, request_uri はそのライフタイムに応じて適切なエントロピーを持っていなければならない (MUST). 再び利用することの無いのが明らかな場合や適切なタイムアウト後には, そのコンテンツを削除することが推奨される (RECOMMENDED). ただしなんらかのアクセスコントロールが実施されている場合はその限りではない.

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

  https://client.example.org/request.jwt#
    GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

6.2.2.  Request using the "request_uri" Request Parameter

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

以下は request_uri パラメータを使った Authorization Request の例である. (改行は掲載上の都合による)

  https://server.example.com/authorize?
    response_type=code%20id_token
    &client_id=s6BhdRkqt3
    &request_uri=https%3A%2F%2Fclient.example.org%2Frequest.jwt
    %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
    &state=af0ifjsldkj&nonce=n-0S6_WzA2Mj
    &scope=openid

6.2.3.  Authorization Server Fetches Request Object

Request を受けると, Authorization Server は参照先の Request Object を取得するため, request_uri に HTTP GET リクエストを送らなければならない (MUST). ただし Request Object がキャッシュ済の場合を除く. Request Object を取得すると, Authorization Server は Authorization Request を取得するため Request Object をパースする.

RP はリクエストごとに異なるパラメータを用いる場合は, リクエストごとにユニークな URI を用いるべきである (SHOULD). もしくは Authorization Server が request_uri 参照先のコンテンツをキャッシュするのを防ぐこと.

以下は Request Object フェッチ例である.

  GET /request.jwt HTTP/1.1
  Host: client.example.org

6.2.4.  "request_uri" Rationale

request_uri を利用する理由はいくつか挙げられる.

1. リクエストパラメータセットが長大になり, ブラウザの URI 長制限を超える. リクエストパラメータを参照渡しすることで, この問題を回避できる.
2. リクエスト全体を値として渡すより, request_uri を渡す方がリクエストレイテンシを抑えることができる.
3. RP が送ってくる Claim は, 基本的に不変である. request_uri は, 事前に不変のリクエストパラメータセットを用意しておき, 時には事前に署名や暗号化を施しておくことを可能にする. (request_uri 値は, 特定の不変なリクエストパラメータに対する "artifact" となる)
4. Registration 時に不変なリクエストパラメータを事前登録しておくことで, OP は Registration 時にリクエストパラメータを事前に検証済にした状態でキャッシュすることができる. これにより, OP はリクエストを受け取った際にコンテンツを取得しにいく必要がなくなる.
5. Registration 時に不変なリクエストパラメータを事前登録しておくことで, OP は顧客保護などの視点から送られてくるであろうリクエストの事前審査を行うことができる. 事前審査を行う主体は, OP 自身なこともあれば, サードパーティであることもあろう.

6.3.  Validating JWT-Based Requests

request ないしは request_uri Authorization Request パラメータを利用する場合, Authentication Request の検証には 3.1.2.2 (Authentication Request Validation), 3.2.2.2 (Authentication Request Validation) および 3.3.2.2 (Authentication Request Validation) に加えて更なるステップが必要となる. このステップとは, Request Object を含む JWT の検証と, Request Object 自体の検証である.

6.3.1.  Encrypted Request Object

もし Authorization Server が Discovery ドキュメント [OpenID.Discovery] (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” November 2014.) 中の request_object_encryption_alg_values_supported と request_object_encryption_enc_values_supported で JWE 暗号化アルゴリズムを公表している場合, またはその他の手段により暗号かアルゴリズムを明らかにしている場合, Client はそれらのアルゴリズムを利用して JWT を暗号化する.

Authorization Server は JSON Web Encryption (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2014.) [JWE] の仕様に従って JWT を復号しなければならない (MUST). Request Object は署名されているかもしれず, 署名無しの平文かもしれない (MAY). 前者の場合, 署名検証は Section 6.3.2 (Signed Request Object) に従うこと (MUST).

復号に失敗した場合, Authorization Server はエラーを返さねばならない (MUST).

6.3.2.  Signed Request Object

署名検証を行うには, JWS ヘッダーの alg パラメータが Client Registration 時の request_object_signing_alg, もしくはその他の手段により事前登録された値と一致しなければならない (MUST). 署名は client_id とアルゴリズムに対して適切な鍵を用いて行わなければならない (MUST).

署名検証に失敗した場合, Authorization Server はエラーを返さねばならない (MUST).

6.3.3.  Request Parameter Assembly and Validation

Authorization Server は, Request Object 値と OAuth 2.0 Authorization Request パラメータから (request と request_uri を除いて) Authorization Request パラメータを集約しなければならない (MUST). Request Object と OAuth Authorization Request パラメータに同じパラメータが含まれる場合, Request Object に含まれるパラメータを用いること. その後 Authorization Server は, 集約された Authorization Request パラメータを用いて, 3.1.2.2 (Authentication Request Validation), 3.2.2.2 (Authentication Request Validation) および 3.3.2.2 (Authentication Request Validation) に従って, 利用されているフローに応じて通常通りリクエストを検証する.

7.  Self-Issued OpenID Provider

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

Self-Issued OP とのメッセージのやりとりは, 通常の OP の場合とほとんど同じである. ここでは Self-Issued のために追加されるパラメータ, およびパラメータ値を定義する.

7.1.  Self-Issued OpenID Provider Discovery

Discovery Process で入力された識別子が self-issued.me ドメインを含んでいた場合, Dynamic Discovery は実行されない. その代わりに以下の静的な設定値が使用される.

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

7.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 ファウンデーションが当該サイトをプロダクション用途を想定して提供するまでその環境に依存すべきではない.

7.2.1.  Providing Information with the "registration" Request Parameter

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

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,” November 2014.) [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 される). Request Object (Section 6.1 (Passing a Request Object by Value) 参照) 内で利用される場合, registration メンバーの値として JSON オブジェクトを指定する.

Self-Issued OP へのリクエストの中で典型的に利用する登録パラメータは以下である. policy_uri, tos_uri, and logo_uri. Client が一つ以上の Redirection URI を使用する際, それらを登録するために redirect_uris パラメータを利用する. 最後にもし Client が暗号化されたレスポンスをリクエストする場合は, 以下のパラメータを利用する. jwks_uri, id_token_encrypted_response_alg, and id_token_encrypted_response_enc.

7.3.  Self-Issued OpenID Provider Request

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

scope

REQUIRED. Section 3.1.2 (Authorization Endpoint) で定義されている scope パラメータの値.

response_type

REQUIRED. 固定の文字列 id_token.

client_id

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

id_token_hint

OPTIONAL. Section 3.1.2 (Authorization Endpoint) で定義されている id_token_hint パラメータの値. Self-Issued OP に対して暗号化した ID Token を送信する場合, 署名付き ID Token の sub (subject) を JWE の kid (Key ID) として指定しなければならない (MUST). 現状 Self-Issued OP に対して暗号化したコンテンツを送信できるのは, OP の JWK 鍵タイプが RSA であり, かつ暗号化アルゴリズムが RSA1_5 である場合に限る.

claims

OPTIONAL. Section 5.5 (Requesting Claims using the "claims" Request Parameter) で定義されている claims パラメータの値.

registration

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

request

OPTIONAL. Section 6.1 (Passing a Request Object by Value) で定義されている Request Object 値. Client は, 暗号化した Request Object を Self-Issued OP に送信することもできる (MAY). その場合, その Client に対して既に発行済の ID Token の sub (subject) を JWE の kid (Key ID) として指定しなければならない (MUST). 現状 Self-Issued OP に対して暗号化したコンテンツを送信できるのは, OP の JWK 鍵タイプが RSA であり, かつ暗号化アルゴリズムが RSA1_5 である場合に限る.

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

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

以下は, User Agent が Self-Issued OpenID Provider に対して 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

7.4.  Self-Issued OpenID Provider Response

OpenID Connect では Self-Issued OpenID Provider Responses で使うために以下の Claim を定義する.

sub_jwk

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

Self-Issued OpenID Provider のレスポンスは, 通常の Implicit Flow のレスポンスに以下の改変をしたものと同じである. Implicit Flow のレスポンスなので, 異なる Response Mode が指定されていない限り, レスポンスパラメータは URL フラグメントコンポーネントの中で返される.

1. iss (issuer) Claim Value が 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., “JSON Web Key (JWK) Thumbprint,” July 2014.) に定義されている.
4. UserInfo エンドポイントへアクセスするための Access Token は返されないため, すべての Claim は ID Token の中で返されなければならない (MUST).

7.5.  Self-Issued ID Token Validation

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

1. Client は, iss (issuer) Claim の値が https://self-isued.me であることを検証しなければならない (MUST). もし iss が別の値を含んでいた場合, その ID Token は Self-Issued ではないので, Section 3.1.3.7 (ID Token Validation) に沿って検証されなければならない (MUST).
2. Client は, Client がAuthentication Request で送信した redirect_uri の値が, aud Claim にオーディエンスとして含まれていることを検証しなければならない (MUST).
3. Client は, JOSE Header の alg Header Parameter に指定されたアルゴリズムを使い JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.) [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 7.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"
    }
  }

8.  Subject Identifier Types

Subject Identifier は, Client によって利用されることを意図している, Issuer 内で一意な再割り当てされない End-User の識別子である. 当仕様では, 2つの Subject Identifier タイプを定義している:

public

全ての Client に対し同一の sub (subject) 値を提供する. これはプロバイダのディスカバリドキュメント内の subject_types_supported 要素が 存在しない場合のデフォルトである.

pairwise

各々の Client に対し異なる sub 値を提供する. そのためClient は, 許可なくして End-User の行動を集約して関連づけることが不可能となる.

OpenID Provider の Discovery ドキュメントには, サポートしている Subject Identifier のタイプのリストが subject_types_supported 要素に記載されているべきである (SHOULD). 一つ以上のタイプがリストされている場合, Client は Registration 時に subject_type パラメータを用いて, 任意のタイプを選択してもよい (MAY).

8.1.  Pairwise Identifier Algorithm

pairwise Subject Identifier を使用する際, OpenID Provider は, 各々の Sector Identifier 毎に一意な sub (subject) 値を計算しなければならない (MUST). Subject Identifier 値は, OpenID Provider 以外の Party にとって, 可逆であってはならない (MUST NOT).

pairwise sub 値を使用し, かつ Dynamic Client Registration (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.) [OpenID.Registration] をサポートする Provider は, sector_identifier_uri パラメータを使用すべきである (SHOULD). これは, 共通の管理下にあるウェブサイト群に対し, 個々のドメイン名とは独立して pairwise sub 値の 一貫性を保持する手段を提供する. また, Client に対し, 全ユーザを再登録させることなしに redirect_uri を変更する手段も提供する.

Client が Dynamic Client Registration (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.) [OpenID.Registration] で sector_identifier_uri の値を提供しなかった場合, pairwise identifier の計算に用いる Sector Identifier は, 登録された redirect_uri のホスト部である. 登録された redirect_uris に複数のホスト名が存在した場合, Client は sector_identifier_uri を登録しなければならない (MUST).

sector_identifier_uri が提供された場合, URL のホスト部が pairwise identifier の計算に用いる Sector Identifier として使用される. sector_identifier_uri の値は, redirect_uri 値の配列を含んだ JSON ファイルを示す https スキームの URL でなければならない (MUST). 登録された redirect_uris の値は, 配列の要素に含まれていなければならない (MUST).

OpenID Provider による pairwise Subject identifier の計算には, 以下の特性を持つ任意のアルゴリズムを用いることが出来る:

• Subject Identifier 値が, OpenID Provider 以外の Party にとって, 可逆であってはならない (MUST NOT).
• 異なる Sector Identifier 値は, 異なる Subject Identifier 値にならなければならない (MUST).
• 同じ入力に対して必ず同じ結果となる決定的アルゴリズムでなければならない (MUST).

3つの手法例を以下に示す:

1. Sector Identifierを, ローカルアカウントIDおよび Provider によって秘密にされているソルト値と連結する. そして連結した文字列を適切なアルゴリズムによってハッシュ化する.
   
   sub = SHA-256 ( sector_identifier || local_account_id || salt ) を計算する.
   
   
2. Sector Identifierを, ローカルアカウントIDおよび Provider によって秘密にされているソルト値と連結する. そして連結した文字列を適切なアルゴリズムによって暗号化する.
   
   sub = AES-128 ( sector_identifier || local_account_id || salt ) を計算する.
   
   
3. Issuer は, Sector Identifier とローカルアカウントIDのペアに対し, Globally Unique Identifier (GUID) を作成する.

9.  Client Authentication

ここでは, Client が Token Endpoint にアクセスする際に, Authorization Server に対して自身を認証する Client Authentication 方法を定義する. Client Registration で RP (Client) は Client Authentication 方法を登録できる (MAY). もし認証方法が登録されていない場合, デフォルトで client_secret_basic を用いる.

Client Authentication 方法は以下の通りである.

client_secret_basic

Authorization Server から client_secret 値を受け取った Client は, OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Section 3.2.1 に従い, HTTP Basic 認証スキーマを利用して Authorization Server に対して自身を認証する.

client_secret_post

Authorization Server から client_secret 値を受け取った Client は, OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Section 3.2.1 に従い, Client Credential をリクエストボディに含めて Authorization Server に対して自身を認証する.

client_secret_jwt

Authorization Server から client_secret 値を受け取った Client は, HMAC SHA-256 等の HMAC SHA アルゴリズムを利用して JWT を生成する. HMAC (Hash-based Message Authentication Code) は, client_secret の UTF-8 オクテットを共通鍵として利用して計算される.

Client は JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants (Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.) [OAuth.JWT] および Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants (Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.) [OAuth.Assertions] に従い認証を行う. JWT は以下の必須 (REQUIRED) の Claim Value を含まねばならず (MUST), 任意 (OPTIONAL) な Claim Value を含んでもよい (MAY).

iss

REQUIRED. Issuer. OAuth Client の client_id を含まねばならない (MUST).

sub

REQUIRED. Subject. OAuth Client の client_id を含まねばならない (MUST).

aud

REQUIRED. Audience. aud (audience) Claim. Authorization Server をオーディエンスとして指定する. Authorization Server は自身がオーディエンスに含まれることを検証しなければならない (MUST). Audience は Authorization Server の Token Endpoint URL にすべきである (SHOULD).

jti

REQUIRED. JWT ID. トークンごとにユニークな識別子. トークンの再利用を防ぐために利用される. これらのトークンは, 再利用条件について関係者での合意を得られていない限り, 2度以上利用しないようにしなければならない (MUST). そのような合意の詳細については本仕様の定めるところではない.

exp

REQUIRED. ID Token の有効期限. この時刻を超えて当該 ID Token を受理してはならない (MUST NOT).

iat

OPTIONAL. JWT 発行時刻.

この JWT には, 他の Claim を含めても良い (MAY). 理解できない Claim は無視すること (MUST).

認証トークンは [OAuth.Assertions] (Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.) の client_assertion パラメータとして送信すること (MUST).

[OAuth.Assertions] (Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.) の client_assertion_type パラメータには, [OAuth.JWT] (Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.) の通りに "urn:ietf:params:oauth:client-assertion-type:jwt-bearer" とすること.

private_key_jwt

公開鍵を登録済の Client は, そのペアとなる秘密鍵で JWT に署名を行っても良い. Client は JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants (Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.) [OAuth.JWT] および Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants (Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.) [OAuth.Assertions] に従い認証すること. JWT は以下の必須 (REQUIRED) の Claim Value を含まねばならず (MUST), 任意 (OPTIONAL) な Claim Value を含んでもよい (MAY). JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants (Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.) [OAuth.JWT] and Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants (Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.) [OAuth.Assertions]. The JWT MUST contain the following REQUIRED Claim Values and MAY contain the following OPTIONAL Claim Values: -->

iss

REQUIRED. Issuer. OAuth Client の client_id を含まねばならない (MUST).

sub

REQUIRED. Subject. OAuth Client の client_id を含まねばならない (MUST).

aud

REQUIRED. Audience. aud (audience) Claim. Authorization Serve をオーディエンスとして指定する. Authorization Server は自身がオーディエンスに含まれることを検証しなければならない (MUST). Audience は Authorization Server の Token Endpoint URL にすべきである (SHOULD).

jti

REQUIRED. JWT ID. トークンごとにユニークな識別子. トークンの再利用を防ぐために利用される. これらのトークンは, 再利用条件について関係者での合意を得られていない限り, 2度以上利用しないようにしなければならない (MUST). そのような合意の詳細については本仕様の定めるところではない.

exp

REQUIRED. ID Token の有効期限. この時刻を超えて当該 ID Token を受理してはならない (MUST NOT).

iat

OPTIONAL. JWT 発行時刻.

この JWT には, 他の Claim を含めても良い (MAY). 理解できない Claim は無視すること (MUST).

認証トークンは [OAuth.Assertions] (Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.) の client_assertion パラメータとして送信すること (MUST).

[OAuth.Assertions] (Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.) の client_assertion_type パラメータには, [OAuth.JWT] (Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.) の通りに "urn:ietf:params:oauth:client-assertion-type:jwt-bearer" とすること.

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

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

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

none

Client は Token Endpoint での認証を行わない. これには, Implicit Flow を使う (よって Token Endpoint 自体を利用しない) 場合と, Token Endpoint は利用するが Client Secret を持たない Public Client である場合, およびその他の何らかの認証手段を用いる場合がある.

10.  Signatures and Encryption

メッセージ送信経路によって, メッセージの完全性は保証されないこともあり, メッセージ送信者の認証も行われないこともある. これらのリスクを軽減するため, ID Token, UserInfo Response, Request Object および Client Authentication JWT は JSON Web Signature (JWS) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.) [JWS] によってそのコンテンツに対して署名することができる. メッセージ秘匿性を得るには, JSON Web Encryption (JWE) (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2014.) [JWE] を用いてコンテンツを暗号化する.

メッセージに署名と暗号化双方を適用する場合, Section 16.14 (Signing and Encryption Order) に従い, まず先に署名を行いその後暗号化すること (MUST). 結果はネストした JWT になる ([JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.) 参照). JWE の暗号手法は全て完全性チェックを含むことに注意すること.

OP は自身がサポートする署名および暗号化アルゴリズムを Discovery ドキュメント中で示すか, その他の方法でそれらを告知しても良い. RP は自身が要求する署名および暗号化アルゴリズムを Dynamic Registration リクエスト中に指定するか, その他の方法でそれらを告知しても良い.

OP は自身の公開鍵を Discovery ドキュメント中で示すか, その他の方法でそれを告知しても良い. RP は自身の公開鍵を Dynamic Registration リクエスト中に指定するか, その他の方法でそれを告知しても良い.

10.1.  Signing

署名者は受信者がサポートするアルゴリズムを元に署名アルゴリズムを選択しなければならない (MUST).

Asymmetric Signatures

RSA および ECDSA 署名を利用する場合, JWS ヘッダーの alg パラメータ値には, JSON Web Algorithms (Jones, M., “JSON Web Algorithms (JWA),” July 2014.) [JWA] に従い適切な値を指定しなければならない (MUST). 署名に使われた秘密鍵は, 署名検証に用いられる公開鍵と関連づいている必要があり, その公開鍵は署名者が JWK Set ドキュメントとして公開すること (MUST). JWK Set ドキュメントに複数の鍵が含まれる場合, JWS ヘッダーに kid 値を含まねばならない (MUST). 鍵は署名に使えるものでなければならない (MUST).

Symmetric Signatures

MAC ベースの署名を利用する場合, JWS ヘッダーの alg パラメータ値には, JSON Web Algorithms (Jones, M., “JSON Web Algorithms (JWA),” July 2014.) [JWA] に従い MAC アルゴリズムを指定しなければならない (MUST). MAC 鍵は client_secret の UTF-8 オクテットとする. client_secret のエントロピー要件に関しては Section 16.19 (Symmetric Key Entropy) を参照すること. 共通鍵署名は Client Secret を持たない Public Client (Non-Confidential Client) には利用できない (MUST NOT).

署名付リクエストについての Security Considerations については Section 16.20 (Need for Signed Requests) を参照すること.

10.1.1.  Rotation of Asymmetric Signing Keys

署名鍵のローテーションを行うには, 以下のアプローチに従うこと. 署名者は jwks_uri で指定した場所に JWK Set を公開し, 各メッセージの JWS ヘッダーに kid を含める. kid によって, 検証者はどの鍵を署名検証に用いれば良いか知ることができる. ここで jwks_uri で公開された JWK Set に定期的に新たな鍵を追加していくことで, 鍵をロールオーバーすることができる. 署名者は任意のタイミングで新しい鍵の利用を開始し, kid 値を用いて検証者に鍵が変わったことを知らせることができる. 検証者は未知の kid を検知した場合は jwks_uri にアクセスし, 再び鍵を取得する. jwks_uri にある JWK Set ドキュメントは, 利用停止から適切な期間, 利用廃止された鍵を含んだままにすべきである (SHOULD). それにより鍵の移行がスムーズになる.

10.2.  Encryption

暗号化を行う主体は, 受信者がサポートするアルゴリズムを元に, 暗号化アルゴリズムを選択しなければならない (MUST).

Asymmetric Encryption: RSA

公開鍵の暗号化に使う公開鍵は, 受信者が公開する JWK Set ドキュメント中に含まれている公開鍵でなくてはならない (MUST). JWK Set ドキュメント中に複数の鍵がある場合は, JWE ヘッダー中に kid を含めなければならない (MUST). ランダムな Content Encryption Key によって署名付 JWT を暗号化し, その鍵をサポートされている RSA 暗号化アルゴリズムを用いて暗号化すること. 鍵は暗号化に使えるものでなければならない (MUST).

Asymmetric Encryption: Elliptic Curve

JWE ヘッダーの epk に指定するには, 短命な Elliptic Curve 公開鍵を生成する. 鍵交換に利用するその他の鍵については, 受信者が JWK Set ドキュメント中に公開すること (MUST). JWK Set に複数の鍵が含まれる場合は, JWE ヘッダーに kid を指定すること. 署名済 JWT の暗号化に用いる Content Encryption Key の鍵交換には, ECDH-ES アルゴリズムを用いる. 鍵は暗号化に使えるものでなければならない (MUST).

Symmetric Encryption

共通鍵暗号に用いる共通鍵は, client_secret UTF-8 オクテット SHA-2 ハッシュから左側を切り詰めたものとする. 256ビット以下の鍵には SHA-256, 257-384ビットの鍵には SHA-384, 385-512ビットの鍵には SHA-512 を用いること. ハッシュ値は, 利用する AES 鍵ラップやその他の暗号化アルゴリズムによって適切な長さになるよう, 左側を切り詰めること. 例えば A128KW を用いる場合は, SHA-256 ハッシュを切り詰めて128ビットを取り出す. 512ビット以上の鍵が必要になった場合は, client_secret から鍵を導出する何らかの方法を, 拡張仕様として定義することになろう. 共通鍵暗号は Client Secret を持たない Public Client (Non-Confidential Client) には利用できない (MUST NOT).

暗号化リクエストについての Security Considerations については Section 16.21 (Need for Encrypted Requests) を参照すること.

10.2.1.  Rotation of Asymmetric Encryption Keys

暗号鍵のローテーションは, 署名鍵のローテーションとは異なるプロセスとなる. これは暗号化の場合, 暗号化を行う主体からプロセスが開始され, kid の変更を鍵交換のサインとして利用できないからである. 暗号化を行う主体は, JWE ヘッダーに kid を指定して, どの鍵で復号すべきかを復号を行う主体に知らせることができる. しかしながら暗号化を行う主体は受信者の jwks_uri にある JWK Set から, 適切な鍵を選ばねばならない.

鍵ローテーションを行うには, 復号を行う主体がまず新しい鍵を jwks_uri で公開し, 廃止された鍵を JWK Set から削除する. jwks_uri は, RFC 2616 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] に従いレスポンス中の Cache-Control ヘッダーに max-age を含め, 暗号化を行う主体による JWK Set のキャッシュを適切にコントロールし, 暗号化を行うたびに毎回 JWK Set を取得する必要がないようにすべきである (SHOULD). 復号を行う主体は廃止された鍵を jwks_uri が参照する JWK Set から削除しつつも, 適切な期間その鍵を内部的に保持しておくべきである (SHOULD). これにより暗号化を行う主体が新しい鍵を取得するまでにある程度の猶予を許し, スムースな移行が可能になる. キャッシュ期間は, Section 10.1.1 (Rotation of Asymmetric Signing Keys) にある新しい署名鍵の発行とのバランスを取り, 適切に調整すること (SHOULD).

11.  Offline Access

OpenID Connect では, offline access を要求するため以下の scope 値を定義している.

offline_access

OPTIONAL. OAuth 2.0 Refresh Token の発行を要求する. Request Token は End-User の関与を必要とせずに End-User の UserInfo Endpoint にアクセスするための Access Token を取得するために利用される.

offline access を要求する際には, リクエストするリソースに対する offline access の許可に必要な何らかの他の条件を満たさない限り, prompt パラメータに consent を指定しなければならない (MUST). OP は Refresh Token を発行する際は必ず明示的な同意を得なければならない (MUST). ユーザーの事前同意は offline access の許可には常に十分とはならない.

offline_access scope を受け取った Authorization Server は, 以下に従う.

• prompt パラメータが consent を含むことを確認する. offline access 要求処理における何らかの他の条件を満たす場合はその限りではない. 上記の条件のどちらをも満たさない場合, offline_access リクエストを無視しなければならない (MUST).
• Client が Authorization Code を返すような response_type を指定しない場合, その offline_access を無視しなければならない (MUST).
• Client の登録した application_type が web の場合は, 明示的に同意を得なければならない (MUST).
• Client の登録した application_type が native の場合でも, 明示的な同意を得るべきである (SHOULD).

Refresh Token の利用は, offline_access がもたらすユースケースのみに限らない. Authorization Server は異なるコンテキストにおいて Refresh Token を発行しても良い (MAY). なおそのようなコンテキストについては, 本仕様の定めるところではない.

12.  Using Refresh Tokens

Refresh Token を利用するには, OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Section 6 に従い, Token Endpoint に grant_type を refresh_token としたリクエストを送る. ここでは OpenID Connect Authorization Server が Refresh Token を受け取った際の挙動について定義する.

12.1.  Refresh Request

Access Token 再発行のため, Client は自身の client_id に紐づいて登録された認証方法で, Token Endpoint に対して自身を認証しなければならない (MUST). 詳細は Section 9 (Client Authentication) 参照. Client は Section 13.2 (Form Serialization) で述べた Form Serialization を用いて, Token Endpoint に HTTP POST リクエストを送る.

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

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

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

Authorization Server は Refresh Token を検証し, それが Client に対して発行されたものであることを確認し, Client 認証がその Client の Client Authentication 方法によって成功したことを確認しなければならない (MUST).

12.2.  Successful Refresh Response

Refresh Token の検証が成功すると, レスポンスボディに Section 3.1.3.3 (Successful Token Response) で述べた Token Response を含める. ただしこのレスポンスは id_token を含まない場合もある.

トークン再発行の際に ID Token を発行する場合は, 以下に従う.

• iss Claim Value は, 最初の認可発生時に発行された ID Token と同じ値にすること (MUST).
• sub Claim Value も同様に, 最初の認可発生時に発行された ID Token と同じ値にすること (MUST).
• iat Claim は新しい ID Token の発行時刻にすること (MUST).
• aud Claim Value は, 最初の認可発生時に発行された ID Token と同じ値にすること (MUST).
• ID Token に auth_time Claim を含める場合は, 新しい ID Token の発行時刻ではなく, 最初の認証を行った時刻とすること (MUST).
• azp Claim Value は, 最初の認可発生時に発行された ID Token と同じ値にすること (MUST). azp が最初に発行された ID Token に含まれない場合は, 新しい ID Token にもそれを含めてはならない (MUST NOT).
• それ以外に関しては, 最初の認証時に発行された ID Token と同じルールを適用する.

以下は Refresh Response の例である.

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

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

12.3.  Refresh Error Response

Refresh Request が不正もしくは認証できなかった場合, Authorization Server は OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Section 5.2 に従い Token Error Response を返す.

13.  Serializations

メッセージは以下のいずれかの方法でシリアライズされる.

1. Query String Serialization
2. Form Serialization
3. JSON Serialization

ここではこれらのシリアライゼーション方法のシンタックスについて記述する. それらがいつ利用可能, もしくは利用する必要があるかを記述するのは, 他セクションに委ねる. すべてのシリアライゼーションがすべてのメッセージに利用可能ではないことに注意すること.

13.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 フォーマットを使いパラメータと値を URL のクエリコンポーネントへ追加することで文字列を構成する. Query String Serialization は一般的に HTTP GET リクエストで使用される.

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

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

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

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

13.3.  JSON Serialization

パラメータは各パラメータを JSON オブジェクトの最上位メンバーに追加する形で, JSON オブジェクトにシリアライズされる. パラメータ名と文字列値は JSON 文字列として表現される. 数値は JSON 数値, Boolean 値は JSON 真偽値となる. 他で特別に指示されない限り, 省略されているパラメータおよび値が指定されていないパラメータは省略し, JSON null としないようにすべきである (SHOULD). 各パラメータは JSON オブジェクトおよび JSON 配列をその値とすることができる (MAY).

以下はシリアライズの参考例である.

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

14.  String Operations

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

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

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

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

15.  Implementation Considerations

本仕様では, Relying Party と OpenID Provider の両者により利用される機能について定義している. OpenID Provider によっては, RP との事前登録不要で動的に利用可能なものもあれば, 固有で out-of-band な設定を必須とするものもあるだろう. このため, OP 向けの実装必須の機能を以下の２グループに分類しておく. 1つ目は全ての OP 向け, 2つ目は "Dynamic" な OpenID Providers 向けである.

15.1.  Mandatory to Implement Features for All OpenID Providers

全ての OpenID Provider は本仕様にて定義される下記機能を実装しなければならない (MUST). このリストは別の場所で "REQUIRED" もしくは "MUST" として既に記載されている機能セットを拡張するものあり, それ単体で広範囲に渡る OP 向けの実装要件となるものではない.

Signing ID Tokens with RSA SHA-256

OP は RSA SHA-256 (alg=RS256) による ID Token への署名をサポートしなければならない (MUST). ただし OP が ID Token を (Authorization Code フローの場合のように) Token Endpoint のみから返却し, ID Token 署名アルゴリズムとして none を要求した状態でのみ Client 登録を許可する場合は, その限りでは無い.

Prompt Parameter

OP は Section 3.1.2 (Authorization Endpoint) で定義されている prompt パラメータをサポートしなければならない (MUST). これには none や login などが規定するユーザインタラクションの実装を含む.

Display Parameter

OP は Section 3.1.2 (Authorization Endpoint) で定義されている display パラメータをサポートしなければならない (MUST). (このパラメータで要求される最低限度のサポートは, 単にこれを使うことでエラーにならないことであることに注意)

Preferred Locales

OP は Section 3.1.2 (Authorization Endpoint) で定義されている ui_locales と claims_locales パラメータによってユーザインターフェースと Claim 用の推奨の言語や文字種のリクエストをサポートしなければならない (MUST). (これらのパラメータで要求される最低限度のサポートは, 単にこれをつかうことでエラーにならないことであることに注意)

Authentication Time

OP は Section 2 (ID Token) で定義されているように, 要求があれば auth_time Claim によってエンドユーザが認証を行った時刻返却しなければならない(MUST).

Maximum Authentication Age

OP は Section 3.1.2 (Authorization Endpoint) で定義されているように, max_age パラメータによる最大認証期間 (maximum authentication age) の強制をサポートしなければならない (MUST).

Authentication Context Class Reference

OP は Section 3.1.2 (Authorization Endpoint) で定義されているように, acr_values パラメータを用いて特定の認証コンテキストクラスリファレンスの値のリクエストをサポートしなければならない (MUST). (このパラメータで要求される最低限度のサポートは, 単にこれを使うことでエラーにならないことであることに注意)

15.2.  Mandatory to Implement Features for Dynamic OpenID Providers

上記の機能に加えて, 事前設定をしていない RP と動的に連携を行うことをサポートしている OpenID Provider は, 本仕様や関連仕様にて定義されている下記の機能も実装しなくてはならない (MUST).

Response Types

OpenID Provider は Response Type id_token, また Self-Issued OP ではない OP は code と id_token token もサポートしなければならない (MUST).

Discovery

OP は OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” November 2014.) [OpenID.Discovery] で定義されているように Discovery 機能をサポートしなければならない (MUST).

Dynamic Registration

OP は OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.) [OpenID.Registration] で定義されているように, Dynamic Client Registration をサポートしなければならない (MUST).

UserInfo Endpoint

Access Token を発行する全て動的な OP は Section 5.3 (UserInfo Endpoint) で定義されているように, UserInfo Endpoint をサポートしなければならない (MUST). (Self-Issued OP は Access Token を発行しない)

Public Keys Published as Bare Keys

OP は自身の公開鍵を素の JWK 鍵として公開しなければならない (MUST). (当該鍵は JWK 形式に加えて別途 X.509 形式で公開してもよい (MAY))

Request URI

OP は Section 3.1.2 (Authorization Endpoint) で定義されているように, request_uri パラメータで提供された Request URI から取得する Request Object 値を使ってリクエストを送信できるようにしなければならない (MUST).

15.3.  Discovery and Registration

OpenID Connect 導入にあたっては, 事前に設定された OpenID Provider および Relying Party のセットが利用可能なこともある. そのような場合には, Identity やサービス, Dynamic Client Registration についての情報に関する Dynamic Discovery をサポートする必要は無いかもしれない.

しかし, 事前登録のない Relying Party と OpenID Provider 間の予期しないやりとりをサポートすることを選択したならば, OpenID Discovery 1.0 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” November 2014.) [OpenID.Discovery] と OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.) [OpenID.Registration] の仕様で定義されているファシリティを実装するべきである (SHOULD).

15.4.  Mandatory to Implement Features for Relying Parties

一般的に, OpenID Provider と通信する際にどの機能を利用するかは, Relying Party に次第である. しかし, いくつかの選択肢に関しては, OAuth Client の性質によって決定づけられるものもある. secret を秘匿に保てる Confidential Client であれば Authoriation Code Flow が適切であるし, User Agent Based Application や静的登録された Native Application のような Public Client には, Implicit Flow が適切であろう.

OpenID Connect の機能を利用する際に, それらが "REQUIRED" や "MUST" として記載されていれば RP に利用されるときに実装必須の機能となる. 同様に "OPTIONAL" と記載されている機能は, 特定のアプリケーションコンテキストで価値をもたらさないのであれば, 利用したりサポートする必要はない. 最後に, Discovery をサポートする OpenID Provider とやりとりをするときは, OP の Discovery ドキュメントを利用して, RP がどの OP の機能を利用できるかを動的に決定することもできる.

15.5.  Implementation Notes

15.5.1.  Authorization Code Implementation Notes

Authorization Code フローあるいは Hybrid フロー を用いる場合, Authorization Code を用いた Token Request への応答として, ID Token が Token Endpoint から返却される. ある実装では, Authorization Code 値の中に, 返却する ID Token の状態を符号化して持たせることを選択するかもしれない. 別の実装では, 状態を格納しているデータベースに対するインデックスとして, Authorization Code 値を使用するかもしれない.

15.5.2.  Nonce Implementation Notes

nonce パラメータ値は, セッション毎の状態を含むとともに, 攻撃者によって推測されないようにする必要がある. Web Server Client がこの要件を満足する手法の一つは, HttpOnly 属性付きのセッションクッキーとして暗号論的乱数値を格納し, その値の暗号学的ハッシュを nonce パラメータとして使用することである. このケースでは, 第三者による ID Token リプレイを検出するために, 返却される ID Token 内の nonce と セッションクッキーのハッシュを比較する. JavaScript Client に対して適用可能な関連手法として, HTML5 ローカルストレージに暗号論的乱数値を格納し, その値の暗号学的ハッシュを用いる方法がある.

15.5.3.  Redirect URI Fragment Handling Implementation Notes

レスポンスパラメータを Redirection URI のフラグメント値として返却する場合, Client は User Agent に対し, そのフラグメント内の符号化された値をパースさせ, Client の処理ロジックにその値を受け渡す必要がある. 暗号 API に直接アクセスする User Agent は, 例えば全ての Client コードを JavaScript で記述するなど, 処理に必要なロジック等を全て自己の中で完結させることが出来る.

しかし, Client を完全に User Agent 内だけで実行しない場合, 検証のために Web Server Client にデータを送信することで目的を実現する方法もある.

Client が自身の redirect_uri 上でホストすることが考えられる JavaScript ファイルの例を以下に示す. これは Authorization Server からのリダイレクトによってロードされる. フラグメント部はパースされた後, 受信した情報の検証と利用を行う URL に対し, POST で送信される.

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

15.6.  Compatibility Notes

15.6.1.  Pre-Final IETF Specifications

実装者は, この仕様がまだ最終仕様でない複数の IETF 仕様を利用していることに注意すべきである. それらの仕様は以下のとおり:

• JSON Web Token (JWT) draft -25 (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.) [JWT]
• JSON Web Signature (JWS) draft -31 (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.) [JWS]
• JSON Web Encryption (JWE) draft -31 (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2014.) [JWE]
• JSON Web Key (JWK) draft -31 (Jones, M., “JSON Web Key (JWK),” July 2014.) [JWK]
• JSON Web Algorithms draft -31 (Jones, M., “JSON Web Algorithms (JWA),” July 2014.) [JWA]
• Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants draft -17 (Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.) [OAuth.Assertions]
• JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants draft -10 (Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July 2014.) [OAuth.JWT]

これらの仕様に重要な変更を防ぐためにあらゆる努力を行うとしても, それらは発生するかもしれない. OpenID Connect の実装は上記の特別に参照された各ドラフトバージョンを Final バージョンに優先して利用しつづけるべきである. 将来的に OpenID Connect の Profile や仕様がこれらの参照を更新した場合には, その限りではない.

15.6.2.  Google "iss" Value

この文書を執筆している時点では, Google の OpenID Connect の実装は, ID Token の iss (issuer) Claim 値として必須となっている https:// スキームプレフィックスを省略していることに注意すべきである. Google と連携を希望する Relying Party は, この実装が更新されるまでは, これに対処するためのコードを持っている必要がある. このような問題を回避するためのコードは, Google が Issuer 値にプレフィックスを追加した場合でも, 壊れないような形式で書かれるべきである.

15.7.  Related Specifications and Implementer's Guides

関連する OPTIONAL 仕様は, 追加機能を提供するために本仕様と組み合わせて利用されるかもしれない (MAY).

• OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” November 2014.) [OpenID.Discovery] - Relying Party が OpenID Provider についての情報を動的に発見する方法を定義する.
• OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.) [OpenID.Registration] - Relying Party が OpenID Provider に動的に登録する方法を定義する.
• OpenID Connect Session Management 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Session Management 1.0,” November 2014.) [OpenID.Session] - ログアウト機能を含む, OpenID Connect のセッション管理の方法を定義する.
• OAuth 2.0 Form Post Response Mode (Jones, M. and B. Campbell, “OAuth 2.0 Form Post Response Mode,” February 2014.) [OAuth.Post] - HTTP POST を使用するユーザエージェントによって, 自動送信された HTML フォーム値を使用して, OAuth2.0 の Authorization Response パラメータ (OpenID Connect Autentication Response パラメータを含む) を返却する方法を定義する.

これらの実装者ガイドは, 基本的な Web ベースの Relaying 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,” November 2014.) [OpenID.Basic] - この実装者ガイドは, OAuth Authorization Code 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,” November 2014.) [OpenID.Implicit] - この実装者ガイドは, OAuth Implicit Flow を使用するベーシックな Web ベースの Relying Party で利用することを目的とした, この仕様のサブセットを含んでいる.

16.  Security Considerations

本仕様は, OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の Section 10, OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] の Section 5 に定義されている security considerations を参照する. さらに, OAuth 2.0 Threat Model and Security Considerations (Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.) [RFC6819] は, この仕様にもよくあてはまる OAuth 2.0 をベースとした脅威と制御の広範囲なリストを提供する. ISO/IEC 29115 (International Organization for Standardization, “ISO/IEC 29115:2013 -- Information technology - Security techniques - Entity authentication assurance framework,” March 2013.) [ISO29115] もまた, 実装者が考慮する必要がある脅威と制御を提供する. 実装者には, これらの引用の詳細を読み, それらに記載されている対抗策を適用することを勧める.

加えて, 以下の攻撃ベクトルと救済策のリストもまた, 考慮される.

16.1.  Request Disclosure

適切な処置が講じられないとき, リクエストは攻撃者に漏洩され, セキュリティとプライバシーの脅威をもたらすかもしれない.

[RFC6819] (Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.) の Section 5.1.1 にあることに加え, この仕様は request パラメータ (request の内容は適切な鍵と暗号により暗号化された JWT) もしくは request_uri パラメータを利用することによりエンドツーエンドでリクエストの機密性を提供する方法を提供する. これは, 間接的なリクエストの場合に改ざんされた User Agent からも保護する.

16.2.  Server Masquerading

悪意のある Server は, 様々な方法を用いて正規の Server に成りすますかもしれない. そのような攻撃を検知するため, Client は Server を認証する必要がある.

[RFC6819] (Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.) の Section 5.1.2 にあることに加え, この仕様は適切な鍵と暗号を用いた Signed JWT と Encrypted JWT の両方で Server を認証する方法を提供する.

16.3.  Token Manufacture/Modification

攻撃者は偽のトークンを生成もしくは既存の解析可能なトークンの内容 (Claim や署名など) を修正し, RP に Client への不適切なアクセスを引き起こすかもしれない. 例えば, 攻撃者は解析可能なトークンの有効期限を延長するかもしれない : Client は彼らが閲覧できない情報にアクセスするために解析可能なトークンを修正するかもしれない.

この攻撃を軽減するための2つの方法がある:

1. トークンはOPによりデジタル署名をつけることができる. Relying Party はそれが正規の OP から発行されたことを確認するためにデジタル署名を検証すべき (SHOULD).
2. トークンは TLS のような, 保護されたチャンネル上で送られることができる. TLS の利用についての情報は Section 16.17 (TLS Requirements) を参照すること. この仕様では, トークンは常に TLS で保護されたチャンネル上で送られる. しかし, この手段は第3者の攻撃に対する防御のみであり, Client が攻撃者になるケースには適用できない点に注意すること.

16.4.  Access Token Disclosure

OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] の Section 1.4 で定義されているように, Access Token は Protected Resources にアクセスするために用いられるクレデンシャルである. Access Token は End-User の認可を表すものであり, 認可されていない対象にさらされることはあってはならない (MUST NOT).

16.5.  Server Response Disclosure

サーバーのレスポンスは, 認証データとセンシティブな Client 情報を含む Claim を含む可能性がある. レスポンス内容の暴露は, Client を他の種類の攻撃に対して脆弱にすることができる.

サーバーレスポンスの公開は, 次の2つの方法により軽減されることができる:

1. Response Type に code を利用する. レスポンスは TLS で保護されたチャンネル上で送られ, Client は client_id と client_secret によって認証される.
2. その他の Response Type については, 適切な鍵と暗号により暗号化された JWT として Client の公開鍵もしくは共有秘密鍵を暗号化されることができる.

16.6.  Server Response Repudiation

適切なメカニズムが実施されていないならば, レスポンスは Serverにより拒否されるかもしれない. 例えば, Server が デジタル署名をレスポンスに施さなかった場合, Server はそれが自身のサービスを通して生成されていないと主張することができる.

この脅威を軽減するため, レスポンスは否認防止のための鍵を用いて Server により署名されてもよい (MAY). Client はそれが正規の Server から発行されたものであり, 完全であることを確認するためにデジタル署名を検証すべき (SHOULD).

16.7.  Request Repudiation

脆弱または悪意のある Client がリクエストを誤った対象に送ることがありえるため, bearer token のみを利用して認証された Client はいかなるトランザクションでも拒否されることができる.

この脅威を軽減するため, Server は Client により否認防止のための鍵を用いてデジタル署名されたリクエストを要求してもよい (MAY). Server はそれが正規の Client から発行されたものであり, 完全であることを確認するためにデジタル署名を検証すべき (SHOULD).

16.8.  Access Token Redirect

攻撃者は, あるリソースのために生成された Access Token を別のリソースへのアクセスするために利用する.

この脅威を軽減するため, Access Token は audience と scope に対して制限をかけるべき (SHOULD). それを実装するひとつの方法として, audience として生成されたリソースの識別子を含むことがある. リソースは, 受け取ったトークンが audience として自身の識別子を含むことを確認する.

16.9.  Token Reuse

攻撃者は, 対象の Resource のために既に一度利用された Authorization Code のようなワンタイムなトークンの再利用を試みる. この脅威を軽減するため, トークンはタイムスタンプを含み, 有効期限を短くすべき (SHOULD). Relying Party は, トークンが現時点で有効であることを確実にするため, タイムスタンプと有効期限の値をチェックする.

あるいは, サーバーはトークンの利用状況を記録し, リクエスト毎にその状態を確認してもよい (MAY).

16.10.  Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)

User Agent がマルウェアに感染している場合は, [RFC6819] (Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.) Section 4.4.1.1 にある攻撃パターンに加え, Authorization Code が TLS セッションの終端となる User Agent 上でも盗聴される可能性がある. Client Authentication やレスポンス暗号化を用いると, この盗聴パターンは無効化できる.

16.11.  Token Substitution

Token Substitution は, 不正なユーザがトークンを置換するタイプの攻撃である. 交換されるトークンには Authorization Code も含まれる. アタッカーがあるセッション中からトークンを取り出し, 別のセッション中でそれを利用するなどすることで, この攻撃が可能となる. トークンがブラウザに渡される場合, これは非常に簡単な作業であり, 別名 "cut and paste" 攻撃とも呼ばれる.

OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Implicit Flow は, このリスクを考慮した設計になってはいない. OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Section 10.16 においては, End-User 認証の為に OAuth 2.0 を利用する場合, Client が ID Token や Access Token が認証目的で利用可能かどうか判断できる追加のセキュリティメカニズムがない場合には Implicit Flow を利用しないよう Client に要求している (MUST NOT).

OpenID Connect では, ID Token を利用することでこのリスクを回避できる. ID Token は署名付きのセキュリティトークンであり, iss (issuer), sub (subject), aud (audience), azp (authorized party), at_hash (access token hash), および c_hash (code hash) を Claim として提供する. ID Token を利用することで, Client は Token Substitution Attack を検知可能になる.

ID Token 内の c_hash は, Authorization Code 置換を防ぐために利用できる. 同様に at_hash は Access Token 置換を防ぐために利用できる.

また不正なユーザが, Authorization Endpoint と Client の間, もしくは Token Endpoint と Client の間の通信に介入し, Authorization Code を置換したりメッセージの順序を入れ替えたりすることで, 特権ユーザになりすます可能性もある. この攻撃により, Token Endpoint が攻撃者の提示した認可グラントが, より権限の強い特権ユーザのそれとして受け入れてしまうかもしれない.

本仕様で定義された HTTP バインディングでは, Token Request に対するレスポンスは HTTP メッセージ順に対応するリクエストと紐づけられる. トークンを含んだレスポンスとリクエストが TLS で保護されている限り, パケットの順序入れ替えは検知および防御可能であろう.

Token Endpoint へのリクエストとレスポンスを強固に紐づけることができない何らかの他のプロトコルをバインディングとして本仕様を適用する場合, この問題に対する何らかの追加の対策が必要となる (MUST). c_hash Claim を含んだ ID Token をトークンリクエストおよびレスポンスに含むことなどが, 例として挙げられる.

16.12.  Timing Attack

タイミングアタックにより, 攻撃者は復号処理や署名検証の成功/失敗にかかる処理時間の違いを通じて, 必定以上に多くの情報を得ることができる. この攻撃は, 暗号文の有効な鍵長を限定する為に利用できる.

実装者はエラーを検知した際すぐに検証プロセスを終了するのではなく, 他のオクテットに対する処理を終えるまで処理を継続し, この攻撃を防ぐべきである (SHOULD).

16.13.  Other Crypto Related Attacks

暗号, 署名, 完全性検証の手法に応じて, 暗号関連の様々な攻撃が考えられる. 実装者は JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.) [JWT] の Security Considerations, および JWT が参照する, 各脆弱性を防ぐための仕様群に従うこと.

16.14.  Signing and Encryption Order

暗号文に対する署名は, 多くの法域 (jurisdiction: 法律用語, ある法律が適用される地域のこと) で有効と認められない. 従って本仕様では, 完全性と非否認性を確保するため署名を利用する際には, 平文の JSON Claim に対して署名をすることを要求する. 署名と暗号化がともに必要となる場合, 署名対象の Claim を含んだ JWS に対して暗号化を行うこと. これにより [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.) で述べられている Nexted JWT が導出される. なお, 全ての JWE 暗号化アルゴリズムは完全性保護を提供しており, 暗号文に別途署名を行う必要はないことに注意すること.

16.15.  Issuer Identifier

OpenID Connect では, 1つの Host と Port のペアに対して複数の Issuer を配置することができる. 従って, ディスカバリーで返される issuer は, ID Token に含まれる iss と完全一致しなければならない (MUST).

OpenID Connect は Issuer URI のパスコンポーネントを Issuer Identifier の一部として扱う. よって例えば subject が同じ "1234" であったとしても, Issuer Identifier が "https://example.com" なものと "https://example.com/sales" なものとでは, 異なる subject となる.

ホストごとに単一の Issuer にとどめることを推奨する (RECOMMENDED). しかしながらマルチテナントなホストでは, 単一ホストに対して複数の Issuer が必要になるケースもあるであろう.

16.16.  Implicit Flow Threats

Implicit Flow では, Access Token は Client の redirect_uri のフラグメントを介して HTTPS で返される. 従って OP と User Agent の間, User Agent と RP の間の通信は, 保護されている. しかしながら User Agent がマルウェアに感染していたり不正な操作者のコントロール下にある場合は, TLS セッションの終端となる User Agent 上で Access Token を読み取られることもありうる.

16.17.  TLS Requirements

各実装は TLS をサポートしなければならない (MUST). どのバージョンを実装するかは, 時間の経過や広く利用されている実装, 既知のセキュリティ上の脆弱性などによって, その時々で変化しうる. 本仕様執筆時点では, TLS version 1.2 [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) が最新のバージョンであるが, 実装は限定される. そのため実装時に使うツールキットではすぐには利用できないかもしれない. TLS version 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) は最も広く利用されているバージョンであり, 最も広い相互運用性を提供するであろう.

情報漏洩や改竄に対しては, TLS を用いた秘匿性保護が必須である (MUST). TLS の秘匿性および完全性保護を提供する暗号スイートを利用すること.

TLS を利用する際は, 常に TLS サーバ証明書を検証しなければならない (MUST). 詳細は RFC 6125 (Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.) [RFC6125] を参照のこと.

16.18.  Lifetimes of Access Tokens and Refresh Tokens

Authorization Server は Access Token を無効化できないかもしれない. 従って, Access Token の有効期間は一度の利用に十分な期間, もしくは非常に短い期間に限定するべきである (SHOULD).

UserInfo Endpoint や他の Protected Resource に対する継続したアクセスが必要な場合は, Refresh Token を利用できる. Client は Token Endpoint に Refresh Token を送ることで, 新規の有効期間の短い Access Token を取得し, リソースアクセスに利用できる.

Authorization Server は Authorization 中に User に対して長期間の認可を与えようとしていることを明示すべきである (SHOULD). Authorization Server は End-User に対して, 特定の Client に発行された Access Token および Refresh Token を無効化する手段を提供すべきである (SHOULD).

16.19.  Symmetric Key Entropy

Section 10.1 (Signing) と Section 10.2 (Encryption) では, 鍵は client_secret 値から導出される. 従って共通鍵暗号による署名および暗号化を行うためには, client_secret が十分なエントロピーを持った暗号論的に強固な鍵とする必要がある (MUST). また client_secret は利用するアルゴリズムが利用する MAC 鍵に必要な最低限のオクテット長を持つ必要がある (MUST). 例えば HS256 を利用する際は, client_secret は最低でも32オクテットが必要である (MUST). (なお, 多くのの場合 client_secret はアルファベットに限定されるため, 明らかにそれ以上のオクテットが必要となるであろう (SHOULD))

16.20.  Need for Signed Requests

場合によっては, Client はリクエストパラメータの改竄を防止するため, リクエストに署名を行う必要があるかもしれない. 例えば max_age と acr_values などは, 署名付きリクエストを用いた方がより正確に認証処理についての保証として有用になるであろう.

16.21.  Need for Encrypted Requests

場合によっては, OpenID Connect リクエストを除き見ることで, End-User に関するセンシティブな情報を漏洩させることもある. 例えば Client が特定の Claim を要求したことや特定の認証方法を要求したことを知ることで, End-User に関するセンシティブな情報を漏洩させることもある. OpenID Connect は OpenID Provider へのリクエストを暗号化可能とすることで, センシティブ情報の漏洩を防止可能にする.

17.  Privacy Considerations

17.1.  Personally Identifiable Information

The UserInfo Response typically contains Personally Identifiable Information (PII). As such, End-User consent for the release of the information for the specified purpose should be obtained at or prior to the authorization time in accordance with relevant regulations. The purpose of use is typically registered in association with the redirect_uris.

Only necessary UserInfo data should be stored at the Client and the Client SHOULD associate the received data with the purpose of use statement.

17.2.  Data Access Monitoring

The Resource Server SHOULD make End-Users' UserInfo access logs available to them so that they can monitor who accessed their data.

17.3.  Correlation

To protect the End-User from a possible correlation among Clients, the use of a Pairwise Pseudonymous Identifier (PPID) as the sub (subject) SHOULD be considered.

17.4.  Offline Access

Offline access enables access to Claims when the user is not present, posing greater privacy risk than the Claims transfer when the user is present. Therefore, it is prudent to obtain explicit consent for offline access to resources. This specification mandates the use of the prompt parameter to obtain consent unless it is already known that the request complies with the conditions for processing the request in each jurisdiction.

When an Access Token is returned via the User Agent using the Implicit Flow or Hybrid Flow, there is a greater risk of it being exposed to an attacker, who could later use it to access the UserInfo endpoint. If the Access Token does not enable offline access and the server can differentiate whether the Client request has been made offline or online, the risk will be substantially reduced. Therefore, this specification mandates ignoring the offline access request when the Access Token is transmitted through the User Agent. Note that differentiating between online and offline access from the server can be difficult especially for native clients. The server may well have to rely on heuristics. Also, the risk of exposure for the Access Token delivered through the User Agent for the Response Types of code token and token is the same. Thus, the implementations should be prepared to detect whether the Access Token was issued through the User Agent or directly from the Token Endpoint and deny offline access if the token was issued through the User Agent.

Note that although these provisions require an explicit consent dialogue through the prompt parameter, the mere fact that the user pressed an "accept" button etc., might not constitute a valid consent. Developers should be aware that for the act of consent to be valid, typically, the impact of the terms have to be understood by the End-User, the consent must be freely given and not forced (i.e., other options have to be available), and the terms must fair and equitable. In general, it is advisable for the service to follow the required privacy principles in each jurisdiction and rely on other conditions for processing the request than simply explicit consent, as online self-service "explicit consent" often does not form a valid consent in some jurisdictions.

18.  IANA Considerations

18.1.  JSON Web Token Claims Registration

This specification registers the Claims defined in Section 5.1 (Standard Claims) and Section 2 (ID Token) in the IANA JSON Web Token Claims registry defined in [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2014.).

18.1.1.  Registry Contents

• Claim Name: name
• Claim Description: Full name
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: given_name
• Claim Description: Given name(s) or first name(s)
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: family_name
• Claim Description: Surname(s) or last name(s)
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: middle_name
• Claim Description: Middle name(s)
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: nickname
• Claim Description: Casual name
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: preferred_username
• Claim Description: Shorthand name by which the End-User wishes to be referred to
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: profile
• Claim Description: Profile page URL
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: picture
• Claim Description: Profile picture URL
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: website
• Claim Description: Web page or blog URL
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: email
• Claim Description: Preferred e-mail address
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: email_verified
• Claim Description: True if the e-mail address has been verified; otherwise false
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: gender
• Claim Description: Gender
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: birthdate
• Claim Description: Birthday
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: zoneinfo
• Claim Description: Time zone
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: locale
• Claim Description: Locale
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: phone_number
• Claim Description: Preferred telephone number
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: phone_number_verified
• Claim Description: True if the phone number has been verified; otherwise false
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: address
• Claim Description: Preferred postal address
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: updated_at
• Claim Description: Time the information was last updated
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 5.1 (Standard Claims) of this document

• Claim Name: azp
• Claim Description: Authorized party - the party to which the ID Token was issued
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 2 (ID Token) of this document

• Claim Name: nonce
• Claim Description: Value used to associate a Client session with an ID Token
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 2 (ID Token) of this document

• Claim Name: auth_time
• Claim Description: Time when the authentication occurred
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 2 (ID Token) of this document

• Claim Name: at_hash
• Claim Description: Access Token hash value
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 2 (ID Token) of this document

• Claim Name: c_hash
• Claim Description: Code hash value
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 3.3.2.11 (ID Token) of this document

• Claim Name: acr
• Claim Description: Authentication Context Class Reference
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 2 (ID Token) of this document

• Claim Name: amr
• Claim Description: Authentication Methods References
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 2 (ID Token) of this document

• Claim Name: sub_jwk
• Claim Description: Public key used to check the signature of an ID Token
• Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification Document(s): Section 7.4 (Self-Issued OpenID Provider Response) of this document

18.2.  OAuth Parameters Registration

This specification registers the following parameters in the IANA OAuth Parameters registry defined in RFC 6749 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749].

18.2.1.  Registry Contents

• Parameter name: nonce
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2 (Authorization Endpoint) of this document
• Related information: None

• Parameter name: display
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2 (Authorization Endpoint) of this document
• Related information: None

• Parameter name: prompt
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2 (Authorization Endpoint) of this document
• Related information: None

• Parameter name: max_age
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2 (Authorization Endpoint) of this document
• Related information: None

• Parameter name: ui_locales
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2 (Authorization Endpoint) of this document
• Related information: None

• Parameter name: claims_locales
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 5.2 (Claims Languages and Scripts) of this document
• Related information: None

• Parameter name: id_token_hint
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2 (Authorization Endpoint) of this document
• Related information: None

• Parameter name: login_hint
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2 (Authorization Endpoint) of this document
• Related information: None

• Parameter name: acr_values
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2 (Authorization Endpoint) of this document
• Related information: None

• Parameter name: claims
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 5.5 (Requesting Claims using the "claims" Request Parameter) of this document
• Related information: None

• Parameter name: registration
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 7.2.1 (Providing Information with the "registration" Request Parameter) of this document
• Related information: None

• Parameter name: request
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 6 (Passing Request Parameters as JWTs) of this document
• Related information: None

• Parameter name: request_uri
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 6 (Passing Request Parameters as JWTs) of this document
• Related information: None

• Parameter name: id_token
• Parameter usage location: Authorization Response, Access Token Response
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.3.3 (Successful Token Response) of this document
• Related information: None

18.3.  OAuth Extensions Error Registration

This specification registers the following errors in the IANA OAuth Extensions Error registry defined in RFC 6749 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749].

18.3.1.  Registry Contents

• Error name: interaction_required
• Error usage location: Authorization Endpoint
• Related protocol extension: OpenID Connect
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2.6 (Authentication Error Response) of this document

• Error name: login_required
• Error usage location: Authorization Endpoint
• Related protocol extension: OpenID Connect
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2.6 (Authentication Error Response) of this document

• Error name: account_selection_required
• Error usage location: Authorization Endpoint
• Related protocol extension: OpenID Connect
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2.6 (Authentication Error Response) of this document

• Error name: consent_required
• Error usage location: Authorization Endpoint
• Related protocol extension: OpenID Connect
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2.6 (Authentication Error Response) of this document

• Error name: invalid_request_uri
• Error usage location: Authorization Endpoint
• Related protocol extension: OpenID Connect
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2.6 (Authentication Error Response) of this document

• Error name: invalid_request_object
• Error usage location: Authorization Endpoint
• Related protocol extension: OpenID Connect
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2.6 (Authentication Error Response) of this document

• Error name: request_not_supported
• Error usage location: Authorization Endpoint
• Related protocol extension: OpenID Connect
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2.6 (Authentication Error Response) of this document

• Error name: request_uri_not_supported
• Error usage location: Authorization Endpoint
• Related protocol extension: OpenID Connect
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2.6 (Authentication Error Response) of this document

• Error name: registration_not_supported
• Error usage location: Authorization Endpoint
• Related protocol extension: OpenID Connect
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 3.1.2.6 (Authentication Error Response) of this document

19.  References

19.1. Normative References

19.2. Informative References

Appendix A.  Authorization Examples

The following are non-normative examples of Authorization Requests with different response_type values and their responses (with line wraps within values for display purposes only):

A.1.  Example using response_type=code

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

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

A.2.  Example using response_type=id_token

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

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogImlz
    cyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4
    Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAi
    bi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEz
    MTEyODA5NzAsCiAibmFtZSI6ICJKYW5lIERvZSIsCiAiZ2l2ZW5fbmFtZSI6
    ICJKYW5lIiwKICJmYW1pbHlfbmFtZSI6ICJEb2UiLAogImdlbmRlciI6ICJm
    ZW1hbGUiLAogImJpcnRoZGF0ZSI6ICIwMDAwLTEwLTMxIiwKICJlbWFpbCI6
    ICJqYW5lZG9lQGV4YW1wbGUuY29tIiwKICJwaWN0dXJlIjogImh0dHA6Ly9l
    eGFtcGxlLmNvbS9qYW5lZG9lL21lLmpwZyIKfQ.rHQjEmBqn9Jre0OLykYNn
    spA10Qql2rvx4FsD00jwlB0Sym4NzpgvPKsDjn_wMkHxcp6CilPcoKrWHcip
    R2iAjzLvDNAReF97zoJqq880ZD1bwY82JDauCXELVR9O6_B0w3K-E7yM2mac
    AAgNCUwtik6SjoSUZRcf-O5lygIyLENx882p6MtmwaL1hd6qn5RZOQ0TLrOY
    u0532g9Exxcm-ChymrB4xLykpDj3lUivJt63eEGGN6DH5K6o33TcxkIjNrCD
    4XB1CKKumZvCedgHHF3IAK4dVEDSUoGlH9z4pP_eWYNXvqQOjGs-rDaQzUHl
    6cQQWNiDpWOl_lxXjQEvQ
    &state=af0ifjsldkj

The value of the id_token parameter is the ID Token, which is a signed JWT, containing three base64url encoded segments separated by period ('.') characters. The first segment represents the JOSE Header. Base64url decoding it will result in the following set of Header Parameters:

  {"kid":"1e9gdk7","alg":"RS256"}

The alg value represents the algorithm that was used to sign the JWT, in this case RS256, representing RSASSA-PKCS-v1_5 using SHA-256. The kid value is a key identifier used in identifying the key to be used to verify the signature. If the kid value is unknown to the RP, it needs to retrieve the contents of the OP's JWK Set again to obtain the OP's current set of keys.

The second segment represents the Claims in the ID Token. Verifying and decoding the ID Token will yield the following Claims:

  {
   "iss": "http://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "gender": "female",
   "birthdate": "0000-10-31",
   "email": "janedoe@example.com",
   "picture": "http://example.com/janedoe/me.jpg"
  }

The third segment represents the ID Token signature, which is verified as described in [JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July 2014.).

A.3.  Example using response_type=id_token token

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

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
    &token_type=Bearer
    &id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogIml
    zcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ
    4Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiA
    ibi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDE
    zMTEyODA5NzAsCiAiYXRfaGFzaCI6ICI3N1FtVVB0alBmeld0RjJBbnBLOVJ
    RIgp9.F9gRev0Dt2tKcrBkHy72cmRqnLdzw9FLCCSebV7mWs7o_sv2O5s6zM
    ky2kmhHTVx9HmdvNnx9GaZ8XMYRFeYk8L5NZ7aYlA5W56nsG1iWOou_-gji0
    ibWIuuf4Owaho3YSoi7EvsTuLFz6tq-dLyz0dKABMDsiCmJ5wqkPUDTE3QTX
    jzbUmOzUDli-gCh5QPuZAq0cNW3pf_2n4zpvTYtbmj12cVcxGIMZby7TMWES
    RjQ9_o3jvhVNcCGcE0KAQXejhA1ocJhNEvQNqMFGlBb6_0RxxKjDZ-Oa329e
    GDidOvvp0h5hoES4a8IuGKS7NOcpp-aFwp0qVMDLI-Xnm-Pg
    &state=af0ifjsldkj

Verifying and decoding the ID Token will yield the following Claims:

  {
   "iss": "http://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "at_hash": "77QmUPtjPfzWtF2AnpK9RQ"
  }

A.4.  Example using response_type=code id_token

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

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
    &id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogIml
    zcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ
    4Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiA
    ibi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDE
    zMTEyODA5NzAsCiAiY19oYXNoIjogIkxEa3RLZG9RYWszUGswY25YeENsdEE
    iCn0.XW6uhdrkBgcGx6zVIrCiROpWURs-4goO1sKA4m9jhJIImiGg5muPUcN
    egx6sSv43c5DSn37sxCRrDZZm4ZPBKKgtYASMcE20SDgvYJdJS0cyuFw7Ijp
    _7WnIjcrl6B5cmoM6ylCvsLMwkoQAxVublMwH10oAxjzD6NEFsu9nipkszWh
    sPePf_rM4eMpkmCbTzume-fzZIi5VjdWGGEmzTg32h3jiex-r5WTHbj-u5HL
    7u_KP3rmbdYNzlzd1xWRYTUs4E8nOTgzAUwvwXkIQhOh5TPcSMBYy6X3E7-_
    gr9Ue6n4ND7hTFhtjYs3cjNKIA08qm5cpVYFMFMG6PkhzLQ
    &state=af0ifjsldkj

Verifying and decoding the ID Token will yield the following Claims:

  {
   "iss": "http://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "c_hash": "LDktKdoQak3Pk0cnXxCltA"
  }

A.5.  Example using response_type=code token

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

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

A.6.  Example using response_type=code id_token token

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

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
    &access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
    &token_type=Bearer
    &id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogIml
    zcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ
    4Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiA
    ibi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDE
    zMTEyODA5NzAsCiAiY19oYXNoIjogIkxEa3RLZG9RYWszUGswY25YeENsdEE
    iCn0.XW6uhdrkBgcGx6zVIrCiROpWURs-4goO1sKA4m9jhJIImiGg5muPUcN
    egx6sSv43c5DSn37sxCRrDZZm4ZPBKKgtYASMcE20SDgvYJdJS0cyuFw7Ijp
    _7WnIjcrl6B5cmoM6ylCvsLMwkoQAxVublMwH10oAxjzD6NEFsu9nipkszWh
    sPePf_rM4eMpkmCbTzume-fzZIi5VjdWGGEmzTg32h3jiex-r5WTHbj-u5HL
    7u_KP3rmbdYNzlzd1xWRYTUs4E8nOTgzAUwvwXkIQhOh5TPcSMBYy6X3E7-_
    gr9Ue6n4ND7hTFhtjYs3cjNKIA08qm5cpVYFMFMG6PkhzLQ
    &state=af0ifjsldkj

Verifying and decoding the ID Token will yield the following Claims:

  {
   "iss": "http://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "at_hash": "77QmUPtjPfzWtF2AnpK9RQ",
   "c_hash": "LDktKdoQak3Pk0cnXxCltA"
  }

A.7.  RSA Key Used in Examples

The following RSA public key, represented in JWK format, can be used to validate the ID Token signatures in the above examples (with line wraps within values for display purposes only):

  {
   "kty":"RSA",
   "kid":"1e9gdk7",
   "n":"w7Zdfmece8iaB0kiTY8pCtiBtzbptJmP28nSWwtdjRu0f2GFpajvWE4VhfJA
        jEsOcwYzay7XGN0b-X84BfC8hmCTOj2b2eHT7NsZegFPKRUQzJ9wW8ipn_aD
        JWMGDuB1XyqT1E7DYqjUCEOD1b4FLpy_xPn6oV_TYOfQ9fZdbE5HGxJUzeku
        GcOKqOQ8M7wfYHhHHLxGpQVgL0apWuP2gDDOdTtpuld4D2LK1MZK99s9gaSj
        RHE8JDb1Z4IGhEcEyzkxswVdPndUWzfvWBBWXWxtSUvQGBRkuy1BHOa4sP6F
        KjWEeeF7gm7UMs2Nm2QUgNZw6xvEDGaLk4KASdIxRQ",
   "e":"AQAB"
  }

Appendix B.  Acknowledgements

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

In addition, the OpenID Community would like to thank the following people for their contributions to this specification:

Naveen Agarwal (naa@google.com), Google

Amanda Anganes (aanganes@mitre.org), MITRE

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

Brian Campbell (bcampbell@pingidentity.com), Ping Identity

Blaine Cook (romeda@gmail.com), Independent

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

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

Vladimir Dzhuvinov (vladimir@nimbusds.com), Nimbus Directory Services

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 C.  Notices

Copyright (c) 2014 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.

Authors' Addresses