Asp.Net Core UserClaimsPrincipalFactory自定义Claims丢失原因排查

这种数小时后自定义Claims莫名消失的问题我碰到过好多次，基本都和身份验证票证的生命周期或者Claims的持久化逻辑有关，给你梳理几个最可能的原因和排查方向：

1. 身份验证票证刷新时未重新生成自定义Claims #

如果你用的是Cookie认证，默认开启SlidingExpiration的情况下，当用户持续活动触发Cookie刷新时，很多开发者会忽略重新调用自定义UserClaimsPrincipalFactory来生成完整Claims。此时系统会用默认逻辑重新生成票证，只保留基础的用户名Claims。

• 排查：检查你的认证配置（比如Program.cs里的AddCookie），确保在OnValidatePrincipal事件中重新调用你的工厂类来更新Claims，示例代码大概是这样：

services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(options =>
    {
        options.Events.OnValidatePrincipal = async context =>
        {
            var factory = context.HttpContext.RequestServices.GetRequiredService<YourCustomClaimsPrincipalFactory>();
            var newPrincipal = await factory.CreateAsync(context.Principal.Identity.Name);
            context.ReplacePrincipal(newPrincipal);
            context.ShouldRenew = true;
        };
    });

2. 缓存逻辑导致Claims不完整或过期 #

不少项目会缓存ClaimsPrincipal来提升性能，但如果缓存过期时间设置过短，或者缓存更新时只存储了基础用户信息，没有包含自定义Claims，就会出现数小时后Claims丢失的情况。

• 排查：查找项目中是否有针对用户身份的缓存代码（比如用IDistributedCache或IMemoryCache），检查缓存的过期时间，以及缓存写入时是否完整序列化了包含自定义Claims的ClaimsPrincipal。

3. 隐性重新登录时未调用自定义工厂 #

有些场景下系统会隐性重新创建ClaimsPrincipal，比如Session过期后自动登录、身份验证中间件重新验证用户身份时，如果此时没有注入并使用你的自定义UserClaimsPrincipalFactory，而是用了默认实现，就只会生成基础的用户名Claims。

• 排查：检查登录逻辑、身份验证相关的中间件代码，确保所有需要生成ClaimsPrincipal的地方都明确使用了你自定义的工厂类，没有 fallback到默认的UserClaimsPrincipalFactory。

4. JWT Token刷新时遗漏自定义Claims（如果用Bearer认证） #

如果是JWT认证，自定义Claims只会在Token生成时加入。如果刷新Token的逻辑没有重新调用你的工厂类生成完整Claims，新的Token就只会包含基础用户标识，导致数小时后旧Token过期，新Token里没有自定义Claims。

• 排查：检查Token生成接口（比如/refresh-token）的逻辑，确保刷新时重新调用自定义工厂生成包含所有Claims的新Token；同时检查AddJwtBearer的配置，确认没有过滤或丢弃自定义Claims的逻辑。

5. 会话状态过期或存储异常 #

如果你的应用依赖会话（Session）来存储用户Claims，当会话过期时间设置过短，或者会话存储（比如Redis、SQL Server）出现异常导致会话数据丢失，重新获取会话时就只能拿到默认的用户名标识。

• 排查：检查会话配置的过期时间（比如services.AddSession(options => { options.IdleTimeout = TimeSpan.FromHours(8); })），查看会话存储的日志是否有异常，确认会话中存储的Claims是否包含自定义项。

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