基于OAUTH2.0的授权操作

最进帮朋友开发网站应用， 现在涉及到一个需求就是网站可以用微薄账号和QQ 账号登陆，干了这多年的WEB开发，很惭愧还没有做过类似的功能，于是想趁此机会学习总结一下 OAUTH 。 

OAUTH 是一个很易于理解的开始的授权协议， 它提供了一种能让我们的程序 作为我们程序用户的代表 访问他们在远程网站/服务器的资源（例如微薄， 博客，图片网站之类）的机制。  这种协议安全可靠，对终端用户来说，它的流程是首先在一个第三方程序中点击用XXX（e.g.微薄） 登陆， 然后看到一个由远程网站/服务器提供的授权页在那里用户需要填入自己的用户名密码进行授权， 注意这个授权页是有远程网站/服务器所提供， 用户所填写的用户名和密码将会提交到远程网站/服务器中， 第三方程序是无法获取用户密码的， 这也是终端用户愿意放心的填入自己密码的重要原因。 当用户点击授权之后，我们的程序就可以得到远程网站/服务器所授予我们的一个访问TOKEN, 有了这个TOKEN 我们就可以通过各种API 进行相关的操作例如发微博什么的， 一般这个TOKEN 都是有时限的， 远程网站/服务器都会提供刷新TOKEN 的接口服务。


OAUTH 最新发展到2.0版本， 2.0 提供了两种授权方式 第一种是 authorization code grand. 流程如下图 
AUTHORIZATION CODE GRAND 流程图

我们的程序首先跳向远程授权页URL， 以腾讯为例 

https://open.t.qq.com/cgi-bin/oauth2/authorize?client_id=APP_KEY&response_type=code&redirect_uri=http://www.myurl.com/example

这里重要的是redirect_uri参数， 它指定当用户完成授权的时候所跳会的网页， 这个网页链接还会有附件参数例如

http://www.myurl.com/example?code=CODE&openid=OPENID&openkey=OPENKEY

这里是CODE 非常重要， 它是我们程序在下一步得到访问TOKEN 的钥匙。 所以我们应该在程序中保存它。 下一步我们的程序通过以下链接来得到最终的访问TOKEN 

https://open.t.qq.com/cgi-bin/oauth2/access_token client_id=APP_KEY&client_secret=APP_SECRET&redirect_uri=http://www.myurl.com/example&grant_type=authorization_code&code=CODE

这里重要的参数是client_id, client_secret, code.  client_id, client_secret 是我们在腾讯注册开发者之后创建应用之后所给予的的应用的 id, 和 secret. code 参数里必须是我们刚才在上一步里得到的值。 

最后远程网站/服务器会访问redirect_uri指定的URI，并且携带参数

access_token=ACCESS_TOKEN&expires_in=60&refresh_token=REFRESH_TOKEN

最终我们得到了ACCESS_TOKEN 通过这个TOKEN 我们就可以访问各种网站API 了。 

新浪微博也提供了相似的链接，我们只要把上面链接的open.t.qq.com 编程 api.wei.com 即可。 大家都符合标准也给我们程序员免去了很多麻烦。 
authorization code grand 的方式按腾讯的开发文档说法是适合SERVER 端的场景， 我的理解是 如果我们的程序（如果是手机程序）有NATIVE 客户端，或者（如果是一个网站服务）有后台的SERVER， 那么应该有限使用这种方式。  

第二种方式是 Implicit grant, 这种方式比较简易， 相对与authorization code grand 方式 它只要发一次连接就可以得到访问TOKEN 不需要先得到CODE 然后在得到TOKEN。腾讯给出的例子是：

https://open.t.qq.com/cgi-bin/oauth2/authorize?client_id=APP_KEY&response_type=token&redirect_uri=http://www.myurl.com/example

返回结果是

http://www.myurl.com/example#access_token=ACCESS_TOKEN&expires_in=60&openid=OPENID&openkey=OPENKEY

这种方试按照OATH2.0 specification 的说法是 "optimized for clients implemented in a browser using a scripting language"。 好像是适合于客户端大部分由脚本语言构成程序， 一般也就是运行在用户浏览器上的JAVASCIRPT了。 


一开始不太理解为什么第二种方式不提供client app secret. google 了一下，有国外网友说第一种方式由于是SERVER TO SERVER 的传输，用户端的浏览器是没办法得到这个secret 的 （得到ACCESS TOKEN 的链接应该由后台程序发出， 例如 JAVA 的HTTP API ）  所以发送secret 很安全。 而第二种方式是有用户端浏览器里的脚本程序发出的，稍微有点网络编程的用户就可以通过FIREBUG 等程序看到这个secret。 所以第二种方法不发secret是为了安全性找想。 


不过还有一点没有相搞懂的是有了方便的第二种方式大家为什么还用第一种方式？ 后来发现新浪微薄好像不支持第二种方式 。 


腾讯和新浪微博都有自己SDK 以方便程序员对他们库API的调用开发。 不过我认为如果只是用来登陆的话，我找的比较靠谱的支持OAUTH 有 GOOGLE JAVA CLIENT API，  毕竟用同样的库可以省去一些麻烦比较好。以前有个oauth signpost 也挺好的，但是只支持到OAUTH1.0.   我的项目还是选择了腾讯和新浪微博自己的SDK， 考虑到以后可能还要使用里面的功能。