Azure Functions/OAuth：不支持SP的端点的AAD非交互式认证实现

针对运行在非交互式环境的Azure Function，需要调用仅支持委托用户身份、不支持服务主体应用权限的端点（如创建synchronizationJob的Graph beta接口），可直接落地的实现路径如下：

核心实现路径 #

方案1：资源所有者密码凭据流（ROPC，纯后端非交互，无后续人工介入） #

• 前置准备
  • 单独创建一个专用AAD服务账号，关闭账号MFA，在租户条件访问策略中，将该账号排除所有要求交互验证、合规设备校验的策略
  • 在Function关联的应用注册中，勾选目标端点要求的委托类型权限，如果权限需要管理员审批，完成一次全局管理员授权
• 函数内实现逻辑
  • 不硬编码账号密码：将服务账号的凭证存储在Key Vault中，通过Function的系统分配托管身份拉取凭证
  • 向AAD令牌端点发起请求，请求参数固定为：
    • grant_type: password
    • client_id: Function关联应用注册的客户端ID
    • client_secret: 应用注册的有效客户端密钥
    • username: 专用服务账号的UPN
    • password: 从Key Vault拉取的账号密码
    • scope: 目标服务的默认范围（如Graph服务为https://graph.microsoft.com/.default）
  • 增加令牌缓存逻辑：将获取到的访问令牌存在函数侧缓存（如临时文件、Azure Cache for Redis），在令牌过期前5分钟触发刷新，避免每次业务调用都重复申请令牌触发AAD限流

方案2：离线授权刷新令牌流（安全等级高于ROPC，无需存储用户密码） #

如果企业安全规范禁用ROPC密码流，可通过一次性离线交互获取长期可用的刷新令牌，后续全流程非交互运行：

• 前置一次性操作（仅需人工介入1次）
  • 本地临时运行简易控制台程序，通过授权码流让专用服务账号完成一次登录，申请目标端点所需的全部委托权限，获取有效期最长的初始refresh_token
  • 将初始refresh_token存储在Key Vault中，同样通过Function托管身份拉取
• 函数内实现逻辑
  • 检测缓存内的访问令牌接近过期时，使用从Key Vault获取的refresh_token，向AAD令牌端点发起刷新请求，请求参数为：
    • grant_type: refresh_token
    • client_id: Function关联应用注册的客户端ID
    • client_secret: 应用注册的有效客户端密钥
    • refresh_token: Key Vault中存储的最新刷新令牌
    • scope: 目标服务的默认范围
  • 令牌同步逻辑：每次调用刷新接口时，AAD会返回新的有效refresh_token，必须将新返回的令牌同步覆盖更新到Key Vault中，避免旧令牌失效导致流程中断

实操避坑要点 #

• 不管用哪种方案，绝对不能给专用服务账号开通MFA，只要触发MFA校验，所有令牌申请请求都会被AAD拒绝
• 租户级别的条件访问策略如果覆盖所有AAD登录请求，必须把专用服务账号加入排除列表，否则会返回invalid_grant类的令牌申请失败
• Graph beta端点的权限要求往往和公开文档描述存在差异，申请令牌前先在Graph Explorer中使用同一个专用服务账号登录，完成对应委托权限的同意流程，确认端点可正常调用后，再把对应的scope映射到函数的令牌申请参数中
• 定期做凭证轮换：每90天对专用服务账号的密码、存储的refresh_token做一次更换，避免长期使用同一凭证带来的安全风险

安全管控要求 #

• 所有敏感凭证（账号密码、refresh_token）一律存储在开启软删除和清除保护的Key Vault中，禁止将明文凭证存在Function应用配置、代码仓库中
• 给专用服务账号分配最小必要权限，仅开放目标端点调用所需的权限范围，禁止分配全局管理员等高权限角色
• 禁用专用服务账号的交互式登录入口，仅允许该账号通过AAD令牌接口获取访问令牌，降低凭证泄露后的滥用风险

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