多实例WebApp基于Azure应用网关的JWT令牌方案咨询

API 探路者

2026-5-19

嘿，针对你这个从单实例转多实例WebApp、部署在Azure应用网关后还要保留自定义多租户认证的场景，我整理了一套非常落地的最佳实践方案，分模块给你拆解清楚：

核心方案概述

核心思路是用无状态JWT令牌替代原来的内存会话表，配合Azure应用网关的负载均衡能力，同时保留你现有的自定义认证逻辑和自有数据库，完全不需要依赖AD。这样既解决了多实例会话共享的问题，又满足多租户隔离的需求。

1. JWT令牌体系设计（替代内存会话）

这是整个方案的核心，要把原来的「内存表匹配会话-令牌-用户」改成无状态的JWT验证：

令牌Payload设计：必须包含这些字段：
- sub：用户唯一标识（和你数据库里的用户ID对应）
- tenant_id：租户ID（多租户隔离的核心标识）
- exp：令牌过期时间（建议设15-30分钟，减少泄露风险）
- iss：签发者（比如你的服务域名，用来验证令牌来源）
- aud：受众（你的WebApp域名，确保令牌只在你的服务内有效）
  还可以额外加roles或permissions字段，存储用户在当前租户内的权限，避免每次请求都查数据库。
签名策略：一定要用RSA256非对称加密，别用HS256对称加密。私钥只保存在你的令牌签发服务（比如自定义认证模块）里，所有WebApp实例只存公钥，用来验证令牌的合法性。这样多实例不需要共享密钥，安全又好维护。
令牌刷新机制：因为access_token过期短，要设计refresh_token来实现无感刷新。refresh_token可以存在你的数据库里（关联用户+租户），用户用过期的access_token+refresh_token请求刷新接口时，验证refresh_token合法性后，签发新的access_token。

保留你现有的自有数据库认证逻辑，调整成适配多实例的模式：

认证流程：
1. 用户提交租户ID、用户名密码到登录接口；
2. 服务从自有数据库验证用户身份（要关联租户ID，确保用户属于该租户）；
3. 验证通过后，用私钥签发access_token和refresh_token；
4. 返回给客户端，建议把refresh_token存在HttpOnly、Secure、SameSite=Strict的Cookie里，access_token可以存在客户端内存或安全的存储中。
多实例验证逻辑：所有WebApp实例收到请求时，先提取Authorization: Bearer <token>头里的令牌，用公钥验证签名、过期时间、租户ID等信息，验证通过后再处理业务逻辑。全程无状态，不需要共享任何内存数据，完美适配负载均衡。

利用网关的负载均衡和路由能力，同时做一些安全加固：

路由规则：如果把认证模块拆成了独立服务，就把/api/auth/*这类请求路由到认证服务实例池，业务请求路由到WebApp实例池；如果没拆分，就统一路由到WebApp实例池，每个实例自己处理令牌验证。
安全配置：
- 开启WAF（Web应用防火墙），拦截SQL注入、XSS等恶意请求；
- 强制HTTPS跳转，确保所有请求都是加密传输，防止令牌被窃取；
- 不需要开启会话亲和性（除非你的业务有特殊依赖），因为JWT是无状态的，网关可以随意把请求分发到任意实例。
健康检查：给WebApp实例配置健康检查路径（比如/health），网关会自动剔除不健康的实例，保证服务可用性。

除了JWT里的tenant_id，还要在业务层做好数据隔离：

数据库层面：所有业务表都添加tenant_id字段，查询、修改数据时必须带上tenant_id条件，绝对禁止跨租户访问数据；
权限层面：结合JWT里的roles/permissions字段，在WebApp实例里做细粒度的权限控制，比如判断用户是否有权限访问当前租户下的某个资源。

令牌撤销：因为JWT是无状态的，没法主动撤销令牌，所以要维护一个refresh_token黑名单（存在Redis或数据库里）。当用户注销、令牌泄露时，把对应的refresh_token加入黑名单，刷新令牌时先检查黑名单，拒绝非法请求。
客户端存储：access_token尽量存在客户端内存中（比如SPA应用），避免存在localStorage被XSS窃取；refresh_token一定要用HttpOnly Cookie，防止JS读取。
密钥轮换：定期轮换RSA密钥对，避免长期使用同一密钥带来的安全风险。轮换时要确保所有WebApp实例都更新公钥，旧密钥可以保留一段时间处理未过期的旧令牌。

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