Do we need a security signature for the web service response?

这取决于.有几种类型的Web服务API.有些人可能需要严格的安全保障.您可以使用几种类型的API：

(1)完全打开API.假设您有一个博客,您发布有关编写RESTful服务和客户端的信息.您可以根据自己的某个帖子托管一个完整的REST服务,以便人们可以自行调整.你不关心谁叫你的服务,服务返回一些虚拟数据等.它只是一个演示,一个玩具,这里没有安全,没有请求签名,虚无…它只是普通的HTTP调用.

(2)使用API​​密钥进行服务.假设您有一个Web服务,并且您想知道是谁调用它.这种服务需要预先注册,每个想要呼叫您的服务的客户都需要先注册并获取密钥.请注意,注册不是关于身份验证或授权,您只是想知道谁在使用您的API(例如,他们在哪个业务部门,他们拥有多少客户,为什么他们使用您的API等)以便您以后制作根据您获得的数据,对您自己进行一些分析,然后根据您的某些(某种营销方式)做出决定.

这个API密钥没有任何秘密.它只是某种UUID,是区分呼叫的最基本方式.这又涉及仅使用密钥作为附加请求参数的普通HTTP调用.

(3)使用API​​密钥和密钥进行服务.这与数字(2)类似,但您需要绝对确保调用来自提供某些API密钥的客户端.您需要这个,因为您可能想要向客户收取他们使用您的服务的费用.你想确保这些电话实际上来自那个客户,而不是那些可能想要对客户账单过高的恶意用户.

因此,客户端使用它的密钥进行识别,并使用密钥对请求进行签名,以实际保证其身份.这也可以是普通的HTTP调用,其中密钥和签名作为附加请求参数.

(4)数据“篡改安全”的Web服务.对于上面的数字(1),(2)和(3),我没有考虑任何消息安全问题,因为大多数API不需要它.交换的内容不是保密的,也不是保护的重要内容.但有时虽然数据不是保密的,但您需要确保它在运输过程中没有被篡改.

假设您是构建某种产品的商店的所有者,并且您希望在某些合作伙伴网站上宣传您的产品.您公开了包含产品详细信息的服务,您的合作伙伴只需使用此数据在其网站上显示您的产品详细信息.每个人都知道你正在建造什么产品,所以你不需要隐藏它,但你对你的竞争对手试图破坏你是偏执的,所以你想避免它们拦截
请求并在结果的回复中乘以10所有价格,以吓跑潜在买家.

上面的数字(3),虽然使用签名部分作为证明呼叫者身份的方式,但也确保请求没有被篡改(如果签名不匹配,服务器将拒绝请求).因此,如果您需要确保原始回复,您也可以签署回复.

为此,该服务可以为客户端提供API密钥和两个密钥.客户端使用一个密钥来签署他们的请求,而客户端使用第二个密钥来验证响应的签名(使用服务器的唯一密钥不是那么安全,因此服务器发出服务器每个客户特有的密钥).

但这有一个弱点：您需要相信您的合作伙伴,他们确实会在显示网站上的信息之前验证响应签名,而不是直截了当地显示它. Paranoid因为你想要防止这种情况,为此你需要HTTPS.

正如@SilverlightFox所说,这证明了响应的有效性.由于数据是加密的,因此数据没有受到限制.客户端不需要额外的步骤来验证响应签名,因为该验证已经在较低(传输)级别完成.

(5)安全服务.现在我们达到了最后一种服务,其中数据实际上是保密的. HTTPS是这些服务的必需品. HTTPS确保数据保密,在传输过程中不进行调整,识别服务器,并且如果使用客户端证书,还可以识别客户端.

因此,总而言之,这取决于您拥有的服务类型.