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

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

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

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

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客户端时，隐式授权更容易实现。但我认为这种看法是错误的。如果您使用的JavaScript客户端直接通过XMLHttpRequest请求受保护的资源，隐式授权是您唯一的选择，尽管它不太安全

授权码授权提供了额外的安全性，但它仅在web服务器请求受保护资源时才有效。由于web服务器可以存储访问令牌，因此访问令牌暴露在Internet上的风险较小，并且可以发出持续较长时间的令牌。由于web服务器是受信任的，所以可以给它一个“刷新令牌”，所以当旧的访问令牌过期时，它可以获得一个新的访问令牌。

But -- and this is a point that's easy to miss -- the security of the Authorization code flow works only if the web server is protected with a session, which is established with user authentication (login). Without a session, an untrusted user could just make requests to the web server, using the client_id, and it would be the same as if the user had the access token. Adding a session means that only an authenticated user can access the protected resources. The client_id is just the "identity" of the JS webapp, not authentication of said webapp.

这还意味着您可以在OAuth令牌过期之前结束会话。没有使访问令牌失效的标准方法。但是如果你的会话过期了，访问令牌就没用了，因为除了web服务器没有人知道它。如果一个不受信任的用户获得了对会话密钥的访问权，那么他们只能在会话有效期间访问受保护的资源。

如果没有网络服务器，你必须使用隐式授权。但这意味着访问令牌暴露在Internet上。如果一个不受信任的用户获得了它的访问权限，他们可以使用它直到过期。这意味着他们将拥有比授权代码授予更长的访问时间。因此，您可能需要考虑让令牌提前过期，并避免授予对更敏感资源的访问权。

*EDIT: More recently, people are recommending that you avoid using the Implicit grant, even on web apps without a server. Instead you can use the Authorization Code grant configured with an empty secret, along with PKCE. The auth-code grant avoids storing the access token in your browser history, and PKCE avoids exposing it if someone hijacks the redirect URL to steal the auth code. In this case you would need the server to avoid returning a refresh token, since your client probably can't store it securely. And it should issue an access token with the same limitations mentioned above.

虽然隐式授权的设计是为了支持不能保护客户端机密的应用程序，包括客户端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

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

以下是我的想法:

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

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

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

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

丹·塔夫林说:

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

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