它可以归结为:如果用户正在运行一个基于浏览器或“公共”(JavaScript)的web应用程序，没有服务器端组件，那么用户隐含地信任该应用程序(以及它运行的浏览器，可能与其他基于浏览器的应用程序……)

没有第三方远程服务器，只有资源服务器。授权代码没有任何好处，因为除了浏览器之外，没有其他代理代表用户。出于同样的原因，客户端凭证没有任何好处。(任何客户端都可以尝试使用此流。)

然而，这对安全的影响是重大的。从https://www.rfc-editor.org/rfc/rfc6749 #节- 10.3:

当使用隐式授权类型时，访问令牌将在中传输 URI片段，这可能会将其暴露给未经授权的一方。

从https://www.rfc-editor.org/rfc/rfc6749 #节- 10.16:

资源所有者可以自愿将对资源的访问委托给 向攻击者的恶意客户端授予访问令牌。这可能 可能是因为网络钓鱼或其他借口…

以下是我的想法:

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

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

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

它可以归结为:如果用户正在运行一个基于浏览器或“公共”(JavaScript)的web应用程序，没有服务器端组件，那么用户隐含地信任该应用程序(以及它运行的浏览器，可能与其他基于浏览器的应用程序……)

没有第三方远程服务器，只有资源服务器。授权代码没有任何好处，因为除了浏览器之外，没有其他代理代表用户。出于同样的原因，客户端凭证没有任何好处。(任何客户端都可以尝试使用此流。)

然而，这对安全的影响是重大的。从https://www.rfc-editor.org/rfc/rfc6749 #节- 10.3:

当使用隐式授权类型时，访问令牌将在中传输 URI片段，这可能会将其暴露给未经授权的一方。

从https://www.rfc-editor.org/rfc/rfc6749 #节- 10.16:

资源所有者可以自愿将对资源的访问委托给 向攻击者的恶意客户端授予访问令牌。这可能 可能是因为网络钓鱼或其他借口…

隐式授权允许使用GET从授权端点获取令牌。这意味着授权服务器不必支持CORS。

如果这不是一个问题，并且没有其他与授权服务器不灵活相关的问题(例如，出于某种原因，刷新令牌不是可选的)，那么授权代码流是首选的，即使是对于公共客户端，根据最近的行业趋势和至少这个(当前)官方草案实例。

从历史上看，实现隐式流还有其他原因，但目前似乎它们被授权代码授予提供的安全优势所超越，包括:

为机密客户端通过反向通道交付和使用令牌的选项 没有在公共客户端的浏览器历史中公开令牌 在发布令牌之前中断未经授权的流-使用PKCE，用于“各种OAuth客户端”

除了其他答案，还必须认识到，隐式配置文件只允许一个前端通道流，而不是需要回调授权服务器的授权代码流;这在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.