OpenID Connect Core 1.0 包含勘誤集 2

摘要

OpenID Connect 1.0 是 OAuth 2.0 協議之上的簡單身份層。它使客戶端能夠根據授權服務器執行的身份驗證來驗證最終用戶的身份，并以可互操作和REST 風格的方式獲取有關最終​​用戶的基本資料信息。

該規范定義了 OpenID Connect 的核心功能：基于 OAuth 2.0 構建的身份驗證以及使用聲明來傳達有關最終用戶的信息。它還描述了使用 OpenID Connect 的安全和隱私注意事項。

目錄

1.  簡介
    1.1.  要求符號和約定
    1.2.  術語
    1.3.  概述
2.   ID 令牌
3.  身份驗證
    3.1.  使用授權碼流程進行身份驗證
        3.1.1.  授權碼流程步驟
        3.1.2.  授權端點
            3.1.2.1.  身份驗證請求
            3.1.2.2.  身份驗證請求驗證
            3.1.2.3.   授權服務器對最終用戶進行身份驗證
            3.1.2.4.  授權服務器獲得最終用戶同意/授權
            3.1.2.5.  成功的身份驗證響應
            3.1.2.6.  身份驗證錯誤響應
            3.1.2.7.  身份驗證響應驗證
        3.1.3.   令牌端點
            3.1.3.1.  令牌請求
            3.1.3.2.  令牌請求驗證
            3.1.3.3.   成功的令牌響應
            3.1.3.4.  令牌錯誤響應
            3.1.3.5.  令牌響應驗證
            3.1.3.6.   ID 令牌
            3.1.3.7.   ID 令牌驗證
            3.1.3.8.  訪問令牌驗證
    3.2.   使用隱式流程進行身份驗證
        3.2.1.  隱式流程步驟
        3.2.2.  授權端點
            3.2.2.1.  身份驗證請求
            3.2.2.2.  身份驗證請求驗證 
            3.2.2.3.  授權服務器對最終用戶進行身份驗證
            3.2.2.4.  授權服務器獲得最終用戶同意/授權
            3.2.2.5.  成功的身份驗證響應
            3.2.2.6.  身份驗證錯誤響應
            3.2.2.7.  重定向 URI 片段處理
            3.2.2.8.  身份驗證響應驗證
            3.2.2.9.   訪問令牌驗證
            3.2.2.10.  ID 令牌
            3.2.2.11.  ID 令牌驗證
    3.3.    使用混合流進行身份驗證
        3.3.1.  混合流步驟
        3.3.2.  授權端點
            3.3.2.1.  身份驗證請求
            3.3.2.2.  身份驗證請求驗證
            3.3.2.3.  授權服務器對最終用戶進行身份驗證
            3.3.2.4.  授權服務器獲得最終用戶同意/授權
            3.3.2.5.  成功的身份驗證響應
            3.3.2.6.  身份驗證錯誤響應
            3.3.2.7.  重定向 URI 片段處理
            3.3.2.8.  身份驗證響應驗證
            3.3.2.9.  訪問令牌驗證
            3.3.2.10.  授權碼驗證
            3.3.2.11.   ID 令牌
            3.3.2.12.  ID 令牌驗證
        3.3.3.  令牌端點
            3.3.3.1.  令牌請求
            3.3.3.2.  令牌請求驗證
            3.3.3.3.   成功的令牌響應
            3.3.3.4.  令牌錯誤響應
            3.3.3.5.  令牌響應驗證
            3.3.3.6.  ID 令牌
            3.3.3.7.  ID 令牌驗證
            3.3.3.8.  訪問令牌
            3.3.3.9.  訪問令牌驗證
4.  啟動第三方登錄
5.  聲明
    5.1.  標準聲明
        5.1.1.  地址聲明
        5.1.2.  附加聲明
    5.2.  權利要求語言和文字
    5.3.  用戶信息端點
        5.3.1.  用戶信息請求
        5.3.2.  成功的 UserInfo 響應
        5.3.3.  用戶信息錯誤響應
        5.3.4.  用戶信息響應驗證
    5.4.  使用范圍值請求聲明
    5.5.  使用“claims”請求參數請求聲明
        5.5.1.  單個聲明請求
            5.5.1.1.  請求“acr”聲明
        5.5.2.  單個聲明的語言和文字
    5.6.  聲明類型
        5.6.1.  普通聲明
        5.6.2.  聚合和分布式聲明
            5.6.2.1.  匯總聲明示例
            5.6.2.2.  分布式聲明的示例
    5.7.  聲明穩定性和唯一性
6.  將請求參數作為 JWT 傳遞
    6.1.  按值傳遞請求對象
        6.1.1.  請求使用“request”請求參數
    6.2.  通過引用傳遞請求對象
        6.2.1. 引用請求對象的 URI
        6.2.2.   使用“request_uri”請求參數進行請求
        6.2.3. 授權服務器獲取請求對象
        6.2.4.   “request_uri” 基本原理
    6.3.  驗證基于 JWT 的請求
        6.3.1.  加密請求對象
        6.3.2.  簽名請求對象
        6.3.3.   請求參數組裝和驗證       
7.  自簽發 OpenID 提供方
    7.1.  自簽發 OpenID 提供方發現
    7.2.  自簽發 OpenID 提供方注冊
        7.2.1.  通過“注冊”請求參數提供信息
    7.3.  自簽發 OpenID 提供方請求
    7.4.  自簽發 OpenID 提供方響應
    7.5.  自頒發的 ID 令牌驗證
8.  主體標識符類型
    8.1.  成對標識符算法
9.  客戶端身份驗證
10.  簽名和加密
    10.1.   簽署
        10.1.1.  非對稱簽名密鑰的輪換
    10.2.  加密
        10.2.1.  非對稱加密密鑰的輪換
11.  離線訪問
12.  使用刷新令牌
    12.1.   刷新請求
    12.2.  成功刷新響應
    12.3.  刷新錯誤響應
13.  序列化
    13.1.  查詢字符串序列化
    13.2.  表單序列化
    13.3.  JSON 序列化
14.  字符串操作
15.  實現注意事項
    15.1. 所有 OpenID 提供方必須實現的功能
    15.2. 動態 OpenID 提供方必須實現的功能
    15.3. 發現和注冊
    15.4.  依賴方必須實現的功能
    15.5. 實現說明
        15.5.1.  授權碼實施說明
        15.5.2.  隨機數實施說明
        15.5.3.  重定向 URI 片段處理實施說明
    15.6.  兼容性說明
    15.7.  相關規范和實施者指南
16.  安全考慮
    16.1.  請求披露
    16.2.  服務器偽裝
    16.3. 令牌制造/修改
    16.4.  訪問令牌披露
    16.5.  服務器響應披露
    16.6.  服務器響應否認
    16.7.  請求否認
    16.8.  訪問令牌重定向
    16.9.  令牌重用
    16.10.    竊聽或泄露授權碼（輔助驗證器捕獲）
    16.11.    令牌替換
    16.12.  定時攻擊
    16.13.  其他與加密相關的攻擊
    16.14.  簽署和加密命令
    16.15.  頒發者標識符
    16.16.  隱式流量威脅
    16.17.   TLS 要求
    16.18.  訪問令牌和刷新令牌的生命周期
    16.19.  對稱密鑰熵
    16.20.  需要簽署請求
    16.21.  需要加密請求
    16.22.   HTTP 307 重定向
    16.23.   iOS上的自定義 URI 方案
17   隱私注意事項
    17.1.  個人身份信息
    17.2.  數據訪問監控
    17.3.  相關性
    17.4.  離線訪問
18.   IANA 注意事項
    18.1.   JSON Web 令牌聲明注冊
        18.1.1.  注冊表內容
    18.2.   OAuth 參數注冊
        18.2.1.  注冊表內容
    18.3.   OAuth 擴展錯誤注冊
        18.3.1.  注冊表內容
    18.4.   URI 方案注冊
        18.4.1.  登記內容
19.  參考文獻
    19.1.  規范性參考文獻
    19.2.  資料性參考文獻
附錄 A.  授權示例
    A.1.  使用response_type=code 的示例
    A.2.  使用response_type=id_token 的示例
    A.3.  使用response_type=id_token 令牌的示例
    A.4.  使用response_type=code id_token 的示例
    A.5.  使用response_type=code 令牌的示例
    A.6.  使用response_type=code id_token 令牌的示例
    A.7.  示例中使用的 RSA 密鑰
附錄 B.  致謝
附錄 C.  通知
§  作者地址

一、簡介

OpenID Connect 1.0 是 OAuth 2.0 [RFC6749]（Hardt, D., Ed.，“OAuth 2.0 授權框架”，2012 年 10 月。）協議 之上的簡單身份層 。它使客戶端能夠根據授權服務器執行的身份驗證來驗證最終用戶的身份，并以可互操作和REST 風格的方式獲取有關最終​​用戶的基本資料信息。

OpenID Connect Core 1.0 規范定義了核心 OpenID Connect 功能：基于 OAuth 2.0 構建的身份驗證以及使用聲明來傳達有關最終用戶的信息。它還描述了使用 OpenID Connect 的安全和隱私注意事項。

作為背景，OAuth 2.0 授權框架（Hardt, D., Ed.，“OAuth 2.0 授權框架”，2012 年 10 月。）[RFC6749] 和OAuth 2.0 承載令牌使用（Jones, M. 和 D. Hardt，“OAuth 2.0 授權框架：不記名令牌的使用”，2012 年 10 月。）[RFC6750] 規范為第三方應用程序獲取和使用對 HTTP 資源的有限訪問提供了通用框架。他們定義了獲取和使用訪問令牌來訪問資源的機制，但沒有定義提供身份信息的標準方法。值得注意的是，如果不分析 OAuth 2.0，它就無法提供有關最終用戶身份驗證的信息。讀者應該熟悉這些規范。

OpenID Connect 將身份驗證作為 OAuth 2.0 授權流程的擴展來實現。客戶端通過在授權請求中包含openid范圍值來請求使用此擴展。有關所執行身份驗證的信息以JSON Web 令牌 (JWT)（Jones, M.、Bradley, J. 和 N. Sakimura，“JSON Web 令牌 (JWT)”，2015 年 5 月。） [JWT]形式返回，稱為 ID 令牌（請參閱第 2 節（身份令牌））。實現 OpenID Connect 的 OAuth 2.0 身份驗證服務器也稱為 OpenID 提供方 (OP)。使用 OpenID Connect 的 OAuth 2.0 客戶端也稱為依賴方 (RP)。

本規范假設依賴方已獲得有關 OpenID 提供方的配置信息，包括其授權端點和令牌端點位置。此信息通常通過 Discovery 獲取，如OpenID Connect Discovery 1.0（Sakimura, N.、Bradley, J.、Jones, M. 和 E. Jay，“OpenID Connect Discovery 1.0”，2023 年 12 月。） [OpenID.Discovery] 中所述，或者可以通過其他機制獲取。

同樣，本規范假設依賴方已獲得足夠的憑據并提供了使用 OpenID 提供方所需的信息。這通常通過動態注冊完成，如 OpenID Connect 動態客戶端注冊 1.0（Sakimura, N.、Bradley, J. 和 M. Jones，“OpenID Connect 動態客戶端注冊 1.0”，2023 年 12 月。） [OpenID.Registration] 中所述，或者可以通過其他機制獲得。

該規范的先前版本是：

• OpenID Connect Core 1.0 包含勘誤集 1（Sakimura, N.、Bradley, J.、Jones, M.、de Medeiros, B. 和 C. Mortimore，“OpenID Connect Core 1.0 包含勘誤集 1”，2014 年 11 月。） [OpenID.Core.Errata1]
• OpenID Connect Core 1.0（最終版）（Sakimura, N.、Bradley, J.、Jones, M.、de Medeiros, B. 和 C. Mortimore，“OpenID Connect Core 1.0（最終版）”，2014 年 2 月。） [OpenID.Core.Final]

1.1.需求符號和約定

關鍵詞“必須”、“不得”、“必需”、“應”、“不應”、“應該”、“不應該”、“推薦”、“不推薦”、“可以”和“可選”本文檔中的“應按照RFC 2119（Bradner, S.，“RFC 中用于指示需求級別的關鍵詞”，1997 年 3 月。） [RFC2119] 中的描述進行解釋。

在本規范的 .txt 版本中，引用值表明它們應按字面意思理解。在協議消息中使用這些值時，不得將引號用作值的一部分。在本規范的 HTML 版本中，按字面意思取值是通過使用這種固定寬度字體來指示的。

本規范中JSON Web 簽名 (JWS)（Jones, M.、Bradley, J. 和 N. Sakimura，“JSON Web 簽名 (JWS)”，2015 年 5 月。） [JWS] 和JSON Web 加密 (JWE)（Jones, M. 和 J. Hildebrand，“JSON Web 加密 (JWE)”，2015 年 5 月。） [JWE] 數據結構 的所有使用均利用 JWS 緊湊序列化或 JWE 緊湊序列化；不使用 JWS JSON 序列化和 JWE JSON 序列化。

1.2.術語

本規范使用術語“訪問令牌”、“授權碼”、“授權端點”、“授權許可”、“授權服務器”、“客戶端”、“客戶端身份驗證”、“客戶端標識符”、“客戶端密鑰”、“ OAuth 2.0（Hardt, D., Ed.，“OAuth 2.0 授權框架”，2012 年 10 月。） [RFC6749]定義的“授權許可類型”、“受保護資源”、“重定向 URI”、“刷新令牌”、“資源服務器”、“響應類型”和“令牌端點”，術語“聲明名稱”、“聲明值”、“JSON Web 令牌 (JWT)”、“JWT 聲明集”和由JSON Web 令牌 (JWT)（Jones, M.、Bradley, J. 和 N. Sakimura，“JSON Web 令牌 (JWT)”，2015 年 5 月。） [JWT] 定義的“嵌套 JWT”，術語“Base64url 編碼”、“標頭參數”和“ JSON Web 簽名 (JWS)（Jones, M.、Bradley, J. 和 N. Sakimura，“JSON Web 簽名 (JWS)”，2015 年 5 月。） [JWS]定義的“JOSE 標頭” 、 RFC 7230（Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing,” June 2014.) [RFC7230]定義的術語“用戶代理”以及OAuth 2.0 多重響應類型編碼實踐 (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 授權請求使用 OpenID Connect 定義的擴展參數和范圍來請求授權服務器（OpenID Connect 提供方）向客戶端（OpenID Connect 依賴方）對最終用戶進行身份驗證。

認證上下文

依賴方在針對身份驗證響應做出權利決定之前可以要求的信息。此類上下文可以包括但不限于所使用的實際身份驗證方法或保證級別，例如 ISO/IEC 29115 (International Organization for Standardization, “ISO/IEC 29115:2013. Information technology - Security techniques - Entity authentication assurance framework,” April 2013.) [ISO29115] 實體身份驗證保證級別。

認證上下文類

在特定上下文中被認為彼此等效的一組身份驗證方法或過程。

身份驗證上下文類參考

身份驗證上下文類的標識符。

授權碼流程

OAuth 2.0 流程，其中從授權端點返回授權碼，并且從令牌端點返回所有令牌。

授權請求

[RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) 定義的 OAuth 2.0 授權請求。

宣稱

斷言有關實體的信息。

聲明類型

用于表示聲明值的語法。該規范定義了普通、聚合和分布式聲明類型。

理賠提供方

可以返回有關實體的聲明的服務器。

憑據

作為使用身份或其他資源的權利證據提供的數據。

最終用戶

人類參與者。

實體

具有獨立且獨特的存在并且可以在上下文中識別的東西。最終用戶是實體的一個示例。

基本聲明

客戶指定的聲明是確保最終用戶請求的特定任務順利授權體驗所必需。

混合流

OAuth 2.0 流程，其中從授權端點返回授權碼，從授權端點返回一些令牌，從令牌端點返回其他令牌。

身份令牌

JSON Web 令牌 (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.) [JWT]，包含有關身份驗證事件的聲明。它可能包含其他聲明。

標識符

在特定上下文中唯一表征實體的值。

身份

與實體相關的屬性集。

隱式流程

OAuth 2.0 流程，其中所有令牌均從授權端點返回，并且既不使用令牌端點也不使用授權碼。

頒發者

發出一組聲明的實體。

頒發者標識符

頒發者的可驗證標識符。頒發者標識符是使用https方案的區分大小寫的 URL，其中包含方案、主機以及可選的端口號和路徑組件，但不包含查詢或片段組件。

信息

OpenID 依賴方和 OpenID 提供方之間的請求或響應。

OpenID 提供方 (OP)

OAuth 2.0 授權服務器能夠對最終用戶進行身份驗證并向依賴方提供有關身份驗證事件和最終用戶的聲明。

請求對象

JWT 包含一組請求參數作為其聲明。

請求URI

引用包含請求對象的資源的 URL。請求 URI 內容必須可由授權服務器檢索。

成對假名標識符 (PPID)

向依賴方標識實體的標識符，該標識符無法與另一個依賴方的實體的 PPID 相關聯。

個人身份信息 (PII)

(a) 可用于識別與該信息相關的自然人的信息，或者 (b) 是或可能與與該信息相關的自然人直接或間接相關的信息。

依賴方 (RP)

OAuth 2.0 客戶端應用程序需要來自 OpenID 提供方的最終用戶身份驗證和聲明。

扇區標識符

依賴方組織使用的 URL 的主機組件，是該依賴方成對主題標識符計算的輸入。

自簽發 OpenID 提供方

頒發自簽發的 ID 令牌的個人自托管 OpenID 提供方。

主題標識符

最終用戶的頒發者內部本地唯一且從未重新分配的標識符，旨在由客戶端使用。

用戶信息端點

受保護的資源，當客戶端提供訪問令牌時，返回有關由相應授權許可代表的最終用戶的授權信息。 UserInfo 端點 URL 必須使用https方案，并且可以包含端口、路徑和查詢參數組件。

驗證

旨在確定結構的健全性或正確性的過程。

確認

旨在測試或證明事實或值的真實性或準確性的過程。

自愿聲明

客戶指定的聲明對最終用戶請求的特定任務有用但不是必需。

讀者重要提示：本節中的術語定義是本規范的規范部分，對實現提出了要求。本規范文本中的所有大寫單詞（例如“頒發者標識符”）均引用這些定義的術語。每當讀者遇到它們時，都必須遵循本節中的定義。

有關某些術語的更多背景信息，請參閱《互聯網安全術語表》第 2 版 (Shirey, R., “Internet Security Glossary, Version 2,” August 2007.)[RFC4949]、 ISO/IEC 29115 實體身份驗證保證 (International Organization for Standardization, “ISO/IEC 29115:2013. Information technology - Security techniques - Entity authentication assurance framework,” April 2013.)[ISO29115] 和ITU-T X.1252 (International Telecommunication Union, “ITU-T Recommendation X.1252 - Cyberspace security - Identity management - Baseline identity management terms and definitions,” April 2010.) [X.1252]。

1.3.概述

OpenID Connect 協議抽象地遵循以下步驟。

1. RP（客戶端）向 OpenID 提供方（OP）發送請求。
2. OP 對最終用戶進行身份驗證并獲得授權。
3. OP 使用 ID 令牌（通常是訪問令牌）進行響應。
4. RP 可以將帶有訪問令牌的請求發送到 UserInfo 端點。
5. UserInfo 端點返回有關最終用戶的聲明。

這些步驟如下圖所示：

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

2. ID令牌

OpenID Connect 對 OAuth 2.0 進行的主要擴展是 ID 令牌數據結構，以使最終用戶能夠進行身份驗證。 ID 令牌是一種安全令牌，包含有關使用客戶端時授權服務器對最終用戶進行身份驗證的聲明，以及可能的其他請求的聲明。 ID 令牌表示為 JSON Web 令牌 (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.) [JWT]。

以下聲明在 OpenID Connect 使用的所有 OAuth 2.0 流的 ID 令牌中使用：

國際空間站

必需。響應的頒發者的頒發者標識符。 iss值是一個區分大小寫的 URL，使用https方案，其中包含方案、主機以及可選的端口號和路徑組件，但不包含查詢或片段組件。

子

必需。主題標識符。最終用戶的頒發者內本地唯一且永不重新分配的標識符，旨在由客戶端使用，例如24400320 或AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4。它的長度不得超過 255 個 ASCII [RFC20]字符。 (Cerf, V., “ASCII format for Network Interchange,” October 1969.)sub值是區分大小寫的字符串。

音頻

必需。此 ID 令牌的目標受眾。它必須包含 依賴方的OAuth 2.0 client_id作為受眾值。它還可以包含其他受眾的標識符。一般情況下，aud值是一個區分大小寫的字符串數組。在有一個觀眾的常見特殊情況下，aud值可以是單個區分大小寫的字符串。

經驗值

必需。到期時間，在該時間或之后，在與 OP 執行身份驗證時，RP 不得接受 ID 令牌。處理此參數要求當前日期/時間必須早于值中列出的到期日期/時間。實施者可以提供一些小的余地，通常不超過幾分鐘，以解決時鐘偏差。它的值是一個 JSON [RFC8259] (Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format,” December 2017.)數字，表示從 1970-01-01T00:00:00Z（以 UTC 測量）到日期/時間的秒數。有關一般日期/時間（特別是 UTC）的詳細信息，請參閱RFC 3339 (Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) [RFC3339]。注意：ID 令牌過期時間與 RP 和 OP 之間經過身份驗證的會話的生命周期無關。

我在

必需。 JWT 的發布時間。它的值是一個 JSON 數字，表示從 1970-01-01T00:00:00Z（以 UTC 測量）到該日期/時間的秒數。

驗證時間

最終用戶身份驗證發生的時間。它的值是一個 JSON 數字，表示從 1970-01-01T00:00:00Z（以 UTC 測量）到該日期/時間的秒數。當發出max_age請求或請求auth_time作為基本聲明時，則此聲明是必需的；否則，其包含是可選的。 （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響應參數。）

隨機數

用于將客戶端會話與 ID 令牌相關聯并減輕重放攻擊的字符串值。該值未經修改地從身份驗證請求傳遞到 ID 令牌。如果 ID 令牌中存在，則客戶端必須驗證隨機數聲明值是否等于 身份驗證請求中發送的隨機數參數的值。如果出現在身份驗證請求中，授權服務器必須在 ID 令牌中包含一個隨機數聲明，該聲明值是身份驗證請求中發送的隨機數值。授權服務器不應該對使用的隨機數值執行其他處理。nonce值是區分大小寫的字符串。

丙烯酰胺

可選。身份驗證上下文類參考。指定身份驗證上下文類參考值的字符串，該值標識執行的身份驗證所滿足的身份驗證上下文類。值“0”表示最終用戶身份驗證不符合 ISO/IEC 29115 (International Organization for Standardization, “ISO/IEC 29115:2013. Information technology - Security techniques - Entity authentication assurance framework,” April 2013.) [ISO29115] 1 級的要求。由于歷史原因，值“0”用于表示不確信同一個人是同一個人。實際上在那里。級別 0 的身份驗證不應用于授權對任何貨幣價值的任何資源的訪問。 （這對應于 OpenID 2.0 PAPE (Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider Authentication Policy Extension 1.0,” December 2008.) [OpenID.PAPE] nist_auth_level 0.）絕對 URI 或RFC 6711 (Johansson, L., “An IANA Registry for Level of Assurance (LoA) Profiles,” August 2012.) [RFC6711] 注冊名稱應該用作acr值；注冊名稱不得以與注冊名稱不同的含義使用。使用此聲明的各方需要就所使用的值的含義達成一致，這可能是特定于上下文的。acr值是區分大小寫的字符串。

阿姆魯

可選。身份驗證方法參考。 JSON 字符串數組，是身份驗證中使用的身份驗證方法的標識符。例如，值可能表明同時使用了密碼和 OTP 身份驗證方法。amr值是區分大小寫的字符串數組。amr聲明中使用的值 應來自在[RFC8176] 建立的IANA 身份驗證方法參考值注冊表[IANA.AMR] (IANA, “Authentication Method Reference Values,” .)中注冊的值；使用此聲明的各方需要就所使用的任何未注冊值的含義達成一致，這可能是特定于上下文的。 (Jones, M., Hunt, P., and A. Nadalin, “Authentication Method Reference Values,” June 2017.)

氮雜蛋白

可選。授權方 - ID 令牌的頒發方。如果存在，它必須包含該方的 OAuth 2.0 客戶端 ID。azp值是包含 StringOrURI 值的區分大小寫的字符串。請注意，實際上，azp聲明僅在使用超出本規范范圍的擴展時出現；因此，鼓勵不使用此類擴展的實現不要使用azp ，并在它發生時忽略它。

ID 令牌可能包含其他聲明。任何不被理解的聲明都必須被忽略。 有關本規范定義的附加聲明， 請 參閱 第 3.1.3.6、3.3.2.11、5.1和 (ID Token)7.4 節 (ID Token)。 (Standard Claims) (Self-Issued OpenID Provider Response)

ID 令牌必須使用JWS [JWS] 進行簽名，并且可選地分別使用 (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.)JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS] 和JWE (Jones, M. and J. Hildebrand, “JSON Web Encryption (JWE),” May 2015.) [JWE]進行簽名和加密，從而根據第 16.14 節 (Signing and Encryption Order)提供身份驗證、完整性、不可否認性和可選的機密性。如果 ID 令牌已加密，則必須對其進行簽名然后加密，結果是嵌套 JWT，如[JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.)中所定義。 ID 令牌不得使用none 作為alg值，除非使用的響應類型未從授權端點返回任何 ID 令牌（例如使用授權碼流程時）并且客戶端在注冊時 明確請求使用 none 。

ID 令牌不應使用 JWS 或 JWE x5u、 x5c、 jku或 jwk 標頭參數字段。相反，根據第 10 節 (Signatures and Encryption)，使用發現和注冊參數提前傳達對所使用密鑰的引用。

以下是 ID 令牌中的聲明集（JWT 聲明集）的非規范示例：

  {
   "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. 認證

OpenID Connect 執行身份驗證以登錄最終用戶或確定最終用戶已登錄。OpenID Connect 將服務器執行的身份驗證結果以安全的方式返回給客戶端，以便客戶端可以信賴它。因此，在這種情況下，客戶端稱為依賴方 (RP)。

身份驗證結果以 ID 令牌形式返回，如第 2 節 (ID Token)中所定義。它有聲明，表達諸如頒發者、主題標識符、執行身份驗證的時間等信息。

身份驗證可以遵循以下三種路徑之一：授權碼流程 ( response_type=code )、隱式流（response_type=id_token token 或response_type=id_token）或混合流（使用 OAuth 2.0 多重響應類型編碼中定義的其他響應類型值）實踐 (de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.)[OAuth.Responses]）。這些流程確定如何將 ID 令牌和訪問令牌返回給客戶端。

下面的非規范表總結了這三種流程的特征。該表旨在提供一些關于在特定情況下選擇哪種流程的指導。

使用的流程由授權請求中包含的response_type值 確定。這些response_type值選擇這些流：

除OAuth 2.0 [RFC6749]定義的代碼響應類型值 外，所有其他值均在OAuth 2.0 多重響應類型編碼實踐[OAuth.Responses] 規范中定義 。注意：雖然 OAuth 2.0 還定義了 隱式流的令牌響應類型值，但 OpenID Connect 不使用此響應類型，因為不會返回 ID 令牌。 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) (de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.)

3.1.使用授權碼流程進行身份驗證

本節介紹如何使用授權碼流程執行身份驗證。使用授權碼流程時，所有令牌均從令牌端點返回。

授權碼流程將授權碼返回給客戶端，然后客戶端可以直接將其交換為 ID 令牌和訪問令牌。這樣做的好處是不會向用戶代理以及可能訪問用戶代理的其他惡意應用程序暴露任何令牌。授權服務器還可以在將授權碼交換為訪問令牌之前對客戶端進行身份驗證。授權碼流程適用于可以在自己和授權服務器之間安全維護客戶端密鑰的客戶端。

3.1.1.授權碼流程步驟

授權碼流程經歷以下步驟。

1. 客戶端準備包含所需請求參數的身份驗證請求。
2. 客戶端將請求發送到授權服務器。
3. 授權服務器對最終用戶進行身份驗證。
4. 授權服務器獲得最終用戶同意/授權。
5. 授權服務器將最終用戶連同授權碼發送回客戶端。
6. 客戶端使用令牌端點處的授權碼請求響應。
7. 客戶端收到響應正文中包含 ID 令牌和訪問令牌的響應。
8. 客戶端驗證 ID 令牌并檢索最終用戶的主題標識符。

3.1.2.授權端點

授權端點執行最終用戶的身份驗證。這是通過使用 OAuth 2.0 定義的請求參數以及 OpenID Connect 定義的附加參數和參數值將用戶代理發送到授權服務器的授權端點進行身份驗證和授權來完成的。

與授權端點的通信必須使用 TLS。有關使用 TLS 的更多信息， 請參閱第 16.17 節。 (TLS Requirements)

3.1.2.1.認證請求

身份驗證請求是 OAuth 2.0 授權請求，請求授權服務器對最終用戶進行身份驗證。

授權服務器必須支持在授權端點使用RFC 7231 [RFC7231]中定義的HTTP GET和 POST方法。客戶端可以使用 HTTP GET或 POST方法將授權請求發送到授權服務器。如果使用 HTTP GET方法，則根據第 13.1 節，使用 URI 查詢字符串序列化來序列化請求參數。如果使用 HTTP POST方法，則根據第 13.2 節 ，使用表單序列化來序列化請求參數。 (Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content,” June 2014.) (Query String Serialization) (Form Serialization)

OpenID Connect 將以下 OAuth 2.0 請求參數與授權碼流程結合使用：

范圍

必需。 OpenID Connect 請求必須包含openid范圍值。如果openid范圍值不存在，則行為完全未指定。可能存在其他范圍值。實現不能理解的范圍值應該被忽略。 有關本規范定義的其他范圍值， 請參閱第 5.4 (Requesting Claims using Scope Values)節 和第 11節。 (Offline Access)

響應類型

必需。 OAuth 2.0 響應類型值，確定要使用的授權處理流程，包括從使用的端點返回哪些參數。使用授權碼流程時，該值為 code。

客戶ID

必需。 OAuth 2.0 客戶端標識符在授權服務器上有效。

重定向URI

必需。響應將發送到的重定向 URI。該 URI 必須與在 OpenID 提供方處預先注冊的客戶端的重定向 URI 值之一完全匹配，并按照[RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.)（簡單字符串比較）第 6.2.1 節中所述執行匹配。使用此流程時，重定向 URI 應使用https方案；但是，它可以使用http方案，前提是客戶端類型是 機密的（如 OAuth 2.0 第 2.1 節中定義），并且 OP 允許在這種情況下使用 http重定向 URI。另外，如果客戶端是本機應用程序，它可以使用帶有 localhost的http方案或 IP 環回文字 127.0.0.1或[::1] 作為主機名。重定向 URI 可以使用替代方案，例如旨在識別對本機應用程序的回調的方案。

狀態

推薦。用于維護請求和回調之間的狀態的不透明值。通常，跨站點請求偽造（CSRF、XSRF）緩解是通過以加密方式將此參數的值與瀏覽器 cookie 綁定來完成的。

OpenID Connect 還使用以下 OAuth 2.0 請求參數，該參數在 OAuth 2.0 多重響應類型編碼實踐 (de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.)[OAuth.Responses] 中定義：

響應模式

可選。通知授權服務器用于從授權端點返回參數的機制。當請求的響應模式是為響應類型指定的默認模式時，不建議使用此參數。

該規范還定義了以下請求參數：

隨機數

可選。用于將客戶端會話與 ID 令牌相關聯并減輕重放攻擊的字符串值。該值未經修改地從身份驗證請求傳遞到 ID 令牌。用于防止攻擊者猜測值的隨機數值中必須存在足夠的熵 。有關實施說明，請參閱第 15.5.2 節 (Nonce Implementation Notes)。

展示

可選。指定授權服務器如何向最終用戶顯示身份驗證和同意用戶界面頁面的 ASCII 字符串值。定義的值為：

頁

授權服務器應該顯示與完整用戶代理頁面視圖一致的身份驗證和同意 UI。如果不指定顯示參數，則這是默認的顯示模式。

彈出窗口

授權服務器應該顯示與彈出的用戶代理窗口一致的身份驗證和同意 UI。彈出的用戶代理窗口的大小應適合以登錄為中心的對話框，并且不應遮蓋其彈出的整個窗口。

觸碰

授權服務器應該顯示與利用觸摸界面的設備一致的身份驗證和同意 UI。

無線應用程序

授權服務器應該顯示與“功能手機”類型顯示一致的身份驗證和同意 UI。

授權服務器還可以嘗試檢測用戶代理的功能并提供適當的顯示。

如果OP接收到一個它不理解的超出上面定義的顯示值，它可以返回一個錯誤或者可以忽略它；實際上，不返回不理解的值的錯誤將有助于促進使用新 顯示值的分階段擴展。

迅速的

可選。以空格分隔、區分大小寫的 ASCII 字符串值列表，指定授權服務器是否提示最終用戶重新進行身份驗證并同意。定義的值為：

沒有任何

授權服務器不得顯示任何身份驗證或同意用戶界面頁面。如果最終用戶尚未經過身份驗證，或者客戶沒有對所請求的聲明預先配置同意，或者不滿足處理請求的其他條件，則會返回錯誤。錯誤代碼通常是 login_required、 interaction_required或第3.1.2.6節 (Authentication Error Response)中定義的其他代碼。這可以用作檢查現有身份驗證和/或同意的方法。

登錄

授權服務器應該提示最終用戶重新進行身份驗證。如果它無法重新驗證最終用戶，它必須返回一個錯誤，通常是login_required。

同意

授權服務器應在將信息返回給客戶端之前提示最終用戶同意。如果它無法獲得同意，它必須返回一個錯誤，通常是consent_required。

選擇帳戶

授權服務器應提示最終用戶選擇用戶帳戶。這使得在授權服務器上擁有多個帳戶的最終用戶能夠在他們可能擁有當前會話的多個帳戶中進行選擇。如果它無法獲取最終用戶做出的帳戶選擇選擇，它必須返回錯誤，通常是account_selection_required。

客戶端可以使用prompt 參數來確保最終用戶仍在當前會話中或引起對請求的注意。如果此參數包含none 或任何其他值，則返回錯誤。

如果 OP 收到上面定義的集合之外的它不理解的提示值，它可以返回錯誤或可以忽略它；在實踐中，不返回不理解的值的錯誤將有助于促進使用新 提示值的分階段擴展。

最大年齡

可選。最大身份驗證年齡。指定自上次 OP 主動驗證最終用戶以來允許的經過時間（以秒為單位）。如果經過的時間大于此值，OP 必須嘗試主動重新驗證最終用戶。 （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 令牌必須包含auth_time聲明值。請注意，max_age=0相當于Prompt=login。

用戶界面區域設置

可選。最終用戶的用戶界面首選語言和腳本，表示為以空格分隔的 BCP47 (Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.) [RFC5646] 語言標簽值列表，按首選項排序。例如，值“fr-CA fr en”表示優先選擇在加拿大使用的法語，然后是法語（沒有地區指定），最后是英語（沒有地區指定）。如果 OpenID 提供方不支持部分或全部請求的語言環境，則不應產生錯誤。

id_token_hint

可選。授權服務器先前頒發的 ID 令牌作為有關最終用戶當前或過去與客戶端進行身份驗證的會話的提示進行傳遞。如果 ID 令牌標識的最終用戶已經登錄或作為請求的結果登錄（OP 可能在此決策中評估 ID 令牌之外的其他信息），則授權服務器返回肯定響應；否則，它必須返回錯誤，例如login_required。如果可能的話，當使用prompt=none 時，應該存在id_token_hint ，如果不存在，可能會返回invalid_request錯誤；然而，服務器應該盡可能成功響應，即使它不存在。當授權服務器用作 id_token_hint值時，無需將其列為 ID 令牌的受眾。

如果 RP 從 OP 接收到的 ID 令牌是加密的，要將其用作 id_token_hint ，客戶端必須解密加密的 ID 令牌中包含的簽名 ID 令牌。客戶端可以使用密鑰重新加密發送給身份驗證服務器的簽名 ID 令牌，該密鑰使服務器能夠解密 ID 令牌并使用重新加密的 ID 令牌作為 id_token_hint值。

登錄提示

可選。向授權服務器提示最終用戶可能用于登錄的登錄標識符（如有必要）。如果 RP 首先向最終用戶詢問其電子郵件地址（或其他標識符），然后希望將該值作為提示傳遞給發現的授權服務，則可以使用此提示。建議提示值與用于發現的值匹配。該值也可以是為phone_number聲明指定的格式的電話號碼 。該參數的使用由 OP 自行決定。

acr_值

可選。請求的身份驗證上下文類參考值。以空格分隔的字符串，指定 請求授權服務器用于處理此身份驗證請求的acr值，這些值按優先順序顯示。所執行的身份驗證所滿足的身份驗證上下文類作為acr聲明值返回，如第 2 節 (ID Token)中所指定。 acr Claim 是通過此參數作為自愿聲明請求的。

可以發送其他參數。 有關本規范定義的其他授權請求參數和參數值， 請參閱第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)節。

以下是客戶端的非規范示例 HTTP 302 重定向響應，它觸發用戶代理向授權端點發出身份驗證請求（值內換行僅用于顯示目的）：

  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

以下是非規范示例請求，該請求將由用戶代理發送到授權服務器，以響應上述客戶端的 HTTP 302 重定向響應（值內換行僅用于顯示目的）：

  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. 身份驗證請求驗證

授權服務器必須驗證收到的請求，如下所示：

1. 授權服務器必須根據 OAuth 2.0 規范驗證所有 OAuth 2.0 參數。
2. 驗證范圍參數是否存在并且包含openid范圍值。 （如果不存在openid范圍值，則該請求可能仍然是有效的 OAuth 2.0 請求，但不是 OpenID Connect 請求。）
3. 授權服務器必須驗證所有必需的參數都存在并且它們的使用符合本規范。
4. 如果使用 ID 令牌的特定值請求子（主題）聲明，則僅當該子值標識的最終用戶與授權服務器有活動會話或已被身份驗證時，授權服務器才必須發送肯定響應請求的結果。授權服務器不得回復其他用戶的 ID 令牌或訪問令牌，即使他們與授權服務器有活動會話。如果實現支持 聲明參數，則可以使用id_token_hint參數或通過請求第 5.5.1 節 (Individual Claims Requests)中所述的特定聲明值來發出此類請求 。
5. 當id_token_hint存在時，OP 必須驗證它是 ID 令牌的頒發者。當 ID 令牌標識的 RP 在 OP 上有當前會話或最近的會話時，OP 應該接受 ID 令牌，即使exp時間已經過去。

正如OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] 中所指定的，授權服務器應該忽略無法識別的請求參數。

如果授權服務器遇到任何錯誤，它必須根據第 3.1.2.6 節 (Authentication Error Response)返回錯誤響應。

3.1.2.3.授權服務器對最終用戶進行身份驗證

如果請求有效，授權服務器將嘗試對最終用戶進行身份驗證或確定最終用戶是否已通過身份驗證，具體取決于所使用的請求參數值。授權服務器用于驗證最終用戶的方法（例如，用戶名和密碼、會話cookie 等）超出了本規范的范圍。授權服務器可以顯示身份驗證用戶界面，具體取決于所使用的請求參數值和所使用的身份驗證方法。

在以下情況下，授權服務器必須嘗試對最終用戶進行身份驗證：

• 最終用戶尚未經過身份驗證。
• 身份驗證請求包含值為 login 的提示參數。在這種情況下，即使最終用戶已經經過身份驗證，授權服務器也必須重新對最終用戶進行身份驗證。

在以下情況下，授權服務器不得與最終用戶交互：

• 身份驗證請求包含值為 none 的提示參數。在這種情況下，如果最終用戶尚未經過身份驗證或無法靜默進行身份驗證，則授權服務器必須返回錯誤。

與最終用戶交互時，授權服務器必須采用適當的措施來防止跨站點請求偽造和點擊劫持，如OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] 的第 10.12 和 10.13 節中所述。

3.1.2.4.授權服務器獲取最終用戶同意/授權

一旦最終用戶通過身份驗證，授權服務器必須在向依賴方發布信息之前獲得授權決定。當所使用的請求參數允許時，這可以通過與最終用戶的互動對話來完成，明確同意什么，或者通過處理請求的條件或其他方式（例如，通過先前的管理）建立同意。同意）。第2 (ID Token)節和 第5.3 (UserInfo Endpoint)節描述了信息發布機制。

3.1.2.5.認證成功響應

身份驗證響應是從 OP 的授權端點返回的 OAuth 2.0 授權響應消息，以響應 RP 發送的授權請求消息。

當使用授權碼流程時，授權響應必須返回OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] 第 4.1.2 節中定義的參數，方法是 將它們作為查詢參數添加到 使用application/x-www-form- 的授權請求中指定的redirect_uri urlencoded格式，除非指定了不同的響應模式。

以下是使用此流程的成功響應的非規范示例（僅出于顯示目的在值內換行）：

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

有關授權碼內容的實施說明，請參閱第 15.5.1 節 (Authorization Code Implementation Notes)。

3.1.2.6.身份驗證錯誤響應

身份驗證錯誤響應是從 OP 的授權端點返回的 OAuth 2.0 授權錯誤響應消息，以響應 RP 發送的授權請求消息。

如果最終用戶拒絕請求或最終用戶身份驗證失敗，OP（授權服務器）將使用OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] 第 4.1.2.1 節中定義的錯誤響應參數通知 RP（客戶端）。 （與 RFC 6749 無關的 HTTP 錯誤將使用適當的 HTTP 狀態代碼返回給用戶代理。）

除非重定向 URI 無效，否則授權服務器將客戶端返回到授權請求中指定的重定向 URI，并帶有適當的錯誤和狀態參數。其他參數不應返回。如果重定向 URI 無效，授權服務器不得將用戶代理重定向到無效的重定向 URI。

如果不支持響應模式值，則授權服務器將返回 HTTP 響應代碼 400（錯誤請求），且不帶錯誤響應參數，因為需要了解響應模式才能知道如何返回這些參數。

除了OAuth 2.0第4.1.2.1節中定義的錯誤代碼之外，本規范還定義了以下錯誤代碼：

需要交互

授權服務器需要某種形式的最終用戶交互才能繼續。當身份驗證請求中的提示參數值為none時，可能會返回此錯誤 ，但如果不顯示最終用戶交互的用戶界面，則無法完成身份驗證請求。

要求登錄

授權服務器需要最終用戶身份驗證。當身份驗證請求中的提示參數值為none時，可能會返回此錯誤 ，但如果不顯示最終用戶身份驗證的用戶界面，則無法完成身份驗證請求。

account_selection_required

最終用戶需要在授權服務器上選擇一個會話。最終用戶可以在授權服務器上使用不同的關聯帳戶進行身份驗證，但最終用戶未選擇會話。當身份驗證請求中的提示參數值為none時，可能會返回此錯誤，但如果不顯示用戶界面來提示要使用的會話，則無法完成身份驗證請求。

需要同意

授權服務器需要最終用戶同意。當身份驗證請求中的提示參數值為none時，可能會返回此錯誤 ，但如果不顯示最終用戶同意的用戶界面，則無法完成身份驗證請求。

無效的請求URI

授權請求中的request_uri 返回 錯誤或包含無效數據。

無效請求對象

請求 參數 包含無效的請求對象。

請求不支持

OP 不支持使用 第 6 節中定義的請求參數。 (Passing Request Parameters as JWTs)

request_uri_not_supported

OP 不支持使用 第 6 節中定義的request_uri參數。 (Passing Request Parameters as JWTs)

不支持注冊

OP 不支持使用 第 7.2.1 節中定義的注冊參數。 (Providing Information with the "registration" Request Parameter)

錯誤響應參數如下：

錯誤

必需。錯誤代碼。

錯誤描述

可選。人類可讀的 ASCII 編碼文本描述錯誤。

錯誤_uri

可選。包含有關錯誤的附加信息的網頁的 URI。

狀態

OAuth 2.0 狀態值。如果授權請求包含狀態參數，則為必需。設置為從客戶端收到的值。

使用授權碼流程時，錯誤響應參數將添加到重定向 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.認證響應驗證

使用授權碼流程時，客戶端必須根據 RFC 6749 驗證響應，尤其是第 4.1.2 節和第 10.12 節。

3.1.3.令牌端點

為了獲取訪問令牌、ID 令牌和可選的刷新令牌，RP（客戶端）在 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.)使用授權碼流程。

與令牌端點的通信必須使用 TLS。有關使用 TLS 的更多信息， 請參閱第 16.17 節。 (TLS Requirements)

3.1.3.1.令牌請求

客戶端通過使用grant_type值 authorization_code 向令牌端點提供其授權許可（以授權碼的形式）來發出令牌請求，如OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] 的第 4.1.3 節中所述。如果客戶端是機密客戶端，則它必須使用為其client_id注冊的身份驗證方法向令牌端點進行身份驗證，如第 9 節 (Client Authentication)中所述。

客戶端根據第 13.2 節，使用 HTTP POST方法和表單序列化 將參數發送到令牌端點，如 OAuth 2.0 [RFC6749] 的第 4.1.3 節中所述。 (Form Serialization) (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.)

以下是令牌請求的非規范示例（值內換行僅用于顯示目的）：

  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.令牌請求驗證

授權服務器必須按如下方式驗證令牌請求：

• 如果已向客戶端頒發客戶端憑證或使用其他客戶端身份驗證方法，請根據第 9 節 (Client Authentication)對客戶端進行身份驗證。
• 確保授權碼已頒發給經過身份驗證的客戶。
• 驗證授權碼是否有效。
• 如果可能，請驗證之前是否未使用過授權碼。
• 確保 redirect_uri參數值 與初始授權請求中包含的redirect_uri參數值相同。如果當只有一個注冊的redirect_uri值時redirect_uri參數值不存在 ，則授權服務器可以返回一個錯誤（因為客戶端應該包含該參數）或者可以在沒有錯誤的情況下繼續（因為OAuth 2.0允許省略該參數在這種情況下）。
• 驗證所使用的授權碼是否是為了響應 OpenID Connect 身份驗證請求而發出的（以便從令牌端點返回 ID 令牌）。

3.1.3.3.成功的令牌響應

在接收并驗證來自客戶端的有效且授權的令牌請求后，授權服務器返回包含 ID 令牌和訪問令牌的成功響應。成功響應中的參數在OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749]的第 4.1.4 節中定義。響應使用application/json 媒體類型。

OAuth 2.0 token_type響應參數值必須是Bearer，如OAuth 2.0 承載令牌使用 (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.)[RFC6750] 中所指定，除非已與客戶端協商了另一個令牌類型。服務器應該支持承載令牌類型；使用其他令牌類型超出了本規范的范圍。請注意，token_type值不區分大小寫。

除了 OAuth 2.0 指定的響應參數之外，響應中還必須包含以下參數：

id_token

與經過身份驗證的會話關聯的 ID 令牌值。

所有包含令牌、秘密或其他敏感信息的令牌響應必須包含以下 HTTP 響應標頭字段和值：

以下是成功令牌響應的非規范示例。示例中的 ID Token 簽名可以使用 附錄 A.7 (RSA Key Used in Examples)中的密鑰進行驗證。

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

  {
   "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] 中所指定的，客戶端應該忽略無法識別的響應參數。

3.1.3.4.令牌錯誤響應

如果令牌請求無效或未經授權，授權服務器將構造錯誤響應。令牌錯誤響應的參數在OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749]的第 5.2 節中定義。 HTTP 響應正文使用application/json 媒體類型，HTTP 響應代碼為 400.

以下是一個非規范的令牌錯誤響應示例：

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

  {
   "error": "invalid_request"
  }

3.1.3.5.令牌響應驗證

客戶端必須按如下方式驗證令牌響應：

1. 遵循 RFC 6749 中的驗證規則，尤其是第 5.1 和 10.12 節中的驗證規則。
2. 遵循第 3.1.3.7 節 (ID Token Validation) 中的 ID 令牌驗證規則。
3. 遵循第 3.1.3.8 節 (Access Token Validation) 中的訪問令牌驗證規則。

3.1.3.6.身份令牌

ID Token 的內容如第 2 節 (ID Token)中所述。使用授權碼流程時，以下 ID 令牌聲明的附加要求適用：

at_hash

可選。訪問令牌哈希值。它的值是access_token值的 ASCII 表示的八位字節的散列的最左半部分的 base64url 編碼 ，其中使用的散列算法是ID 令牌的 JOSE 標頭的alg標頭參數中使用的散列算法。例如，如果alg是 RS256，則使用 SHA-256 哈希 access_token值，然后獲取最左邊的 128 位并對它們進行 base64url 編碼。at_hash值是區分大小寫的字符串。

3.1.3.7. ID令牌驗證

客戶端必須按以下方式驗證令牌響應中的 ID 令牌：

1. 如果 ID 令牌已加密，請使用客戶端在注冊期間指定的 OP 用于加密 ID 令牌的密鑰和算法對其進行解密。如果在注冊時與 OP 協商加密并且 ID 令牌未加密，則 RP 應拒絕它。
2. OpenID 提供方的頒發者標識符（通常在發現期間獲得）必須與iss（頒發者）聲明 的值完全匹配 。
3. 客戶必須驗證 aud（受眾）聲明包含在由iss （頒發者）聲明標識 為受眾的頒發者處注冊的client_id值。 aud （觀眾）聲明可以包含一個具有多個元素的數組。如果 ID 令牌未將客戶端列為有效受眾，或者包含客戶端不信任的其他受眾，則必須拒絕 ID 令牌。
4. 如果實現正在使用導致azp（授權方）聲明存在的擴展（超出了本規范的范圍），則它應該驗證這些擴展指定的 azp值。
5. 此驗證可以包括當azp（授權方）聲明存在時，客戶端應該驗證其client_id 是聲明值。
6. 如果通過客戶端和令牌端點（在此流程中）之間的直接通信接收 ID 令牌，則 TLS 服務器驗證可用于驗證頒發者而不是檢查令牌簽名。客戶端必須根據 JWS [JWS] 使用 JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.)alg標頭參數中指定的算法驗證所有其他 ID 令牌的簽名。客戶必須使用頒發者提供的密鑰。
7. alg值應該是RS256的默認值 或注冊期間 客戶端在 id_token_signed_response_alg 參數中發送的算法。
8. 如果 JWT alg標頭參數使用基于 MAC 的算法，例如 HS256、HS384或HS512 ，則與aud （受眾）聲明中包含的 client_id對應的 client_secret的UTF-8 [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.)表示形式的八位位組將用作驗證簽名的密鑰。對于基于 MAC 的算法，如果aud是多值， 則行為未指定。
9. 當前時間必須早于exp聲明 所表示的時間 。
10. iat Claim 可用于拒絕距當前時間太遠的令牌，從而限制為防止攻擊而需要存儲的隨機數的時間。可接受的范圍是客戶特定的。
11. 如果在身份驗證請求中發送了隨機數值，則必須存在隨機數聲明，并檢查其值以驗證它是否與身份驗證請求中發送的值相同。客戶端應該檢查重放攻擊的隨機數值。檢測重放攻擊的精確方法是客戶端特定的。
12. 如果請求acr聲明，客戶應檢查所主張的聲明價值是否適當。acr聲明值的含義和處理 超出了本規范的范圍。
13. 如果請求了auth_time聲明，無論是通過對此聲明的特定請求還是使用max_age參數，客戶端應該檢查auth_time聲明值，如果確定自上次最終用戶身份驗證以來已經過去了太多時間，則請求重新身份驗證。

3.1.3.8.訪問令牌驗證

使用授權碼流程時，如果 ID 令牌包含at_hash聲明，則客戶端可以使用它以與隱式流相同的方式驗證訪問令牌（如第 3.2.2.9 節 (Access Token Validation)中定義），但使用 ID 令牌和從令牌端點返回的訪問令牌。

3.2.使用隱式流程進行身份驗證

本節介紹如何使用隱式流程執行身份驗證。使用隱式流程時，所有令牌均從授權端點返回；未使用令牌端點。

隱式流程主要由使用腳本語言在瀏覽器中實現的客戶端使用。訪問令牌和 ID 令牌直接返回給客戶端，這可能會將它們公開給最終用戶和有權訪問最終用戶的用戶代理的應用程序。授權服務器不執行客戶端身份驗證。

3.2.1.隱式流程步驟

隱式流程遵循以下步驟：

1. 客戶端準備包含所需請求參數的身份驗證請求。
2. 客戶端將請求發送到授權服務器。
3. 授權服務器對最終用戶進行身份驗證。
4. 授權服務器獲得最終用戶同意/授權。
5. 授權服務器將最終用戶連同 ID 令牌以及訪問令牌（如果請求）發送回客戶端。
6. 客戶端驗證 ID 令牌并檢索最終用戶的主題標識符。

3.2.2.授權端點

使用隱式流程時，授權端點的使用方式與第 3.1.2 節 (Authorization Endpoint)中定義的授權碼流程相同，但本節中指定的差異除外。

3.2.2.1.認證請求

身份驗證請求按照第 3.1.2.1 節 (Authentication Request) 中的定義進行，但這些身份驗證請求參數的使用方式如下：

響應類型

必需。 OAuth 2.0 響應類型值，確定要使用的授權處理流程，包括從使用的端點返回哪些參數。當使用隱式流程時，該值為 id_token token或 id_token。這兩個值的含義在OAuth 2.0 多重響應類型編碼實踐 (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 還定義了 隱式流的令牌響應類型值，但 OpenID Connect 不使用此響應類型，因為不會返回 ID 令牌。

重定向URI

必需。響應將發送到的重定向 URI。該 URI 必須與在 OpenID 提供方處預先注冊的客戶端的重定向 URI 值之一完全匹配，并按照[RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.)（簡單字符串比較）第 6.2.1 節中所述執行匹配。使用此流程時，重定向 URI 不得使用http方案，除非客戶端是本機應用程序，在這種情況下，它可以使用帶有 localhost或 IP 環回文字 127.0.0.1或[::1] 作為主機名的http方案。

隨機數

必需。用于將客戶端會話與 ID 令牌相關聯并減輕重放攻擊的字符串值。該值未經修改地從身份驗證請求傳遞到 ID 令牌。用于防止攻擊者猜測值的隨機數值中必須存在足夠的熵 。有關實施說明，請參閱第 15.5.2 節 (Nonce Implementation Notes)。

以下是使用隱式流的非規范示例請求，該請求將由用戶代理發送到授權服務器，以響應客戶端的相應 HTTP 302 重定向響應（值內換行僅用于顯示目的）：

  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.身份驗證請求驗證

當使用隱式流程時，驗證請求的驗證方式與授權碼流程相同，如第3.1.2.2 節 (Authentication Request Validation)中所定義。

3.2.2.3.授權服務器對最終用戶進行身份驗證

使用隱式流程時，最終用戶身份驗證的執行方式與授權碼流程相同，如第 3.1.2.3 節 (Authorization Server Authenticates End-User)中所定義。

3.2.2.4.授權服務器獲取最終用戶同意/授權

使用隱式流程時，最終用戶同意的獲取方式與授權碼流程相同，如第3.1.2.4 節 (Authorization Server Obtains End-User Consent/Authorization)中所定義。

3.2.2.5.認證成功響應

使用隱式流程時，身份驗證響應的方式與第 3.1.2.5 節 (Successful Authentication Response)中定義的授權碼流程相同，但本節中指定的差異除外。

使用隱式流時，所有響應參數都將添加到重定向 URI 的片段組件中，如 OAuth 2.0 多重響應類型編碼實踐 (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_type值為 id_token ，否則將返回此值。

令牌類型

OAuth 2.0 令牌類型值。該值必須是Bearer或客戶端與授權服務器協商的另一個token_type值。實現此配置文件的客戶端必須支持OAuth 2.0 承載令牌使用 (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.)[RFC6750] 規范。此配置文件僅描述不記名令牌的使用。這與access_token的返回情況相同 。

id_token

必需。 ID 令牌。

狀態

OAuth 2.0 狀態值。如果 授權請求中存在狀態參數，則為必需。客戶端必須驗證 狀態值是否等于授權請求中 狀態參數的值。

過期日期在

可選。訪問令牌的過期時間（以秒為單位，自響應生成以來）。

根據OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] 的第 4.2.2 節，使用隱式流程時不會返回 任何代碼結果。

以下是使用隱式流程成功響應的非規范示例（換行僅用于顯示目的）：

  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.身份驗證錯誤響應

使用隱式流程時，授權錯誤響應的方式與第 3.1.2.6 節 (Authentication Error Response)中定義的授權碼流程相同，但本節中指定的差異除外。

每當返回錯誤響應參數時，例如當最終用戶拒絕授權或最終用戶身份驗證失敗時，授權服務器必須在重定向 URI 的片段組件中返回錯誤授權響應，如第 4.2.2.1 節中所定義。 OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] 和 OAuth 2.0 多重響應類型編碼實踐 (de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.)[OAuth.Responses]，除非指定了不同的響應模式。

3.2.2.7. 重定向 URI 片段處理

由于響應參數是在重定向 URI 片段值中返回的，因此客戶端需要讓用戶代理解析片段編碼值并將它們傳遞給客戶端的處理邏輯以供使用。有關 URI 片段處理的實現說明， 請參閱第 15.5.3 節。 (Redirect URI Fragment Handling Implementation Notes)

3.2.2.8.認證響應驗證

當使用隱式流程時，客戶端必須按如下方式驗證響應：

1. 驗證響應是否符合 [OAuth.Responses] (de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.)第 5 節。
2. 遵循 RFC 6749 中的驗證規則，尤其是第 4.2.2 和 10.12 節中的規則。
3. 遵循第 3.2.2.11 節 (ID Token Validation) 中的 ID 令牌驗證規則。
4. 遵循第 3.2.2.9 節 (Access Token Validation) 中的訪問令牌驗證規則，除非使用的response_type值為 id_token。

3.2.2.9.訪問令牌驗證

要使用 ID 令牌驗證從授權端點頒發的訪問令牌，客戶端應該執行以下操作：

1. 使用JWA [JWA] 中為 ID 令牌的 JOSE 標頭的alg標頭參數 指定的散列算法，對access_token的 ASCII 表示形式的八位位組進行散列。例如，如果alg是 RS256，則使用的哈希算法是 SHA-256. (Jones, M., “JSON Web Algorithms (JWA),” May 2015.)
2. 獲取哈希值的最左半部分并對其進行 base64url 編碼。
3. ID 令牌中at_hash 的值必須與上一步中生成的值匹配。

3.2.2.10.身份令牌

ID Token 的內容如第 2 節 (ID Token)中所述。使用隱式流時，以下 ID 令牌聲明的附加要求適用：

隨機數

此流程需要 使用隨機數聲明。

at_hash

訪問令牌哈希值。它的值是access_token值的 ASCII 表示的八位字節的散列的最左半部分的 base64url 編碼 ，其中使用的散列算法是ID 令牌的 JOSE 標頭的alg標頭參數中使用的散列算法。例如，如果alg是 RS256，則使用 SHA-256 哈希 access_token值，然后獲取最左邊的 128 位并對它們進行 base64url 編碼。at_hash值是區分大小寫的字符串。

如果 ID 令牌是從授權端點使用 access_token值發出的（ response_type值 id_token token就是這種情況），則這是必需的；當沒有頒發訪問令牌時，不能使用它，response_type值 id_token就是這種情況。

3.2.2.11. ID令牌驗證

使用隱式流時，必須以與授權碼流程相同的方式驗證 ID 令牌的內容（如第 3.1.3.7 節 (ID Token Validation)中定義），但本節中指定的差異除外。

1. 客戶端必須使用JOSE 標頭的 alg標頭參數中指定的算法 根據JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS] 驗證 ID 令牌的簽名 。
2. 必須檢查隨機數聲明 的值 ，以驗證它是否與身份驗證請求中發送的值相同。客戶端應該檢查重放攻擊的隨機數值。檢測重放攻擊的精確方法是客戶端特定的。

3.3.使用混合流進行身份驗證

本節介紹如何使用混合流程執行身份驗證。使用混合流時，一些令牌從授權端點返回，其他令牌從令牌端點返回。OAuth 2.0 多重響應類型編碼實踐 (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.混合流程步驟

混合流程遵循以下步驟：

1. 客戶端準備包含所需請求參數的身份驗證請求。
2. 客戶端將請求發送到授權服務器。
3. 授權服務器對最終用戶進行身份驗證。
4. 授權服務器獲得最終用戶同意/授權。
5. 授權服務器將最終用戶連同授權碼以及一個或多個附加參數（根據響應類型）發送回客戶端。
6. 客戶端使用令牌端點處的授權碼請求響應。
7. 客戶端收到響應正文中包含 ID 令牌和訪問令牌的響應。
8. 客戶端驗證 ID 令牌并檢索最終用戶的主題標識符。

3.3.2.授權端點

使用混合流程時，授權端點的使用方式與第 3.1.2 節 (Authorization Endpoint)中定義的授權碼流程相同，但本節中指定的差異除外。

3.3.2.1.認證請求

身份驗證請求按照第 3.1.2.1 節 (Authentication Request) 中的定義進行，但這些身份驗證請求參數的使用方式如下：

響應類型

必需。 OAuth 2.0 響應類型值，確定要使用的授權處理流程，包括從使用的端點返回哪些參數。使用混合流時，該值為 code id_token、 code token或 code id_token token。這些值的含義在OAuth 2.0 多重響應類型編碼實踐 (de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.)[OAuth.Responses]中定義 。

隨機數

如果請求的響應類型是code id_token 或code id_token token，則為必需；如果請求的響應類型為code token ，則為可選。它是一個字符串值，用于將客戶端會話與 ID 令牌相關聯，并減輕重放攻擊。該值未經修改地從身份驗證請求傳遞到 ID 令牌。用于防止攻擊者猜測值的隨機數值中必須存在足夠的熵 。有關實施說明，請參閱第 15.5.2 節 (Nonce Implementation Notes)。

以下是使用混合流的非規范示例請求，該請求將由用戶代理發送到授權服務器，以響應客戶端的相應 HTTP 302 重定向響應（值內換行僅用于顯示目的）：

  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.身份驗證請求驗證

使用混合流程時，驗證請求的驗證方式與授權碼流程相同，如第3.1.2.2 節 (Authentication Request Validation)中所定義。

3.3.2.3.授權服務器對最終用戶進行身份驗證

使用混合流程時，最終用戶身份驗證的執行方式與授權碼流程相同，如第3.1.2.3 節 (Authorization Server Authenticates End-User)中所定義。

3.3.2.4.授權服務器獲取最終用戶同意/授權

使用混合流程時，最終用戶同意的獲取方式與授權碼流程相同，如第3.1.2.4 節 (Authorization Server Obtains End-User Consent/Authorization)中所定義。

3.3.2.5.認證成功響應

當使用混合流時，認證響應的方式與隱式流相同，如第 3.2.2.5 節 (Successful Authentication Response)中所定義，但本節中指定的差異除外。

這些授權端點結果按以下方式使用：

訪問令牌

OAuth 2.0 訪問令牌。當使用的response_type值是 code token或code id_token token時，返回此值。 （在相同情況下也會返回 token_type值。）

id_token

ID 令牌。當使用的response_type值是 code id_token或 code id_token token時返回。

代碼

授權碼。使用混合流時始終會返回此值。

以下是使用混合流成功響應的非規范示例（換行僅用于顯示目的）：

  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.身份驗證錯誤響應

使用混合流程時，授權錯誤響應的方式與第 3.1.2.6 節 (Authentication Error Response)中定義的授權碼流程相同，但本節中指定的差異除外。

每當返回錯誤響應參數時，例如當最終用戶拒絕授權或最終用戶身份驗證失敗時，授權服務器必須在重定向 URI 的片段組件中返回錯誤授權響應，如第 4.2.2.1 節中所定義。 OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] 和 OAuth 2.0 多重響應類型編碼實踐 (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.2.7.重定向 URI 片段處理

使用混合流時，重定向 URI 片段參數處理的要求與隱式流相同，如第 3.2.2.7 節 (Redirect URI Fragment Handling)中所定義。另請參閱第 15.5.3 節 (Redirect URI Fragment Handling Implementation Notes)有關 URI 片段處理的實現說明。

3.3.2.8.認證響應驗證

當使用混合流時，客戶端必須按如下方式驗證響應：

1. 驗證響應是否符合 [OAuth.Responses] (de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.)第 5 節。
2. 遵循 RFC 6749 中的驗證規則，尤其是第 4.2.2 和 10.12 節中的規則。
3. 當使用的response_type值為 code id_token或 code id_token token時，請遵循第 3.3.2.12 節 (ID Token Validation) 中的 ID 令牌驗證規則。
4. 當使用的response_type值為 code token或 code id_token token時，請遵循第 3.3.2.9 節 (Access Token Validation) 中的訪問令牌驗證規則。
5. 當使用的response_type值為 code id_token或 code id_token token時，請遵循第 3.3.2.10 節 (Authorization Code Validation) 中的授權碼驗證規則。

3.3.2.9.訪問令牌驗證

使用混合流時，從授權端點返回的訪問令牌將以與隱式流相同的方式進行驗證，如第 3.2.2.9 節 (Access Token Validation)中所定義。

3.3.2.10.授權碼驗證

要使用 ID 令牌驗證從授權端點發出的授權碼，客戶端應該執行以下操作：

1. 使用JWA [JWA] 中為 ID 令牌的 JOSE 標頭的alg標頭參數 指定的散列算法，對代碼的 ASCII 表示形式的八位位組進行散列。例如，如果alg是 RS256，則使用的哈希算法是 SHA-256. (Jones, M., “JSON Web Algorithms (JWA),” May 2015.)
2. 獲取哈希值的最左半部分并對其進行 base64url 編碼。
3. 如果ID 令牌中存在 c_hash ，則 ID 令牌中的c_hash值必須與上一步中生成的值匹配。

3.3.2.11.身份令牌

ID Token 的內容如第 2 節 (ID Token)中所述。使用混合流時，以下 ID 令牌聲明的附加要求適用于從授權端點返回的 ID 令牌：

隨機數

如果身份驗證請求中存在隨機數參數，則授權服務器必須在 ID 令牌中 包含隨機數聲明。

at_hash

訪問令牌哈希值。它的值是access_token值的 ASCII 表示的八位字節的散列的最左半部分的 base64url 編碼 ，其中使用的散列算法是ID 令牌的 JOSE 標頭的alg標頭參數中使用的散列算法。例如，如果alg是 RS256，則使用 SHA-256 哈希 access_token值，然后獲取最左邊的 128 位并對它們進行 base64url 編碼。at_hash值是區分大小寫的字符串。

如果 ID 令牌是從授權端點使用 access_token值發出的（ response_type值 代碼 id_token token就是這種情況），則這是必需的；否則，其包含是可選的。

c_hash

代碼哈希值。它的值是代碼值的 ASCII 表示的八位字節的散列的最左半部分的 base64url 編碼 ，其中使用的散列算法是ID 令牌的 JOSE 標頭的alg標頭參數中使用的散列算法。例如，如果alg是 HS512，則 使用 SHA-512 對代碼值進行哈希處理，然后獲取最左邊的 256 位并對它們進行 base64url 編碼。c_hash值是區分大小寫的字符串。

如果 ID 令牌是從授權端點發出的，帶有 code ， response_type值 code id_token和 code id_token token就是這種情況，這是必需的；否則，其包含是可選的。

3.3.2.12. ID令牌驗證

當使用混合流時，從授權端點返回的 ID 令牌的內容必須以與隱式流相同的方式進行驗證，如第 3.2.2.11 節 (ID Token Validation)中所定義。

3.3.3.令牌端點

使用混合流時，令牌端點的使用方式與第 3.1.3 節 (Token Endpoint)中定義的授權碼流程相同，但本節中指定的差異除外。

3.3.3.1.令牌請求

使用混合流程時，令牌請求的發出方式與授權碼流程相同，如第3.1.3.1 節 (Token Request)中所定義。

3.3.3.2.令牌請求驗證

使用混合流程時，令牌請求的驗證方式與授權碼流程相同，如第3.1.3.2 節 (Token Request Validation)中所定義。

3.3.3.3.成功的令牌響應

使用混合流程時，令牌響應的方式與授權碼流程相同，如第 3.1.3.3 節 (Successful Token Response)中所定義。

3.3.3.4.令牌錯誤響應

使用混合流程時，令牌錯誤響應的方式與授權碼流程相同，如第3.1.3.4 節 (Token Error Response)中所定義。

3.3.3.5.令牌響應驗證

使用混合流程時，令牌響應的驗證方式與授權碼流程相同，如第3.1.3.5 節 (Token Response Validation)中所定義。

3.3.3.6.身份令牌

使用混合流時，從令牌端點返回的 ID 令牌的內容與從授權端點返回的 ID 令牌的內容相同，如第3.3.2.11 節 (ID Token)中所定義，但本節中指定的差異除外。

如果從授權端點和令牌端點都返回了 ID 令牌（response_type值 代碼 id_token和 代碼 id_token token就是這種情況） ，則兩個 ID 令牌中的iss和sub 聲明值必須相同。任何一個中存在的有關身份驗證事件的所有聲明都應該存在于兩個中。如果任一 ID 令牌包含有關最終用戶的聲明，則兩者中出現的任何內容都應具有相同的值。請注意，例如，出于隱私原因，OP 可以選擇從授權端點返回較少的有關最終用戶的聲明。 at_hash 和c_hash聲明可以從令牌端點返回的 ID 令牌中省略，即使這些聲明存在于從授權端點返回的 ID 令牌中，因為從令牌端點返回的 ID 令牌和訪問令牌值已經進行了加密綁定由令牌端點執行的 TLS 加密結合在一起。

3.3.3.7. ID令牌驗證

使用混合流時，從令牌端點返回的 ID 令牌的內容必須以與授權碼流程相同的方式進行驗證，如第 3.1.3.7 節 (ID Token Validation)中所定義。

3.3.3.8.訪問令牌

如果從授權端點和令牌端點都返回訪問令牌（response_type值 code token和 code id_token token就是這種情況），則它們的值可以相同也可以不同。請注意，由于兩個端點的安全特性不同，可能會返回不同的訪問令牌，并且它們的生命周期和對它們授予的資源的訪問權限也可能不同。

3.3.3.9.訪問令牌驗證

使用混合流時，從令牌端點返回的訪問令牌以與授權碼流程相同的方式進行驗證，如第 3.1.3.8 節 (Access Token Validation)中所定義。

4. 發起第三方登錄

在某些情況下，登錄流程是由 OpenID 提供方或另一方（而不是依賴方）發起的。在這種情況下，發起者在其登錄發起端點重定向到 RP，請求 RP 向指定的 OP 發送身份驗證請求。請注意，此登錄啟動端點可以是 RP 上與 RP 的默認登錄頁面不同的頁面。支持 OpenID Connect 動態客戶端注冊 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” December 2023.) [OpenID.Registration] 的 RP 使用 initiate_login_uri注冊參數注冊此端點值。

發起登錄請求的一方通過重定向到 RP 上的登錄發起端點并傳遞以下參數來實現此目的：

國際空間站

必需。 RP 將向其發送身份驗證請求的 OP 的頒發者標識符。它的值必須是使用https方案的URL 。

登錄提示

可選。向授權服務器提示要進行身份驗證的最終用戶。這個字符串值參數的含義由OP自行決定。在常見用例中，該值將包含 RP 在向 OP 請求身份驗證之前收集的電子郵件地址、電話號碼或用戶名。例如，RP 在向最終用戶詢問其電子郵件地址（或其他標識符）后可以使用此提示，將該標識符作為提示傳遞給 OpenID 提供方。建議提示值與為發現提供的值相匹配。其他用途可以包括使用ID 令牌中的 子聲明作為提示值或有關請求的身份驗證的潛在其他類型的信息。

目標鏈接URI

可選。 RP認證后請求重定向到的URL。 RP 必須驗證target_link_uri的值， 以防止被用作外部站點的開放重定向器。

這些參數可以使用 HTTP GET方法 作為查詢參數傳遞，也可以作為在用戶代理中自動提交的 HTML 表單值傳遞，從而通過 HTTP POST方法傳輸。

如果擴展定義了其他參數，則可以發送。客戶端必須忽略所使用的任何不理解的參數。

客戶應該采用框架破壞和其他技術來防止最終用戶在不知情的情況下通過點擊劫持等攻擊被第三方網站登錄。有關更多詳細信息， 請參閱[RFC6819]的第 4.4.1.9 節。 (Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.)

5. 聲明

本節指定客戶端如何獲取有關最終​​用戶和身份驗證事件的聲明。它還定義了一組標準的基本資料聲明。可以使用特定范圍值請求預定義的聲明集，也可以使用 聲明請求參數請求單個聲明。聲明可以直接來自 OpenID 提供方，也可以來自分布式來源。

5.1.標準聲明

本規范定義了一組標準權利要求。可以請求在 UserInfo 響應（根據第 5.3.2 節 (Successful UserInfo Response)）或 ID 令牌（根據第 2 節） (ID Token)中返回它們。

5.1.1.地址聲明

地址聲明代表實際郵寄地址。實現可以僅返回地址字段的子集，具體取決于可用信息和最終用戶的隱私偏好。例如，可能會返回國家和地區，而不返回更細粒度的地址信息。

實現可以僅將完整地址作為格式化子字段中的單個字符串返回，或者它們可以僅返回使用其他子字段的各個組件字段，或者它們可以同時返回兩者。如果返回兩個變體，它們應該表示相同的地址，格式化的地址指示如何組合組件字段。

下面定義的所有地址值均表示為 JSON 字符串。

格式化的

完整的郵寄地址，格式適合在郵寄標簽上顯示或使用。該字段可以包含多行，以換行符分隔。換行符可以表示為回車/換行對（“\r\n”）或單個換行符（“\n”）。

街道地址

完整的街道地址組件，可能包括門牌號、街道名稱、郵政信箱和多行擴展街道地址信息。該字段可以包含多行，以換行符分隔。換行符可以表示為回車/換行對（“\r\n”）或單個換行符（“\n”）。

地點

城市或地區組成部分。

地區

州、省、地區或地區組成部分。

郵政編碼

郵政編碼或郵政編碼的組成部分。

國家

國家/地區名稱組成部分。

5.1.2.額外聲明

雖然本說明書僅將一小部分權利要求定義為標準權利要求，但其他權利要求可以與標準權利要求結合使用。使用此類聲明時，建議對聲明名稱使用防沖突名稱，如 JSON Web 令牌 (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.) [JWT] 規范中所述。或者，當不太可能出現命名沖突時，可以安全地使用私有聲明名稱，如 JWT 規范中所述。或者，如果特定的附加聲明具有廣泛且普遍的適用性，則可以根據 JWT 規范使用注冊聲明名稱進行注冊。

5.2.權利要求語言和文字

人類可讀的聲明值和引用人類可讀值的聲明值可以用多種語言和腳本表示。為了指定語言和腳本，BCP47 (Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.) [RFC5646] 語言標簽被添加到成員名稱中，并由#字符分隔。例如， family_name#ja-Kana-JP表示日語中片假名的姓氏，通常用于索引和表示以family_name#ja-Hani-JP表示的相同名稱的漢字表示的語音。作為另一個示例，可能會返回website和 website#de聲明值，引用未指定語言的網站和德語網站。

由于聲明名稱區分大小寫，因此強烈建議聲明名稱中使用的語言標簽值應使用在 IANA“語言子標簽注冊表” [IANA.Language] (IANA, “Language Subtag Registry,” .) 中注冊的字符大小寫進行拼寫。特別地，通常語言名稱用小寫字符拼寫，區域名稱用大寫字符拼寫，并且腳本用混合大小寫字符拼寫。然而，由于 BCP47 語言標簽值不區分大小寫，因此實現應該解釋以不區分大小寫的方式提供的語言標簽值。

根據 BCP47 中的建議，聲明的語言標簽值應僅根據需要具體化。例如，在許多情況下使用fr可能就足夠了，而不是fr-CA或 fr-FR。在可能的情況下，OP 應該嘗試將請求的聲明區域設置與其擁有的聲明相匹配。例如，如果客戶要求帶有de（德語）語言標簽的聲明，并且 OP 具​​有帶有de-CH（瑞士德語）標記的值，并且沒有通用德語值，則 OP 應該返回瑞士語德國對客戶的價值。 （這有意將語言標簽匹配的復雜性盡可能轉移到 OP，以簡化客戶端。）

OpenID Connect 定義以下授權請求參數，以指定用于返回聲明的首選語言和腳本：

聲明_區域設置

可選。最終用戶返回的聲明的首選語言和腳本，表示為BCP47 (Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.) [RFC5646] 語言標簽值的空格分隔列表 ，按偏好排序。如果 OpenID 提供方不支持部分或全部請求的語言環境，則不應產生錯誤。

當OP通過 claims_locales參數或其他方式確定最終用戶和客戶端僅以一組語言和腳本請求聲明時，建議OP在使用該語言時返回不帶語言標簽的聲明和腳本。還建議客戶端以可以使用語言標簽處理和利用聲明的方式編寫。

5.3.用戶信息端點

UserInfo 端點是受 OAuth 2.0 保護的資源，可返回有關經過身份驗證的最終用戶的聲明。要獲取有關最終​​用戶的請求聲明，客戶端使用通過 OpenID Connect 身份驗證獲得的訪問令牌向 UserInfo 端點發出請求。這些聲明通常由 JSON 對象表示，該對象包含聲明的名稱和值對集合。

與 UserInfo 端點的通信必須使用 TLS。有關使用 TLS 的更多信息， 請參閱第 16.17 節。 (TLS Requirements)

UserInfo 端點必須支持使用RFC 7231 [RFC7231] 中定義的HTTP GET和 HTTP POST方法。 (Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content,” June 2014.)

UserInfo 端點必須接受訪問令牌作為 OAuth 2.0 承載令牌用法 (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.)[RFC6750]。

UserInfo 端點應支持使用 跨源資源共享 (CORS) (Opera Software ASA, “Cross-Origin Resource Sharing,” July 2010.) [CORS] 和/或其他適當的方法，以使 JavaScript 客戶端和其他基于瀏覽器的客戶端能夠訪問它。

5.3.1.用戶信息請求

客戶端使用 HTTP GET或 HTTP POST 發送 UserInfo 請求。根據OAuth 2.0 承載令牌使用 (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.)[RFC6750] 第 2 節，從 OpenID Connect 身份驗證請求獲取的訪問令牌必須作為承載令牌發送。

建議請求使用 HTTP GET方法，并使用授權標頭字段發送訪問令牌 。

以下是 UserInfo 請求的非規范示例：

  GET /userinfo HTTP/1.1
  Host: server.example.com
  Authorization: Bearer [Your Access Token]

5.3.2.成功的用戶信息響應

UserInfo 聲明必須作為 JSON 對象的成員返回，除非在客戶端注冊期間請求簽名或加密的響應。可以退回 第 5.1 節 (Standard Claims)中定義的聲明，以及此處未指定的其他聲明。

出于隱私原因，OpenID 提供方可以選擇不返回某些請求的聲明的值。不返回所請求的聲明并不是錯誤情況。

如果未返回聲明，則應從表示聲明的 JSON 對象中省略該聲明名稱；它不應該與 null 或空字符串值一起出現。

子（主題）聲明必須始終在 UserInfo 響應中返回。

注意：由于令牌替換攻擊的可能性（請參閱第 16.11 節 (Token Substitution)），用戶信息響應不能保證與ID 令牌的子（主題）元素標識的最終用戶有關。必須驗證 UserInfo 響應中的 子聲明是否與 ID 令牌中的子聲明完全匹配；如果它們不匹配，則不得使用 UserInfo 響應值。

收到 UserInfo 請求后，UserInfo 端點必須在 HTTP 響應正文中返回 UserInfo 響應的 JSON 序列化，如 第 13.3 節 (JSON Serialization)中所述，除非在注冊期間指定了不同的格式 [OpenID.Registration] (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” December 2023.)。 UserInfo 端點必須返回一個內容類型標頭以指示返回哪種格式。如果響應正文是文本 JSON 對象，則HTTP 響應的內容類型必須是application/json ；響應正文應該使用 UTF-8 進行編碼。

如果 UserInfo 響應已簽名和/或加密，則聲明將以 JWT 返回，并且內容類型必須為application/jwt。響應可以在不簽名的情況下進行加密。如果同時請求簽名和加密，則必須對響應進行簽名然后加密，結果是嵌套 JWT，如[JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.)中定義。

如果已簽名，則 UserInfo 響應必須包含聲明 iss（頒發者）和aud（受眾）作為成員。 iss值必須是OP 的頒發者標識符 URL。 aud值必須是或包含 RP 的客戶端 ID 值。

以下是 UserInfo 響應的非規范示例：

  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 端點將返回錯誤響應，如 OAuth 2.0 承載令牌使用 (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.)[RFC6750] 第 3 節中所定義。 （與 RFC 6750 無關的 HTTP 錯誤將使用適當的 HTTP 狀態代碼返回給用戶代理。）

以下是 UserInfo 錯誤響應的非規范示例：

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

5.3.4.用戶信息響應驗證

客戶端必須按如下方式驗證 UserInfo 響應：

1. 根據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 服務器證書檢查驗證響應的 OP 是否是預期的 OP 。
2. 如果客戶端在注冊期間提供了 userinfo_encrypted_response_alg 參數，則使用注冊期間指定的密鑰解密 UserInfo 響應。
3. 如果響應已簽名，客戶端應該根據JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS] 驗證簽名。

5.4.使用范圍值請求聲明

OpenID Connect 客戶端使用OAuth 2.0 [RFC6749]第 3.3 節中定義的范圍值來指定為訪問令牌請求哪些訪問權限。與訪問令牌關聯的范圍決定了哪些資源在用于訪問 OAuth 2.0 受保護端點時可用。受保護的資源端點可以根據請求提供的訪問令牌時使用的范圍值和其他參數執行不同的操作并返回不同的信息。 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.)

對于 OpenID Connect，范圍可用于請求將特定信息集作為聲明值提供。

以下范圍請求的聲明被授權服務器視為自愿聲明。

OpenID Connect 定義了以下用于請求聲明的 范圍值：

輪廓

可選。此范圍值請求訪問最終用戶的默認資料聲明，其中包括： name、 family_name、 given_name、 middle_name、 nickname、 preferred_username、 profile、 picture、 website、 gender、 birthdate、 zoneinfo、 locale和 updated_at。

電子郵件

可選。此范圍值請求訪問電子郵件和 email_verified聲明。

地址

可選。該范圍值請求訪問地址Claim。

電話

可選。此范圍值請求訪問phone_number和 phone_number_verified聲明。

可以通過創建空格分隔、區分大小寫的 ASCII 范圍值列表來使用多個范圍值。

當使用導致頒發訪問令牌的response_type值時，如第5.3.2節中所述， profile、 email、 address和 phone范圍值 請求的聲明 將從UserInfo端點返回。但是，當沒有頒發訪問令牌時（ response_type 值id_token就是這種情況），生成的聲明將在 ID 令牌中返回。 (Successful UserInfo Response)

在某些情況下，最終用戶可以選擇讓 OpenID 提供方拒絕提供 RP 請求的部分或全部信息。為了最大限度地減少最終用戶被要求披露的信息量，RP 可以選擇僅請求 UserInfo 端點提供的信息的子集。

以下是未編碼 范圍請求的非規范示例：

  scope=openid profile email phone

5.5.使用“claims”請求參數請求聲明

OpenID Connect 定義以下授權請求參數，以允許請求單獨的聲明并指定適用于所請求的聲明的參數：

聲明

可選。該參數用于請求返回特定的聲明。該值是一個列出請求的聲明的 JSON 對象。

聲明身份驗證請求參數請求從 UserInfo 端點和/或 ID 令牌中返回特定聲明。它表示為一個 JSON 對象，其中包含從這些位置請求的聲明列表。所請求的聲明的屬性也可以被指定。

對聲明參數 的支持是可選的。如果 OP 不支持此參數而 RP 使用它，則 OP 應使用其認為合適的任何啟發式方法，向 RP 返回一組它認為對 RP 和最終用戶有用的聲明。 Claims_parameter_supported Discovery 結果指示OP是否支持該參數。

聲明 參數值在 OAuth 2.0 請求中表示為 UTF-8 編碼的 JSON（當作為 OAuth 參數傳遞時，最終會進行表單 urlencoded）。當在請求對象值中使用時，根據第 6.1 節 (Passing a Request Object by Value)，JSON 用作 聲明成員的值。

聲明請求 JSON 對象的頂級成員是：

用戶信息

可選。請求從 UserInfo 端點返回列出的各個聲明。如果存在，則請求將列出的聲明添加到使用范圍值請求的任何聲明中 。如果不存在，則從 UserInfo 端點請求的聲明只是使用 范圍值請求的聲明。

當使用userinfo成員時，請求還必須使用response_type 值，該值會導致向客戶端頒發訪問令牌以在 UserInfo 端點處使用。

id_token

可選。請求在 ID 令牌中返回列出的單個聲明。如果存在，則請求將列出的聲明添加到 ID 令牌中的默認聲明中。如果不存在，則根據第 2 節中的 ID 令牌定義以及第 (ID Token)3.1.3.6 (ID Token)、 3.2.2.10 (ID Token)、 3.3.2.11 (ID Token)和3.3.3.6 (ID Token) 節中的附加每流 ID 令牌要求 請求默認 ID 令牌聲明。