SharePoint Search REST API使用Bearer Token返回结果数量异常

这个问题的核心线索其实你已经通过ULS日志抓出来了——身份格式的变化（UPN vs 域账号）直接导致了权限解析的差异，结合Token时效性的现象，我来给你梳理下根因和解决方向：

问题核心现象复盘 #

• 调用Search REST API时，同一Bearer Token会出现“新生成→返回10条→30秒后→返回7条”的100%复现波动，而浏览器NTLM认证始终返回完整的10条结果
• 缺失的3条结果是直接分配给当前用户的项目，而非自定义声明组的权限

已排查到的关键线索（划重点） #

• ULS日志明确显示：返回全量结果时，IdentityContext的UPN为kowalj@spdev.loc；返回部分结果时，身份变为域账号格式spdev\kowalj
• REST代理中检查Claims：Token刚生成时能拿到UPN声明，30秒后UPN声明消失，只能拿到SID相关的声明

根因分析 #

1. Bearer Token的声明缺失+SharePoint身份解析缓存：你当前生成的Token只包含nameid（SID）和nii（发行方）声明，没有直接携带UPN。SharePoint在Token初期会通过SID反向查询AD获取UPN并缓存，但这个缓存的有效期只有30秒左右，缓存失效后，SharePoint只能将SID解析为传统的域账号格式spdev\kowalj。
2. 权限解析的身份格式兼容性问题：你的自定义声明提供程序长期基于NTLM运行，而NTLM始终传递UPN格式的身份。当身份变为域账号格式时，自定义声明逻辑或者SharePoint自身的权限匹配逻辑无法正确识别直接分配给用户的权限，导致那3条结果被过滤掉。

解决方案建议 #

1. 修改Token生成逻辑，直接嵌入UPN声明 #

这是最直接的解决方法，让Token本身携带UPN信息，避免SharePoint后续需要去AD查询缓存。修改你的声明数组：

new Claim[] { 
    new Claim("nameid", sid), 
    new Claim("nii", Constants.Auth.Token.IdentityIssuer),
    new Claim(ClaimTypes.Upn, "kowalj@spdev.loc") // 新增UPN声明，替换为实际用户UPN
};

生成Token后，用JWT解析工具验证UPN声明是否存在，确保Token在整个有效期内都能携带该声明。

2. 检查自定义声明提供程序的身份匹配逻辑 #

确保你的声明提供程序能同时处理UPN格式（user@domain.loc）和域账号格式（DOMAIN\user）的身份。比如在权限映射逻辑中，增加对两种格式的判断，避免只识别UPN导致的权限遗漏。

3. 验证SharePoint的身份缓存策略 #

可以通过SharePoint PowerShell查看身份相关的缓存设置，比如：

Get-SPSecurityTokenServiceConfig | Select-Object TokenLifetime, WindowsTokenLifetime

确认Token的生命周期是否合理，避免短时间内身份解析发生变化。

4. 持续监控身份上下文 #

在REST代理中添加日志，持续记录HttpContext.Current.User.Identity的所有Claims，对比Token初期、30秒后、NTLM认证下的Claims差异，确认是否有其他声明丢失或变化，进一步定位问题。

内容的提问来源于stack exchange，提问作者Adrian Stanisławski