Microsoft Graph API创建事件订阅返回403权限问题求助

我之前在做Office 365日历订阅开发时，也碰到过一模一样的403权限问题，结合你的配置细节，给你梳理几个最可能的原因和排查步骤：

1. ECP配置的全权访问权限可能还未同步 #

Office 365的权限同步经常存在延迟，你在ECP里给用户配置邮箱全权访问后，别着急立刻测试，最少等30分钟，甚至1-2小时再尝试。我上次就是急着验证，折腾了半天，结果发现是权限还没同步到位。

2. 订阅请求的资源路径是否正确 #

如果是订阅会议室日历，一定要确保请求的是会议室邮箱本身的日历资源，而非当前登录用户的日历路径。正确的请求URL格式应该是：

POST https://graph.microsoft.com/v1.0/users/{会议室邮箱ID}/calendars/{目标日历ID}/subscriptions

要是误用了当前用户的路径（比如/me/calendars/...），哪怕有委派权限，也会因为没有直接操作会议室日历的权限而返回403。

3. 确认用户实际的日历访问权限 #

别只依赖ECP的配置页面，手动用该用户账户登录Outlook网页版，直接访问目标会议室日历，试着创建、修改一个测试事件。如果手动操作都失败，那肯定是权限配置有问题，得回去检查ECP的权限是否正确应用；如果手动能正常操作，那问题大概率出在Graph API的请求或权限范围上。

4. 检查Graph API的权限范围 #

虽然你已经添加了Calendar.Shared.ReadWrite和Calendars.ReadWrite，但部分订阅场景下还需要MailboxSettings.Read这个委派权限。你可以去Azure AD的应用注册页面，把这个权限加上，重新生成令牌后再测试。

5. 验证通知URL的有效性 #

Graph API订阅要求通知URL必须是HTTPS，并且能正确响应微软的验证请求（收到validationToken参数后要原样返回）。哪怕你说其他调用正常，也可以用Postman模拟一个GET请求，带上validationToken参数，看看你的URL能不能正确返回该令牌。如果验证失败，也会触发403响应。

按照上面的步骤逐一排查，应该就能解决问题。我当时就是踩了「权限同步延迟+资源路径写错」的坑，调整后就正常了。

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