IdentityServer4+JWT：自定义用户sub声明为GUID而非有序整数

哈哈，这个场景我之前做性能优化的时候刚好碰到过！用IdentityUser<long>解决大数据查询性能问题，但又不想暴露有序ID的风险，确实需要把令牌里的用户标识换成GUID。结合你已经添加了额外字段的情况，给你一步步说怎么实现：

假设你已经在自定义的ApplicationUser（继承自IdentityUser<long>）里加了PublicId（Guid类型）字段，接下来只需要做这几个关键配置：

1. 自定义ProfileService，替换默认的用户声明 #

IdentityServer4里的IProfileService是管令牌里用户信息生成的核心组件，我们重写它，把默认的有序long类型sub（用户ID）声明换成你的GUID：

public class CustomProfileService : IProfileService
{
    private readonly UserManager<ApplicationUser> _userManager;

    public CustomProfileService(UserManager<ApplicationUser> userManager)
    {
        _userManager = userManager;
    }

    public async Task GetProfileDataAsync(ProfileDataRequestContext context)
    {
        // 从当前上下文获取用户
        var user = await _userManager.GetUserAsync(context.Subject);
        if (user == null)
        {
            throw new ArgumentException("找不到指定用户");
        }

        // 先把默认的long类型用户ID声明删掉
        var existingSubClaim = context.IssuedClaims.FirstOrDefault(c => c.Type == ClaimTypes.NameIdentifier);
        if (existingSubClaim != null)
        {
            context.IssuedClaims.Remove(existingSubClaim);
        }

        // 添加上我们的GUID类型用户标识
        context.IssuedClaims.Add(new Claim(ClaimTypes.NameIdentifier, user.PublicId.ToString()));

        // 这里可以按需加其他需要的声明，比如邮箱、角色之类的
        if (!string.IsNullOrWhiteSpace(user.Email))
        {
            context.IssuedClaims.Add(new Claim(ClaimTypes.Email, user.Email));
        }
    }

    public async Task IsActiveAsync(IsActiveContext context)
    {
        // 判断用户是否有效（这里可以根据你的业务规则调整，比如是否邮箱验证、是否禁用等）
        var user = await _userManager.GetUserAsync(context.Subject);
        context.IsActive = user != null && user.EmailConfirmed;
    }
}

2. 注册自定义ProfileService到DI容器 #

在Startup.cs的ConfigureServices方法里，把默认的ProfileService替换成我们自己的：

services.AddIdentityServer()
    .AddAspNetIdentity<ApplicationUser>() // 关联我们的自定义用户模型
    .AddProfileService<CustomProfileService>() // 替换成自定义的ProfileService
    // 下面是你原来的其他配置，比如添加客户端、API资源之类的，保持不变
    .AddInMemoryClients(Config.GetClients())
    .AddInMemoryApiResources(Config.GetApiResources())
    ;

3. （可选但关键）API端根据GUID查找用户 #

如果你的下游API需要根据令牌里的GUID找到对应的用户（用内部的long ID做数据查询），可以加个IClaimsTransformation来做转换：

public class ClaimsTransformer : IClaimsTransformation
{
    private readonly UserManager<ApplicationUser> _userManager;

    public ClaimsTransformer(UserManager<ApplicationUser> userManager)
    {
        _userManager = userManager;
    }

    public async Task<ClaimsPrincipal> TransformAsync(ClaimsPrincipal principal)
    {
        var identity = principal.Identity as ClaimsIdentity;
        var publicIdClaim = identity?.FindFirst(ClaimTypes.NameIdentifier);
        
        if (publicIdClaim != null && Guid.TryParse(publicIdClaim.Value, out var publicId))
        {
            // 根据GUID找到用户
            var user = await _userManager.FindByClaimAsync(new Claim("PublicId", publicId.ToString()));
            if (user != null)
            {
                // 把内部用的long ID添加到声明里，方便后续业务使用
                identity.AddClaim(new Claim("InternalUserId", user.Id.ToString()));
            }
        }

        return principal;
    }
}

然后在Startup.cs里注册这个转换器：

services.AddScoped<IClaimsTransformation, ClaimsTransformer>();

4. 验证效果 #

最后用JWT调试工具解码生成的访问令牌，看看sub字段是不是已经变成你设置的GUID了，而不是原来的有序long数字。

几个注意点： #

• 记得在用户注册的时候，给PublicId自动赋值Guid.NewGuid()，确保每个用户都有唯一的GUID
• 数据库里的long类型主键保留不动，它依然是内部数据查询的最优选择，我们只是对外“隐藏”它而已
• 不管你用的是授权码流程、密码流程还是客户端凭证流程，这个配置都是全局生效的，所有生成的令牌都会用GUID作为用户标识

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