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值以防止重放攻击。检测重放攻击的精确方法用于特定客户端的。