ASP.NET Core 3.1 Identity登录时如何传递无持久化额外变量作为自定义声明

自定义UserClaimsPrincipalFactory能否直接传入登录时的临时变量做声明 #

默认框架机制下无法实现直接传参。
你已经通过DI注册的自定义UserClaimsPrincipalFactory实现，是由Identity框架从DI容器中解析的托管服务，框架内部触发CreateAsync方法时，只会传入校验通过的用户实例，没有预留任何透传登录流程临时业务参数的入口。你在UserRepository.Logar方法里接收到的myExtraStringVariableOrObject属于当前方法的局部作用域变量，和工厂实例的托管生命周期完全独立，框架自动调用工厂的链路里不存在把这个变量透传进去的通道，这条路默认是走不通的。

不硬传参的前提下，如何实现动态添加临时声明（无需持久化） #

结合你不需要存数据库、仅在本次登录流程动态加声明的需求，有两种成熟可落地的实现方式，完全适配你现有的代码结构：

方案1：在现有Logar方法中手动拼装带临时声明的ClaimsPrincipal #

这是改动最小、最直接匹配你当前代码场景的方式，不需要绕路到工厂的调用链路里取值：

• 流程调整：在Logar方法内完成用户密码校验、状态合法性校验后，不要直接调用框架默认的PasswordSignInAsync（这个方法会自动通过工厂生成ClaimsPrincipal，没有临时参数的插入入口）
• 先复用你已注册的ClaimsPrincipalFactory实例，生成包含所有基础用户声明的ClaimsPrincipal
• 直接在这个Principal对象上，把你本地作用域拿到的myExtraStringVariableOrObject转成对应Claim实例加进去
• 最后调用认证中间件的SignInAsync方法，把手动拼装好的带临时声明的Principal写入认证Cookie完成登录
• 核心代码参考：

// Logar方法内，用户校验通过后
var user = await _userManager.FindByNameAsync(input.UserName);
// 复用已注入的工厂生成基础声明
var principal = await _customClaimsPrincipalFactory.CreateAsync(user);
// 直接添加本次登录的临时声明，无需写入数据库
principal.Claims.Add(new Claim("MyExtraDynamicClaim", myExtraStringVariableOrObject.ToString()));
// 写入认证票据完成登录
await _signInManager.Context.SignInAsync(
    IdentityConstants.ApplicationScheme, 
    principal, 
    new AuthenticationProperties { IsPersistent = input.RememberMe });

• 方案优势：临时变量就在你当前方法的作用域里，不存在跨服务传值的链路断点，完全不需要改动已经注册好的工厂类逻辑，实现成本最低。

方案2：通过作用域上下文在工厂链路中透传临时变量 #

如果你希望所有自定义声明的生成逻辑都统一收敛到AdditionalUserClaimsPrincipalFactory里，不想在每个登录入口重复写加Claim的代码，可以利用ASP.NET Core的作用域服务实现透传：

• 定义一个仅用于传递登录临时参数的空上下文类：

public class LoginFlowTempContext
{
    public object? ExtraLoginParam { get; set; }
}

• 在ConfigureServices里把这个类注册为作用域服务：services.AddScoped<LoginFlowTempContext>();
• 在Logar方法里，从DI容器解析出同请求作用域的LoginFlowTempContext实例，把你收到的myExtraStringVariableOrObject赋值给它的属性
• 修改你的AdditionalUserClaimsPrincipalFactory构造函数，把LoginFlowTempContext作为依赖注入进来，在CreateAsync方法里直接读取这个上下文里存的临时参数，生成对应的Claim加入到声明集合中
• 注意触发顺序：必须保证你给LoginFlowTempContext赋值的操作，发生在SignInManager内部调用工厂生成ClaimsPrincipal之前，否则工厂读到的上下文值会是空。因为作用域服务在同一个HTTP请求链路里是单实例，只要顺序对，就能拿到正确的临时参数。

关键实现注意事项 #

• 这类通过流程注入的临时声明，没有和用户表做持久化关联，只要认证Cookie过期、重新走认证流程时，临时声明就会自动消失，完全符合你无需存库的要求
• 不要把高敏感信息放入这类临时声明，因为声明会存储在浏览器的认证Cookie中，可被解密读取
• 要注意边界场景：如果后续出现用户Claims刷新的触发点（比如用户更新个人信息后重新生成Principal），此时原登录请求的作用域已经被回收，工厂读到的临时上下文值会为空，临时声明就不会被生成，需要根据业务场景评估是否可接受。

内容的提问来源于stack exchange，提问作者Mauricio Ferraz