OAuth 2 协议

@see OAuth2 and rfc6749

最近一直在做微信接口的开发工作，发现其中使用了大量的加密相关的算法和协议，所以准备单独拉出来。进行深入了解和学习一下；

一、 需求和提出

引用 rfc 里面的介绍：

  
  In the traditional client-server authentication model, the client requests 
an access-restricted resource (protected resource) on the server by 
authenticating with the server using the resource owner's credentials.  

  In order to provide third-party applications access to restricted resources, 
the resource owner shares its credentials with the third party.  
This creates several problems and limitations: 

  .   Third-party applications are required to store the resource
      owner's credentials for future use, typically a password in
      clear-text.

  .   Servers are required to support password authentication, despite
      the security weaknesses inherent in passwords.

  .   Third-party applications gain overly broad access to the resource
      owner's protected resources, leaving resource owners without any
      ability to restrict duration or access to a limited subset of
      resources.

  .   Resource owners cannot revoke access to an individual third party
      without revoking access to all third parties, and must do so by
      changing the third party's password.

  .   Compromise of any third-party application results in compromise of
      the end-user's password and all of the data protected by that
      password.

看着可能不太了解，举个简答的例子：

微信授权登陆

一般，微信授权另一个平台获取一些信息，传统的方式是，微信将账号密码告诉第三方平台，然后这个平台可以获取微信的一系列信息，然后进行处理；

但是这样做会存在几个弊端：

1. 第三方平台会保存微信的账号和密码，这样很不安全（即使是进行过加密）;

2. 微信必须支持密码登录，这样做存在风险；

3. 第三方平台拥有了用户的密码，这样就可以操作微信，而且信息无法限定；

4. 用户只能通过修改密码来回收权限；但是，这样做会使第三方授权失效；

5. 只要有一个第三方被破解，就会导致用户信息泄露；

因此，需要一个更加安全的方式来处理这种问题；

二、角色

OAuth 中定义了四种角色：

1. resource owner : user 用户 资源拥有者
2. resource server : server 资源服务器，存放用户资源的服务器
3. client : Third-party applications 第三方平台
4. authorization server : 认证服务器 处理认证的服务器，返回 Access Token

关系如下：

Protocol Flow

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

                     Figure 1: Abstract Protocol Flow
                    

其主要流程如下：

A. 用户打开客户端后，客户端要求客户进行授权；

B. 用户同意予以客户端授权

C. 客户端使用上一步的授权，像认证服务器申请令牌

D. 认证服务器对客户端进行认证，确认无误，发放令牌（Access Token）

E. 客户端使用令牌，向资源服务器申请资源

F. 资源服务器确认令牌无误，同意向客户端，开放资源

 The preferred method for the client to obtain an authorization grant
 from the resource owner (depicted in steps (A) and (B)) is to use the
 authorization server as an intermediary, which is illustrated in
 Figure 3 in Section 4.1.

未完待续 ...