受保护资源最终指的还是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开发总结