Azure AD B2C Cookie过大如何缩减？已生成2044字节Cookie

我来帮你拆解这个问题——先搞清楚你的应用Cookie比官方示例大这么多的原因，再给你落地的缩减方案。

一、Azure AD B2C Cookie 包含的核心内容 #

你的应用生成的2044字节Cookie，主要是这几部分内容堆出来的，和官方示例的差异也在这里：

• 身份令牌（ID Token）：存着用户的基础信息（姓名、邮箱、用户ID）、令牌的元数据（发行方、过期时间、受众），如果你的应用配置了自定义用户属性或者在策略里加了额外声明，这部分会更臃肿
• 访问令牌（Access Token）：如果你的应用请求了后端API的权限，Cookie里会附带这个令牌，用来调用API，这部分通常比ID Token占空间
• 刷新令牌（Refresh Token）：默认Azure AD B2C会把它存在Cookie里，用来自动获取新的令牌，这是Cookie变大的关键原因之一
• 会话上下文数据：比如自定义策略的执行状态、多步骤验证的中间数据、会话持久化标识等
• ASP.NET Core 身份框架的额外数据：比如身份验证方案的标识、序列化后的ClaimsPrincipal对象等

官方示例应用之所以只有944字节，大概率是只请求了最基础的ID Token，没有申请访问令牌/刷新令牌，也没加任何自定义声明，所以内容极简。

二、把Cookie缩减到示例大小的具体方案 #

1. 只请求必要的令牌和声明 #

这是最直接的优化：

• 如果你的应用不需要调用后端API，不要在授权请求里加offline_access范围和API权限，这样Azure AD B2C不会返回刷新令牌和访问令牌，直接砍掉一大块内容
• 在应用注册或自定义用户旅程里，只添加业务必需的用户声明——别默认返回所有用户属性，只选姓名、邮箱这些真正要用的，多余的声明一律去掉

2. 把令牌移到服务器端存储 #

如果必须保留访问令牌和刷新令牌，别存在Cookie里，改用服务器端存储：

• 在ASP.NET Core中，可以配置分布式缓存（比如Redis）作为SessionStore，Cookie里只存一个简短的会话ID，令牌都存在服务器端。示例配置大概是这样：

  services.AddAuthentication(...)
      .AddCookie(options =>
      {
          options.SessionStore = new DistributedCacheTicketStore(
              services.BuildServiceProvider().GetRequiredService<IDistributedCache>());
      });
  

  这能把Cookie大小直接砍到几百字节以内。

3. 优化令牌本身的内容 #

• 启用Azure AD B2C的精简令牌功能，去掉不必要的元数据声明（比如nbf、iat如果业务不需要的话，但注意部分声明是OAuth2规范必需的）
• 检查自定义策略，删掉所有非必需的自定义声明和额外步骤——复杂的策略会在Cookie里存储更多上下文数据，简化策略就能减少这部分内容

4. 调整Cookie的配置 #

• 启用Cookie压缩：在ASP.NET Core里开启app.UseResponseCompression()，同时配置Cookie的压缩选项（注意要兼容目标浏览器）
• 使用会话Cookie而非持久Cookie：持久Cookie会存储额外的持久化标识，会话Cookie关闭浏览器就失效，内容更精简，配置时把Cookie.IsPersistent设为false

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