我需要构建一个控制台应用程序(使用. net Framework 4.8)，它可以从我们公司的azure托管实例中的单个邮箱读取电子邮件消息。该应用程序将由Windows Task Scheduler定期启动，并将调用Microsoft Graph API。我知道该怎么做。
我的问题与应用程序的身份验证有关。我认为合适的选项是授权代码提供程序和客户端凭据提供程序，但两者都存在问题。
授权代码流主要是为与用户交互的应用程序设计的。用户尝试访问应用程序，它让他们登录，授予应用程序所需的权限(范围)，最终从Azure获得的访问令牌用于对Graph API进行后续调用以获取数据。问题是这个应用程序不是特别具有交互性。这个想法是应用程序将被配置一次(例如，通过提供一个访问令牌)，然后将从它自己运行。
因此，客户机凭据流可能看起来更合适。Microsoft的文档为执行批处理作业的桌面应用程序(如Windows上的Windows服务或Linux上的守护进程)或在后台运行的操作系统服务推荐使用此身份验证提供者。完美的。除此之外，据我所知，具有用于客户端凭证流的令牌的应用程序(具有Mail.Read作用域)可以访问我们组织中任何用户的邮箱。出于这个原因，我们的管理员不愿意授权这样的应用程序是可以理解的。对于这种性质的应用程序来说，这个极端敏感的问题在上面链接的文档中得到了强调。我们可以控制在应用程序的代码中访问哪些邮箱，并严格限制对代码和运行它的服务器的访问，但代码仍然在那里
。我正在学习的一个解决方案是一种hack，我让用户通过一次授权代码流来获得访问令牌和刷新令牌，这两个令牌都与访问令牌的过期时间一起存储在数据库中。然后，我让应用程序的代码检查授权码是否在每次运行时过期，如果是，使用刷新令牌获取新的令牌并将其保存到数据库。
这感觉很像一个反模式，但它是有效的。它允许应用程序独立于用户运行，尽管我们采取了严格的保护措施，但如果访问代码被泄露，只有一个邮箱会受到攻击。然而，我很想知道是否有更好的方法来实现这一点，并且符合标准模式。
客户端id和secret是我喜欢称之为王国的钥匙，不能像你想的那样限定在一个盒子里。
请允许我建议另一种方法:创建一个Flow或Logic应用程序来从收件箱中提取电子邮件，并将其发送给一个服务来处理它并完成其余的工作。也许是一个带有Azure函数的Azure队列，或者只是一个API在某处监听，或者任何你喜欢的。