REST API的身份验证小结

这几天在写APP的web服务端接口，API是之前就已经在写的restful风格。这几天一直在研究token在客户端和服务端交互之间的应用，刚看到一篇文章，感觉和这几天的整理不谋而合。

全文太长，就取几个重点来发。

1. All REST API calls must take place over HTTPS with a certificate signed by a trusted CA. All clients must validate the certificate
   before interacting with the server.

译：所有REST API请求都必须通过加密的HTTPS协议来传递，加密所用的证书应由一个trusted CA (certificate
authority)签发。所有客户端必须验证服务器端的身份证书，然后才开始进行会话。

首先的确这一点是之前没有考虑到的，之前一直在想服务端如何验证客户端的身份，如何加密、混淆客户端的token生成过程。客户端验证服务端的身份的确是没有想到，之后考虑在通信之前2者先用一个key做一次握手，SSL感觉有条件就上，没条件的只能对传输的数据自行编码解码了。

2. All REST API calls should occur through dedicated API keys consisting of an identifying component and a shared, private secret.
   Systems must allow a given customer to have multiple active API keys
   and de-activate individual keys easily.

译：所有 REST API必须由专门的API密匙来验证。API密匙（注意：这里的密匙是广义的，不一定是指public key
authentication中的key）必须有一个身份确认段，以及一个客户端/服务器端共享的私有秘密。服务器端的系统必须允许每个用户拥有一个或多
个API密匙，并且可以方便地禁用某些密匙（使之不再有效）。

这个跟我之前设想的一致，访客在一开始会从服务端获取一个access key用于获取public数据，在登录之后才会获得secret key
来获取private数据。

3. All REST queries must be authenticated by signing the query parameters sorted in lower-case, alphabetical order using the private
   credential as the signing token. Signing should occur before URL
   encoding the query string.

所有REST的查询请求都必须经过验证，验证的方式是客户端需对所有查询参数以小写字母顺序排序后用上文所提到的shared, private
secret进行签名加密。签名加密的步骤应该在对查询字符串进行URL编码之前执行。

这一条上跟作者的观点一致：

Ok, 这点是我不敢苟同的。对于查询字串加密会造成很多问题：比如所有的代理服务器的功能都无效了，比如服务器端缓存就无法实现了，最搞笑的是用户如果想把某个REST查询在Facebook上分享给朋友都不可能了。

其实最最重要的是我觉得要求在REST查询的URL上夹带authentication信息是对REST原则的一种违反。我不敢说我完全理解Roy Fielding大师论文的真义，但我觉得REST协议的一个基本原则就是低耦合，也就是专项专用。URL就是用来决定resource的位置的，而不应 该也不必要再夹带其他功能，比如身份验证。身份验证的信息完全可以通过其他标准的HTTP协议的组件来实现（比如最简单的Authorization请求 报头 – request header）。

恩，就目前的填坑速度，API Token估计还要填一段时间

文章地址：REST API的身份验证（Authentication）