写在前面
OAuth2.0作为目前应用最为广泛的一种授权协议，有必要进行一下系统的学习。本文就先来一起看下OAuth2.0中最全面，安全性最高的授权流程，授权码许可。
1：授权码许可的角色
在授权码许可中一种有四种角色：
1：受保护资源的拥有者
一般是我们自己
2：受保护的资源
一般就是HTTP的接口形式的API，当然也可以是其他形式
3：客户端
一般是希望拿到受保护资源的角色
4：授权服务器
给客户端完成授权的角色
我们以几个具体的场景来对应下这四个角色。
1.1：极客时间微信三方登录
1：受保护资源的拥有者
我们自己
2：受保护的资源
我们微信的基本信息，微信名，头像等
3：客户端
极客时间
4：授权服务器
微信的开放平台授权服务
1.2：对接巨量引擎的广告平台
1：受保护资源的拥有者
我们自己
2：受保护的资源
巨量引擎平台的广告投放数据，以及广告投放接口等
3：客户端
巨量引擎后台
4：授权服务器
巨量引擎开放平台授权服务器
2：授权码许可的流程（web）
流程如下：
注意：需要在客户端已经通过用户名密码方式登录的前提下进行。
1：受保护资源的拥有者访问客户端，客户端弹出引导授权操作按钮，引导受保护资源的拥有者点击操作跳转到授权服务器进行授权
2：客户端使用携带了回调地址信息的url重定向到授权服务器，受保护资源拥有着点击授权，授权服务器验证客户端的合法性
3：授权服务器生成授权码，并根据回调地址，回调到客户端并携带授权码
4：客户端服务器端获取到授权码，之后使用授权码交换获取访问令牌（access_token）
5：客户端服务器使用访问令牌访问受保护资源，获取需要的数据
使用序列图表示：
其实上图可以分为两部分，一部分是通过浏览器这个中介完成客户端服务端和授权服务器的交互的过程，第二部分是客户端服务器和授权服务器直接交互的过程，如下图：
3：授权码许可的一些知识点
3.1：授权码是什么？
授权码是授权服务器通过回调地址发送给客户端服务器用来交换access_token的临时凭证。
3.2：没有授权码在回调直接返回access_token可以吗？
不可以，原因：
1:安全性，access_token是安全级别非常高的数据，可以直接用来获取受保护数据，如果是直接爆露在url上的话，风险太高
那，授权服务器直接将access_token回调给客户端服务器，就解决了access_token暴漏在url上的问题，这个时候是不是就可以不需要授权码了？
依然需要，因为如果是少了客户端跳转的这一步，对于用户来说，客户端的操作就断了，客户端将没有机会将授权的过程展现给用户，会给用户带来一种不好的用户体验。当然你可以通过浏览器定时到客户端服务器检测的方式来解决这个问题，但这样又会增加编程的复杂程度，并且实时性也会降低，其实也还是降低了用户体验。
3.3：refresh_token的作用是什么？
提高用户体验。
refresh_token相比于access_token有更长的有效期，如果每次access_token失效都让用户重新授权一次的话，这用户体验就太差了。因此使用refresh_token来生成一个新的access_token就可以了。当然，如果是refresh_token也过期了，就肯定需要用户重新授权了。
3.4：其他一般都会使用哪些措施来安全性。
1：https传输
2：授权服务器使用IP白名单，只有IP白名单里的客户端服务器才能访问授权服务器
3.5：一定要有浏览器的参与吗？
不是，OAuth2.0只是一种协议，只要按照其要求实现所有必要的流程就行了，方式是无所谓的。
因为最初基于浏览器的web应用大行其道，所以其应用的也最多，但是当前如微信小程序等非浏览器的场景，此时需要设置grant_type=authorization_code，之后可以通过wx.login(Object object)该方法sdk提供获取code值，获取到code值之后通过auth.code2Session获取session_key（就是access_token了，oauth2只是一种协议，按照其进行灵活实现即可）。
