4. JWT与Token设计

在多租户SaaS架构中，JWT（JSON Web Token）不仅是身份凭证，更是跨服务传递租户上下文的核心载体。设计不当的载荷会导致租户隔离失效、权限越界或Token风暴。本节从载荷结构、签发策略、刷新机制三个维度，给出面向多租户的工程化方案。

4.1 多租户JWT载荷结构设计

标准JWT载荷（Payload）包含注册声明（iss、sub、exp等）和公共声明。多租户场景下，必须显式声明以下三个自定义字段：

一个完整的JWT载荷示例：

{
  "sub": "user_7890",
  "tenant_id": "t-abc123",
  "role": "workspace_admin",
  "permissions": [
    "read:workspace",
    "write:workspace",
    "read:member",
    "invite:member",
    "delete:member"
  ],
  "iat": 1710000000,
  "exp": 1710003600,
  "iss": "https://auth.saas.example.com"
}

4.2 Token签发策略

多租户场景下，Token签发必须绑定租户上下文。以下是标准签发流程：

1. 身份认证：用户通过用户名/密码、OAuth2.0或SSO完成认证。
2. 租户选择：用户选择要操作的租户（或系统根据子域名/请求头自动识别）。
3. 角色解析：查询该用户在选定租户下的角色，并解析出权限列表。
4. Token签发：使用RS256或ES256算法，用私钥签名生成JWT。
5. 返回Token：同时返回Access Token和Refresh Token。

签发策略对比表：

4.3 Token刷新策略

刷新流程需要额外校验租户上下文是否变更。当用户切换租户时，必须重新签发Token，而非直接刷新旧Token。

标准刷新流程：

1. 客户端携带Refresh Token请求刷新端点。
2. 服务端校验Refresh Token签名和有效期。
3. 校验Refresh Token是否被吊销（检查黑名单或版本号）。
4. 重新查询用户在当前租户下的角色和权限（防止租户内角色变更）。
5. 签发新的Access Token和Refresh Token（可选轮换）。
6. 返回新Token对，旧Refresh Token失效。

4.4 多租户JWT生命周期与鉴权流程

下图展示了从Token签发、请求鉴权到刷新的完整链路：

4.5 多租户Token安全最佳实践

4.6 多租户Token存储与传输

客户端Token存储方案对比：