最近想拿一个小项目来试水RESTful Web API，项目只有几个调用，比较简单，但同样需要身份验证，如果是传统的网站的话，那不用说，肯定是用户名+密码在登录页获得登录Token，并把登录Token记在Cookie和Session中作为身份标识的这种方式，但现在不同了，关键是RESTful，这意味着我们设计出来的这些API是无状态的（Stateless），下一次的调用请求和这一次的调用请求应该是完全无关的，也就是说，正宗的RESTful Web API应该是每次调用都应该包含了完整的信息，没错，包括身份信息！

那如何确保安全？传输时给密码做MD5加密？得了吧！这样做只能让你自己感觉“安全”点，其实没什么任何用处，利用现在的技术（有种叫什么Rainbow Table啥的来着？本人外行，不是很懂）很快就能算出明文密码了，而且如何防止挟持和重发攻击？

也许你想到了，SSL，如果你打算采用SSL，请忘记一切自行设计的加密方案，因为SSL已经帮你做好了一切，包括防止监听，防止挟持，防止重发……一切都帮你考虑好了，你大胆地把明文密码写在你的包中就OK了，我向你保证没问题。

但SSL的缺点是服务器端配置相对有点复杂，更关键的就是客户端对此支持可能不好，那你考虑一种自己的加密方法，有木有？我这里提供一种方法，思路来自于：http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/，我只是把上面的内容中整理了一下变成了我的方法。（传说中的剽窃？呵呵）方法描述如下：

1. 假设有一个用户，用户名是guogangj，密码是123456（呃……这也能叫密码？）
2. 他要GET http://test.com/api/orders/
3. 于是把 http://test.com/api/orders/这个URL和一个新生成的GUID拼在一起，再用123456这个密码执行对称加密，生成的密文为XXXXOOOOXXXXOOOO（假设而已）
4. 数据包中带上用户名guogangj和XXXXOOOOXXXXOOOO这个密文，发送给服务器
5. 服务器收到包后，根据guogangj这个用户名到数据库中查找到123456这个密码
6. 服务器使用123456这个密码来解密XXXXOOOOXXXXOOOO这个密文，得到了明文，即http://test.com/api/orders/这个URL和前面由客户端生成的那个GUID
7. 服务器到一个全局的集合中查找这个GUID，看看是否已经存在，如果存在，则验证不通过，如果不存在，就将其放入这个集合中。这是为了避免重发攻击。这个全局的集合会越来越大，所以还要定期清理。
8. 服务器再比对解密出来的URL和用户真实请求的URL是否一致，如果一致，那么认为这是合法用户，验证通过！

这是大致过程，如果数据库里找不到该用户，或者解密错误，都被认为验证不通过。以下是一些改进：

1. 数据库中的密码最好做一下摘要（MD5之类的），客户端对应地也要做一下。
2. 在生成密文的时候可以考虑加入另外一些不希望被明文传输的敏感内容，甚至可以加入IP地址，并在服务器端验证。
3. 并非每次都要真正去数据库里拿一次用户信息，也许你有更好的办法，比如一个简单的缓存（不过需要处理缓存更新的问题），或者当你的系统大到一定程度的时候，你考虑使用统一的服务来获取用户信息，这就不是缓存那么简单了，里面的文章很多，我相信现在大规模的门户网站都有自己的一套复杂的机制，所以表明上看RESTful Web API很“低效”，但这种RESTFul的思路和模式却在实际中有很大的可塑性和威力。

这种方法应该足够安全了！

密码根本没有在网络上传输，密文采用的是非验证的对称加密，没有密钥就无法逆转，URL验证避免了传统的身份挟持攻击（即拦截一个用户的包并冒充此用户来访问其它的资源，即便无法破解用户密码）， 再用GUID来避免了重发攻击，唯一需要担心的是用户泄露了自己的密码。

元芳，你怎么看？