为接入oauth2.0，受保护资源服务需要做哪些工作

受保护资源最终指的还是Web API，比如说，访问头像的API、访问昵称的API。对应到我们的打单软件中，受保护资源就是订单查询API、批量查询API等。

首先要做的是检查令牌的合法性，之后确定权限范围。提供一个统一的网关层来处理校验。

1. 检查令牌的合法性

受保护资源来调用授权服务提供的检验令牌的服务

方案有两个：

• 共享存储方案

  比如授权服务依赖一个数据库，受保护资源服务也依赖这个数据库

• 校验端点方案

  在如今已经成熟的分布式以及微服务的环境下，不同的系统之间是依靠服务而不是数据库来通信了，可以让授权服务给受保护资源服务提供一个校验端点Introspection Endpoint

如果是JWT令牌，由于其具有“自编码”的能力，所以无需调用授权服务来检验令牌，但由于JWT令牌一般都是加密的，比如授权服务使用私钥将其加密，那么受保护资源服务需要请求授权服务，获取公钥，进行解密。

获取公钥的方式一般有两种：

• 方式1：访问授权服务，获取公钥
• 方式2：在受保护资源服务导入公钥

2. 确定权限范围

在我们处理受保护资源服务中的逻辑的时候，校验权限的处理会占据很大的比重。你想啊，访问令牌递过来，你肯定要多看看令牌到底能操作哪些功能、又能访问哪些数据吧。现在，我们把这些权限的类别总结归纳下来，最常见的大概有以下几类。

权限维度1：不同的权限对应不同的操作

com.oauth.ch03.ProtectedServlet 使用此类来模拟【受保护资源服务】

String accessToken =  request.getParameter("token");

//根据当时授权的token对应的权限范围，做相应的处理动作
//不同权限对应不同的操作
String[] scope = com.oauth.ch03.OauthServlet.tokenScopeMap.get(accessToken);

StringBuffer sbuf = new StringBuffer();
for(int i=0;i<scope.length;i++){
    sbuf.append(scope[i]).append("|");
}

if(sbuf.toString().indexOf("query")>0){
    queryGoods("");
}

if(sbuf.toString().indexOf("add")>0){
    addGoods("");
}

if(sbuf.toString().indexOf("del")>0){
    delGoods("");
}

权限维度2：不同的权限对应不同的数据

这里的数据，就是指某一个API里包含的属性字段信息。比如，有一个查询用户信息的API，返回的信息包括Contact（email、phone、qq）、Like（Basketball、Swimming）、Personal Data（sex、age、nickname）。如果第三方软件软件请求过来的一个访问令牌access_token的scope权限范围只对应了Personal Data，那么包含该access_token值的请求就不能获取到Contact和Like的信息，关于这部分的代码，实际跟不同权限对应不同操作的代码类似。

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

权限维度3：不同的用户对应不同的数据

这种权限是什么意思呢？其实，这种权限实际上只是换了一种维度，将其定位到了用户上面。

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

更多的场景却是基于用户属性的。还是以第三方软件打单软件为例，商家每次打印物流面单的时候，第三方软件打单软件都要知道是哪个商家的订单。这种情况下，商家为第三方软件软件授权，第三方软件软件获取的access_token实际上就包含了商家这个用户属性。

String user = com.oauth.ch03.OauthServlet.tokenMap.get(accessToken);
queryOrders(user);

3. 提供一个统一的网关层来集中处理校验

更多内容，参考：oauth2.0开发总结