Auth0 不原生支持多租户隔离，需全程贯穿 tenant_id：初始化、令牌解析、API 调用、缓存键及上下文传递均须显式绑定并校验，每个租户对应独立 client_id，ID Token 的 aud/iss 必须严格匹配租户预期值。
Auth0 本身不原生支持多租户身份源隔离，必须靠你自己的架构设计来补足租户边界——不是配个 domain 就完事，而是从认证上下文、令牌解析、API 调用到缓存键全部贯穿 tenant_id。
Auth0 初始化必须显式传参且区分 tenant scope
Auth0 Go SDK auth0.New() 不读环境变量，漏掉 client_id 或 domain 会直接 panic。更关键的是：多租户场景下，你不能共用一套 client_id 和 domain —— 每个租户应注册独立 Auth0 application（哪怕只是逻辑隔离），否则无法按租户控制 callback URL、allowed origins、scope 权限粒度。
- 每个租户对应一个 Auth0 application，
domain相同（如your-org.us.auth0.com），但client_id不同；management API 的audience必须统一为https://your-org.us.auth0.com/api/v2/，不能按租户拆 - OIDC 登录时，
AuthCodeURL中的state必须绑定租户上下文（比如拼接tenant_abc:random_string），回调时先解出 tenant_id，再查该租户对应的client_id去换 token - 别在 middleware 里硬编码单个
auth0.Client实例——要按租户动态构造，或至少用 map[string]*auth0.Client 缓存，避免跨租户复用 client 导致 audience 错乱
ID Token 解析必须带 tenant_id 校验 aud 和 issuer
Auth0 返回的 ID Token 是 JWT，但 aud 字段默认是 client_id，iss 是固定 domain。如果多个租户共用同一 client_id，你就无法区分 token 归属；若强行用不同 client_id，则必须在解析时校验 aud 是否匹配当前租户预期值，否则前端可伪造请求绕过租户隔离。
- 解析前从 JWT 的
payload提取aud，查表确认是否属于当前租户合法的client_id列表 -
issuer必须严格等于https://your-domain.auth0.com/（注意末尾斜杠），不能只比对域名部分 - JWKS 加载地址固定为
https://your-domain.auth0.com/.well-known/jwks.json，但解析时要用jwt.WithKeySet()+ 动态 JWK Set，不能 fallback 到静态公钥 - 推荐用
golang-jwt/jwt/v5配合lestrrat-go/jwx/v2/jwk，手动调用jwk.Fetch(ctx, jwksURL)获取 key set
Management API 调用需 tenant-aware scope 和 subject 绑定
调用 /api/v2/users 等接口时，Auth0 不自动过滤租户数据。你得靠 subject（即 sub claim）和租户上下文双重约束：token 的 sub 是全局唯一用户 ID，但必须结合当前请求的 tenant_id 才能定位到该租户下的用户元数据。
立即学习“go语言免费学习笔记（深入）”；
- Management API 的
scope（如read:users）要在 Auth0 控制台 API 设置里启用，且 scope 权限必须按租户配置——比如租户 A 只能读自己域下的用户，不能读租户 B 的 - 调用
GET /api/v2/users/{id}时，{id}必须是 Auth0 用户 ID（auth0|xxx格式），但后续业务逻辑必须检查该用户是否归属当前tenant_id（查你自己的tenant_users关联表） - 别用 Management API 创建用户——用户应在租户上下文中注册后，再调用 Auth0 的
POST /api/v2/users并显式设置app_metadata.tenant_id字段 - 所有 Management API 请求头必须带
Authorization: Bearer {mgmt_token}，这个 token 要用租户专属client_id/client_secret换，不能复用
缓存与上下文传递必须强制 tenant_id 注入
JWT 解析成功后，tenant_id 必须立刻注入 context.Context，并贯穿整个请求生命周期。任何缓存 key、DB 查询、下游 HTTP 调用，都不得遗漏这个字段——漏一次，就可能把租户 A 的配置缓存覆盖给租户 B。
- 用
ctx = context.WithValue(ctx, tenantKey, tenantID)注入，tenantKey推荐定义为struct{}类型避免冲突 - Redis 缓存 key 必须形如
tenant:{tenant_id}:user:{sub}，禁止出现user:{sub}这种无租户前缀的写法 - Ent 或 sqlc 生成的查询方法，统一封装
WithTenant(ctx)方法，在 WHERE 条件中自动追加tenant_id = ? - HTTP 客户端调用下游服务时，必须透传
X-Tenant-IDheader，但下游服务不能信任该 header——它只用于链路追踪，真实租户判定仍以认证上下文为准
真正容易被忽略的点在于：Auth0 是身份源，不是租户控制器。它只管“你是谁”，不管“你属于哪个租户”。tenant_id 必须由你自己的认证流程推导、绑定、传递，并在每一层做显式校验——没有魔法开关，只有代码里每处 WHERE、每个 cache.Key、每次 ctx.Value() 都写对了，才叫落地。
