OAuth2双方客户端凭据流和“机密”客户端 - 如何隐藏client_secret

Question

我有一个REST API，它接受基本上是匿名的调查响应，即来自未经过身份验证的用户。我的组织希望允许一些（可能是12个）合作伙伴开发客户端应用程序来收集响应并将其发送到api。我希望api验证这些客户端，即验证客户端是我们授权的12个客户端之一。我计划使用OAuth 2“客户端凭据”流程，为每个客户端提供唯一的client_id和client_secret。客户端将使用其client_id和client_secret请求令牌，然后在后续的api调用中使用该令牌。客户端将被要求是https基于服务器的应用程序，可以保持client_secret隐藏 - 即“机密客户端”用于OAuth2规范（https://tools.ietf.org/html/rfc6749#page-14）。

但是client_secret真的可以在客户端凭据流中保密吗？据我了解，传递client_id和client_secret的推荐方法是HTTP Basic auth头中的base64编码值。如果攻击者浏览该客户端应用程序以提交suryvey响应，他不能只使用浏览器开发工具查看base64编码的client_id：client_secret值，解码它，并使用相同的client_id和client_secret构建自己的应用程序吗？

我知道我可以使用CORS将基于浏览器的请求限制为来自12个授权域的请求。所以我想我真的在询问非浏览器攻击，试图冒充其中一个授权客户。

所以我的问题：

1. 我是对的，这个可见的base-64编码版本的client_id：client_secret在一个vanilla OAUth2 2-legged客户端凭证流中提出了一个漏洞（即没有最终用户授权客户端）？
2. 我认为我们可以使用签名令牌方法（可能是JWT），而不是客户端凭据，类似于所描述的here，其中：
   • 客户端服务器和api服务器具有共享私钥。
   • 客户端生成令牌，使用私钥的哈希加上时间戳对其进行签名。客户端在api请求中发送该令牌，以及用于散列的“请求时间戳”。
   • api服务器使用私钥和“请求时间戳”验证令牌以验证散列。服务器仅接受最近的时间戳（例如，在最后2秒内）以防止重放攻击。
   • 这听起来像是一种合理的做法吗？
3. 有人能想到另一种方法将api限制为只授权客户吗？