如何为Azure B2C用户授予Blob存储资源的访问权限

核心逻辑说明 #

你在AWS侧使用Cognito User Pool存用户、Identity Pool换S3临时访问凭证的逻辑，在Azure生态中不能直接套用：Azure AD B2C默认签发的令牌受众是你的单页应用本身，无法直接用于访问存储账户等Azure原生资源，需要通过以下两种可行方案实现需求。

方案1：后端代理签发SAS令牌（生产环境优先推荐） #

该方案对应你AWS侧Identity Pool的凭证交换逻辑，权限完全可控，无需额外配置租户关联：

• 单页应用通过MSAL完成B2C登录后，将获取到的B2C ID令牌传递给你的后端服务
• 后端服务校验ID令牌的签名、受众、签发者等信息，确认当前用户身份合法性
• 后端使用存储账户密钥、连接字符串或托管身份，调用存储SDK生成对应用户权限的用户委托SAS令牌，可自行限制可访问的容器/Blob路径、操作权限、过期时间
  示例代码（Node.js环境）：

  const { BlobServiceClient, generateBlobSASQueryParameters, StorageSharedKeyCredential } = require("@azure/storage-blob");
  const sharedKeyCredential = new StorageSharedKeyCredential("存储账户名", "存储账户密钥");
  const sasToken = generateBlobSASQueryParameters({
    containerName: "目标容器名",
    permissions: "r", // 只读权限，可按需调整
    expiresOn: new Date(new Date().valueOf() + 3600 * 1000), // 1小时过期
  }, sharedKeyCredential).toString();
  

• 后端将SAS令牌返回给前端，前端直接将SAS拼接在Blob资源URL后，或传入存储SDK即可访问对应资源

该方案优势：权限粒度灵活、无需给每个用户配置Azure IAM角色、SAS可随时失效，安全等级更高。

方案2：直接获取存储服务访问令牌（无后端场景适用） #

如果你没有后端服务，可以通过配置B2C与存储账户所在Azure AD的信任关系，直接获取存储服务认可的访问令牌：

• 在B2C租户的应用注册中，添加Azure Storage的API权限，选择user_impersonation委托权限并完成管理员同意
• 调整MSAL登录时的scope配置，添加https://storage.azure.com/user_impersonation作为请求scope
• 登录成功后获取到的访问令牌，其受众为Azure存储服务，可直接用于调用Blob存储REST API或传入存储SDK完成认证
• 提前在存储账户的IAM配置中，给每个B2C用户分配对应角色，如存储Blob数据读者，否则令牌会被存储服务拒绝

该方案限制较多：权限粒度受IAM角色限制、需要维护用户与IAM角色的绑定关系、仅支持同组织关联的租户配置，生产环境不推荐。

常见踩坑说明 #

• 不要直接使用B2C默认返回的、受众为你应用客户端ID的访问令牌调用存储，会直接返回401错误
• SAS令牌的过期时间建议设置在1小时以内，最长不要超过24小时，避免泄露后被滥用
• 如果需要限制用户只能访问自己的专属路径，直接在生成SAS时指定具体的Blob前缀即可，无需额外配置其他资源

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