C# 代表用户从守护程序订阅Office 365流媒体通知

在windows my service中，我需要能够在租户的Office 365会议室日历中订阅事件通知。由于安全原因，无法使用推送通知，因此使用推送通知只是可行的（或轮询，但这是最后的手段）。 但如该页所述，订阅范围不能从当前用户“我”更改。因此，我不能依赖应用程序角色分配（我已经可以使用Graph API来轮询感兴趣的日历）。 当然，我有这些会议室帐户的用户凭据，但基本身份验证暂时不受支持

挑战：我的服务需要代表会议室用户进行订阅和接收通知，但来自后台程序服务，无需用户交互。 实际上，它将有一个管理UI，但在添加一个会议室后，管理员将离开该UI，服务将需要单独工作、续订、在服务器重新启动时重新建立流

我想，这是一种选择

---

您建议采用什么方法/流程？

我想您有两种选择：

• 您可以使用Azure AD支持的OAuth客户端凭据授权，该授权允许服务通过简单地显示其客户端ID和客户端机密（无需用户凭据）来获取访问令牌。为了授予此服务访问会议室日历的权限，您必须让租户的管理员一次性同意您的服务。中介绍了获取此同意和令牌的说明。您应该能够使用

  日历。阅读
  应用程序权限订阅通知（尽管我自己还没有尝试过）

• 另一种方法是让某人使用会议室的凭据登录到您服务的管理UI，并使用正常的OAuth授权码授权和

  日历。读取
  范围，授予服务访问其日历的许可。是的，这种方法需要在管理控制台中进行一次用户交互。但是，您的服务将接收回一个长期存在的刷新令牌，并可用于获取新的访问令牌，而无需进一步的用户交互。默认情况下，此刷新令牌不会过期，这可能使其适用于您的场景。不过，租户管理员可以缩短刷新令牌的生命周期，如果有人故意禁用/删除您的服务访问，则可以撤销刷新令牌的生命周期

---

设备配置文件流几乎是第二个选项。它仍然需要用户登录，并且服务仍然代表用户。唯一的区别是用户输入凭据的方式。就您的目的而言，常规OAuth授权代码流比设备配置文件流（主要用于有限的输入设备）更合适。

谢谢。第二点似乎是有用的，但我无法想象如何让两个并行用户登录，甚至在登录时切换用户上下文（如果将使用web ui）。第一点是不可用的，因为根据文档，应用程序本身无法描述iser资源流。