简介oauth2与微信认证
开发过微信公众号的朋友应该都看过这些字眼：令牌token，凭证ticket，oauth认证等。对于只开发过传统登录认证的朋友们第一次见到都多少会有点懵逼。今天将简单讲讲oauth2和微信中各术语之间的区别与意义。
token认证与oauth2
互联网公司为了提高平台的扩展性，开放一系列API，建立自己的技术生态圈。第三方开发者可以根据其开放接口API自定义自己的服务，既然与平台相关，那么势必会调用到平台的某些资源（resource，可以平台存储的图片，名称等）。
传统登录权限认证，第三方服务器作为用户的代理层，我们需要从用户手中获取到其在互联网平台上的账号和密码，然后登录平台，将其在平台中各种资源获取下来。从理论上这完全行得通，但是用户手中的密码在我们中间转了一层，就有可能被被窃取，而且权限远远大于用户原本的意图。
oauth就是在这种场景下顺势而生的，oauth2是一个简化版。oauth并不需要获取到用户的账号密码，而是仅仅获得用户在平台上某部分资源的权限。而这个权限的凭证，就是token。打个比方，加入你是一个大老板（授权和资源服务器），你拥有一个由众多小仓库组成的大仓库。当某天有个生意伙伴（第三方服务器）要求租赁仓库中小仓库1（资源），他向你交了押金（secret），你交给他一把小仓库1的钥匙（token）给他，这个伙伴就可以使用你大仓库中小仓库1，而不是整个仓库。
如下图所示，第三方服务器携带appid、secret先通过授权服务器认证成功后，授权服务器意识其只有获取头像的权限，返回一个只能获取头像的token给第三方服务器。第三方服务器在携带token去资源服务器中获取相应的资源。我们常看到在第三方app登录时候的微信登录、支付宝登录、微博登录等快捷登录也是oauth的应用（登录后获取到头像和昵称等）。
这样，第三方服务器不需要知晓用户的密码，也能获取到相应的资源。而且平台服务器能控制第三方开发者的权限，部分开放给用户。oauth认证方式有四种，一般用的是客户端认证模式
微信access_token与ticket
在接入微信公众平台的开发，微信的相关接口都需要认证才能使用。access_token是当前公众号全局性的令牌。当你申请的是一个普通订阅号，那么你的access_token就只能使用订阅号的部分权限，同样，如果是认证服务号，权限就更多了，比如可以进行微信支付。
在接入jsapi的时候（需要调到其分享朋友功能），需要进行url签名，官方文档中声明既需要定时获取access_token，再通过access_token去获取jsapi_ticket，最后通过ticket与随机字符串和时间戳与url进行加密。这里通过token再去获取ticket，而不是直接用token进行签名，原因是这个ticket仅仅针对的jsapi的，还有，ticket有用于调用微信卡券的api_ticket、用于兑换二维码的ticket等。所以针对jsapi，微信又进行的更细粒度的授权。为了更加安全，微信规定token和ticket的有效期都是2小时，这个后续可能改动，所以我们需要定时去获取新的token或者ticket。
微信access_token与服务器token区别
上文说到的access_token是微信分发的，2小时失效，所以这个是随机的。但是可能会有朋友问，微信的后台有个如下图的设置，也有一个token，这个明显是固定的，而且是我们自己设定的，那么之间有什么区别。要明白其中区别，需要看谁请求谁。
这个是微信与我们自定义服务器设定的契约。当我们通过上图接入到微信服务器，微信服务器会将其收到的信息推送到我们的业务服务器，如用户留言，我们可以根据业务自定义返回给用户的信息。注意：这里，是微信请求我们业务服务器。用户如何保证信息是微信发来的呢？这就是通过这个契约token，微信发过来的信息通过这个我们预留在公众号后台的token进行加密。而不可能是随机的，微信有成千上万个第三方服务器（看看小程序和活跃的公众号就行），如果第三方服务器去设定会过期的token，那么微信可做不到定时去轮序啊！
而access_token是我们服务器请求微信服务器，微信作为统一的资源授权，自然可以定时更换token，用户通过其随机的token进行签名后，微信校验确实是我们业务服务器发送过来的（防护窃取，dns劫持等伪造），才肯放权。
了解两者的区别，就明白了微信为什么会这么设计了。