为什么在许多 Web API 中同时使用密钥和秘密？答案

【问题标题】：Why both a key and a secret in many web APIs?为什么在许多 Web API 中同时使用密钥和秘密？
【发布时间】：2012-09-25 15:25:47
【问题描述】：

许多 Web REST API 为您提供密钥和秘密。当您向 API 发出请求时，您必须将它们都返回。这个有什么用？一个还不够吗？

我唯一能找到的是对How to use a key and secret for verification? 的回答，该回答说服务器可以使用密钥廉价地散列您的域（或者可能是用户名或其他内容）并检查它是否与密钥匹配。真的有用吗？

（奖励将是这种机制的名称。它似乎与我在 stackoverflow/wikipedia 上找到的关于加密机制的内容不匹配。）

更新：答案和几个 cmets 告诉我，在请求中同时传递密钥和相应的密钥是一个坏主意。它确实在实践中发生，但它仍然是一个坏主意。

【问题讨论】：

请阅读：thebuzzmedia.com/… 这应该让您了解为什么同时使用密钥和秘密。
方便的资源！但是...我询问了发送秘密和密钥的 API，因此没有任何 HMAC 内容。像raven.readthedocs.org/en/latest/config/… 和 oauthing 到 github 的初始阶段：app id 和 app secret 都在同一个请求中。
好吧，这看起来对我来说并不安全。请注意，我不是安全专家，但根据我的理解，我认为任何请求都不应该发送密钥。它应该离线传送给您（即通过单独的邮件甚至在纸上），并且应该用于散列您的请求，但永远不要发送到任何地方。
看看我对这个问题的回答是否有帮助：stackoverflow.com/questions/1482472/…

标签： rest

【解决方案1】：

您将谈论HMAC Authentication
您提及的key 类似于您的帐户名，它不会直接用于任何身份验证。 secret 将严格离线共享，并且永远不会发回。在 HMAC 身份验证中，您发送回一个签名，该签名源自服务器和客户端之间商定的一组参数，当然secret 是其中的一部分。

【讨论】：

好吧，我说的是我看到了几个例子，其中密钥确实被发送了。例如，在第 2 步中的 developer.github.com/v3/oauth 上，我看到一个客户端 ID 和一个客户端密码通过网络传输。
@ReinoutvanRees：永远不要将任何 ol' 实现作为规则。换句话说：虽然该实现可能同时发送密钥和秘密，但这并不意味着该实现实际上是根据它应该做的事情来做......请注意，并不是说他们没有做他们应该做的事情，只是你不应该将（实施的）示例作为规范。总是回到源头（规范、标准、......）而不是某人的解释和随后的实施。误解和错误/错误确实会蔓延。
@ReinoutvanRees：出于同样的原因，您永远不应该在不了解代码到底在做什么的情况下复制/粘贴代码（然后您可以自己编写）。
你是对的。这就是我试图理解它的原因。并且为了防止在我的实现中留下巨大的漏洞，以防我决定自己编写:-) 感谢所有信息。