代表用户从守护程序订阅到Office 365流式传输通知

Question

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

挑战：我的服务需要代表会议室用户进行订阅，并接收通知，但是来自守护程序服务的通知，无需用户交互。 实际上它会有一个管理UI，但是在添加会议室后，管理员将离开该UI并且该服务将需要单独工作，续订订阅，在服务器重新启动的情况下重新建立流。我想，device profile是一种选择。

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

Answer 1

我会说你有两个选择：

• 您可以使用OAuth客户端证书授予代理通过Azure的广告，允许服务通过简单地展示其客户端ID &客户端密钥来获得访问令牌支持（无用户信用要求）。为了授予此服务访问会议室日历的授权，您必须让租户的管理员同意您的服务一次。在this article中描述了获取此令牌&令牌的说明。您应该可以使用calendars.read应用程序权限来订阅通知（尽管我自己没有尝试过）。
• 另一种方法是让某人用会议室的凭证登录到服务的管理界面，并使用正常的OAuth授权代码授权和范围授予该服务访问其日历的同意。是的，这种方法需要管理控制台中的用户交互一次。但是，您的服务将收到一个刷新令牌，该令牌将会长期存在，并可用于获取新的访问令牌，而无需进一步的用户交互。此刷新令牌默认情况下不会过期，这可能会使您的场景变得可行。然而，刷新令牌的生存期可以由租户管理员缩短，或者如果有人故意禁用/删除服务的访问权，则可以撤消刷新令牌。

设备配置文件流几乎是第二种选择。它仍然要求用户登录，并且该服务仍然代表用户行事。唯一的区别是用户如何输入他们的凭证。听起来就像您的目的一样，定期的OAuth授权代码流将比设备配置文件流程更合适（主要用于有限的输入设备）。