我不知道是否只是我有某种盲点，但我已经多次阅读了OAuth 2规范并查看了邮件列表归档，但我尚未找到一个好的解释为什么开发了Implicit Grant flow以获取访问令牌。与Authorization Code Grant相比，它似乎只是放弃了客户端身份验证，没有非常引人注目的原因。这个“针对在使用脚本语言实现的浏览器中的客户端进行优化”（引用规范）是如何实现的呢？
这两种流程都是从相同的起点开始的（来源：https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-22）：
1. 客户端通过将资源所有者的用户代理重定向到授权终端点来启动流程。 2. 授权服务器通过用户代理对资源所有者进行身份验证，并确定资源所有者是否授予或拒绝客户端访问请求。 3. 假设资源所有者授予访问权限，则授权服务器使用之前提供的重定向URI（在请求或客户端注册期间）将用户代理重定向回客户端。
重定向URI分别包含授权代码（Authorization code flow）和访问令牌（Implicit flow）。
这里是流程分叉的地方。在这两种情况下，此时重定向URI指向客户端托管的某个端点：
1. 在Authorization code flow中，当用户代理使用URI中的Authorization code命中该端点时，该端点上的代码将授权代码与其客户端凭据交换以获取访问令牌，然后可以根据需要使用它。例如，它可以将其写入页面，页面上的脚本可以访问它。 2. Implicit flow完全跳过了此客户端身份验证步骤，并仅加载带有客户端脚本的Web页面。这里有一个URL片段的巧妙技巧，使访问令牌不会被传递太多次，但最终结果基本相同：客户端托管的站点提供了一个带有一些脚本的页面，可以抓取访问令牌。因此我的问题是：跳过客户端认证步骤有什么收获？
这两种流程都是从相同的起点开始的（来源：https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-22）：
1. 客户端通过将资源所有者的用户代理重定向到授权终端点来启动流程。 2. 授权服务器通过用户代理对资源所有者进行身份验证，并确定资源所有者是否授予或拒绝客户端访问请求。 3. 假设资源所有者授予访问权限，则授权服务器使用之前提供的重定向URI（在请求或客户端注册期间）将用户代理重定向回客户端。
重定向URI分别包含授权代码（Authorization code flow）和访问令牌（Implicit flow）。
这里是流程分叉的地方。在这两种情况下，此时重定向URI指向客户端托管的某个端点：
1. 在Authorization code flow中，当用户代理使用URI中的Authorization code命中该端点时，该端点上的代码将授权代码与其客户端凭据交换以获取访问令牌，然后可以根据需要使用它。例如，它可以将其写入页面，页面上的脚本可以访问它。 2. Implicit flow完全跳过了此客户端身份验证步骤，并仅加载带有客户端脚本的Web页面。这里有一个URL片段的巧妙技巧，使访问令牌不会被传递太多次，但最终结果基本相同：客户端托管的站点提供了一个带有一些脚本的页面，可以抓取访问令牌。因此我的问题是：跳过客户端认证步骤有什么收获？