OpenID Connect Core 1.0（六）使用隐式验证流

3.2 使用隐式验证流（authentication using the implicit flow）

本节描述如何使用隐式流程执行验证。使用隐式流程时，所有令牌从授权终结点返回；不使用令牌终结点返回。

隐式流程主要是由客户在浏览器中使用脚本语言实现。直接返回access token和id token到客户端，这可能会让他们接触到最终用户和应用程序，这些用户可以访问终端用户的用户代理。授权服务器不进行客户端验证。

 

3.2.1隐式流程步骤（implicit flow steps）

隐式流程动遵循以下步骤:

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

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

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

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

5、授权服务器将终端用户返回给客户端，并使用id token，如果需要的话，则可以使用一个access token。

6、客户端验证id token和检索终端用户的从属标识符。

 

3.2.2 授权终结点（authorization endpoint）

当使用隐式流程时，是以3.1.2节定义的授权码流程的一样的方式使用授权的终结点，除了在本节中指出的差异。

 

3.2.2.1验证请求（authentication request）

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

response_type

必需的。oauth 2.0授权处理流程规定的响应类型值，包括返回终结点的参数。使用隐式流时，这个值是 “id_token token” 或 “id_token” 。这两个值的含义在oauth 2.0多个响应类型编码实践 [oauth.responses] 中定义。没有access token值时只返回 id_token 。

注意：虽然oauth 2.0还定义了隐式流程令牌响应类型值，但openid connect不使用这种响应类型，因而没有返回id token。

redirect_uri

必需的。将发回响应的uri重定向。这个uri必须精确匹配客户端预注册的openid提供者的一个重定向uri值，匹配执行在 6.2.1节 (rfc3986) (简单的字符串比较) 中描述。当使用隐式流程时，重定向的uri 不能使用 http方案，除非客户端是一个本地应用程序,在这种情况下,它可能使用 http: 主机名是localhost。

nonce

必需的。用于将客户端会话与id token关联起来的字符串值，并减轻重播攻击。该值在请求id token中是不会修改的。nonec必须足够复杂，以防止攻击者猜测。实现说明,请参阅 15.5.2节 。

下面是一个非规范化的，使用隐式流程请求示例，这将是由用户代理发送到授权服务器，为以响应客户端相应的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验证请求验证（authentication request validation）

使用隐式流程时，其验证请求，与在 3.1.2.2节中定义的授权码流程方式一致。

 

3.2.2.3授权服务器验证用户（authorization server authenticates end-user）

使用隐式流程时，终端用户执行验证，与在 3.1.2.3节中定义的授权码流程方式一致。

 

3.2.2.4授权服务器获得用户同意/授权（authorization server obtains end-user consent/authorization）

使用隐式流程时，终端用户同意，与在 3.1.2.4节中定义的授权码流程方式一致。

 

3.2.2.5成功的验证响应（successful authentication response）

使用隐式流程时，验证响应与在 3.1.2.5节中定义的授权码流程方式一致。

使用隐式流程时，所有响应参数添加到重定向的uri片段组件中，在 oauth 2.0有多个响应类型编码实践 (oauth.responses)，除非指定不同的响应模式。

下列参数将从授权终端返回：

access_token

oauth 2.0的access token。该值会返回，除非所使用的 response_type 值是id token。

token_type

oauth 2.0令牌类型的值。该值必须是bearer或另一个与授权服务器协商好了的token_type 值。客户实现这个配置，必须支持 oauth 2.0使用的bearer令牌 (rfc6750)规范。配置仅仅描述了使用bearer令牌。access_token返回情况相同。

id_token

必需的。id token。

state

oauth 2.0状态值。如果state参数是出现在授权请求中。客户端必须确认state值是否等于授权请求时传入的state值。

expires_in

可选的。从响应发生到access token过期时间的秒数。

  oauth 2.0 (rfc6749) 中4.2.2节，当使用隐式流程没有code结果返回。

下面是一个使用隐式流成功响应的非规范示例（换行仅用于显示目的）：

  http/1.1 302 found

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

    access_token=slav32hkkg

    &token_type=bearer

    &id_token=eyj0 ... nij9.eyj1c ... i6ijiifx0.dewt4qu ... zxso

    &expires_in=3600

    &state=af0ifjsldkj

 

3.2.2.6验证错误响应（authentication error response）

当使用隐式流程，授权错误响应与在 3.1.2.6节中定义的授权码流程方式一致。

如果最终用户拒绝了请求，或者终端用户身份验证失败，授权服务器必须在重定向uri的片段组件中返回错误授权响应，oauth 2.0 (rfc6749) 4.2.2.1中定义的和 oauth 2.0多个响应类型编码实践 (oauth.responses)，除非指定不同的响应模式。

 

3.2.2.7重定向uri片段处理（redirect uri fragment handling）

由于响应参数在重定向uri片段值中返回，所以客户端需要让用户代理解析片段编码的值，并将其传递给客户端的处理逻辑以供消费。有关uri片段处理的实现说明，请参阅第15.3节。

 

3.2.2.8验证响应验证（authentication response validation）

使用隐式流程时，客户端必须验证响应如下:

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

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

3、按照3.2.2.11部分的id token验证规则。

4、按照3.2.2.9部分的access token验证规则,除非 response_type 使用的值是 id_token。

 

3.2.2.9 access token验证（access token validation）

要验证带有id token的授权端点发出的access token，客户端应该做到以下几点:

1、用jwa 中指定的哈希算法对access_token的ascii表示进行散列计算，以获得id令牌的jose header的alg头参数。例如，如果alg是rs256，那么使用的散列算法是sha-256。

2、取最左边的一半哈希和base64url编码。

3、id令牌中的at_hash值必须与上一步中生成的值相匹配。

 

3.2.2.10 id token（id token）

id token的内容在第二节中描述。使用隐式流程时，要求以下额外的声明申请id token:

nonce

使用 nonce 声明在隐式流中是必需。

at_hash

access token 散列值。它的值是base64url编码，它是 access_token  值的ascii表示的八进制散列中最左半部分的编码，其中使用的散列算法是在id令牌的jose 标头的alg头参数中使用的散列算法。例如，如果alg是rs256，用sha-256将 access_token  值哈希，然后用最左边的128位和base64url编码它们。at_hash值是一个大小写敏感字符串。

如果带有 access_token值的 id token从授权端点颁发 ，当response_type值是id_token token，这是必需的；当response_type值是id_token时 access_token不会使用。

 

3.2.2.11 id token验证（id token validation）

使用隐式流程时，必须以3.1.3.7中定义授权码流程的同样方式验证id token的内容，除了在本节中指定的差异。

1、客户端必须使用jws的方法来验证 id token 的签名，其算法是在jose header的alg头参数中指定。。

2. 必须检查nonce 声明值，以验证它是否与在认证请求中发送的值相同。客户端应该检查nonce值以防止重放攻击。检测重放攻击的精确方法用于特定客户端的。