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×tamp=1261496500" ”，而签名是应用API密钥的私钥所得到的HMAC-SHA256哈希值。
他承认在大部分类REST的RESTFul API方案中，认证几乎肯定被看作是次要的问题。然而，在文章的结论中他建议读者“最好参照别人的例子，而不应自创认证模式”。
InfoQ的读者们，请别吝惜你的意见。最初的博文地址是：O’Rielly社区博客.
查看英文原文： RESTful API Authentication Schemes