在正式介绍各大开放平台的使用细节之前，我们先来看看大厂的开放平台全局体系。据我观察，各个开放平台基本的系统结构和授权系统在中间的交互流程，大同小异，都是通过授权服务来授权，通过网关来鉴权。所以接下来，我就以京东商家开放平台为例，来和你说说开放平台的体系到底是什么样子的。开放平台体系是什么样子的？我们首先来看一下京东商家开放平台全局体系的结构，如下图所示。
我们可以把这个架构体系分为三部分来看：
第三方软件，一般是指第三方开发者或者 ISV 通过对接开放平台来实现的应用软件，比如小兔打单软件。
京东商家开放平台，包含 API 网关服务、OAuth 2.0 授权服务和第三方软件开发者中心服务。其中，API 网关服务和 OAuth 2.0 授权服务，是开放平台的“两条腿”；
第三方软件开发者中心服务，是为开发者提供管理第三方软件应用基本信息的服务，比如 app_id、app_secret 等信息。京东内部的各个微服务，比如订单服务、商品服务等。这些微服务，就是我们之前提到的受保护资源服务。
从图中我们还可以看到这个体系整体的调用关系是：第三方软件通过 HTTP 协议请求到开放平台，更具体地说是开放平台的 API 网关服务，然后由 API 网关通过内部的 RPC 调用到各个微服务。
接下来，我们再以用户小明使用小兔打单软件为例，来看看这些系统角色之间具体又是怎样交互的？
到这里，我们可以发现，在开放平台体系中各个系统角色间的交互可以归结为：
当用户小明访问小兔软件的时候，小兔会首先向开放平台的 OAuth 2.0 授权服务去请求访问令牌，接着小兔拿着访问令牌去请求 API 网关服务；
在 API 网关服务中，会做最基本的两种校验，一种是访问令牌的合法性校验，比如访问令牌是否过期的校验，另一种是小兔打单软件的基本信息的合法性校验，比如 app_id 和 app_secret 的校验；
都校验成功之后，API 网关服务会发起最终的数据请求。
依靠开放平台提供的能力，可以说开放平台、用户和开发者实现了三赢：小明因为使用小兔提高了打单效率；小兔的开发者因为小明的订购服务获得了收益；而通过开放出去的 API 让小兔帮助小明能够极快地处理 C 端用户的订单，京东提高了用户的使用体验。
我们已经知道，用户给第三方软件授权之后，授权服务就会生成一个访问令牌，而且这个访问令牌是跟用户关联的。比如，小明给小兔打单软件进行了授权，那么此时访问令牌的粒度就是：小兔打单软件 + 小明。
我们还知道了，小兔打单软件可以拿着这个访问令牌去代表小明访问小明的数据；如果访问令牌过期了，小兔打单软件还可以继续使用刷新令牌来访问，直到刷新令牌也过期了。
现在问题来了，如果小明注销了账号，或者修改了自己的密码，那他之前为其它第三方软件进行授权的访问令牌就应该立即失效。否则，在刷新令牌过期之前，第三方软件可以一直拿着之前的访问令牌去请求数据。这显然不合理。
所以在这种情况下，授权服务就要通过 MQ（消息队列）接收用户的注销和修改密码这两类消息，然后对访问令牌进行清理。
其实，这个案例中解决访问令牌安全问题的方式，不仅仅适用于开放平台，还可以为你在企业内构建自己的 OAuth 2.0 授权体系结构时提供借鉴。
以上就是开放平台整体的结构，以及其中需要重点关注的用户访问令牌的安全性问题了。我们作为第三方软件开发者，在对接到这些开放平台或者浏览它们的网站时，几乎都能看到类似这样的一句话：“所有接口都需要接入 OAuth 授权，经过用户确认授权后才可以调用”，这正是 OAuth 2.0 的根本性作用。
理解了开放平台的脉络之后，接下来，就让我们通过一组图看一看开放平台是如何使用 OAuth 2.0 授权流程的吧。
各大开放平台授权流程
我们以微信、支付宝、美团为例，看看它们在开放授权上是如何使用 OAuth 2.0 的。我们首先看一下官方的授权流程图：
引自微信官方文档
引自支付宝开放平台文档
引自美团外卖开放平台
我们可以在这三张授权流程图中看到，都有和授权码 code 相关的文字。这就说明，它们都建议开发者首选授权码流程。
总结
当有多个受保护资源服务的时候，基本的鉴权工作，包括访问令牌的验证、第三方软件应用信息的验证都应该抽出一个 API 网关层，并把这些基本的工作放到这个 API 网关层。
各大开放平台都是推荐使用授权码许可流程，无论是网页版的 Web 应用程序，还是移动应用程序。
对于第三方软件开发者重点关注的参数，可以从授权服务的授权端点和令牌端点来区分，授权端点重点是授权码请求和响应的处理，令牌端点重点是访问令牌请求和响应的处理。