当前位置： 移动技术网 > IT编程>软件设计>架构 > OpenID Connect Core 1.0（七）使用混合流验证

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

2018年10月22日  | 移动技术网IT编程  | 我要评论

3.3 使用混合流验证(authentication using the hybrid flow)

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

3.3.1 混合流程的步骤（hybrid flow steps）

混合流程遵循以下步骤:

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

2、客户端发送请求到授权服务器。

3、授权服务器验证用户。

4、授权服务器获得用户同意/授权。

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

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

7、客户端接收到包含一个id token和access token的body响应。

8、客户端验证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)

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

1、验证的响应符合[oauth.responses]的第五节 。

2、遵循rfc 6749的验证规则，尤其是4.2.2和10.12部分。

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

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

5、遵循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验证授权结点发出的授权码，客户端应该执行以下操作:

1、用jwa 中为id token的jose报头的alg报头参数指定的哈希算法对代码的ascii表示的八字节进行哈希。例如，如果alg是rs256，则使用的哈希算法是sha-256。

2、取散列的最左边一半，然后对其进行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节中定义的那样。

 

 

 

您可能感兴趣的文章:

如对本文有疑问， 点击进行留言回复！！

相关文章:

验证码：
最近更新的文章
大家感兴趣的文章
移动技术网