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