写在前面

OAuth2.0用简练的话来解释，就是一个授权框架，它能使第三方应用在不需要用户凭证的情况下，获得被保护的资源。
当然这里还是得解释两句，想象一下，微信读书App希望获得微信的用户头像、昵称等信息。最暴利的方式，就是微信读书App直接拿着微信的登录名/密码去访问微信，从而得到相关信息。这里的微信登录名/密码就是上面说的用户凭证。这种实现既不优雅也不现实。因此得有一种方法，vx可以提供临时性的认证方式，让这一次第三方应用的访问需求可以实现。
这种临时性的方案需要做到两点：

• 非用户凭证
• 具有临时性，也就是说仅在一段时间内有效
  因此OAuth2.0的解决方案就是通过颁发访问令牌的方式实现。
  下面的解释我们都已[微信读书]通过[微信]第三方登录来进行解释和描述。

应用注册

在使用OAuth之前，需要对服务进行注册，也就是说[微信读书]需要[微信]提供第三方登录的功能，需要提前在[微信]挂号，[微信]需要对这类App提前进行资格审查，从而在正式使用中，[微信]知道是谁向其提交的第三方登录的申请。
在[微信开放平台]的官方文档中，涉及到微信登录功能也提到这一点：

微信登录准备工作.png

可以看到，经过应用注册，[微信读书]最终会获得AppId和AppSecret。

授权码模式

OAuth2.0有多种授权方式，其中，授权码模式应用最为广泛，因为它针对服务器端的应用进行了优化，上文我们说到的AppSecret被安全的维护在应用程序的服务端([微信读书])。但是这种模式，是基于重定向的流程，这意味着应用程序必须能够与用户代理（即用户的网络浏览器）进行交互，并接收通过用户代理路由的API授权代码。

授权码模式流程.png

step1: 应用服务请求第三方授权
这个过程中，请求中会带上上文提到的app_id以表明身份；redirect_url当授权成功后重定向地址；response_type=code，表明请求对象是授权码；scope标识，标识请求的权限范围，在[微信开放平台]的官方文档中，这个字段要求固定为某字段：

微信开放平台对scope的要求.png

step2:在应用程序申请第三方授权后，第三方服务收到请求，并在已登录的情况下，对这次请求进行接受或拒绝操作。如果接受，如图中第三步所示。
step3:通过第一步指定的redirect_url返回code（授权码）
step4:通过code、app_id、"app_secret"三元组向第三方服务[微信]申请access_token；
获取access_token的过程为什么非得需要前置获取code呢，笔者认为主要是从安全性考虑，防止app_id、"app_secret"泄露。每个code都是user在一定时间内主动接受授权请求的情况下产生的，因此能保证时效性和风险的最小化。
step5:权限服务（[微信]）返回access_token给应用服务（[微信读书]）。
通过上面的5步操作，应用程序就获得了第三方服务的access_token。需要注意的是，这个token是对于第三方服务的token，它意味着应用服务（[微信读书]）可以通过access_token访问第三方服务（[微信]）,获得第三方服务的相关数据信息，比如用户信息等。

微信读书第三方.png