IdentityServer4无Subject的委托扩展授权实现问题

我刚好碰到过一模一样的场景，用client_credentials模式的客户端本身就没有用户Subject（也就是sub声明），这时候硬凑一个不存在的用户ID去让IUserStore查找肯定会报错——因为IdentityServer默认会把Subject当成用户身份来处理。正确的思路是基于客户端身份来构造验证结果，而不是强行模拟用户。

正确的实现方式 #

当调用方是使用client_credentials的客户端时，身份主体应该是客户端本身，而非用户。你可以直接用客户端ID作为Subject，然后收集需要传递的声明（包括客户端自带的声明或自定义业务声明），用带Claims参数的GrantValidationResult重载返回结果，完全不需要依赖IUserStore：

// 获取当前请求的客户端信息
var client = context.Request.Client;

// 收集需要传递给下游API的声明集合
var claims = new List<Claim>
{
    // 将客户端ID作为核心标识声明
    new Claim("client_id", client.ClientId),
    // 可以直接传递客户端自带的所有声明（如果需要全部透传）
    client.Claims.Select(c => new Claim(c.Type, c.Value)),
    // 也可以添加自定义业务声明，比如从请求参数里获取的业务标识
    new Claim("message_topic", context.Request.Raw.Get("topic"))
}.SelectMany(c => c).ToList();

// 构造验证结果：用客户端ID作为Subject，指定你的委托授权类型，传入声明集合
context.Result = new GrantValidationResult(
    subject: client.ClientId,
    authenticationMethod: "your_delegation_grant_type", // 替换成你的委托授权类型名称
    claims: claims);

为什么之前的方法会报错？ #

你之前用“魔法GUID”作为Subject，IdentityServer会默认认为这是一个用户ID，进而调用IUserStore.FindByIdAsync去查找用户。不管返回null还是空用户实例，后续的Identity流程都会因为找不到合法的用户身份而抛出异常——毕竟这个场景下根本不存在用户，身份主体是客户端，完全不需要走用户存储的逻辑。

额外提示 #

如果下游API需要区分请求是来自用户还是客户端，可以添加一个自定义声明来标识身份类型：

claims.Add(new Claim("identity_type", "client"));

这样下游API就能根据这个声明做不同的权限逻辑处理。

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