代表用户从后台进程订阅Office 365流通知

Question

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

挑战:我的服务需要代表会议室用户订阅和接收通知，但需要从守护程序服务接收通知，而无需用户交互。实际上，它将有一个管理UI，但在添加会议室后，管理员将离开该UI，服务将需要单独工作，续订订阅，在服务器重新启动的情况下重新建立流。

我想，device profile是一种选择。

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

Answer 1

我想说你有两个选择：

• 您可以使用Azure AD支持的OAuth客户端凭据授予，它允许服务通过简单地显示其客户端ID和客户端机密(不需要用户凭据)来获取访问令牌。要授予此服务访问会议室日历的授权，您必须让租户的管理员同意您的服务一次。在this article中描述了获取此同意和获取令牌的说明。您应该能够使用calendars.read应用程序权限来订阅通知(尽管我自己还没有尝试过)。
• 另一种方法是让某人使用会议室的凭据登录到您的服务的管理UI，并使用普通的OAuth授权码授予和calendars.read作用域授予该服务访问其日历的许可。是的，这种方法需要用户在管理控制台中进行一次交互。但是，您的服务将接收回一个长期存在的刷新令牌，并可用于获取新的访问令牌，而无需进一步的用户交互。默认情况下，此刷新令牌不会过期，这可能会使其适用于您的场景。但是，租户管理员可以缩短刷新令牌的生存期，如果有人故意禁用/删除您的服务的访问权限，也可以撤销刷新令牌的生存期。

设备配置文件流几乎是第二种选择。它仍然需要用户登录，并且服务仍然代表用户执行操作。唯一的区别是用户如何输入他们的凭据。就您的目的而言，常规的OAuth授权码流将比设备配置文件流(主要用于有限的输入设备)更合适。