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=