我正在试图弄清楚如何实现可以配置为在多租户方案中与WebApi通信的Windows服务（无头）。我能找到的最接近的例子是Calling web APIs in a daemon or long-running process。此示例的问题并未显示您将如何处理多租户方案。如果您为每个租户使用相同的AppKey，如果有人决定在应用中搜索ClientID和AppKey，则不可能冒充其他租户吗？似乎有一种方法是为每个加入我们服务的租户生成一个新的AppKey。当客户安装服务时，需要将此AppKey作为配置参数提供给Windows服务。这是正确的方法吗？这似乎不是正确的方向，因为从AAD门户网站看哪个AppKey与哪个租户相关联并不明显。看起来你必须自己管理它。我知道您必须将租户ID作为权限的一部分传递，但这些ID与AppKey或密码不同。这种情况的正确方法是什么？
我也看一下这个样本Building a multi-tenant web API secured by Azure AD。不幸的是，这个示例是一个Windows应用商店。它有UI，因此它可以与AAD进行典型的同意舞蹈。显然，我的windows服务无法使用这种方法。我可以在Windows服务中自行托管WebApp，强制用户至少进行一次同意过程，因此令牌就像本示例中的缓存一样。但是，我使用什么作为RedirectUrl？这不是Windows商店应用程序，因此我无法使用
WebAuthenticationBroker.GetCurrentApplicationCallbackUri();
我不清楚这种情况是否得到支持。
答案 0 :(得分：1)
你的后一种方法是要走的路。不要为每个租户创建一个密钥，这将是一个关键的管理噩梦。
创建一个应用，让它请求“应用”权限＆＃39;您的服务需要。在您的服务获得给定租户的令牌之前，您确实需要获得租户管理员的交互同意，该管理员将提供您的应用所需的authZ。然后，您的应用程序将能够像您引用的守护程序文章一样请求和接收令牌。
我们通常建议您让管理员在注册您的服务时通过同意，这通常会有一些互动流程。您绝对可以为此目的托管网站。但您也可以复制用于请求管理员同意的URL，并将其发送给您的客户，而不是托管某些网页。您可以通过电子邮件或其他方式将URL发送给他们。您不必担心在他们同意后获取授权响应 - 您只需要他们登录并授予同意。
答案 1 :(得分：0)
我建议实施JSON Web令牌（JWT） - 请参阅JSON Web Token in ASP.NET Web API 2 using Owin。然后你可以使用JWT Refresh Tokens，它基本上允许用户永远保持身份验证，但是可以撤销它们。