azure - 为后台控制台应用程序选择身份验证提供程序

Question

我需要构建一个控制台应用程序(使用 .NET Framework 4.8)，它可以从我们公司的 Azure 托管实例中的单个邮箱读取电子邮件。该应用程序将由 Windows 任务计划程序定期启动，并将调用 Microsoft Graph API。我知道如何做到这一切。

我的问题与应用程序的身份验证有关。我认为合适的选项是 authorization code provider和 client credentials provider ，但是两者都存在问题。

授权代码流程主要是针对与用户交互的应用程序而设计的。用户尝试访问应用程序，它让他们登录，授予应用程序所需的权限(范围)，最终从 Azure 获得的访问 token 用于对 Graph API 进行后续数据调用。问题是这个应用程序的交互性不是特别好。这个想法是，应用程序将被配置一次(例如，通过为其提供访问 token )，然后将从此自行运行。

因此，客户端凭据流可能看起来更合适。 Microsoft's documentation建议将此身份验证提供程序用于“执行批处理作业的桌面应用程序(例如 Windows 上的 Windows 服务或 Linux 上的守护进程)，或在后台运行的操作系统服务”。完美的。除此之外，据我所知，具有用于客户端凭据流(具有 Mail.Read 范围)的 token 的应用程序可以访问任何的邮箱我们组织中的用户。因此，我们的管理员不愿意授权这样的应用程序，这是可以理解的。上面链接的文档中强调了这种性质的应用程序的极端敏感性问题。我们将控制在应用代码中访问哪些邮箱，并严格限制对代码及其运行的服务器的访问，但代码仍然在那里。

我倾向于的一种解决方法是一种黑客攻击，其中我让用户通过一次授权代码流程来获取访问 token 和刷新 token ，我将这两个 token 与访问 token 的到期时间。然后，我让应用程序的代码在每次运行时检查授权代码是否已过期，如果是，则使用刷新 token 来获取新 token 并将其保存到数据库中。

这感觉很像一种反模式，但它确实有效。它允许应用程序独立于用户运行，并且如果访问代码受到损害，尽管我们采取了严格的保护措施，但只有一个邮箱会受到攻击。尽管如此，我很想知道是否有更好的方法来实现这一点，并且符合标准模式。

Answer 1

我喜欢将客户端 ID 和 secret 称为“王国的 key ”，并且不能按照您的意愿将范围限制在单个框内。

请允许我建议一种替代方法:创建一个流程或逻辑应用程序来从该收件箱中提取电子邮件，并将其发送到一个服务来处理它并完成其余的工作。也许是带有 Azure Function 的 Azure 队列，或者只是在某处监听的 API，或者您喜欢的任何内容。