为什么具有委派域访问权限的服务帐户仍需要模拟？

Question

我正在考虑使用 OAuth 2.0 service accounts 和 domain-wide delegation of authority 将我们的服务与 Google Apps 集成。一个特定的用例是：

• 当 Google Apps 客户注册我们的服务时，利用客户现有的组织结构或资源（组织单位、组、设备、用户、文件夹、文件等）预先提供我们的服务。

• 当客户的 Google Apps 资源发生变化时，将适用的更改同步到我们的服务。

我发现在使用服务帐号时，我需要为我正在查询的域指定授权超级用户的电子邮件地址，如下所示：

var cred = new ServiceAccountCredential( new ServiceAccountCredential.Initializer( "{SERVICEACCOUNTEMAIL}" )
  {
     Scopes = new[]
              {
                 DirectoryService.Scope.AdminDirectoryOrgunitReadonly
              },
     User = "{USERTOIMPERSONATE@customergadomain.com}"
  }.FromCertificate( x509cert ) );

如果我想，例如

1. 查询域中的所有组织单位或组
2. 查询组织拥有的所有文件夹，或特定用户的文件夹

理想情况下，我不希望将我们服务器上的自动后台进程与特定的 Google Apps 用户结合起来，以使资源与域管理员或用户可能在 Google Apps 方面发生的更改保持同步。

我不想指定用户。所以我的主要问题是，我是否使用正确的授权模型来执行我正在尝试做的事情？

我的第二个问题更多的是旁白。当委派已授予对域资源的访问权限时，要求模拟以使用管理 API 的目的是什么？与正常的 OAuth 2.0 授权工作流程相比，我不必代表用户授权，我只需指定她的电子邮件地址。我是否缺少服务帐户/委托访问模型的意图？

Answer 1

域范围的委派模型允许服务帐户模拟用户，从而在域中获得与授予应用程序的用户身份和范围集所暗示的相同的权限。

对于您调用的 API，只有域管理员可以访问这些 API。凭借您被授予的范围 + 模拟此类管理员的能力，您可以访问这些 API。

如果任务是访问管理员拥有的单个资源（例如组织的日历），则管理员可以与服务帐号共享该资源，然后服务帐号可能会冒充自己访问该资源。但是，对于代表许多资源集合的整个 API，使用 ACL 是不可行的，唯一可行的方法是授予服务帐户直接模拟特定 API 管理员的能力。