OpenID Connect Core 1.0（七）使用混合流验证

3.3 使用混合流验证(Authentication using the Hybrid Flow)

本节描述如何使用混合流执行验证。当使用混合流(Hybrid Flow)时一些令牌从受权端点返回，另外一些则从令牌端点返回。混合流中返回令牌的机制在OAuth 2.0多响应类型编码实践中指定[OAuth. responses]。

3.3.1 混合流程的步骤（Hybrid Flow Steps）

混合流程遵循如下步骤:

一、客户准备一个包含所需的验证请求的请求参数。

二、客户端发送请求到受权服务器。

三、受权服务器验证用户。

四、受权服务器得到用户赞成/受权。

五、受权服务器将终端用户发送给回客户端一个受权码，根据响应类型，返回一个或多个额外的参数。

六、客户端使用的这个受权码到令牌终结点请求响应。

七、客户端接收到包含一个ID Token和Access Token的body响应。

八、客户端验证ID Token和检索终端用户的 Subject 标识符。

 

3.3.2 受权终结点（Authorization Endpoint）

当使用混合流程，使用受权的终结点，是以3.1.2节定义的受权码流程的同样的方式使用受权的终结点，除了在本节中指定的差别。

 

3.3.2.1 验证请求（Authentication Request）

验证请求是由3.1.2.1节中定义 ，除了如下使用的验证请求参数:

response_type

必需的。肯定要使用的受权处理流的OAuth 2.0响应类型值，包括从使用的端点返回的参数。当使用混合流程，此值是“code id_token” ，“code token”,或“code id_token token”。这些值定义在 OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses]。

下面是一个使用混合流的非规范示例请求，该混合流将由用户代理发送到受权服务器，以响应客户机相应的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 验证请求验证（Authentication Request Validation）

当使用混合流程，验证请求的验证方式与第3.1.2.2节中定义的受权代码流相同。

 

3.3.2.3 受权服务器验证用户（Authorization Server Authenticates End-User）

当使用混合流程，终端用户身份验证的执行方式与第3.1.2.3节中定义的受权代码流相同。

 

3.3.2.4受权服务器得到用户赞成/受权（Authorization Server Obtains End-User Consent/Authorization）

当使用混合流程，最终用户赞成的得到方式与第3.1.2.4节中定义的受权代码流相同。

 

3.3.2.5成功的验证响应（Successful Authentication Response）

当使用混合流程，以隐式流程3.2.2.5节中定义的一样方式验证响应，除了在本节中指定的差别。

这些受权终结点结果的使用方式以下:

access_token

OAuth 2.0Access Token。当 response_type 使用的值是 code token，或 code id_token token返回。(token_type 值也在一样的状况下返回。)

id_token

ID Token。当 response_type 使用的值是code id_token 或 code id_token token时返回。

code

受权码。当使用混合流时，其老是返回。

下面是一个非规范化成功的响应使用混合流程的例子(换行仅为显示):

  HTTP/1.1 302 Found

  Location: https://client.example.org/cb#

    code=SplxlOBeZQQYbYS6WxSbIA

    &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso

    &state=af0ifjsldkj

 

3.3.2.6 验证错误响应（Authentication Error Response）

当使用混合流程，受权错误响应的方式与第3.1.2.6节中定义的受权代码流相同，除了在本节中指定的差别。

若是最终用户拒绝请求或最终用户身份验证失败，受权服务器必须在重定向URI的片断组件中返回错误受权响应，OAuth 2.0 (RFC6749) 4.2.2.1中定义和 OAuth 2.0多个响应类型编码实践 (OAuth.Responses) 中定义，除非指定不一样的响应模式。

 

3.3.2.7 重定向URI片断处理(Redirect URI Fragment Handling)

当使用混合流程，重定向的URI参数处理片断与隐式流程3.2.2.7部分中定义请求相同。同时参照 15.5.3节中URI片断处理实现注意事项。

 

3.3.2.8 身份响应验证(Authentication Response Validation)

当使用混合流程，客户端必须验证以下响应:

一、验证的响应符合[OAuth.Responses]的第五节 。

二、遵循RFC 6749的验证规则，尤为是4.2.2和10.12部分。

三、遵循3.3.2.12验证规则，验证ID Token ，response_type 使用的值是“code id_token” 或“code id_token token”。

四、遵循3.3.2.9部分验证规则，验证IAccess Token ，当 response_type 使用的值“code token”或“code id_token token”。

五、遵循3.3.2.10部分规则，验证受权码，当 response_type使用的值是“code id_token ”或“code id_token”。

 

3.3.2.9 Access Token验证（Access Token Validation）

当使用混合流时，从受权终结点返回的Access Token将以与隐式流相同的方式进行验证，如3.2.2.9节中定义的那样。

 

3.3.2.10 受权码验证（Authorization Code Validation）

要使用ID Token验证受权结点发出的受权码，客户端应该执行如下操做:

一、用JWA 中为ID Token的JOSE报头的alg报头参数指定的哈希算法对代码的ASCII表示的八字节进行哈希。例如，若是alg是RS256，则使用的哈希算法是SHA-256。

二、取散列的最左边一半，而后对其进行base64url编码。

3. 若是ID Token中存在c_hash，则ID Token中的c_hash值必须与前一步中生成的值匹配。

 

3.3.2.11 ID Token

ID Token的内容如第2节所述。当使用混合流时，如下ID Token声明的这些附加要求适用于受权终结点返回的ID Token:

nonce

nonce 声明是必需。

at_hash

Access Token的哈希值。它的值是access_token值的ASCII表示的最左半哈希的base64url编码，其中使用的哈希算法是ID Token的JOSE头的alg头参数中使用的哈希算法。例如，若是alg是RS256，那么用SHA-256散列access_token值，而后取最左边的128位，base64url对其进行编码。at_hash值是一个区分大小写的字符串。

若是ID Token使用access_token值从受权终结点发出，则须要使用access_token，这是response_type值代码id_token的状况;不然，它是可选的。

c_hash

Code 的哈希值。它的值是Code的ASCII表示的最左半哈希的base64url编码，其中使用的哈希算法是ID Token的JOSE报头的alg报头参数中使用的哈希算法。例如，若是alg是HS512，用SHA-512对Code进行哈希，而后取最左边的256位，base64url对其进行编码。c_hash值是一个区分大小写的字符串。

若是ID Token是经过从受权终结点发出的Code，对于response_type值code id_token和code id_token来讲，这是必需的；不然，它是可选的。

 

3.3.2.12 ID Token验证（ID Token Validation）

在使用混合流时，必须以与隐式流相同的方式验证从受权终结点返回的ID Token的内容，如3.2.2.11节中定义的那样。

 

3.3.3 令牌终结点（Token Endpoint）

在使用混合流时，令牌终结点的使用方式与第3.1.3节中定义的受权代码流相同，但本节中指定的差别除外。

 

3.3.3.1 令牌的请求（Token Request）

当使用混合流时，令牌请求的方式与受权代码流的方式相同，如3.1.3.1节中定义的那样。

 

3.3.3.2 请求令牌验证（Token Request Validation）

在使用混合流时，令牌请求的验证方式与在3.1.3.2节中定义的受权代码流相同。

 

3.3.3.3 成功的令牌响应

当使用混合流时，令牌响应的方式与受权代码流的方式相同，如3.1.3.3节中定义的那样。

 

3.3.3.4 令牌错误响应

当使用混合流时，令牌错误响应的方式与受权代码流相同，如3.1.3.4节中定义的那样。

 

3.3.3.5 令牌响应确认

在使用混合流时，令牌响应的验证方式与在3.1.3.5节中定义的受权代码流相同。

 

3.3.3.6 ID Token（ID Token）

在使用混合流时，从令牌终结点返回的ID Token的内容与从受权终结点返回的ID Token的内容相同，如3.3.2.11节中定义的那样，但本节中指定的差别除外。

若是一个ID Token从受权终结点和令牌终结点返回，对于response_type值code id_token和code id_token来讲就是这样，那么iss和sub声明值在这两个ID Token中必须是相同的。任何一方中出现的关于身份验证事件的全部声明都应该出如今双方中。若是任何一个ID Token都包含关于最终用户的声明，那么在二者中出现的任何声明都应该具备相同的值。注意，出于隐私缘由，OP可能选择从受权终结点返回关于最终用户的最少声明。从ID Token牌终结点返回，at_hash和c_hash声称能够省略，即便这些声明出如今从受权终结点中返回的 ID Token中，由于ID Token和Access Token值，在令牌终结点中返回时已经经过TLS加密并绑定在一块儿。

3.3.3.7 ID Token验证（ID Token Validation）

在使用混合流时，从令牌端点返回的ID令牌的内容必须以与在3.1.3.7节中定义的受权代码流相同的方式进行验证。

3.3.3.8 Access Token（Access Token）

若是一个从令牌的终结点的Access Token受权端返回,当 response_type 值是 “code id_token”和 “code id_token token” ，它们的值多是相同的或者他们可能会有所不一样。注意，可能会有不一样的Access Token返回，这是因为两个端点的不一样安全特性以及它们授予的资源的使用寿命和访问时间可能也不一样。

3.3.3.9 Access Token验证（Access Token Validation）

当使用混合流时，从令牌端点返回的访问令牌将以与受权代码流相同的方式进行验证，如3.1.3.8节中定义的那样。