我做了一些谷歌搜索，但有点被信息量所淹没。到目前为止，我一直在考虑为每个API调用请求一个有效的md5哈希，但我意识到劫持这样一个系统并不困难。你们愿意为我提供一些可以帮助我搜索的链接吗？感谢。
答案 0 :(得分：2)
首先，考虑OAuth。它现在已成为基于Web的API的标准。
其次，其他一些潜在资源 -
一些不错的博客文章：
上一个问题：
答案 1 :(得分：1)
我想在这个问题上添加一些澄清信息。 “使用OAuth”答案是正确的，但也是加载的（鉴于规范很长，不熟悉它的人通常希望在看到它后自杀）。
在这里设计安全的REST API时，我写了一篇关于如何从无安全性到基于HMAC的安全性的故事式教程：
这最终基本上被称为“双腿OAuth”;因为OAuth最初用于验证客户端应用程序，所以流程分为三部分，涉及身份验证服务，用户盯着屏幕以及想要使用客户端凭据的服务。
两条腿OAuth（以及我在该文章中深入介绍的内容）旨在让服务API在彼此之间进行身份验证。例如，这是Amazon Web Services用于所有API调用的方法。
gist 是指通过HTTP的任何请求，您必须考虑攻击媒介，其中一些恶意的中间人正在录制和重播或更改您的请求。
例如，你向名为'bob'的/ user / create发出一个POST，中间人可以向/ user / delete发出一个名为'bob'的POST只是为了讨厌。< / p>
客户端和服务器需要某种方式相互信任，唯一可能的方法是通过公钥/私钥。
你不能只是来回传递公钥/私钥NOR你可以简单地提供一个用私钥签名的唯一令牌（这通常是 大多数人所做的事情并认为这使得他们虽然这将确定来自真实客户端的原始请求，但它仍然会使评论的参数保持可变。
例如，如果我发送： /chargeCC?user=bob&amt=100.00&key=kjDSLKjdasdmiUDSkjh
其中密钥是我的私钥签名的公钥，只有中间人可以拦截此调用，并以“amt”值“10000.00”重新提交给服务器。 / p>
关键是你必须包括你在哈希计算中发送的所有参数，所以当服务器获得它时，它会通过重新计算其侧面的相同哈希值来重新检测所有值。
提示：只有客户端和服务器知道私钥。
这种验证方式称为“HMAC”;它是验证请求内容的校验和。
因为哈希生成非常敏感，并且必须在客户端和服务器上完全相同完全才能获得相同的哈希值，所以对于所有值应该如何应该有超严格的规则合并。
例如，当您尝试使用SHA-1对它们进行签名时，这两行提供了非常不同的哈希值： / chargeCC＆安培;用户鲍勃=＆安培; AMT = 100 / chargeCC＆安培; AMT = 100安培;用户鲍勃=
很多OAuth规范用于描述精确组合方法的难以理解的细节，使用“自然字节排序”等术语和其他非人类可读的垃圾。
这很重要，因为如果你得到的值组合错误，客户端和服务器就无法正确地审查彼此的请求。
您也无法使用快捷方式，只需将所有内容连成一个巨大的字符串，亚马逊就使用AWS签名版本1和turned out wrong进行了尝试。
我希望所有这些都有所帮助，如果你被困住，请随时提问。