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

我想Will Cain回答了这个问题，他说:“出于同样的原因，客户凭证没有任何好处。(任何客户端都可以尝试使用这个流程。)”还要考虑隐式流的redirect_uri可能是“localhost”——没有从授权服务器对隐式流进行回调。由于无法预先信任客户端，用户必须批准用户声明的发布。

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

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

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.

虽然隐式授权的设计是为了支持不能保护客户端机密的应用程序，包括客户端JavaScript应用程序，但一些提供商正在实现一种替代方案，使用没有客户端机密的授权代码。OAuth 2.0 IETF RFC-6749于2012年发布，目前的建议是2017年的一些最新讨论。

关于IETF OAuth邮件列表的2017年讨论可从以下实现者获得:

红帽:https://www.ietf.org/.../oauth/current/msg16966.html 德国电信:https://www.ietf.org/.../oauth/current/msg16968.html 智能健康IT: https://www.ietf.org/.../oauth/current/msg16967.html

点击此处阅读更多信息:

https://aaronparecki.com/oauth-2-simplified/ https://aaronparecki.com/oauth-2-simplified/#single-page-apps

Implicit was previously recommended for clients without a secret, but has been superseded by using the Authorization Code grant with no secret. ... Previously, it was recommended that browser-based apps use the "Implicit" flow, which returns an access token immediately and does not have a token exchange step. In the time since the spec was originally written, the industry best practice has changed to recommend that the authorization code flow be used without the client secret. This provides more opportunities to create a secure flow, such as using the state parameter. References: Redhat, Deutsche Telekom, Smart Health IT.

从隐式授权转移到没有客户端机密的认证代码也提到了这里的移动应用:

https://aaronparecki.com/oauth-2-simplified/#mobile-apps

我刚刚看到一些关于OAuth 2.0的文章。作者指出隐式流背后的原因是JS应用程序在那里的请求非常有限:

如果您想知道为什么隐式类型包含在OAuth 2.0中，那么 解释很简单:同源策略。那时，正面 应用程序不允许向不同的主机发送请求 使用代码获取访问令牌。今天我们有CORS (Cross-Origin) 资源共享)。

https://medium.com/securing/what-is-going-on-with-oauth-2-0-and-why-you-should-not-use-it-for-authentication-5f47597b2611