使用Microsoft Graph API写入日历事件时遇403权限拒绝问题求助

• 确认非默认日历的权限设置
  应用权限授予的全局Calendars.ReadWrite不代表能访问所有用户日历的编辑权限，非默认日历可能被用户单独设置了共享权限，仅允许特定用户/组编辑。需要检查目标日历的共享配置，确认应用对应的Azure AD服务主体是否被添加为具有编辑权限的成员。

• 检查Graph API请求端点的正确性
  应用权限模式下，必须使用用户ID路径的端点：POST /users/{user-id}/calendars/{calendar-id}/events，不能用/me/calendars/...（/me仅适用于委派权限的用户上下文）。错误的端点会导致权限上下文不匹配，触发403。同时确保请求头的Authorization字段格式为Bearer {access-token}，无拼写错误。

• 验证Access Token的有效性
  解码token后，除了确认roles包含Calendars.ReadWrite，还要检查：

  • aud（受众）必须是https://graph.microsoft.com，避免获取到其他Azure资源的token；
  • iss（颁发者）是对应租户的Azure AD端点，确保token来自正确的租户；
  • 确认没有被授予Calendars.ReadWrite.Shared这类受限权限，该权限仅允许编辑共享给应用的日历，而非所有日历。

• 确认应用权限的配置状态

  • 在Azure AD应用的“权限”页面，确认Calendars.ReadWrite（应用权限）的状态是“已授予 {租户名} 管理员同意”，避免误配置为委派权限；
  • 管理员同意后可能存在短暂的权限同步延迟，可以重新获取一次token，或者在Azure AD中重新触发一次管理员同意操作。

• 对比默认日历的写入测试
  先尝试向用户的默认日历写入事件：POST /users/{user-id}/calendar/events。如果成功，说明问题集中在非默认日历的权限隔离；如果同样失败，则排查全局应用权限的授予是否生效，或者token的/.default范围是否正确映射到了Calendars.ReadWrite权限。

• 检查Graph API版本兼容性
  确保使用的是Graph API v1.0版本（https://graph.microsoft.com/v1.0/...），beta版本可能存在非默认日历应用权限的兼容性问题，优先使用稳定版接口测试。

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