IdentityServer3登录重定向时idsrv.partial Cookie过大引发请求错误

你遇到的这个问题确实有点棘手——明明Claims数量不算多，却出现了Cookie分块过多触发请求过大的错误，而且环境差异导致复现不稳定。结合IdSrv3 2.6.1的特性，除了Claims数量，还有这些容易被忽略的因素会影响idsrv.partial Cookie的payload大小：

• 单个Claim的内容长度：别只看Claim的数量，要关注每个Claim的Type和Value的实际字符长度。比如如果有几个Claim的Value是超长字符串（比如包含用户的完整权限列表JSON、长描述文本或者Base64编码的内容），哪怕只有10个这样的Claim，总大小也会轻松超过单个Cookie的4KB限制。
• 序列化与编码的额外开销：IdSrv3会把Claims序列化为JSON，再做Base64编码——Base64本身会让原始数据体积增加约33%。另外，如果你的Claim里包含复杂类型（比如自定义的Claim类型，而非简单字符串），JSON序列化时会附带更多元数据，进一步增大体积。
• Cookie中的额外上下文数据：idsrv.partial Cookie不只是存Claims，还会包含重定向相关的临时数据，比如redirect_uri的长度、nonce的大小、状态参数等。如果你的redirect_uri本身带有大量查询参数（比如复杂的回调地址），或者生成的nonce是超长字符串，这些都会直接增加Cookie的总大小。
• 环境差异中的服务器配置限制：不同环境的服务器（比如IIS）请求头大小限制可能不同。比如IIS的requestLimits里的maxRequestBytes或maxQueryString配置，如果某个环境的限制值更低，哪怕Cookie分块后的总大小和其他环境差不多，也会触发“request too big”错误。另外，部分服务器的HTTP头压缩配置差异（虽然Cookie通常不被压缩，但个别配置可能例外）也会影响实际传输的体积。
• 冗余或自动添加的Claims：你看到的100个Claims可能只是业务层面的，IdSrv3默认会添加一些标准Claims（比如iss、aud、amr、exp等），如果某些环境中还加载了自定义扩展模块，可能会额外注入更多调试或业务相关的Claims，这些都会悄悄增加Cookie体积。
• Cookie分块的逻辑与浏览器差异：IdSrv3拆分Cookie的逻辑是基于单块Cookie的大小阈值（参考浏览器的4KB限制），但不同浏览器的实际限制略有差异。如果某个环境的用户浏览器对单块Cookie的限制更严格，就会导致拆分出更多块，最终触发服务器的请求大小限制。

排查建议 #

1. 用浏览器开发者工具（比如Chrome的Application面板）查看所有idsrv.partial块的内容，把每个块的Base64编码解码后，分析序列化的JSON数据，找出体积最大的部分（是某个超长Claim，还是额外的上下文数据）。
2. 对比正常环境和异常环境的Claims列表、redirect_uri、nonce等数据，找出差异点。
3. 检查异常环境的服务器请求头大小配置，比如IIS的web.config中的requestLimits设置。

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