你确定懂OAuth 2.0的三方软件和受保护资源服务？（下）

1.2 服务市场

• 什么是服务市场？

• 

  三方开发者开发的软件，都发布到这样一个“市场”里售卖。

2 构建受保护资源服务

受保护资源最终指向 API，比如排版软件中的受保护资源就是文章查询 API、批量查询 API 等及公众号头像、昵称的 API。

在互联网上的系统之间的通信，基本都是以 Web API 为载体的形式进行。授权服务最终保护的就是这些 API。在构建受保护资源服务时，除检查令牌的合法性，更关键是权限范围。校验权限的占比大。肯定要看该令牌到底能操作哪些、能访问那些数据。

2.1 不同权限对应不同操作

操作对应 API，比如公众号平台提供有查询、新增、删除文章 API。若xx请求过来的一个访问令牌 access_token 的 scope 权限范围只对应查询、新增 API，那包含该 access_token 值的请求，无法执行删除文章 API。

2.2 不同权限对应不同数据

数据，指某 API 里包含的字段信息。比如，有一个查询我的信息的API，返回值包括 Contact（email、phone、qq）、Like（Basketball、Swimming）、Personal Data（sex、age、nickname）。若xx请求过来的一个访问令牌 access_token 的 scope 权限范围只对应 Personal Data，那么包含该 access_token 值的请求就不能获取到 Contact 和 Like 的信息。

这种权限范围的粒度要比“不同的权限对应不同的操作”的粒度要小，遵循最小权限范围原则。

2.3 不同用户对应不同数据

这种权限实际上只是换了一种维度，将其定位到用户。

一些基础类信息，比如获取地理位置、天气预报，不带用户归属属性，即这些并不归属某用户，是公有信息。这样信息，平台提供出去的 API 接口都是“中性”的，没有用户属性。

但更多场景却是基于用户属性。用户每次推送文章，xx都要知道文章是哪个用户的。用户为xx授权，xx获取的 access_token 实际上就包含公众号用户的这个用户属性。

公众号开放平台的受保护资源服务每次接收到xx的请求，都会根据该请求中

access_token 的值找到对应的用户 ID，继而根据用户 ID 查询到该用户的文章，即不同用户对应不同文章数据。

3 微服务架构下 API GATEWAY 的意义

现在已是分布式系统，若有很多受保护资源服务，比如提供用户信息查询的用户资源服务、提供文章查询的文章资源服务、提供视频查询的视频资源服务，那每个受保护资源服务岂不是都要把上述权限范围校验执行一遍，不就有大量重复？

为解决这问题，应有统一网关层处理校验，所有请求都会经过 跳转到不同受保护资源服务。如此无需在每个受保护资源服务上都做权限校验，只在 API GATEWAY 做即可。

参考

• 如何安全、快速地接入OAuth 2.0