OAuth 2 中隐式授权类型的目的是什么？

Question

我不知道我是否只是有某种盲点或什么，但我已经多次阅读 OAuth 2
规范并仔细阅读邮件列表档案，我还没有找到一个很好的解释来解释为什么隐式授权已经开发了获取访问令牌的流程。与授权码授予相比，它似乎只是无缘无故地放弃了客户端身份验证。这是如何“针对使用脚本语言在浏览器中实现的客户端进行优化”（引用规范）？

两个流程开始时相同（来源：https ://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-22 ）：

1. 客户端通过将资源所有者的用户代理定向到授权端点来启动流程。
2. 授权服务器验证资源所有者（通过用户代理）并确定资源所有者是允许还是拒绝客户端的访问请求。

3. 假设资源所有者授予访问权限，授权服务器使用之前提供的重定向 URI（在请求中或在客户端注册期间）将用户代理重定向回客户端。

4. 重定向 URI 包含授权码（授权码流）

5. 重定向 URI 在 URI 片段中包含访问令牌（隐式流）

这是流量分裂的地方。在这两种情况下，此时的重定向 URI 都指向客户端托管的某个端点：

• 在授权代码流中，当用户代理使用 URI 中的授权代码访问该端点时，该端点上的代码将授权代码与其客户端凭据一起交换为访问令牌，然后它可以根据需要使用该令牌。例如，它可以将其写入网页上的脚本可以访问的网页。
• 隐式流程完全跳过了这个客户端身份验证步骤，只是加载了一个带有客户端脚本的网页。URL 片段有一个可爱的技巧，可以防止访问令牌被过多地传递，但最终结果基本相同：客户端托管的站点提供一个页面，其中包含一些可以获取访问令牌的脚本.

因此我的问题是：跳过客户端身份验证步骤在这里获得了什么？

Answer 1

以下是我的想法：

授权码流中授权码 + 令牌的目的是令牌和客户端密码永远不会暴露给资源所有者，因为它们在服务器到服务器之间传输。

另一方面，隐式授权流适用于完全使用 javascript
实现并在资源所有者的浏览器中运行的客户端。您不需要任何服务器端代码即可使用此流程。然后，如果一切都发生在资源所有者的浏览器中，那么发布验证码和客户端密码就没有意义了，因为令牌和客户端密码仍将与资源所有者共享。包括身份验证代码和客户端密码只会使流程更加复杂，而不会增加任何真正的安全性。

那么关于“获得了什么？”的答案是什么？是“简单”。