没有播种，何来收获；没有辛苦，何来成功；没有磨难，何来荣耀；没有黯淡，何来辉煌。
OAuth协议要解决的问题是什么
OAuth协议中的各种角色与职责
我们用微信来举例：
假如我有一个给微信用户自拍添加五星红旗的应用，现在我要拿到微信用户的自拍才能进行操作。之前的做法就是让用户给你用户名和密码。那有什么弊端呢？
1、应用拥有用户在微信上的所有权限，不能单单限定与读取头像。
2、用户只有修改密码，才能收回授权。但是这个微信用户不单单只是把用户名密码给了我这一个应用，如果改了密码其他应用的授权就也跟着失效啦。 OAuth协议就是用来解决上面三个问题而诞生的，它的一个主要思路就是用户不用把他的用户名和密码告诉我而是交给我一个令牌（token）,我再去访问微信上用户的自拍时，就不用用户的用户名和密码了，而是改成用token方式进行访问。令牌上会存储给予应用的权限和认证时间，这个时候上面三个问题就都不存在啦。
1、服务提供商（Provider）,它是提供令牌的。在我们例子中微信就是服务提供商。
2、资源所有者（Resource Owner）,资源是在我们上面例子上用户的自拍数据。资源所有者也就是我们的用户。
3、第三方应用（Client）,也就是我们例子中给用户添加五星红旗的应用。 4、认证服务器（Authorization Server）,它在服务提供商里面，它的作用是认证用户的身份并产生令牌。
5、资源服务器（Resource Server）,它也在服务提供商里面，它的作用是保存用户的资源和验证令牌。上方例子中用户的自拍数据就是存在资源服务器上面的。
简略请求经过： 第三方应用在发送请求的时候会携带认证服务器给出的token到资源服务器中请求用户资源，在资源服务器中验证这个token，如果验证通过就会把用户的资源给第三方应用。
注意：在逻辑上认证服务器与资源服务器是两个角色但是在真正的开发时可以是一个应用。
1、第三方应用请求用户给予它授权，是否允许第三方应用访问用户资源。
3、第三方应用访问服务提供商的认证服务器，告诉认证服务器用户已同意第三方应用访问用户资源，申请令牌。
4、认证服务器会验证第三方应用真实性，并发放令牌给第三方应用。 5、第三方应用拿到令牌之后就可以使用这个令牌来访问用户资源啦。 6、资源服务器会验证第三方应用请求携带的令牌的真实性，并把资源开放。 授权码模式（authorization code）
密码模式（resource owner password credentials）
客户端模式（client credentials）
也就是说在OAuth协议运行流程中的第二步可以有四种方式进行授权！我们这里介绍最常见的授权码模式，密码模式后续会讲解，其他两种模式不涉及！ 授权码模式是这四个模式中功能最完整、流程最严密的一个授权模式。各大平台所有的服务提供商全部使用此模式，来完成整个OAuth流程的。
3、用户同意授权后认证服务器会携带授权码返回到第三方应用。
4、第三方应用收到授权码之后会拿着授权码向认证服务器申请令牌。
6、第三方应用拿到令牌之后就可以使用这个令牌来访问用户资源啦。 7、资源服务器会验证第三方应用请求携带的令牌的真实性，并把资源开放。 1、用户同意授权的动作是在认证服务器上完成的。密码模式和客户端模式同意授权的动作都是在第三方应用上完成的，所以此种模式下无法确定用户是否真正授权。
2、用户同意授权的时候在认证服务器返回第三方的时候返回的并不是令牌而是授权码，第三方应用拿着授权码再去申请令牌，此模式是后台操作用户无感知，所以授权码模式必须要求第三方应用要有自己的服务器。好多应用是静态网页所以不能用此模式只能用简化模式。
