Azure AD B2C登录报错：HTTP 400请求头过长，业务完全受阻

我完全理解这有多棘手——业务完全卡壳在登录环节简直是噩梦！既然你说Stack上常规方案没用，咱们来一步步深挖可能的原因和针对性解决办法：

一、先排查客户端缓存的"冗余Cookie"问题 #

这是最容易被忽略但高频触发的点：Azure AD B2C会在客户端存储大量身份相关Cookie，若用户频繁登录、切换应用/租户，Cookie会持续积累，最终导致请求头体积超标。

• 先让测试用无痕/匿名窗口登录，如果能正常访问，直接实锤是客户端缓存问题。
• 指导用户清除对应域名的Cookie（而非全量清除）：以Chrome为例，打开chrome://settings/siteData，搜索你的B2C租户域名（比如yourtenant.b2clogin.com），删除所有相关数据后重启浏览器重试。

二、检查令牌声明的"过度膨胀" #

如果匿名窗口也报错，大概率是令牌本身体积过大，导致请求头里的Authorization字段超限：

• 登录Azure门户进入你的B2C租户，找到对应应用注册的令牌配置页面，检查是否添加了过多自定义声明（比如把用户的所有属性、组信息都塞进ID令牌）。
• 非必要的声明直接移除，或者把部分属性移到/userinfo端点获取（登录后单独调用接口拉取，而非塞进令牌）；如果必须包含组信息，记得设置为只包含直接所属组，避免嵌套组导致声明爆炸。

三、调整Web服务器/反向代理的请求头限制 #

如果你的应用前端有Nginx、IIS或Azure App Service，默认的请求头大小限制可能不足以容纳膨胀的身份请求：

• IIS：修改web.config，添加/调整以下配置：

  <system.web>
    <httpRuntime maxRequestLength="1048576" requestValidationMode="2.0" />
  </system.web>
  <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxAllowedContentLength="1073741824" />
      </requestFiltering>
    </security>
  </system.webServer>
  

• Nginx：在nginx.conf的http或server块中调整：

  large_client_header_buffers 4 32k;
  

• Azure App Service：在应用服务的配置→应用设置中添加WEBSITE_MAX_HEADER_SIZE，值设为65536（或更大，根据实际需求调整）。

四、排查身份提供者（IDP）的冗余配置 #

如果你的B2C租户关联了大量外部IDP（比如Google、Facebook、多个AD租户），每次登录请求会携带所有IDP的元数据信息，导致请求头变大：

• 暂时禁用几个不常用的IDP，测试登录是否恢复正常；如果有效，考虑优化IDP选择逻辑（比如用自定义策略做动态IDP展示，而非全量加载）。

五、自定义策略的"冗余逻辑"排查 #

如果用了自定义用户旅程或策略，最近的修改可能引入了冗余步骤：

• 对比之前正常运行的策略版本，回滚到旧版本测试；如果回滚后正常，检查新版本中是否添加了过多声明转换、会话管理配置，导致会话令牌体积超标。

六、特定用户的身份属性排查 #

如果只有部分用户报错，大概率是该用户的身份属性异常：

• 查看该用户的Azure AD B2C属性，是否存在大量冗余组、自定义属性；清理不必要的属性，或者调整令牌中包含的属性范围。

每完成一步都要测试登录状态，因为可能是多个因素叠加导致的问题。

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