为何向ClaimsPrincipal添加声明的微软示例代码是正确的？

为什么微软示例的写法是正确的？ #

微软示例中每次创建新ClaimsIdentity并添加到Principal的设计，是基于以下核心考量：

• 声明来源隔离
  现有ClaimsIdentity通常来自原始认证渠道（如JWT、Cookie、OAuth提供商），承载的是身份认证类声明（比如用户ID、用户名）；而IClaimsTransformation的职责是补充业务授权类声明（比如角色、权限）。将两类声明放在不同Identity中，能清晰区分数据来源和用途，避免污染原始认证数据，也方便后续排查问题时快速定位声明的生成环节。

• 兼容不可变的原始Identity
  部分认证源生成的ClaimsIdentity是只读的（比如JWT解析后生成的Identity，其Claims集合可能被标记为不可修改）。如果直接尝试往这类Identity中添加声明，会抛出异常或无法生效。创建新Identity的写法完全规避了这个兼容性问题，确保代码在各种认证场景下都能稳定运行。

• 天然支持幂等性与多身份场景
  示例中会先检查Principal是否已存在目标声明，再决定是否添加新Identity——即使TransformAsync被多次调用，也不会重复添加相同的业务声明。同时，ClaimsPrincipal本身就支持多Identity并存（比如用户同时拥有本地账户和企业AD账户），这种写法完全契合框架的设计初衷，为后续多身份扩展预留了空间。

为什么不直接将声明添加到现有ClaimsIdentity中？ #

除了上面提到的"原始Identity可能不可修改"之外，还有两个关键原因：

• 保护原始Identity的语义完整性
  原始Identity的AuthenticationType、IsAuthenticated等属性，是认证环节的核心状态标识。直接修改其Claims集合，可能会模糊这些状态的语义（比如让原始认证身份带上业务权限声明，混淆了"认证"和"授权"的边界）。新创建的Identity可以设置独立的AuthenticationType（比如自定义为"BusinessAuthorization"），明确标识这部分声明的用途。

• 避免潜在的状态冲突
  现有Identity可能被其他组件共享或监控，直接修改其Claims集合可能干扰依赖原始Identity状态的逻辑。创建新Identity是一种无侵入的扩展方式，不会影响原有认证流程的稳定性。

关于多Identity的补充说明 #

你遇到的Principal包含多个ClaimsIdentity的情况是正常的——ClaimsPrincipal会自动合并所有Identity的声明，当调用principal.HasClaim(...)或遍历principal.Claims时，会返回所有Identity中的声明，不会影响业务逻辑。如果确实希望减少Identity数量，也可以自定义逻辑：遍历现有Identity，找到标记为自定义类型的Identity并复用，不存在时再创建新的，但微软示例的写法是更通用、更安全的通用方案。

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