OAuth2.0协议(五)、可落地的微服务混合jwt和token模式

原则上token只要满足唯一性、不连续性、不可猜性就可以,但是针对于内网和外网需求场景在安全性和扩展性上要求是不同的。一般内网环境可以使用jwt,而外网则要使用普通的token。使用普通token其本身不能像jwt一样通过工具类反解析就可以获取信息,而是需要调用授权服务,授权服务调用存储的redis或者mysql存储才能知道绑定的资源和资源粒度。

如果微服务架构体系需要同时支持内外网基于token而非session的系统,那么本架构应该适用大部分体量的架构,如下图:

架构图例说明:

1、Customer、EU(End User)这里可能是浏览器或者Android、ios的前端,并且这里可能是内网环境也可能是外网环境,其中如果是内网环境可以使用jwt,如果是外网环境最好使用token;

2、Nginx层,负载均衡、反向代理、静态缓存 不啦不啦。。。

3、Web层即前后端分离后的前端应用部署的位置,由前端团队维护,可以基于Spring MVC+模板引擎(Thymeleaf等),当然现在的项目基本都是基于node.js 技术栈;

4、API网关,前些年微服务选型可能会基于Zuul,现在基本都会基于 Spring Cloud Gateway进行搭建;

    gateway网关的拆分部署粒度:这里的网关层可以基于B端和C端流量的隔离,也可以进一步按照前端的分类进行隔离,也可以基于流量的大小进行隔离等;我们可以基于gateway的filter等拦截器技术实现,限流、日志监控、已经CORS等功能。

    这里gateway还承担着两个重要的角色,

 5、IDP服务

IDP 是 Identity Provider 的简称,主要负责 OAuth 2.0 授权协议处理,OAuth 2.0 和 JWT 令牌颁发和管理,以及用户认证等功能。IDP 使用后台的 Login-Service 进行用户认证。对于 IDP 的技术选型,当前主流的 Spring Security OAuth,或者 RedHat 开源的 KeyCloak,都可以考虑。其中,Spring Security OAuth 是一个 OAuth 2.0 的开发框架,适合企业定制。KeyCloak 则是一个开箱即用的 OAuth 2.0/OIDC 产品。

6、 BFF 层

BFF(Backend for Frontend)主要用于对前端的后端领域服务的聚合、个人的开发经验中该层可以聚合下层多个微服务或者领域的数据,进行服务调用的编排。并且这一个可能会使用线程池并行对多个相互独立的领域数据进行调用,再在主线程中处理聚合维度的数据。并且这一层可以在业务允许范围内进行该层的数据缓存。

7、微服务层

    微服务层个人接触的很多项目可能没有BFF层,则其代码就下沉到单个的微服务中,整个微服务的边界控制非常乱。按照该架构模型需要在微服务的filter层处理接口需要的token关联的上下文信息。

具体个人认为有两种方式处理token和jwt流程:

1、gateway的filter层统一根据白名单验证token和jwt,验证token的时效性等,jwt比较简单只需要一个Util工具类进行反解析放入ThreadLocal,如果下面服务需要在线程池(或切换线程)中还能使用,可以将ThreadLocal换为阿里的TransmittableThreadLocal。

这样做的效果就是统一,从网关服务以下的都只有jwt,底层不用再调用认证服务,底层代码统一。不好的就是不论接口本身是否需要外网token的用户和认证信息,都在网关层执行了一次rpc,有一定的性能损耗,最好是将token转jwt的信息存放在redis中。

 

2、也可以不在网关层做处理,只是底层需要解析数据时,才去调用rpc,这样做的好处就是资源的利用;但是需要两个filter处理token和jwt。

 

根据自己经历的项目对BFF层的思考,也欢迎讨论:

1、BFF层按照什么进行拆分?

首先BFF的全称Backend For Frontend,既然是for 前端那么拆分粒度自然以前端为主,再分解下层微服务的粒度进行整合。个人理解可以按照下面的粒度进行拆分:

  1. BFF是为前端做的聚合,那么可以先按照前端的端进行拆分,也就对B端流程和C端流程进行了隔离;
  2. 每个端可以再按照业务领域进行拆分,比如有个复杂的APP: 首页BFF、门店BFF、搜索BFF、活动BFF等;
  3. 如果某些业务比较复杂,也可以单独抽取一个BFF,比如自己之前的 单品页BFF,去统计底层各个维度的数据,开了17个子线程的任务去查询,然后再在主线程中阻塞组装结果。

2、BFF层本身还需要进行分层吗?

     看业务复杂度,如果非常复杂可以考虑分层,最好不要分层。gateway层其实已经可以对BFF拆分抽象做分组,比如B端流量和C端流量。并且从BFF往Gateway层抽就比较方便了,只是增加Gateway和修改yml配置。

3、BFF可以连数据库吗?

如果是B端可以考虑连库,C端主要作用是聚合底层各路数据,所以经常会涉及线程池并发异步进行获取,如果业务允许,该部分还可以有自己维度的缓存。

这个几篇文章一直在分析OAuth2.0协议的各种类型和适用场景,但是最好不要学习了之后为了用而用,可以做以下的思考和讨论:

  • 一定要使用OAuth2.0协议吗?
  • 要使用OIDC协议吗?要使用sso单点登录吗?
  • gateway网关与认证服务IDP服务要分开(独立成服务)吗?IDP与登录服务要单独部署(独立成)吗?
  • 一定要使用混合模式,并且实现OAuth2.0的token转jwt吗?可能公司知名度就很低,没有攻击的价值,并且开发人员的情况就比较低,不适合复杂的权限认证体系。

可能答案都是否定的,没有最好的形态,适合当前项目架构的就是最好的,但是要知道服务发展的后续该怎么调整,知道业界的一些标准。

这里一直没有讨论授权认证体系,和权限模型的具体实现,个人理解可以根据公司和项目需求的情况,做一下的权衡:

  1. 完全自研(根据Oauth2.0等协议,设计实现)
  2. 基于shiro、spring security等框架进行搭建,同时两个框架都能集成OAuth2.0、OIDC
  3. 使用三方产品,【CAS、KeyClack(开源可定制开发)】、Authing等

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Spring Security是一个主流的Java Web安全框架,它提供了许多现成的安全功能如身份认证、授权和攻击防护。基于Spring Security,我们可以构建出一个安全可靠的Web应用程序。JWT是一种轻量级的身份实体认证方法。在Web应用程序中,用户登录成功之后,服务器会颁发一个JWT令牌给客户端,客户端每次访问时需要携带这个JWT令牌,服务器通过验证JWT令牌的合法性来认证用户身份。OAuth2.0是一个授权框架,它定义了四种角色:资源所有者、客户端、授权服务器和资源服务器。在OAuth2.0框架下,资源服务器只有在通过授权服务器验证后,才会向客户端提供访问资源的权限。 Spring Security提供了对JWTOAuth2.0的支持。通过集成JWTOAuth2.0,我们可以构建出一个更加安全和灵活的Web应用程序。具体地,我们可以使用Spring Security的JWT机制来实现用户身份认证,并使用OAuth2.0机制来实现对资源的授权。这意味着,我们可以通过Spring Security来管理应用程序中所有的安全相关事务,包括用户的认证和授权。 使用Spring Security的JWTOAuth2.0,我们可以实现几种不同的认证和授权模式,例如,密码模式、授权码模式和刷新令牌模式等。每种模式都具有自己的使用场景和优缺点。例如,密码模式适用于Web应用程序需要进行用户身份认证的场景,而授权码模式适用于Web应用程序需要访问第三方资源的场景。 综上所述,Spring Security是一个强大的Java Web安全框架,它提供了许多功能,包括身份认证、授权和攻击防护等。使用Spring Security的JWTOAuth2.0,我们可以实现更加安全和灵活的Web应用程序。通过选择不同的认证和授权模式,我们可以满足不同的使用场景和需求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值