你的问题很典型——用Application级别的Calendars.ReadWrite权限确实会默认授予对所有用户/资源日历的访问权，而你又没法用Delegated权限。下面是两个可行的方案，从权限层面和代码层面分别解决问题：

1. 使用Exchange Online资源特定应用权限（RSC）（推荐） #

这是最安全的方案，能从权限层面直接限制应用仅访问指定的会议室日历，完全隔离用户日历的访问权限。

配置步骤： #

• 第一步：准备目标会议室邮箱
  如果有多个会议室，建议创建一个Exchange邮件安全组，把所有需要应用访问的会议室邮箱添加到这个组里（方便统一管理）。
• 第二步：通过PowerShell创建应用访问策略
  打开Exchange Online PowerShell（需要Exchange管理员权限），运行以下命令：

  # 单个会议室的情况
  New-ApplicationAccessPolicy -AppId "<你的应用客户端ID>" -PolicyScopeGroupId "<会议室邮箱的UPN，比如conf-room-01@domain.com>" -AccessRight AllowAccess -Description "允许应用仅访问该会议室日历"
  
  # 多个会议室（用安全组）的情况
  New-ApplicationAccessPolicy -AppId "<你的应用客户端ID>" -PolicyScopeGroupId "<安全组的UPN，比如conf-rooms-group@domain.com>" -AccessRight AllowAccess -Description "允许应用访问组内所有会议室日历"
  

• 第三步：验证策略生效
  运行Get-ApplicationAccessPolicy查看已创建的策略，之后应用就只能访问指定的会议室邮箱，无法访问其他用户的日历了。

注意：RSC权限仅适用于Exchange Online环境，且需要Exchange管理员权限配置。

2. 代码层面强制过滤（补充防护） #

如果你暂时没法配置RSC，也可以在代码里严格控制访问范围，确保只针对会议室邮箱操作：

• 调用Graph API时，明确指定会议室的UPN或ID，比如：

  POST /users/conf-room-01@domain.com/events
  

• 绝对避免遍历所有用户（比如/users端点）或访问非会议室的用户日历；在服务内部维护一个允许访问的会议室邮箱列表，每次操作前校验目标邮箱是否在列表内。

这个方案是代码层面的防护，虽然不如RSC权限限制彻底，但能有效避免误访问用户日历。

为什么Delegated权限不可行？ #

你提到的Delegated.Calendars.ReadWrite确实只能访问授权用户的日历，但需要用户交互授权（通过/authorize端点），而你的服务是以会议室身份运行，无法获取用户凭据，所以这条路走不通，还是得用Application权限的变种（RSC）。

内容的提问来源于stack exchange，提问作者Richard Grand'Maison