查了些资料. 大多都是网关Gateway,做认证.鉴权.
也有根据实际情况,在gateway做认证和部份鉴权+单微服务内做业务鉴权.
我觉得自己的比较合适第二种,gateway+单微服务这种方式.但还有几点疑惑还在犹豫中
环境: spring cloud gateway,nacos,openfeign,(认证.鉴权,授权未使用三方库)
认证没有什么问题.
鉴权部分的话,应该只能做根据url的鉴权. 配置url+权限这种方式.这种方式需与api做协调,一边加了url,也需要在gateway层配置这个url+允许权限+拒绝权限.
需要在业务鉴权,比如管理员,发布者,拥有同样的功能,甚至比发布者更多功能.为了减低相同逻辑的维护成本, 所有觉得用鉴权这种方式比较合适一点.
因为gateway加载过这个权限列表,所以在转发时带上这个权限列表,在单个微服务内,直接拿这个权限列表做鉴权,这种方式需要带着权限列表跑.这种方式避免多次加载权限列表,微服务将脱离auth依赖,缺点是需要带着这个列表到处跑.
这种方式需要多次鉴权,gateway跑auth鉴权,微服务跑auth鉴权. 所有需要鉴权的服务都依赖auth
微服务中定义权限,自动注册到权限模块.
这些只是一些构思,还没有去实现,肯定有不合理的地方,也有些问题还没考虑到.
欢迎大家指点一二. 让我能有机会一次性比较全面的完成这个模块.
常用的鉴权有url鉴权、角色菜单鉴权，题主提到的鉴权也比较完善，此外可以考虑将权限做成动态配置，即做成前端配置
1、前端设置不同角色
2、前端配置不同角色对应的权限标识符
3、前端配置接口的访问权限标识符或者角色
4、配置的角色、权限标识符和接口的关系可以保存到数据库以及缓存中
5、重点是后端接口开发时采用注解形式进行鉴权，需要鉴权的接口就配置注解，注解内可以传入参数，比如可以访问的角色或者权限标识符等
6、接口访问时，触发注解切面，请求Auth模块进行鉴权
7、Auth从注解内参数获取可访问角色或权限标识符，以及从缓存中查询到前端配置的角色或权限标识符
8、Auth从请求上下文中获取当前用户角色以及对应权限标识符，跟第6步查询到的作对比进行鉴权
优点：
1、动态配置权限，可在不重启服务情况下修改权限
2、鉴权交由Auth统一处理，各服务仅需要将需要鉴权的接口，以及接口认证的角色以及权限标识符传给Auth即可
3、注解类写在Common模块，各微服务引入即可，在注解实现类中调用Auth模块
缺点：
1、接口鉴权实际上不在gateway中进行鉴权
2、为保证鉴权效率，将用户的角色以及对应权限标识符放在token或者redis缓存中，从上下文中拿到用户即可快速获取到用户拥有的角色以及对应权限标识符，但是这样会导致用户更新角色和权限标识符变得困难，只有token到期之后才会重新获取最新的角色以及对应权限标识符，存在一定延迟
优化：
1、可以将用户角色以及对应权限标识符根据用户ID存在缓存中，前端动态更新用户角色或者权限标识符时，即可快速修改，避免缺点2中延迟性，但是会加大开发难度，暂未真正实现