2

我正在通过OAuth 2.0协议与Azure AD合作,并且还创建了一个服务/ Dameon应用程序来处理Microsoft Graph SDK的身份验证过程。对于服务/守护进程,我制作了一个HttpWebRequest并传递了client_idclient_secret以生成一个access_token,然后我可以提供给Microsoft Graph SDKAzure AD - 具有守护程序服务和授权码授予流程的多租户,目标租户是否可以生成client_secret?

我也已经成功地创建对应的服务主体到目标租户,其中管理员已授予的权限,以使用授权代码准予流应用程序。该应用程序然后在(portal.azure.com)内的Overview -> Quick tasks -> Find an enterprise app中显示。

我的问题是,我可以利用服务/守护进程的方法,同时也允许目标租户的管理员授权应用程序,这将允许目标租户创建一个client_secret通过,这将是唯一的房客?

回答

3

简短的回答是没有。当管理员地同意你的多租户应用程序:

  1. 服务主要是为在他们的租户
  2. 权限由应用要求建立在租户被授予

这意味着你的应用程序可以现在也可以通过其客户端凭据(id + secret)对其租户进行身份验证。因此,所有批准的租户都使用相同的密钥。

这意味着您的应用程序可以在任何给定时间免费获取任何访问令牌,无论是谁登录。所以它会为您的应用程序承担一些责任,以保持数据分离。

如果您从https://login.microsoftonline.com/company.com/oauth2/token获得访问令牌,则生成的令牌将包含该租户的标识符。而像Microsoft Graph API这样的API只会为该租户提供该令牌的数据。因此,您的应用必须确保只使用拥有与用户的租户ID声明相同的租户ID的令牌。

+0

如果是这种情况,那么租户是否会限制其他租户用户的查看? – jdave

+0

编辑我的问题。应用程序权限使您的应用程序有责任为预定租户的数据获取令牌。如果使用委托权限(守护进程不是这种情况),那么就不用担心了,因为您将始终以用户身份进行调用。 – juunas

0

我会说juunas的答案是99%正确的。简短的回答基本上是否定的,他所提及的考虑也是可靠的。

但我相信在某些考虑因素下这在技术上是可行的。当管理员同意守护程序服务时,服务负责人将在客户的租户中创建。服务主体确实允许添加可用作每个租户基础上的客户机密的凭证。问题是,没有真正的方法可以通过程序从应用程序中以编程方式向服务主体添加凭证。您必须让管理员运行一些脚本来将新凭证添加到其承租人的服务主管。

即使你经历了所有这些,你仍然需要确保你的服务在客户/租户的基础上被隔离。从安全角度来看,如果您的单一守护进程可以访问所有的秘密,那么创建每个租户的客户机密信息是毫无意义的。

相关问题