首先：我不太确定问题的标题，所以如果您有更好的主意，请随时告诉（：
我想了解提供 API 并希望您作为开发人员使用某些 API-Key 的服务（如 Twitter 或 co）阻止第三方获取该密钥的最佳实践示例。
我会用不好的例子来解释我的问候：
据我所知，Twitter 和 FB 要求您使用 API-Keys 进行 API 请求。这对于服务器端应用程序来说很好，但是一旦您从 Web 应用程序或桌面应用程序提交您的密钥，其他人就可以看到该密钥。
因为您必须提交该密钥，所以将其超级安全地存储在您的应用程序中没有多大意义。对于请求，它必须是简单的。
您可能会做的一件事是托管您自己的 Web 服务或包装器，它附加密钥服务器端，然后将该请求路由到目标服务器。
但是，如果 Twitter/或您使用的任何服务限制每个 IP 的 API 请求或想要创建基于 IP 的统计信息，则这是不可能的。
总结一下：如果我能够为其他人创建 API 并且不希望他们使用 SSL，那么我必须确保他们的密钥是安全的并且不容易被盗的？
最佳做法是：
基本思想。为每个单独的用户帐户创建一个 API 密钥（一个 128 位对称密钥）。此密钥需要安全地存储在服务器上，同时也安全地存储在用户的客户端上。
对于客户端发出的每个请求，添加一个额外的请求参数，该参数在整个请求上具有“签名”。“签名”应计算为 S = MAC( K , R )，其中K是 API 密钥，R是整个请求，包括所有请求参数。这里的MAC应该是一种安全的消息认证码算法，比如AES-CMAC或者SHA1-HMAC。
计算签名并将其附加到请求是客户的责任；服务器有责任验证签名并忽略任何签名无效的请求。您可能还需要在请求中包含一个附加参数，以标识发出请求的用户帐户。
这将提供请求的身份验证，但不提供机密性或重放预防，并且客户端确实会收到来自服务器的经过身份验证的响应。
我建议通过 https（不是 http）发送所有请求。这将为许多棘手的情况提供额外的安全级别。这样做对性能的影响比你想象的要小——SSL 的性能开销比大多数人想象的要小——所以不要因为性能原因而放弃这个想法，除非你实际测量了性能开销并发现它是不可接受的.
需要注意的其他事项。 您可能希望使用一次性随机数，以防止重播经过身份验证的请求。我建议使用加密强度随机值（至少 64 位长）。如果您使用 https，则这是不必要的。
确保您的服务器是为防御主机参数污染 (HPP) 攻击而编写的。例如，它应该拒绝具有相同类型的多个请求参数的任何请求（例如，http://example.com/foo.html?name=x&name=y）。此外，在编写服务器代码时，根据收到的请求创建新请求时要小心。例如，在处理每个请求之前，您的服务器代码可能会验证请求仅带有预期的参数列表，仅此而已；在处理请求之前丢弃重复的参数或意外的参数。
如果您决定使用消息身份验证代码保护多个值，请注意连接缺陷。