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等