初探OAuth2.0第三方认证登录

什么是OAuth2.0？

• 假设我有一件非常重要的文件存储与于瑞士银行的私有保险柜中，如果我需要委托某个人将他提取出来，除了将密码告诉他之外别无他法，
  但是OAuth的目的却是定义一种协议帮助资源的拥有者在不提供自身凭证的前提下授权第三方应用以他的名义存取受保护的资源。OAuth的全称为“Open Authorization”，所以它是一个开放的协议，目前最新的版本为2.0。
• OAuth2.0对OAuth1.0是完全不兼容的。目前支持OAuth的网站有t.sina.com.cn，t.qq.com，t.sohu.com，t.163.com，www.douban.com，www.twitter.com，www.facebook.com
• 开心网open文档：http://wiki.open.kaixin001.com/index.php?id=OAuth2.0%E6%96%87%E6%A1%A3

OAuth2.0涉及角色

• 资源拥有者（RO：Resource Owner）：资源的拥有者也是授权者，如果它是一个“人”，一般就是指最终用户。由于“资源”在这个场景中表示为用户的电子邮箱地址，所以资源拥有者自然就是指最终用户。
• 客户端应用（Client）：需要取得资源拥有者授权并最终访问受保护资源的应用，对于我们的场景来说，就是我们创建的App。
• 资源服务器（Resource Server）：最终承载资源的服务器，它一般体现为一个可被调用的Web API。对于我们提供的场景来说，客户端通过调用新浪微博得Web API获得用户的电子邮箱地址，所以新浪微博就是资源服务器。
• 授权服务器（Authorization Server）：它对用户（一般情况下为资源拥有者）和客户端应用实施认证，并在用户授权的情况下向客户端应用颁发Access Token。在我们提供的场景中，资源服务器和认证服务器合二为一，均为新浪微博。

实现方案

这里面的access_token可以考虑放在缓存中而不是放在数据库中，一旦过期时间到就可以作废了
oauth2.0有许多种流程，分别适应不同的第三方应用，并且这些流程数目还在不断增加和完善中，一个网站可以实现一种或多种流程

1. Web Server Flow(适合有server的第三方使用的)：web Server Flow是把oauth1.0的三个步骤缩略为两个步骤

1. 客户端http请求authorize
2. 服务端接收到authorize请求，返回用户登陆框页面
3. 用户在客户端登陆
4. 服务器端将浏览器定位到callbackurl，并同时传递Authorization Code
5. 客户端使用https发送access_token
6. 服务器端收到access_token请求，验证Authorization Code—生成access_token, refresh_token,和过期时间–access_token和refresh_token和过期时间入库
7. 返回access_token和refresh_token,过期时间
8. 用户使用HTTPS+ access_token请求开放平台接口

2.User-Agent(适合所有无server端配合的客户端)：

1. 客户端http请求authorize
2. 服务端接收到authorize请求，返回用户登陆框页面
3. 用户在客户端登陆
4. 服务器端将浏览器定位到callbackurl，并同时传递access_token和过期时间