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