OAuth协议简介
OAuth协议主要作用
OAuth协议的主要就是种授权协议，就是在用户不将服务提供商的账号密码交给第三方应用的场景下，让第三方的应用有权限去访问用户存放在服务提供商上的一些资源
OAuth协议要解决的问题
这里直接举例说明，如我们的微信账号，这个微信号上有我们一些用户信息，如头像昵称，性别等信息！作者我呢要开发一个APP，需要使用微信用户关联微信号登陆，那么就需要得到微信账号授权的用户数据，这里最大的问题是微信肯定不允许我们任意读取用户数据的，那么这里就需要微信用户的授权，授权同意后我使用微信账号的用户数据，当我们的APP有了微信用户的授权后，我们就可以在微信中读取授权用户的微信账户数据了，那么微信就会将用户的账号部分数据开放给我们了，那么我们如何得到用户的授权呢，最传统的做法就是我们自己开发的APP向用户去要账号和密码，看用户愿不愿意给，就算用户愿意给，那么这样的流程还是存在很大的问题的
OAuth诞生的原因
- 首先我们的APP得到账号和密码后可以访问用户在微信上的所有数据，
- 用户只有修改密码才能收回授权，这里改密码的话，如果这个账号还有其他第三方使用的话，那么密码一旦修改，其他第三方也会无法使用！
- 密码泄露的可能性大大提高，如果这里有多个第三方使用这种方式授权，那么就会有多个地方密码暴露的风险，任何一个第三方账号密码泄露了，那么微信账号密码可能就会丢失，
OAuth解决的问题
那么OAuth协议就是为了解决上面传统授权存在问题所诞生的！这里OAuth中的思路就是用户不在告诉我们微信的账号密码，而是同意授权后会交给我们一个令牌（Token），当我们在向微信获取用户部分数据时就不在通过账号密码了，而是通过微信授权的令牌，那么使用这个机制，上面提到传统方式存在的那些问题就都不存在了，
- 颁发的令牌明确限制只能访问特定的部分数据，而不是所有。
这个授权后的令牌（Token）会有个有效期，如有效期一个月，过了一个月后那么我们就无法在获取用户数据了，需要用户从新再次授权才行， - 就是密码不会暴露，因为我们压根就没获取用户的账号密码，而是使用令牌（Token）
- 那么这些问题的解决就是OAuth存在的意义。
Oauth协议中的各种角色
1.服务提供商 Provider： 作用提供商主要视同令牌（Token），上面提到OAuth是围绕令牌使用的，谁提供令牌谁就是服务提供商，在上面例子中，微信提供授权令牌（Token）那么微信就是服务提供商
2.资源所有者 Resource Owner 资源是指用户相关数据，正在的所有者是用户，而不是微信，用户只是将数据放在微信上存储。
3.第三方应用 Client 也就是上面例子中我们自己开发的APP，它的目的是把用户存储在微信的一些数据获取到自己服务器存储
那么在上面这三个主要的角色以外，在服务提供商里面还有认证服务器Authorization Server，他的作用是认证用户身份并产生令牌（Token），还有一个资源服务器Resource Server（用户信息相关数据） 他的作用就是存储用户相关数据和验证令牌，最终我们第三方APP发送请求是发给资源服务器的，发请求的时候会带上从服务提供商获取的令牌（Token），然后请求到达资源服务器后验证令牌（Token），验证通过后就会把授权数据给第三方我们的APP，这里要注意的是认证服务器和资源服务器在逻辑上是两个角色，在物理上他们可以是同一台服务器，只是同一台机器上部署了两个应用而已
OAuth协议运行流程
这里2授权同意在OAut业务流程发展过程*产生4中方式，那么这4中方式为授权码模式（authorization code）、简化模式（implicit）、密码模式（resource owner password credentials）、客户端模式（client credentials）用的较多的是授权码模式和密码模式用的较多，简化模式和客户端模式用的较少。
授权码模式
授权码模式是这4中模式里面功能最完整，流程最严密的一种授权模式，在现在互联网上能看到的所有的提供商，不管是微博、微信、QQ、百度、淘宝也好，所有的服务提供商都是采用的授权码模式来完成整个OAuth流程的，下面就来介绍授权码模式完整的流程
这里的话就举例微信扫码登录网址的流程，如我们在某网站逛的时候，需要登录，当我们点击登录的时候
这里就会开始1将用户导向认证服务器
用户使用微信扫码完成2用户同意授权
当认证服务器收到2用户授权后，我们自己的第三方APP服务器中有个接口会接收认证服务器携带授权码的回调，也就是图中步骤3.返回Client并携带授权码，这里注意返回的不是令牌（Token），而是授权码，第三方应用收到授权码以后会拿着授权码向认证服务器申请令牌，也就是4申请令牌，注意这一步申请的流程是在第三方应用的服务器上发出去的对用户是无感的，那么认证服务器收到申请令牌的请求后会校验步骤4申请令牌中携带的授权码是否是第3步返回Client并携带的授权码，如果是的话那么就会走5发放令牌（Token的操作），那么这个就是授权码的一个完整流程，这里在步骤3中返回的授权码，所以这种模式也就叫做授权码模式，在其他模式中是没有授权码这个概念的，这种模式主要有两个特点，将其他的三种模式分开，
第一个特点就是用户这个授权的动作是在认证服务器上完成的（也就是我们手机上的微信上扫码点击授权），那么如密码模式，和客户端模式这个授权的过程是在第三方应用上完成的，完成以后第三方就会向认证服务器申请令牌的时候就会带着一些信息告诉认证服务器用户已经授权给这个应用了，允许这个APP访问用户数据，这里认证服务器是没法知道是否是用户真的授权了的，有可能这个授权信息是第三方应用伪造的，而在授权码模式里，同意授权的动作实在认证服务器上完成的，也就是那个二维码界面，这个界面是微信提供的，扫码授权也是在微信APP里面完成的，所以微信的认证服务器就能明确的知道这是用户授权过的，这是第一个特点，
第二个特点就是用户同意授权的时候在3返回Client并携带授权码的时候返回的并不是令牌（Token） ，而是一个授权码，第三方应用在收到授权码之后会再从第三方服务器在发一个4申请令牌的请求给认证服务器，那授权码换取真正的令牌，这种模式下要求第三方应用必须有一个服务器，那么像有些网站可能就是个静态界面，没有服务器，那么这种类型 的网站就会使用4种模式中的简化模式在授权3时就直接返回令牌（Token），这里就会将令牌直接返回给浏览器的界面上，然后界面会使用脚本读取返回的令牌，这种简化模式令牌是发给浏览器的，而不是像授权码一样发给服务器的所以授权码模式是相比简化模式安全性更高的
那么拥其这两个特点这个授权码模式是这4种模式中功能最完整，流程最严密的一种授权模式，这也是主流服务商采用这种授权模式的原因