我一直在浏览一些关于OAuth2机密和非机密授权流程的文件，即this和RFC。
据我了解，非机密流程不需要client_secret，或者更好的是，您实际上不应该使用client_secret，因为您假设任何人都可以与client_id一起掌握它，从而更容易摆姿势作为客户端应用程序。
所以为了实现非机密流，客户端必须首先使用服务器下发的client_id和客户端生成的状态。然后客户端应该使用服务器返回的代码和相同的状态值。还必须向服务器注册redirect_uri 。
AFAIK（据我所知）这就是区分机密流和非机密流的原因：机密流需要client_secret而非机密流不需要。此外，这就是非机密流程的定义，即缺少client_secret。我的假设是否正确？
第 2.3 节似乎没有具体说明这一点。
相关 Q，来自第 4.1.3 节：
如果客户端类型是机密的或客户端已获得客户端凭据（或分配了其他身份验证要求），则客户端必须向授权服务器进行身份验证，如 第 3.2.1 节所述。
“其他身份验证要求”到底是什么？这不是必须授权的任何客户吗？
机密客户可以保留/保护机密，而非机密客户则不能。
由于非机密客户端无法保密，因此 OAuth 2 规范不允许与此类客户端共享刷新令牌或任何类型的机密信息。这也意味着非机密客户端不能被秘密或私钥信任。
如果没有这样的密钥，客户端就无法通过授权服务器验证自己（即使用给定的 client_id 安全地标识自己）。
即使为非机密客户分配了 client_id，任何人都可以伪装成该 client_id。因此，授权服务器故意限制它将与非机密客户端共享的信息类型。
AFAIK（据我所知）这就是区分机密流和非机密流的原因：机密流需要 client_secret 而非机密流不需要。
区分机密和非机密的是客户端，而不是流程本身（我看到它通常被称为public。）
机密客户是那些有能力存储秘密的客户。带有后端服务器的传统 Web 应用程序属于这一类。由于可以存储秘密，OAuth 流可以在授权流中使用 client_secret。
公共客户端（非机密客户端）是无法对客户端密码保密的应用程序。不使用 client_secrets 的实现，因为它不能被认为是安全的。
“其他身份验证要求”到底是什么？这不是必须授权的任何客户吗？
我认为可能存在一些边缘情况，即资源所有者使用不同的方式来实现客户端凭据，而不是客户端凭据。在大多数情况下，我认为您不必担心这一点。
“其他身份验证要求”可能是指身份验证方法，而不是客户端凭据（客户端 ID 和客户端密码）。例如，客户端身份验证（使用证书）。