据我了解：客户端机密在OAuth1中很重要，但在OAuth2中已不再重要。
但是，似乎像Google和Twitter这样的公司都要求客户秘密来获得访问令牌。
从授权服务器（例如Google，Twitter，Github ...）的角度来看：在以下哪种情况下推荐/（要求）客户端秘密？
仅通过授权码获得访问令牌是否足以要求它？或者当有人使用访问令牌获取资源时是否也应该提交它？
TLDR：在我的情况下：请求“通过授权码获取访问令牌”和请求“通过以下方式获取新的访问令牌和刷新令牌”需要客户端秘密刷新令牌”。当客户端尝试通过访问令牌获取资源时，我还应该要求客户端秘密吗？
答案 0 :(得分：1)
首先，您所有问题的答案都隐藏在RFC-6749 The OAuth 2.0 Authorization Framework中。
您的问题：
在以下哪种情况下推荐/（要求）客户秘密？ 从授权码中获取访问令牌。
请参阅section 4.1.3。它告诉您，如果客户是公开的而不是机密的，则不需要客户机密。同样在section 2.1. Client Types中，机密客户端类型也描述为：
能够维护其凭据的机密性的客户端（例如，在对客户端凭据的访问受到限制的安全服务器上实现的客户端），或者能够使用其他方式对客户端进行安全身份验证。
很快，Google，Twitter或其他大公司的所有客户都是机密的。因此，获取访问令牌时必须使用客户端ID和客户端密码。
第二个问题：
使用刷新令牌获取新的访问令牌。
第一个问题的答案相同。如果客户端是机密的，则需要客户端机密。
第三个问题：
通过访问令牌获取资源。
不需要客户端机密，因为资源服务器使用访问令牌。但是，授权服务器使用客户端密钥对客户端进行身份验证。如果客户端具有访问令牌，则意味着它已经通过身份验证。请参阅section 7. Accessing Protected Resources。
作为总结，如果您具有访问令牌，则无需要求客户端密码即可访问资源。但是，如果您是机密客户端，则必须将客户端ID和客户端机密传递到授权服务器（Google，Twitter等）以获取访问令牌。
答案 1 :(得分：0)
否，当客户端尝试通过访问令牌获取资源时，您不应要求客户端密码。访问令牌应该足够了，但是您需要对其进行验证。
答案 2 :(得分：0)
您询问当客户端尝试通过访问令牌获取资源时是否应请求客户端密码。
您的问题的答案为否，因为访问令牌本身代表授权结果，并且旨在通过应用，授权服务器< / strong>，和资源服务器，而客户端机密应该是仅应用和授权服务器已知的机密。
我还可以告诉您，客户端机密等效于具有用户名和密码，因此您不应将其公开给资源服务器。
使用客户端机密对请求进行身份验证，以便将临时授权码交换为访问令牌，降低了攻击者拦截授权码并自行使用的风险。
访问令牌本身是短暂令牌，这样，所有可嗅探的HTTP访问都将使用即将失效的令牌进行。 Google的OAuth 2 API使用的有效期为5分钟。
此外，在“授权代码授予”流中，访问令牌对用户永远不可见，减少了令牌泄漏给其他人的风险！
〜
让我们看看oauth 2 draft：
3.2.1。客户端身份验证
当向令牌端点发出请求时，机密客户端或其他已颁发客户端凭据的客户端必须按照第2.3节中的说明，通过授权服务器进行身份验证。客户端身份验证用于：
强制执行刷新令牌和授权代码的绑定 至 被签发给的客户。客户端身份验证至关重要 当授权码传输到重定向时 端点通过不安全的通道，或重定向URI具有 尚未完全注册。
通过禁用受感染客户端或从受感染客户端恢复 更改其凭据，从而防止攻击者滥用 刷新令牌被盗。更改一组客户 凭证比吊销一整套证书要快得多 刷新令牌。
- 实施身份验证管理最佳实践，其中 需要定期进行凭据轮换。整套旋转 刷新令牌可能具有挑战性，而单个令牌的旋转 一组客户端凭据非常容易。
在向令牌端点发送请求时，客户端可以使用“ client_id”请求参数来标识自身。
在对令牌终结点的“ authorization_code”“ grant_type”请求中，未经身份验证的客户端务必发送其“ client_id”，以防止其自身不经意地接受发给具有不同“ client_id”的客户端的代码。
这可以防止客户端替换身份验证代码。 （它不为受保护的资源提供额外的安全性。）
第2.3节是对上一节的补充：
2.3。客户端身份验证
如果客户端类型为机密，则客户端和授权服务器将建立适合于授权服务器安全要求的客户端身份验证方法。 授权服务器可以接受满足其安全性要求的任何形式的客户端认证。
通常会向机密客户端颁发（或建立）一组用于通过授权服务器进行身份验证的客户端凭据（例如密码，公钥/私钥对）。
授权服务器可以与公共客户端建立客户端认证方法。但是，授权服务器不得出于识别客户端的目的而依赖于公共客户端身份验证。
客户端在每个请求中不得使用多种身份验证方法。
最后是关于访问令牌的1.4节：
1.4。访问令牌
访问令牌是用于访问受保护资源的凭据。 访问令牌是代表颁发给客户端的授权的字符串。该字符串通常对客户端是不透明的。令牌代表资源所有者授予并由资源服务器和授权服务器强制实施的特定访问范围和持续时间。
令牌可以表示用于检索授权信息或以可验证的方式自包含授权信息的标识符（即，由某些数据和签名组成的令牌字符串）。为了使客户端使用令牌，可能需要超出本规范范围之外的其他身份验证凭据。
访问令牌提供了一个抽象层，用资源服务器可以理解的单个令牌替换了不同的授权结构（例如用户名和密码）。这种抽象使发出的访问令牌比获得令牌的授权更为严格，并且消除了资源服务器了解各种身份验证方法的需要。
根据资源服务器的安全要求，访问令牌可以具有不同的格式，结构和使用方法（例如，密码属性）。访问令牌属性和用于访问受保护资源的方法超出了本规范的范围，并且由伴随规范定义。
答案 3 :(得分：0)
OAuth2，使用客户端机密机制作为授权客户端的一种方法，并且 请求访问令牌的软件。您可能会认为它是一个秘密密码，可以向身份验证服务器证明客户端应用有权代表用户发出请求。 (server sided)
因此，客户机密是客户密码的一种方式。为了使服务器使用客户端，它还必须发送其随附的密码，以证明它可以访问此客户端。例如：请求访问令牌的服务器端应用程序必须知道客户端密码才能获取令牌。这样可以防止未经授权的恶意应用使用令牌来获取有效的访问令牌。
由于客户机密的敏感特性，其他类型的流中不使用客户机密。例如，您不会在JavaScript或桌面应用程序中使用它们，因为它们可以反编译，检查，查看源代码，调试等。服务器在大多数情况下应该是安全的，因此客户端机密不如它在桌面应用程序上，等等。
授权代码流服务器端。
我想想的方式是，如果您使用Web浏览器登录用户，则这是客户端应用程序，我们可以相信登录是执行此操作的用户。
如果它是服务器端语言，并且通信是在应用程序服务器而不是用户计算机上进行的，则它的服务器端将需要发送客户端密码，以验证该服务器实际上是具有以下功能的正确服务器：访问此客户端，并且该呼叫尚未被劫持。
仍然需要客户端机密，并将其与Oauth2一起使用，它仅取决于您使用的授予类型以及其服务器端还是客户端应用程序。
来自评论
我不明白为什么不需要访问密钥来通过访问令牌获取资源
这实际上是一个单独的问题，也是一个好问题，但我将在这里解决。
应用程序一旦具有访问令牌，便不会再次验证。 （除了可能确保其具有正确的权限外）。资源假定访问令牌仍然有效，那么我仍然可以使用它，因此无需再次验证它们。这就是访问令牌短暂存在的原因，它们通常仅有效一小时。行业标准接受，如果您的访问令牌被盗，则黑客可以在非常有限的时间内访问它，因此造成的损失很小。