Azure Static Web Apps代登录用户一周后发邮件如何处理认证？

Azure Static Web Apps（以下简称SWA）内置的身份验证能力不会自动持久化刷新令牌，供你这种脱离用户活跃会话的延迟任务使用，你不需要申请高风险的Mail.Send应用程序权限，也不用从零手写整套OAuth令牌维护逻辑，有两种完全符合最小权限原则的实现方式。

方案1：开启离线权限+持久化刷新令牌（改动量最小，无需用户二次操作） #

• 前置配置：先在SWA的Microsoft Entra ID身份提供者配置里，给授权scope添加上offline_access和Mail.Send两个委托权限。用户首次登录完成同意授权后，微软身份平台会返回有效期1小时的访问令牌，以及有效期90天、支持滚动续期的刷新令牌。SWA默认只会在用户主动访问站点时，自动用刷新令牌换发新访问令牌维持会话，不会帮你把刷新令牌存下来给后端离线任务用，这一步需要你自己处理。
• 具体实现流程：
  1. 用户填写完邮件内容、目标邮箱提交表单时，请求会先打到和SWA集成的Durable Functions入口，你可以直接从请求附带的身份信息里，调用SWA内置的令牌获取接口拿到当前用户的刷新令牌。
  2. 把加密后的刷新令牌、邮件内容、目标地址、计划发送时间一起存在持久化存储层（比如Azure Table Storage、Cosmos DB都可以，必须对刷新令牌做静态加密，绝对不能明文存储），同时启动Durable Functions编排任务，设置7天的延迟触发定时器。
  3. 7天后定时器触发，活动函数从存储里取出加密的刷新令牌，解密后调用微软身份平台的令牌接口换发新的有效访问令牌，带着新令牌调用MS Graph的/me/sendMail接口完成发信即可。
  4. 补充异常处理：如果刷新令牌换发失败（比如用户主动撤销了应用授权、账号被停用），直接终止任务，按你的业务需求发通知告知用户即可，不用做无意义重试。
• 这个方案全程只持有单个用户授权的委托权限，完全没法越权操作其他用户的邮箱，符合你一开始的最小权限要求。

方案2：编排器挂起等待用户二次验证（零敏感令牌存储，安全等级最高） #

如果你不想存储刷新令牌这类高敏感凭证，可以选这个方案：

• 用户提交发信任务后，Durable Functions编排器启动7天倒计时，在距离计划发信时间还剩24小时的时候暂停编排，给用户的登录邮箱发一封验证提醒，附带一个带唯一任务标识、短时效的验证链接，跳转到你SWA站点下的验证页面。
• 用户点击链接完成登录验证（这是用户主动触发的活跃访问，SWA会自动完成令牌刷新，拿到有效的Mail.Send权限访问令牌），前端拿到新的有效令牌后，传回给等待中的Durable Functions实例。
• 编排器拿到有效令牌后，等到预设的发送时间点直接调用MS Graph发信就行，全程不需要长期存储任何用户敏感凭证。
• 这个方案的缺点是依赖用户在发信前24小时内完成一次主动验证，如果用户没点验证链接，任务会自动取消，适合对数据安全要求极高、不允许留存长期用户授权凭证的场景。

常见误区提醒 #

不要尝试手动拉长访问令牌有效期来绕开刷新逻辑，不管是个人微软账户还是Entra ID工作/学校账户，访问令牌默认有效期最长只有1小时，不支持自定义延长到7天，所有绕开这个规则的操作都不符合微软安全规范，随时可能失效。

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