如何设置带有权限的Google服务帐户,以发送电子邮件以发送一个用户帐户(不是域名范围的代表团)
在设置了一个特定项目的服务帐户中,该项目将其添加到启用API中的“ Gmail API”。
是否可以在Google Workspace帐户(不是每个帐户)上设置一个用户帐户之一的权限,以便该服务帐户只能发送该用户帐户的电子邮件?
In have set up a service account for a particular project and that project has the "Gmail API" added to it as an enabled API.
Is there a way to set up permissions for one of the user accounts on the Google workspace account (not every account) so that that service account can send emails for that user account only?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
服务帐户是无法访问各个用户数据的凭据。 SA只能通过域范围的委托访问每个用户的用户数据。换句话说,使用服务帐户是您需求的错误方法。
另一方面,客户ID是用于请求特定用户对用户拥有的数据访问的凭据。这是使用Google Workspace API(例如Gmail API)请求访问数据时使用的主要凭据。此凭据需要用户同意。但是,一旦获得了此同意,服务器应用程序就可以访问用户数据,而无需使用用户。这称为离线访问。
该同意采用访问令牌和刷新令牌的形式。您可以使用Google OAuth 2 API获取它们,并以相同的方式使用服务帐户使用它们。
A Service Account is a credential that can not access individual user data. SA can only access user data for every user via Domain Wide Delegation. In other words, using a service account is the wrong approach for your needs.
Client Id, on the other hand, is the credential used to request access to user-owned data for a specific user. This is the primary credential used when requesting access to data using Google Workspace API such as GMail Api. This credential requires user consent. However, once this consent is obtained, a server application can access user data without user being ever present. This is called offline access.
This consent takes form of an access token and a refresh token. You can obtain them using Google OAuth 2 Api and use them in a similar same way you would use a service account.
要代表Google Workspace用户发送电子邮件,您需要将域范围内的授权委托给您的服务帐户。该服务帐户可以一次模仿不同的用户。因此,如果您想模仿一个用户,则没有问题,因为您在制作授权的API调用。
将DWD委派给服务帐户后,您将进行授权的API调用,并在其中指定用户的电子邮件地址以模仿。这意味着服务帐户仅可以从该应用程序中的特定帐户中访问数据。
To send emails on behalf of a Google Workspace user, you need to delegate domain-wide authority to your service account. The service account can impersonate different users one at a time. So if you are looking to impersonate one user, there is no problem as you actually specify the user's email address when making an authorized API call.
After you delegate DwD to a service account, you make the authorized API call where you specify the user's email address to impersonate. This means that the service account only has access to data from that specific account the application is impersonating.