Question

如何使用 Oauth 实现一个安全的 REST API 服务

Answer 1

流程如下:
[客户端]在调用REST API之前，首先将待发送消息体打包, combine a bunch of unique data together(websevice端将要接收的数据)

[客户端]用系统分派的密钥使用哈希(最好是HMAC-SHA1 or SHA256 ) 加密(第一步的数据).

[客户端]向服务器发送数据:

用户身份认证信息例如,用户ID，客户ID或是其他能别用户身份的信息。这是公共API，大家都能访问的到(自然也包括了那些居心叵测的访问者)系统仅仅需要这部分信息来区分发信人而不考虑可靠与否(当然可以通过HMAC来判断可靠性).

发送生成的HMAC码.
发送消息体（属性名和属性值），如果是私有信息需要加密，像是（“mode=start&number=4&order=desc”或其他不重要的信息）直接发送即可.
(可选项)避免重放攻击 “replay attacks” o的唯一办法就是加上时间戳。在使用HMAC算法时加入时间戳，这样系统就能依据一定的条件去验证是否有重放的请求并拒绝.
[服务器端]接收客户端发来的消息.
[服务器端] (参看可选项)检查接收时间和发送时间的间隔是否在允许范围内（5-15分）以避免重放攻击replay attacks.
提示: 确保待检对象的时区无误daylight savings time
更新: 最近得到的结论就是直接使用UTC时区而无需考虑DST的问题 use UTC time .
[服务器端]使用发送请求中用户信息（比如.API值）从数据库检索出对应的私匙.

[服务器端]

跟客户端相同，先将消息体打包然后用刚得到的私匙加密（生成HMAC）消息体.
(参看可选项) 如果你使用了加入时间戳的方式避免重放攻击，请确保服务端生成的加密信息中拥有和客户端相同的时间戳信息以避免中间人攻击man-in-the-middle attack.
[服务器端] 就像在客户端一样，使用HMAC哈希加密刚才的信息体.

[服务器端]

将服务器端刚生成的哈希与客户端的对比。如果一致，则通讯继续；否则，拒绝请求!

提示: 在打包消息体的时候一定要考虑清楚，如果像亚马逊进行签名版本1中信息识别那样会面临哈希冲突的问题 open yourself up to hash-collisions! (建议：将整个包含URL的请求加密即可!)
特别提示:私匙绝对不能在通讯过程中传递，它仅仅用来生成HMAC,服务器端会自动查询出它的私匙并重新生成自己的HMAC.我来翻译公匙仅仅用来区分不同的用户，即使被破解也无所谓。因为此时的消息无需判断其可靠性，服务端和客户端还是要通过私匙来加密