我想知道是否可以使用标准用户帐户根据订阅下载邮件。
背景：
我已经在Azure上注册了一个应用程序，以拥有一个应用程序ID和一个机密。
我使用此凭据创建传入邮件的订阅。通知将发送到服务器，由服务器提取并下载邮件内容。
这一切都很好，但是使用App ID和密码使我可以访问所有邮箱，这可能是安全问题。
为解决这个问题，我寻找了两个选择，但没有找到很多东西：
有人尝试过解决方案2还是可以指导我阅读某些文档？
据我所知，只能进行交互式用户登录吗？
答案 0 :(得分：0)
这是使用客户端凭据的副作用。由于您是在验证应用而不是用户的身份（您经常会听到以下内容：仅应用与应用+用户）。当您对应用程序进行身份验证时，它实际上是受限的超级用户（对于您同意的范围，超级用户而言为“受限”）。
共享邮箱（通常称为“服务帐户”）模型可以工作，但它可能非常脆弱。您需要构建一种机制，以在/访问令牌与访问令牌刷新时（如果出现异常）重新验证该帐户。您还需要一种机制来通知您发生了什么事情，并实施了可靠的流程，以便您本人以外的其他人可以在2年后重新设置。由于您需要引导每个用户共享他们的邮箱（对于大多数用户而言，这并不是完全熟悉的工作流程），因此这也带来了支持上的麻烦。
我会要求他们授权应用程序，而不是要求每个用户都执行共享工作流程。然后，您为每个用户使用单独的app + user令牌设置订阅。该模型确实需要与上述相同的机制，但是它们以自助服务为重点，因此在记住几年后如何设置时不再依赖IT。
为此，您需要站起来一些要素：
您需要一个描述正在发生的事情的网页，并显示一个“使用Microsoft登录”按钮来对用户进行身份验证。
您需要一个供用户在完成该过程后登录的网页（即“谢谢”页面）。
您需要安全地为每个用户存储“刷新”令牌。这没有听起来那么危险，因为任何恶意黑客都需要两者您的客户密码和刷新令牌。
您需要一种机制来捕获失败或丢失的刷新令牌，并向用户发送电子邮件，以更改需要重新认证的令牌。
工作流程如下：
在提取邮件时，我还会考虑使用/delta。这样一来，您仅可以获得自上次执行/delta以来到达的消息。它使用“增量令牌”来跟踪已处理的消息。您可以将此令牌与“刷新”令牌一起存储（我也将订阅元数据也存储在其中）。
这是一个复杂的过程，而Stack Overflow并不是这些的最佳论坛。如果您不满意此模型，请告诉我，我们可以开始聊天并进行Q＆A的带外讨论（如果以后需要，我可以随时更新此答案）。