OAuth2.0 协议的理解

OAuth(Open Authorization)协议就是为用户资源的授权提供了一个安全、开放、简易的标准。

OAuth在第三方应用与服务提供商之间设置了一个授权层，第三方应用通过授权层获取令牌，再通过令牌获取信息。

一、OAuth中的一些名词

Client 第三方应用程序，又称客户端。

Resource Owner 资源所有者。

Http service 提供http服务的服务提供商。

Authorization server 认证服务器，服务提供商专门用来处理认证的服务器。

Resource server 资源服务器，服务提供商专门用来提供用户资源的服务器。

二、OAuth协议流程

+--------+                                 +-------------+
|        |--- (1) Authorization Request -->|   Resource  |
|        |<-- (2) Authorization Grant   ---|   Owner     |
|        |                                 +-------------+
|        |
|        |                                 +-------------+
| Client |--- (3) Authorization Grant   -->|Authorization|
|        |<-- (4) Access Token          ---|   Server    |
|        |                                 +-------------+
|        |
|        |                                 +-------------+
|        |--- (5) Access Token          -->|   Resource  |
|        |<-- (6) Protected Resource    ---|   Server    |
+--------+                                 +-------------+

1、第三方应用请求用户给予授权。

2、用户同意给予第三方应用授权。

3、第三方应用使用上一步获取的授权，向认证服务器申请令牌。

4、认证服务器对第三方应用进行认证，准确无误后，发放令牌。

5、第三方应用使用令牌，向资源服务器获取资源。

6、资源服务器确认令牌无误后，向第三方应用开放资源。

不难看出，第二步是最关键的，第三方应用获取了授权，就可以通过授权获取令牌，进而通过令牌获取资源。

三、OAuth的四种授权模式

1、授权码模式

　　功能最完整、流程最严密的授权模式。

　　特点就是通过第三方应用的后台服务器，与服务提供商的认证服务器进行互动。

　　流程如下：

　　(1)、用户使用第三方应用，第三方应用将用户跳转到认证服务器。

　　(2)、用户选择是否给第三方应用授权。

　　(3)、如果用户给予授权，则认证服务器将用户跳转至事先指定的重定向URI(redirect_uri)，同时在URL附加上一个授权码(code)。

　　(4)、第三方应用获取授权码(code)，附加上重定向URI(redirect_uri)，向认证服务器申请令牌。这一步是在第三方应用服务器后台完成的，用户不可见。

　　(5)、认证服务器确认授权码(code)和重定向URI(redirect_uri)无误后，向第三方应用发送令牌(access_token)和更新令牌(refresh_token)。

2、简化模式

　　不通过第三方应用的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。

　　所有步骤在浏览器中完成，令牌对访问者是可见的，且第三方应用不需要认证。

　　流程如下：

　　(1)、用户使用第三方应用，第三方应用将用户跳转到认证服务器。

　　(2)、用户选择是否给第三方应用授权。

　　(3)、如果用户给予授权，认证服务器将用户跳转至事先指定的重定向URI(redirect_uri)，在URI的hash部分包含了访问令牌。

　　(4)、浏览器向资源服务器发出请求，想要提取URI中的令牌(access_token)。

　　(5)、资源服务器返回带有解析脚本的页面，用于解析重定向URI中的令牌(access_token)。

　　(6)、浏览器使用解析脚本，获取令牌。

　　(7)、浏览器将令牌发送给第三方应用。

3、密码模式

　　用户向第三方应用提供自己的用户名和密码。第三方应用使用这些信息，向服务商提供商索要授权。

　　在这种模式中，用户必须把自己的密码给第三方应用，但是第三方应用不得储存密码。

　　这通常用在用户对第三方应用高度信任的情况下，比如第三方应用是操作系统的一部分，或者由一个著名公司出品。

　　而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。

　　流程如下：

　　(1)、用户将用户名和密码提供给第三方应用。

　　(2)、第三方应用将用户名和密码发送给认证服务器，申请令牌。

　　(3)、认证服务器确认无误后，向第三方应用提供令牌。

4、客户端模式

　　指第三方应用以自己的名义，而不是以用户的名义，向服务提供商进行认证。

　　严格地说，客户端模式并不属于OAuth框架所要解决的问题。

　　在这种模式中，用户直接向第三方应用注册，第三方应用以自己的名义要求服务提供商提供服务，其实不存在授权问题。

　　流程如下：

　　(1)、第三方应用向认证服务器申请令牌。

　　(2)、认证服务器确认无误后，向第三方应用提供令牌。

四、以接入QQ第三方登陆为例

1、首先我们需要到https://connect.qq.com/创建一个开发者账号，审核通过后，获取到appid和appkey。

2、在网站上放置QQ登录按钮。

3、当用户点击QQ登录按钮，则会跳转至QQ的授权地址。

https://graph.qq.com/oauth2.0/authorize?response_type=code&state=&client_id=&redirect_uri=

4、用户给予授权后，页面将跳转至上一步redirect_uri设置的地址，并附加上授权码(code)。

5、通过授权码，向认证服务器申请令牌(access_token)。

https://graph.qq.com/oauth2.0/token?grant_type=authorization_code&client_id=&client_secret=&code=&redirect_uri=

6、通过令牌，我们就可以拿到用户的openid。

https://graph.qq.com/oauth2.0/me?access_token=

7、通过appid，openid和令牌，我们就可以获取用户信息了。

https://graph.qq.com/user/get_user_info?access_token=&oauth_consumer_key=&openid=