七、OAuth协议

不管是SpringSocial还是SpringSecurityOAuth，这两个框架都是根据OAuth协议来提供功能的。为了理解这两个框架的功能，我们需要对OAuth协议有一个较全面的理解。

一、OAuth协议要解决的问题

首先我来举一个例子。

比如说我要开发一个微信翻译助手，即将用户手动输入的语言文字转化为另一方需要的语言翻译过去。这件事对于双方系统都是一件有利的事。对于微信来说，我提供这种翻译服务用户可能就会因为使用微信频率过高更愿意把这种语言文字提交给微信去翻译而不会放到别的平台上去。而对于我自己的这种翻译系统，默认的我可以把微信平台上的所有的这些用户都变为我的潜在用户，这比我从0开始一个个地去扩展用户的效率还是成本都好很多，这本身就是一种共赢的事情。

但是问题来了，微信肯定是不会允许我去随便地去读用户的微信的信息的。这是我就需要用户的一个授权，用户同意我去读用户在微信中的聊天数据。有了这个授权之后我就可以告诉微信说用户同意了，这个时候微信就会把用户的聊天数据开放给我了。那么如何来得到用户的授权呢？我们可能会想到去要用户的微信名和微信密码，先不说安全问题，就算用户给了我微信名和密码，我拿着用户名和密码去微信中读取用户的聊天记录，也是会存在很大的问题的。

问题1：应用可以访问用户在微信上的所有数据。因为如果用户把密码给我，我登录微信上之后我想看什么看什么比如说自己的通讯录好友，朋友圈等信息，并不能只看到一条聊天记录。
问题2：用户只有修改密码，才能收回授权。因为我知道用户名密码了，但是用户并不能控制我到底能用多久，可能用户不更改密码我可以一直使用这个微信账号，但是用户一旦改了密码可能对于下次翻译功能如果再授权就会还需要告诉我用户名密码。
问题3：密码泄露的可能性大大提高。如果用这种方式授权，就比如说我只是用户授权的其中之一的服务商，可能对于其他功能还会有很多授权，那么如果其中一个服务商将密码安全泄露了那么可能用户的信息数据就会丢失，密码泄露的可能性就会大大提高。

那么为了解决这些问题，OAuth协议就诞生了，它出现的意义就在于，在用户给服务商授权的时候并不用给我用户名密码，而是可以交给我一个令牌（Token），我再去访问微信上用户的聊天数据的时候我就不会去用用户的微信名和密码了，而是用用户的密码去进行访问。有了这个机制，上述三个问题就会迎刃而解了。

二、OAuth协议中的各种角色

OAuth的角色

1.服务提供商（Provider）

它用来提供令牌。因为之前说了OAuth协议是基于令牌（Token）的，这个令牌总不能让用户写个纸条给我，它本身就是一个电子化的东西。那么谁提供这个令牌，谁就是这个提供商，在我上边的例子中，主要是微信提供这个令牌，那么微信就是这个服务提供商。

(1)认证服务器（Authenrization Server）

它的作用是认证用户的身份并且产生令牌，令牌是从这个角色中产生出来的。

(2)资源服务器（Resource Server）

这个角色有两个作用：

第一个作用就是保存用户的资源，即将用户的聊天数据保存起来。
第二个作用就是验证令牌。最终我们第三方应用发送请求的时候是发送到资源服务器上边的，发请求的时候会带着认证服务器发给我的Token，由资源服务器去验证这个Token，如果验证过了就会把用户的聊天数据给第三方应用。

2.资源所有者（Resource Owner）

资源是指什么？资源就是用户需要翻译的聊天数据。这些聊天数据所有者是用户，而不是微信，用户只是把这些资源放在了微信上。那么这里的资源所有者就是用户

3.第三方应用（Client）

第三方应用也就是我们例子中的翻译助手，它的目的就是将微信用户转化为第三方的用户。然后向微信提供服务。

三、OAuth协议的运行流程

流程.png

首先用户要访问第三方应用。
然后第三方应用就会请求用户去授权，第三方应用必须要让用户去访问聊天数据才能对其进行服务。
如果用户同意授权，那么第三方应用就会去访问服务提供商的认证服务器，告诉认证服务器用户同意我访问微信聊天数据了，你给我一个申请的令牌。
其次认证服务器会去验证第三方应用“说的是不是实话”，即用户是不是真的同意授权了。如果验证通过了就会给第三方应用发送一个令牌。
第三方应用拿到了这个令牌之后，它就可以使用这个令牌去资源服务器中申请访问资源。
资源服务器根据第三方应用给出的这个令牌，确认令牌无误之后，它会同意把用户的聊天数据开放给第三方应用。

在这几个步骤中，第二步（用户同意授权）这个是关键，因为有了这个授权之后，Client才能去进行下面的一系列操作。

四、OAuth协议中的授权模式

在用户授权的时候，可以将授权模式分为以下几种：

1.授权码模式（authorization code）
2.密码模式（resource owner password credentials）
3.客户端模式（client credentials）
4.简化模式（implicit）

其中，客户端模式（client credentials）和简化模式（implicit）在实际开发应用过程中会用的比较少，用的最多的还是授权码模式（authorization code）和密码模式（resource owner password credentials）。