基于Azure AD B2C的营销自动化工具：Microsoft Graph API权限及实现疑问

一、权限类型选择：必须用Delegated权限 #

你的直觉是对的，这个场景只能用Delegated API权限，原因如下：

• Application权限（Daemon应用）以应用自身身份操作，无法代表外部用户（非Azure组织成员）发送邮件——收件人看到的发件人会是应用而非用户本人，不符合“代用户发送自动化邮件”的核心需求；此外，Daemon需要用户授予全局邮箱权限，但外部用户没有权限给你的应用授予这类组织级权限。
• Delegated权限以用户身份操作，能确保发件人显示为用户自己的邮箱，且通过Azure AD B2C的用户流，外部用户可主动授权你的应用访问他们的邮箱（需申请Mail.Send Delegated权限，同时必须添加offline_access权限）。

二、现有代码的疏漏与优化点 #

你的代码思路方向正确，但存在几个关键问题：

1. 仅存储Access Token的风险 #

Access Token有效期通常只有1小时，定时任务后台运行时用户不会主动登录刷新Token。如果只存Access Token，一段时间后Token过期，邮件发送会直接失败。

• 解决方法：用户授权时必须获取并存储Refresh Token（需申请offline_access权限），每次发送邮件前先检查Access Token是否过期，过期则用Refresh Token调用Azure AD B2C的Token端点获取新的Access Token。

2. 大量创建Graph Client实例的性能浪费 #

遍历数千个序列就创建数千个msGraphClient实例，会造成不必要的资源消耗。

• 优化方向：复用同一个Graph Client实例，每次调用API时动态传入有效Access Token，或在authProvider中实时获取当前用户的有效Token，而非为每个用户新建客户端。示例优化代码：

// 初始化一次全局Graph Client
const msGraphClient = Client.init({
  authProvider: (done) => {
    // 自定义方法：检查当前用户token是否过期，过期则用refresh token刷新
    const validAccessToken = getValidAccessToken(sequence.user);
    done(null, validAccessToken);
  },
});

sequences.forEach(sequence => {
  sequence.contacts.forEach(sequenceContact => {
    // 复用同一个客户端发送邮件，authProvider自动适配当前用户的有效token
    msGraphClient.api('/me/sendMail')
      .post({ /* 邮件内容结构体 */ });
  })
})

3. 缺乏异常处理机制 #

代码未处理Token刷新失败、API调用失败的场景（比如用户撤销授权、Refresh Token过期）。

• 解决方法：添加异常捕获逻辑，当Token刷新失败或API返回401/403错误时，记录日志并通知用户重新登录授权。

三、额外注意事项 #

• 确保Azure AD B2C应用注册中，已添加Mail.Send（Delegated）和offline_access权限，且用户在注册登录流程中完成了这些权限的授权。
• 存储Refresh Token时必须加密，避免泄露用户授权信息。

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