Azure AD B2C登录报错：Bad Request - Request Too Long（HTTP 400请求头过长）

我完全理解这个问题有多棘手——业务因为登录故障停滞简直是噩梦！既然你说Stack Overflow上的常规方案没起作用，咱们直接针对Azure AD B2C场景的特殊情况来深度排查：

1. 先锁定浏览器端的Cookie冗余问题 #

• 先让测试用户用无痕/隐私窗口尝试登录，如果能成功，那大概率是浏览器积累了过多Azure AD B2C相关的Cookie（比如ARRIAUTHPERSISTENCE、B2C_*开头的系列Cookie）。
• 指导用户手动清理指定域名下的Cookie：找到你的Azure AD B2C租户域名（例如yourtenant.b2clogin.com），删除该域名下所有过期或重复的Cookie后再重试。

2. 检查Azure AD B2C的应用配置细节 #

• 精简回复URL（Redirect URI）：如果配置了过多URL或URL本身过长，会导致授权请求里的redirect_uri参数体积过大，间接推高请求头总大小。先暂时只保留当前在用的1-2个URL测试。
• 压缩请求的scope范围：如果你的应用同时请求了多个API权限，ID Token或Access Token的体积会急剧膨胀，进而让存储令牌的Cookie超标。先只保留openid、profile、email这些基础scope试试。

3. 调整服务器端的请求头限制 #

• 若部署在IIS：修改web.config中的maxRequestHeadersTotalSize配置，把默认值调高到足够的大小，比如64KB：

  <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxRequestHeadersTotalSize="65536" />
      </requestFiltering>
    </security>
  </system.webServer>
  

• 若部署在Azure App Service：在门户的「配置」>「常规设置」里找到「请求头大小限制」，调整为64KB或128KB再测试。

4. 排查用户流/自定义策略的声明冗余 #

• 检查自定义用户属性：如果你的用户流里添加了大量自定义属性且都在令牌中返回，会直接导致令牌体积超标。暂时移除非必需的自定义声明，只保留核心用户信息重试。
• 关闭非必要的可选声明：在用户流的「令牌颁发」设置里，看看是否开启了ipaddr、auth_time这类非必需的声明，先关闭它们再验证登录。

5. 排除浏览器扩展的干扰 #

部分广告拦截、隐私类浏览器扩展会自动添加额外的请求头或Cookie，导致总大小超限。让用户禁用所有扩展后再尝试登录，排查是否是第三方工具的问题。

如果以上步骤都无效，建议你收集以下信息进一步定位：

• 错误发生时的完整请求头（用浏览器开发者工具「网络」tab捕获）
• 你的Azure AD B2C使用的是用户流还是自定义策略
• 应用的具体部署环境（IIS、Azure App Service等）

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