基于用户身份的流量重定向方案优化及WASM插件相关问题咨询

一、当前方案的优化点 #

现有流程存在可精简的环节，优化方向如下：

• 合并两个WASM Filter的逻辑：将两次JWT检查与重定向逻辑整合到单个Filter中，减少网关的处理环节，降低请求链路延迟。
• 移除冗余验证：第二个WASM Filter已完成补充JWT的存在性检查，VirtualService中关联的RequestAuthentication可移除，仅保留AuthorizationPolicy用于细粒度权限校验（如有需求）。
• 优化重定向流程：将获取补充JWT的前端重定向改为WASM内部异步调用微服务，直接在网关层完成JWT的获取与注入，无需前端跳转，减少用户体验损耗。

二、第三步JWT回传的实现方法 #

让微服务生成的JWT传回初始请求，常用两种可靠方式：

1. Cookie存储+重定向
   微服务生成JWT后，设置HttpOnly、Secure属性的Cookie（规避XSS风险），然后根据请求中的Referer头或前端传入的redirect_uri参数，重定向回用户最初的请求地址。后续WASM Filter可直接从Cookie中读取该JWT。
2. 请求头注入（后端调用场景）
   如果采用WASM直接调用微服务的优化方案，微服务可直接返回JWT，WASM将其注入请求的自定义头中，无需前端参与，直接传递到后续流程。

三、WASM插件直接查询数据库的可行性与建议 #

可行性 #

Istio WASM插件支持发起外部HTTP请求，可通过PostgREST、Hasura这类数据库REST封装工具查询数据，再在WASM内部生成JWT。但直接调用数据库原生TCP协议（如MySQL、PostgreSQL）的支持度有限，需额外适配，兼容性较差。

不建议直接在WASM中查库的核心原因 #

• 性能损耗：网关作为流量入口，每个请求都发起数据库查询会大幅增加响应延迟，降低整体吞吐量。
• 稳定性风险：网关直接依赖数据库可用性，一旦数据库故障，会导致所有请求无法处理，扩大故障影响范围。
• 维护与安全成本：WASM插件中存储数据库凭证存在泄露风险，且在WASM中编写查询逻辑的调试、更新成本远高于单独的微服务。

替代简化方案 #

将查询数据库的微服务做成轻量Sidecar，与Istio Gateway部署在同一Pod内，减少跨Pod网络开销；或者将该逻辑整合到Keycloak的自定义认证器中，在用户登录时直接拉取补充数据并写入JWT，彻底省去后续的补充JWT校验环节。

内容的提问来源于stack exchange，提问作者Kemical