如果你使用过阿里云的云产品的API或者API网关，你会发现API签名是件比较难以搞定的事情。为什么要搞这么复杂？

他们是怎么签名的

两种类型的API都如何签名，点击查看详细API网关签名、云产品签名（以Ecs为例）

看完签名文档，你会发现，两种API都是需要用户，使用密钥对排序后的请求全部内容（注意：是全部内容，包括请求的Method、HEADERS、URL、QueryString、BODY）计算签名串，并将签名串放入请求，供验证请求身份。还需要在请求中增加TimeStamp和Nonce内容。

为什么这样设计

搞这么复杂？是产品经理脑残么？还是有意炫耀技术高深？其实不然，每个API操作都是用户与系统的交互过程。既然是系统交互，那么就少不了身份认证，也就是系统要识别请求的来源是否合法，应该给予什么样的操作权限。所以，在API安全中的一个关键词就是“请求认证”。

这个认证和我们在页面上输入一个用户名、密码不同，因为用户实在我们提供的网站上输入的用户名密码。

防密钥泄漏

使用这种签名，只需要API的调用者在API的请求中增加签名，而无需传递密钥。

防篡改

防篡改，是是防止有人恶意篡改请求数据以达到恶意攻击的目的。

原理：签名针对的是所有的请求内容，所以即使请求被拦截，修改任何值都会造成签名失败，因此请求无法被篡改。

防重放攻击

我们先看看重放攻击的概念：攻击者发送一个目的主机已接收过的包，特别是在认证的过程中，用于认证用户身份所接收的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的安全性。这种攻击会不断恶意或欺诈性地重复一个有效的数据传输，重放攻击可以由发起者拦截并重复发该数据到目的主机进行。

所以两种API都在签名中增加了TimeStamp和Nonce避免黑客截获请求后重放攻击。

• Timestamp：时间戳，在±15分钟内有效
• Nonce：请求的唯一标识，在±15分钟内只允许使用一次

原理：

如此复杂怎么用

别急，复杂确实复杂了一点，但其实是为了API的安全，安全和易用本身就是一堆矛盾体，我们要从中找到平衡点。

为此，API网关和云产品都提供了大量的SDK、调用Demo来降低用户实现签名的难度。API网关、云产品

最后

您可能还想一个问题，无论API的签名如何安全，都需API的调用方有一个密钥，但若是纯前端的js、手机app来调用API，密钥写入JS、APP？显然会有安全问题，应该如何做？也许您看看这个《OpenID Connect 认证》应该能够找到答案。