如果Google Apps for Work域管理员为其域安装了我们的应用,则有一个marketplace requirement,管理员和其域中的所有用户此后都不会在访问我们的应用时看到范围验证屏幕。为域安装应用程序的行为应隐式委托与我们的应用程序关联的服务帐户的域范围权限。
为了实现此行为,我正在尝试delegation of authority to a service account代表当前登录用户AKA模仿。
下面的代码段显示了我为实现此目的所做的各种尝试。唯一有效的方法是将域超级用户的电子邮件地址作为" sub"创建JWT时的param(AKA 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
);
Google是否尊重任何其他ID,而不仅仅是您要模仿的人的电子邮件地址,例如特殊的&#39; me&#39;值?
感觉好像我们在这里碰到了鸡和蛋的问题。基本上我们不想对电子邮件地址进行硬编码(特别是不是管理员电子邮件),所以感觉我们必须进行API调用。但我们无法冒充用户就可以进行API调用。
答案 0 :(得分:1)
在这种情况下,您无需使用服务帐户和域范围的委派。相反,只需与用户一起浏览正常的OAuth2流程,就会自动跳过审批屏幕。
当管理员安装应用程序并批准您的范围时,它们实际上会自动授予您对域中所有用户的访问权限的权限。虽然要求用户看不到批准屏幕,但仍需要与他们一起完成OAuth2流程以获取OAuth2令牌。如果您为用户启动了OAuth2流程,并且未请求域管理员尚未批准的任何作用域,并且未在URL中设置approval_prompt=force
,则OAuth2批准屏幕将立即重定向到您的重定向URI ,使该过程对用户不可见。