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 Provider
    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 SlAV32hkKG

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 令牌声明。