为什么授权请求在 OAuth2 授权代码授予流程中不需要客户端密码？答案

【问题标题】：Why does Authorization Request not require client secret in OAuth2 Authorization Code Grant Flow?为什么授权请求在 OAuth2 授权代码授予流程中不需要客户端密码？
【发布时间】：2018-04-03 12:35:36
【问题描述】：

在 RFC 6749 中所述的 OAuth2.0 Authorization Code Grant 中，令牌请求需要根据 sec4.1.3 的客户端密码；但是，授权请求不是根据sec4.1.1。

有人知道为什么吗？似乎对授权和令牌请求都使用客户端密码可以使过程更加安全。

【问题讨论】：

标签： oauth oauth-2.0 authorization

【解决方案1】：

它们是不同的，因为它们是两种不同类型的请求。 4.1.1

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 主机：server.example.com

用于向用户显示实际的同意屏幕。

一旦用户接受，代码就会被交换为访问令牌

 >HTTP/1.1 302 Found
 Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
           &state=xyz

不需要任何秘密，因为您目前处于文档的授权代码部分。

4.1。授权码授予

授权码授权类型用于同时获取访问权限令牌和刷新令牌，并针对机密客户端进行了优化。由于这是一个基于重定向的流程，客户端必须能够与资源所有者的用户代理（通常是网络浏览器）并能够接收传入的请求（通过重定向）来自授权服务器。

授权代码有时被称为隐式流，因为所需的访问令牌被发送回客户端应用程序，而无需授权请求令牌。这使得整个流程非常容易，但也不太安全。由于客户端应用程序（通常是在浏览器中运行的 JavaScript）不太受信任，因此不会返回用于长期访问的刷新令牌。将访问令牌返回给 JavaScript 客户端还意味着您的基于浏览器的应用程序需要特别小心——想想可能会将访问令牌泄漏到其他系统的 XSS（跨站脚本）攻击。

基本上，用户隐式信任他们的电脑，因此实际上不需要客户端密码验证步骤。只有用户无权访问服务器的服务器端应用程序才需要客户端密码，因此服务器必须自行验证。

【讨论】：

谢谢，@DalmTo。我想我明白了。正如您所引用的，既然 authZ 请求是 a redirection-based flow,，那么简单地输入 client_secret 意味着将秘密暴露给资源所有者。
Authorization Code is sometimes refereed to as the Implicit flow, 不，事实并非如此。它们是两种不同的流。事实上，出于安全原因，现在不推荐使用隐式流 (tools.ietf.org/html/…)；你在回复中提到了 XSS，还有其他的。授权码流程未弃用；使用授权码流时，建议大家使用PKCE（tools.ietf.org/html/…）。