多租户场景下需按租户隔离 token 管理：为每个租户维护独立 accesstoken、refreshtoken 及刷新状态；请求拦截器动态注入对应租户 authorization header；401 响应须携带租户标识并精准刷新；静默刷新防并发，失败仅清空该租户 token；存储需加 tenantid 前缀或用 indexeddb。

多租户场景下，Token 过期错误不能简单全局刷新或跳转登录页——因为用户可能同时在多个租户上下文里操作（比如切换 Tab 或 iframe），各租户的 Token 有效期、刷新机制、登出策略都可能不同。关键是要按租户隔离鉴权状态，并精准响应过期事件。

按租户维护独立的 Token 生命周期

不要共用一个全局 token 变量或 axios 默认 header。为每个租户（例如通过 subdomain、tenantId 请求头、或 URL path 前缀识别）维护独立的认证上下文：

• 用 Map 或对象缓存各 tenantId 对应的 accessToken、refreshToken、过期时间、刷新锁状态
• 请求拦截器中，根据当前请求所属租户动态注入 Authorization header
• 避免跨租户 token 混用：比如从 tenant-a 的页面发起 tenant-b 的 API 请求时，必须显式指定 tenant-b 的 token

401 响应需携带租户标识并分级处理

后端返回 401 时，务必在响应头（如 X-Tenant-Id）或响应体中明确指出是哪个租户的 token 失效，前端据此触发对应租户的刷新逻辑：

Auth0 Token Vault

通过 Auth0 Token Vault，代表已认证用户访问 Gmail、Slack、Google Calendar、GitHub 等第三方服务以及自定义 Auth0 连接。使用...

下载

• 若响应含 X-Tenant-Id: corp-x，只刷新 corp-x 的 token，不影响其他租户会话
• 若无租户标识，且当前上下文可推断（如当前路由含 /t/corp-x/），则 fallback 到路由解析
• 禁止对所有租户统一登出或清空 localStorage —— 这会导致用户在其他租户 Tab 中突然掉线

租户级静默刷新 + 容错降级

Token 即将过期前（如提前 60 秒），主动用 refresh_token 请求新 accessToken。但要防并发刷新和失败场景：

• 每个租户维护一个 refreshPromise，重复刷新请求复用同一个 Promise，避免多次调用刷新接口
• 刷新失败时，清除该租户 token 缓存，但不强制跳转；后续对该租户的请求再触发 401 处理流程
• 提供“当前租户已登出”轻提示（非全屏遮罩），并保留页面状态，允许用户手动重新登录该租户

避免共享存储导致的租户污染

localStorage/sessionStorage 是域级共享的，不能直接存 tenant-scoped token：

• 把 token 存为 tenantId_accessToken 键名（如 corp-x_accessToken），而非统一的 accessToken
• 使用 IndexedDB 或内存 Map 管理更安全；若必须用 localStorage，读写前始终拼接租户前缀
• 登出某租户时，只删其对应 key，不调用 clear()

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南