我正在构建一个使用Oauth2.0协议的Web应用程序。我已经使用授权服务器注册了我的应用程序，并收到了我的客户端ID和客户端密码。
我现在正致力于授权部分，特别是使用授权代码授权类型。在该过程中，我使用以下查询参数将用户发送到授权端点：code，client_id，redirect_uri，scope和state。 （省略client_secret）
我正在处理的问题是我收到错误，说我还需要提供client_secret。
我认为这部分不需要client_secret，不应该在此请求中发送，而是在客户端发送授权代码（以及id＆amp; secret）以获取访问令牌时。
所以我的问题是，授权服务器是否需要在授权代码请求中发送客户端密钥是错误的（针对oauth 2协议）？
答案 0 :(得分：1)
我不是百分之百确定这一点，但我自己做了一些研究，我发现这不是一个真正的问题，不能让客户保密＃34;一个秘密。某些事实阻止了恶意能够通过授权规范的唯一可能性：
1。客户需要直接从用户获取授权代码，而不是从服务
获取授权代码即使用户表明他/她信任客户的服务，也是如此 客户端无法通过显示从服务获取授权代码 客户端ID和客户端密钥。相反，客户必须得到 授权代码直接来自用户。 （这通常是通过 URL重定向，我将在稍后讨论。）因此，对于恶意 客户端，仅知道用户信任的客户端ID /秘密是不够的。 它必须以某种方式涉及或欺骗用户授予它 代码，这应该比知道客户端ID /秘密更难。
2。重定向URL使用客户端ID / secret
注册让我们假设恶意客户端以某种方式设法涉及到 用户并让她/他点击＆＃34;授权此应用＆＃34;服务上的按钮 页。这将触发服务的URL重定向响应 用户的浏览器带有授权码。那么 授权代码将从用户的浏览器发送到重定向 URL，客户端应该在重定向URL处侦听 收到授权码。 （重定向URL可以是localhost 我也认为这是“公共客户”的典型方式 接收授权码。）因为此重定向URL已注册 具有客户端ID /机密的服务，恶意客户端不具备 有办法控制授权代码的位置。这个 表示具有您的客户端ID / secret的恶意客户端具有另一个 获取用户授权码的障碍。
//复制hideaki答案的粘贴
OAuth2指定如果您的应用程序是基于服务器端的应用程序（不同于单页应用程序或移动设备）而无法使其源代码可用，则需要将您的机密通知给请求。但是，如果您无法像在本机移动应用程序中那样控制基本代码，则应该寻找其他解决方案。