Google api 使用服务帐户调用Google API时模拟当前用户&；授权

如果Google Apps for Work domain管理员为其域安装了我们的应用程序，则管理员及其域中的任何用户在访问我们的应用程序时都不应看到scope auth屏幕。为域安装应用程序的行为应隐含地为与我们的应用程序关联的服务帐户授予域范围的权限

为了实现此行为，我尝试代表当前登录的用户（也称为模拟用户）进行工作

下面的代码片段显示了我为使其工作所做的各种尝试。唯一有效的方法是在创建JWT时将域超级用户的电子邮件地址作为“sub”参数（也称为prn）传递。然而，这实际上将普通域用户的权限提升为超级用户的权限，这并不是期望的效果

var client = new googleapis.auth.JWT(
    '<serviceaccount>@developer.gserviceaccount.com',
    'localhost.pem',
    null,
    ["https://www.googleapis.com/auth/admin.directory.user.readonly"],
    //  null - // 403 not auth
    // {'userId' : 'domainsuperuser@email.com'} // 403 not auth
    // {'userId' : 'me'} // 403 not auth
    // "domainsuperuser@email.com" // works!
    // "{domainsuperuser@email.com}" // not a valid email error
    // 'me' // invalid impersonation prn email address
  );

var client=new googleapis.auth.JWT(
“@developer.gserviceaccount.com”，
'localhost.pem'，
无效的
["https://www.googleapis.com/auth/admin.directory.user.readonly"],
//null-//403未验证
//{'userId'：'domainsuperuser@email.com'}//403未验证
//{'userId'：'me'}//403未验证
// "domainsuperuser@email.com“//有效！
// "{domainsuperuser@email.com}“//不是有效的电子邮件错误
//'me'//无效的模拟prn电子邮件地址
);

除了你想冒充的人的电子邮件地址之外，谷歌是否尊重其他身份证，比如特殊的“我”值

---

感觉我们在这里遇到了鸡和蛋的问题。本质上，我们不想硬编码电子邮件地址（特别是不是管理员电子邮件），所以感觉我们必须进行API调用。但是我们不能在不模拟用户的情况下进行API调用。

在这种情况下，您不需要使用服务帐户和域范围的委派。相反，只需与用户一起通过正常的OAuth2流程，批准屏幕将自动跳过

---

当管理员安装应用程序并批准您的作用域时，他们实际上会自动授予您对域中所有用户的这些作用域的访问权限。虽然要求用户看不到approval屏幕，但您仍然必须与他们一起通过OAuth2流才能获得OAuth2令牌。如果您为用户启动OAuth2流，并且没有请求任何未经域管理员批准的范围，并且没有在URL中设置

approval\u prompt=force

，那么OAuth2 approval屏幕将立即重定向到您的重定向URI，从而使该过程对用户不可见。

Hi Eric，感谢您的响应。这将适用于我们应用程序的新安装，但任何现有安装都需要谷歌组织的管理员手动添加这些范围。他们有没有办法将作用域添加到现有API客户端的访问中？在这里尝试过，但在我尝试更新时失败了：对域进行授权是我们能够想到的消除现有用户范围提示的唯一方法。增加应用程序使用范围并不是今天最愉快的体验。使用新的作用域更新应用程序市场配置后，管理员应在管理控制台中看到重新授权应用程序的选项（他们不需要手动添加作用域）。但是，在他们这样做之前，用户将看到一个授权提示，询问新的作用域。这是正常的，但是，不应该影响您现有的上市。不过，通常最好向管理员发送电子邮件或在应用程序中显示警告栏，通知他们需要重新验证。再次感谢Eric。我想我们已经整理好了大部分范围，但是现在我们看到的不是范围屏幕，而是一个新的（对我们来说）屏幕，上面有一个人员选择器。这也是预期的吗？你使用多重登录吗？如果是，则可能第一次显示。