图解Browser端访问OAuth2 API的安全性问题与解决方案
OAuth2是基于HTTP的认证API，一般与OAuth2搭配的API也是基于HTTP的REST风格API（比如新浪微博和github），很多人一定想过是否可以直接从浏览器端调用REST API。
我最近做了一些这方面的研究，因为OAuth2中有secret key的存在，所以纯粹的客户端是不行的，但是服务端仅仅参与认证过程，由浏览器去调用REST API则是完全可行的。
于是比如你想开发一个github应用，那么服务端只需要一个没有界面的Auth服务就可以了，大部分的工作可以让浏览器端完成，这个架构可以大大减轻服务器的压力，对于不熟悉后端语言的前端工程师来说，是个不错的选择。
首先传统的oauth过程是这样的：
首先由跳转到OAuth服务器的登录认证页面，进行登录或者授权（假如已经在别的地方登录，就只需要授权）：
然后服务端通常会返回302跳转到一个带ticket参数的网址，这个网址一般是在OAuth服务器注册的地址，也有些OAuth允许客户端指定：
这样浏览器端拿到302后，会自动转到App服务器，因为请求的Query String里面带了ticket，App Server于是拿到了ticket。客户端对App Server的请求是非Https，这个ticket是不怕被截获的，因为ticket是一次性的，而且攻击者拿到了ticket没有secret key是没法去Oauth服务器骗取token的：
App Server再对Oauth Server发HTTP请求，带上Secret Key：
OAuth服务器会把access_token传给App Server：
原本如果只用服务端访问REST API，这个token保存在服务端就可以了，但是我们现在希望直接在浏览器端用XHR去访问REST API，所以我们必须把token传给浏览器端。
这时候问题出现了，对于大部分开发者而言，花钱买个证书走https是不现实的，而http请求中明文传递token是可能被截获的：
token中包含用户授权信息，只要黑客截获了token，就可以冒充用户身份去Oauth服务器为所欲为：
解决的办法是使用RSA在浏览器端生成一对RSA密钥，然后把公钥传给App Server（建议用cookie，非常方便），Server用公钥加密token后传回给客户端。
我使用的是斯坦福大学的RSA开源实现（这个真的是非常高质量的RSA实现，向斯坦福师生致敬）
http://www-cs-students.stanford.edu/~tjw/jsbn/
学者们的实现比较文艺，依赖关系稍微有些复杂，这里我把所有文件打了个包，方便大家下载：
over，接下来在浏览器端去使用token吧。
github API 的一个开源实现，请看 https://github.com/wintercn/github.wind
