单个JWT token携带多账号权限的实现方式及行业标准咨询

你的初步设计完全符合行业通用实践，目前IETF没有针对多账号关联权限的强制JWT标准声明，但这类场景在多租户SaaS、账号关联类产品中已经有非常成熟的落地共识，核心方案分为两类，适配不同的业务场景：

方案1：结构化accounts数组（你当前的设计） #

这是中小规模场景下的最优方案，适合单用户关联账号数≤20的场景，优势是资源服务无需额外查询权限存储，直接解析JWT即可完成鉴权，性能损耗最低。
你可以根据权限粒度选择用roles或者scopes字段：

• 粗粒度角色管控（比如admin/guest两级权限）：直接保留roles字段即可
• 细粒度接口权限管控：替换为账号专属scopes字段，示例结构如下：

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "aud": "[api]",
  "accounts": [
     {
        "account_id": 123,
        "scopes": ["order:read", "order:write", "user:manage"]
     },
     {
        "account_id": 234,
        "scopes": ["order:read"]
     }
   ]  
}

鉴权逻辑也非常直接：解析JWT后匹配请求路径中的account_id，校验对应账号下的角色/权限是否覆盖当前接口要求即可。

方案2：扁平化权限声明 #

如果单用户关联的账号数较多（20~50个），结构化数组会导致JWT体积过大，容易触发反向代理、CDN的请求头大小限制，这时可以用扁平化的声明格式，有效压缩payload体积：

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "aud": "[api]",
  "account_perms": ["123:admin", "234:guest"]
}

鉴权时直接判断{路径中的account_id}:{需要的角色/权限}是否存在于account_perms数组中即可。

特殊场景适配 #

如果单用户关联账号数超过50，不建议把所有权限都塞入JWT：
JWT最终会放在Authorization请求头中，大部分云服务商的CDN、负载均衡默认只支持最大8KB的请求头，权限过多会导致请求被拦截。这种场景下JWT只需要存储用户唯一标识，资源服务收到请求后，携带用户ID和请求中的account_id去权限中心/缓存查询对应权限即可。

内容的提问来源于stack exchange，提问作者Kristoffer Brinch Kjeldby