我不确定我是否正确理解了答案和丹的评论。在我看来，这个答案已经陈述了一些正确的事实，但它确实指出了OP所问的问题。如果我理解正确的话，隐式授权流的主要优势是像JS应用程序这样的客户端(例如Chrome扩展)不需要暴露客户端秘密。

丹·塔夫林说:

.．.在授权代码流中，资源所有者永远不需要看到访问令牌，而在javascript客户端中，这是不可避免的。客户端秘密仍然可以从javascript客户端使用授权代码流，然而..

也许我误解了您的意思，但是客户端(在本例中是JS应用程序)必须在授权代码流中将客户端凭证(客户端密钥和秘密)传递给资源服务器，对吗?客户端机密不能“对JS保密”。

除了其他答案，还必须认识到，隐式配置文件只允许一个前端通道流，而不是需要回调授权服务器的授权代码流;这在OpenID Connect(一种建立在Auth 2.0之上的SSO协议)中非常明显，其中隐式流类似于非常流行的SAML POST绑定，而授权代码流类似于不太广泛部署的SAML Artifact绑定

https://www.rfc-editor.org/rfc/rfc6749#page-8

Implicit The implicit grant is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript. In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly (as the result of the resource owner authorization). The grant type is implicit, as no intermediate credentials (such as an authorization code) are issued (and later used to obtain an access token). When issuing an access token during the implicit grant flow, the authorization server does not authenticate the client. In some cases, the client identity can be verified via the redirection URI used to deliver the access token to the client. The access token may be exposed to the resource owner or other applications with access to the resource owner's user-agent. Implicit grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application), since it reduces the number of round trips required to obtain an access token.

在隐式流程中，如果用户的浏览器被损坏(邪恶的扩展/病毒)，那么损坏就可以访问用户的资源，并可以做坏事。

在认证流中，腐败不能，因为它不知道客户端的秘密。

它的存在是出于安全考虑，而不是为了简单。

您应该考虑用户代理和客户端之间的区别:

用户代理是用户(“资源所有者”)与系统其他部分(身份验证服务器和资源服务器)通信的软件。

客户端是在资源服务器上访问用户资源的软件。

In the case of decoupled user-agent and client the Authorization Code Grant makes sense. E.g. the user uses a web-browser (user-agent) to login with his Facebook account on Kickstarter. In this case the client is one of the Kickstarter's servers, which handles the user logins. This server gets the access token and the refresh token from Facebook. Thus this type of client considered to be "secure", due to restricted access, the tokens can be saved and Kickstarter can access the users' resources and even refresh the access tokens without user interaction.

If the user-agent and the client are coupled (e.g. native mobile application, javascript application), the Implicit Authorization Workflow may be applied. It relies on the presence of the resource owner (for entering the credentials) and does not support refresh tokens. If this client stores the access token for later use, it will be a security issue, because the token can be easily extracted by other applications or users of the client. The absence of the refresh token is an additional hint, that this method is not designed for accessing the user resources in the absence of the user.

以下是我的想法:

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

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

因此，关于“我们获得了什么?”的答案是“简单”。