我正在构建一个使用 Oauth2.0 协议的网络应用程序。我已经在授权服务器上注册了我的应用并收到了我的客户端 ID 和客户端密码。
我现在正在研究授权部分，特别是使用授权代码授权类型。在该过程中，我使用以下查询参数将用户发送到授权端点：代码、client_id、redirect_uri、范围和状态。 （省略client_secret）
我正在处理的问题是我收到一条错误消息，说我还需要提供 client_secret。
我的印象是这部分不需要 client_secret 并且不应该在此请求中发送，而是在客户端发送授权代码（连同 id 和密钥）以获取访问令牌时发送。
所以我的问题是，授权服务器要求在授权码请求中发送客户端密码是错误的（违反 oauth 2 协议）吗？
【问题讨论】：
我不是 100% 确定这一点，但我自己做了一些研究，我发现不将“客户秘密”保密并不是一个真正的问题。一些事实阻止了恶意者能够通过授权规范的唯一可能性：
1。客户端需要直接从用户获取授权码，而不是从服务获取
即使用户表明他/她信任客户端的服务， 客户端无法仅通过显示从服务中获取授权码 客户端 ID 和客户端密码。相反，客户必须获得 直接来自用户的授权码。 （这通常由 URL 重定向，我稍后会谈到。）所以，对于恶意 客户端，仅知道用户信任的客户端 ID/秘密是不够的。 它必须以某种方式涉及或欺骗用户才能授予它授权 代码，这应该比只知道客户端 id/secret 更难。
2。重定向 URL 已使用客户端 id/secret 注册
让我们假设恶意客户端以某种方式设法让 用户并让她/他单击服务上的“授权此应用程序”按钮 页。这将触发来自服务的 URL 重定向响应到 带有授权码的用户浏览器。然后 授权码将从用户的浏览器发送到重定向 URL，并且客户端应该正在监听重定向 URL 到 收到授权码。 （重定向 URL 可以是 localhost 也是，我认为这是“公共客户”的典型方式 接收授权码。）由于此重定向 URL 注册于 具有客户端 id/secret 的服务，恶意客户端没有 有一种方法可以控制授权码的提供位置。这 意味着具有您的客户端 ID/秘密的恶意客户端有另一个 获取用户授权码的障碍。
// 复制粘贴隐藏答案
OAuth2 指定如果您的应用程序是基于服务器端的应用程序（不同于单页应用程序或移动应用程序）且不提供其源代码，则您需要在请求中告知您的秘密。但是，如果您无法控制基本代码，例如在原生移动应用程序中，您应该寻找其他解决方案。
【讨论】：
client_secret 应该不在授权请求中，这是一个重定向，因此参数在用户客户端（浏览器）中可见。哪个系统可以做到这一点？如果是 Kong，Kong 的授权端点并不是真正打算在浏览器中使用，而是来自授权服务器的自定义实现。