RESTful API 认证模式

“所有人都觉得编写客户化认证协议是有必要的”， George Reese 说，这也是他在使用云提供者和 SaaS 提供商们提供的 API 进行编程的过程中的领悟之一。在一篇博文中他提出了一组旨在适用于任何 REST 的认证需求的标准。

George 曾开发过各种各样的 Web 服务 API，他发现每一种 API 都需要一种特定的认证机制。

我已经疲于在这种事情上上浪费脑细胞了，比如某提供商 A 的要求是在 URL 编码之前或之后为查询字符串进行签名。我也早已厌倦了提供商们诸如要求使用用交互用户的凭证进行 API 调用的这样的认证要求了。

他勾勒了 REST API 的认证机制的设计规则。他说，“让我们变得简单些：如果你不加密 API 调用，你甚至连假装安全都做不到”。

1。 所有的 REST API 调用必须运行在使用可信的 CA 签名过的证书的 HTTPS 之上。所有客户端与服务端交互之间必须要验证服务端证书。

通过使用由可信机构签名的证书，SSL 可以保护你免受“中间人”攻击。中间人攻击的手段是在客户端和服务端之间插入一个代理进而窃听“加密的”通信。

如果你不验证服务端的 SSL 证书，你就无法知道谁在接收你的 REST 查询请求。

2。所有的 REST API 调用应该通过专门的 API 密钥完成，该密钥由标识成分和共享密钥两部分组成。系统必须允许一个指定客户端拥有多个活动的 API 密钥并能方便地让个别密钥失效。

前半部分的重点是发起 REST 请求的系统不应是某个交互用户……REST 认证的的是程序而不是人，它支持比人使用的用户名 / 密码更强大的认证手段。

后半部分的意思是，每个 REST 服务器应该支持每个客户端拥有多个 API 密钥。该需求使得孤立潜在危害和当危害发生时解决问题更为简单。[…] 当应用被破坏时，你也需要一种完善的方式铺开替换的 API 密钥。

3. 所有的 REST 查询必须通过签名令牌签名的方式进行认证，该过程通过对按小写的字母顺序排序的查询参数使用私钥进行签名。签名应在查询字符串的 URL 编码前完成。

换言之，你不能将共享密钥作为查询串的一部分进行传递，而应使用它进行签名。签名后的查询串看起来应该是这样的：

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

被签名的串是“ “/object?apikey=Qwerty2010&timestamp=1261496500” ”，而签名是应用 API 密钥的私钥所得到的 HMAC-SHA256 哈希值。

他承认在大部分类 REST 的 RESTFul API 方案中，认证几乎肯定被看作是次要的问题。然而，在文章的结论中他建议读者“最好参照别人的例子，而不应自创认证模式”。

InfoQ 的读者们，请别吝惜你的意见。最初的博文地址是： O’Rielly 社区博客.

查看英文原文： RESTful API Authentication Schemes