OAuth2.0介绍，OAuth2.0与OAuth 1.0对比

OAuth概念

OAuth目前已经成为互联网标准协议之一

字面意理解：open authorization 开放授权，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将密码等数据提供给第三方应用。

原版：OAuth is a security protocol that enables users to grant third-party access to their web resources without sharing their passwords.

例如：

OAuth授权过程

在认证和授权的过程中涉及的三方包括：

1. 服务提供方，用户使用服务提供方来存储受保护的资源，如照片，视频，联系人列表。
2. 用户，存放在服务提供方的受保护的资源的拥有者。
3. 客户端，要访问服务提供方资源的第三方应用，通常是网站，如提供照片打印服务的网站。在认证过程之前，客户端要向服务提供者申请客户端标识。

---

OAuth2.0与OAuth1.0对比

对比点	OAuth1.0	OAuth2.0	对比结果
是否兼容	-	OAuth 2.0是个全新的协议	不兼容
token有效期	有效期非常长的token(典型的是一年有效期或者无有效期限制)	短有效期的access token和长生命期的refresh token。这将允许客户端无需用户再次操作而获取一个新的access token，并且也限制了access token的有效期	不兼容
协议	采用http	采用https	2.0更加安全
授权流程	-	-	不同

---

~ OAuth 2.0协议 开始~~~~~~~~~~~~~~~~~~~~~~~~~~~~

协议的参与者

OAuth的参与者至少有以下四个：

1. RO(Resource Owner)：资源所有者，对资源具有授权能力的人。其实来讲就是用户，如上文的小明。
2. RS(Resource Server)：资源服务器，它存储资源，并处理对资源的访问请求。如上文的新浪微博资源服务器。
3. Client：第三方应用，它获取RO的授权后就可以访问RO的资源。如上文的第三方客户端。
4. AS(Authorization Server)：授权服务器，它认证RO的身份，为RO提供授权审批流程，并最终颁发授权令牌(AccessToken)。AS和RS的功能可以由同一个服务器来提供。

简单的来讲就是用户、第三方客户端、服务器。这个服务器有两个工作：授权和提供资源。

OAuth的思路

OAuth在Client和RS之间设置了一层授权层。Client不能直接登录RS，只能利用令牌来登录授权层，而且这个令牌有权限范围和有效期。

时序图

基本流程：

1. 用户打开第三方客户端（后面简称客户端），客户端引导用户去授权。
2. 用户同意授权给客户端，也就是点击了同意授权的按钮，之后客户端会拿到授权证据。这里用户如何批准是关键，后面会讲到。
3. 客户端向服务器请求访问令牌(Access Token)，同时出示前面的步骤拿到的授权证据。
4. 服务器通过认证后，向客户端返回访问令牌。
5. 客户端携带访问令牌去访问服务器上的资源。
6. 服务器验证令牌的有效期和真伪，验证通过后才能提供服务。

有两个关键的东西，一个是用户同意授权的授权证据，一个是用授权证据进一步请求拿到的访问令牌。

客户端的授权

上面讲到用户给客户端授权这一步是关键。客户端必须得到用户的授权才能获得令牌。Auth2.0定义了四种授权方式：

授权码模式
简化模式
密码模式
客户端模式

授权码模式

授权码模式是功能最完整、流程最严密的授权模式。其特点是通过Client的后台服务器与AS进行互动。

基本流程：

1、客户端初始化协议的执行流程，通过HTTP 302来重定向用户代理到服务器。这里的用户代理基本上就是指浏览器。客户端申请认证的URI包含以下参数：

• response_type：授权类型，此处的值固定为“code”(必选)
• client_id：客户端的ID(必选)
• redirect_uri：重定向URI(可选)
• scope：申请的权限范围(可选)
• state：客户端的当前状态，可指定任意值，认证RS会原封不动地返回这个值

2、服务器认证用户身份证，并提供页面供用户决定是否批准或拒绝客户端的此次请求。

3、若请求被批准，服务器使用步骤(1)中客户端提供的redirect_url重定向用户代理到指定页面。redirect_uri必须包含authorization_code，也就是我们前面所说的比较重要的授权证据。以及步骤(1)中Client提供的state。若请求被拒绝，AS将通过- redirect_uri返回相应的错误信息。

• code：授权码(必选)。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI是一一对应的关系。
• state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

4、客户端拿authorization_code去访问服务器以交换所需的access_token，也就是前面所说的访问令牌。客户端请求信息中应包含用于认证客户端身份所需的认证数据，以及上一步请求authorization_code时所用的redirect_uri。

• grant_type：授权模式，此处的值固定位“authorization_code”(必选)
• code：上一步获取的授权码(必选)
• redirect_uri：重定向URI，必须与步骤(1)中的该参数值保持一致(必选)
• client_id：客户端ID(必选)

5、服务器收到authorization_code时需要验证客户端的身份，并验证收到的redirect_uri与步骤(3)请求authorization_code时所用的redirect_uri相匹配。如果验证通过，AS将返回access_token以及refresh_token。

• access_token：访问令牌
• token_type：令牌类型
• token_type：表示过期时间
• refresh_token：更新令牌，用来获取下一次的访问令牌
• scope：权限范围，如果与客户端申请的范围一致，此项可省略

更新令牌

如果Client的访问令牌过期，则需要使用更新令牌申请一个新的访问令牌。
Client发出更新令牌的HTTP请求，包含以下参数：

• grant_type：授权模式，此处的值固定为“refreshtoken”
• refresh_token：之前收到的更新令牌
• scope：申请的授权范围，不可以超出上一次申请的范围，如果省略该参数，则表示与上一次一致

以简书为例子，来简单说明oauth2.0授权登陆流程:

• 服务商：以微信为例子，那么服务商就是微信[服务器]或腾讯
• 用户 : 就是你，你的相关信息(例如用户名/密码/性别/ 省份等等等等)都是存放在服务商的服务器中。注意：你不是第三方(例如简书)的用户，而是微信的用户(因为你是注册在微信中，而不是简书中)
• 第三方网站 : 这里指的就是简书[服务器]

而这种授权无需将用户提供用户名和密码提供给该第三方网站。
这句话的意思很明显，就是简书服务器是没法拿到你在微信服务器中的用户名和密码的，但是的确能够让你登陆简书服务器

既然第三方(简书)无法拿到你的用户名和密码，那肯定是由服务商(微信)来进行验证，那么第三方肯定要和服务商有一种机制来进行辨识:
在认证过程之前，第三方(简书)需要先向服务商(微信)申请第三方(简书)服务的唯一标识
因此第三方(简书)填写本公司相关信息，提供本公司账号，域名等信息，并且花三百块钱给服务商(腾讯)进行审核。服务商腾讯收到钱，并且审核通过后，会给第三方(简书)两个编号:AppID和appSecret(及其重要，不能泄露)。通过这两个编号，就能确认唯一性了。当然过程是很复杂的。

第三方[服务器]和服务商[服务器]之间的通信：
既然第三方(简书)用通过服务商(微信)来验证用户(你)身份的合法性，那么肯定涉及到：一旦服务商(微信)确认用户(你)的合法身份后，如何将信息传递给第三方(简书)
很简单，通过第三方(简书服务器)提供的回调URL，服务商(微信服务器)将相关数据以参数形式写入到第三方(简书服务器)提供的回调URL,第三方(简书服务器)解析服务商(微信服务器)发过来的信息抽取出来就OK了！
那在微信公众号的申请中，有要求第三方(简书)提供回调地址

~ OAuth 2.0协议 结束~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---