我有一个移动应用程序，它可以与后端的ASP WebAPI对话
我已经实现了令牌流身份验证(在Taiser指南的帮助下)。
还有一个概念我无法理解：CleintId和ClientSecret。
据我所知，客户端机密(以及客户端id)是指在我的API中阻止对生成令牌的端点的访问。通过这种方式，可以保护端点免受恶意用户试图绕过API并试图通过使用各种输入调用它来获取一些信息的影响。
也就是说，只有掌握秘密的客户端才能启动真实流。就我而言，我只有一个客户端，它是一个移动应用程序，它的秘密存储在一个安全的地方(iOs的KeyChain)。但我读到，这些钥匙链可以很容易地被丢弃，并被剖析以寻找秘密。
因此，我得出的结论是，我可以摆脱整个客户端机密逻辑，主要是将ValidateClientAuthentication()留空：
public async override Task ValidateClientAuthentication(OAuthValidateClientAuthenticationContext context)
{
context.Validated();
return;
}
对我来说，这似乎不是一个安全漏洞，只是现在已经消失的流动中的一薄层。因为，同样，任何持有安装了应用程序的移动设备的恶意用户都很容易泄露客户端机密，一旦他得到了，这一层安全性就毫无用处了。
这些假设是错误的吗？
我可以将ValidateClientAuthentication()方法留空吗？
正如您已经发现的，移动应用程序不能将其凭据保持为私有，因为它们可以从应用程序二进制文件中提取。更不用说，使用代理服务器和Fiddler或Wireshark等流量分析器可以很容易地拦截请求。
使用授权代码流(1)或资源所有者密码证书授予，如果客户端不能安全地存储其证书，则客户端认证不是强制性的，因此不能被视为"认证"；"机密"；应用程序(请参阅https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3和https://www.rfc-editor.org/rfc/rfc6749#section-4.3.2).
对于非机密应用程序，可以安全地调用context.Validated()。
就我个人而言，我尽量避免授予资源所有者密码凭据，因为这显然违背了OAuth2的目的：对密码保密并授予受限授权。如果你的应用程序是完全可信的，那么这应该不会成为问题。
- 在实践中，在不强制客户端身份验证的情况下使用授权代码流是极为罕见的，因为在移动客户端应用程序中使用隐式流更简单，在这种情况下提供了类似的安全级别(更不用说它避免了到令牌端点的第二次往返)