专栏名称: 芋道源码
纯 Java 源码分享公众号,目前有「Dubbo」「SpringCloud」「Java 并发」「RocketMQ」「Sharding-JDBC」「MyCAT」「Elastic-Job」「SkyWalking」「Spring」等等
目录
相关文章推荐
芋道源码  ·  5.6K ... ·  15 小时前  
ImportNew  ·  亚马逊程序员破防:AI ... ·  2 天前  
芋道源码  ·  面试官:为什么数据库连接很消耗资源? ·  2 天前  
芋道源码  ·  我用这11招,让接口性能提升了100倍 ·  2 天前  
51好读  ›  专栏  ›  芋道源码

微服务Token鉴权设计的几种方案

芋道源码  · 公众号  · Java  · 2025-04-25 09:30

正文

请到「今天看啥」查看全文



7329352197837029385


Token透传(不推荐)

刚开始接触微服务时网上给的方案大都数是通过透传Token做鉴权,但我认为这种方式不是很妥当。接着往下看:

这种方式通过透传Token使得各微服务都能获取到当前登录人信息,在代码编写上确实可能会方便,但我认为这不是一种很好的设计方式。

原因一:内部API与外部API混合在一起不太好区分。

原因二:内部调用的微服务API因该具备无状态性质,这样才能保证方法的原子性以提高代码复用率。

换句话说:B服务提供API时不因该关心当前是否为登录状态,登录状态应该由路由中的第一个服务校验维护,在调用后续服务时应该显示的传入相关参数。比如以下场景:

场景一:用户签到添加积分

场景二:后台管理员给用户手动添加积分

场景三:分布式调度批量增加用户积分

根据需求积分服务提供了一个给用户添加积分的API,如果你的API是通过获取的当前登录用户ID增加的积分,那么面对场景二时你需要重新编写一个给用户添加积分的API,因为当前登录的是后台管理员而不是用户(代码复用率较低)

不透传数据,显示的提供入参







请到「今天看啥」查看全文