我有一个Web应用程序，该应用程序以用户的名义发送电子邮件（Gmail）
时，当用户注册时，她提供Gmail帐户和密码。她还必须启用较不安全的应用程序的访问（我建议为此创建一个新帐户）
，然后我可以打开Gmail会话
session = Session.getInstance(props, new javax.mail.Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication(user.getEmail(), user.getPassword());
}
});
并代表她发送电子邮件。
不幸的是，这将停止下一个5月30日，当Google仅允许oauth2访问时，
我遵循 gmail api的java QuickStart 我有代码启动并运行了用于使用OAuth2：enable Gmail API发送电子邮件的代码，在Google Cloud Platform上创建一个应用程序，Grant send send send oleuth2 client2 client 2 client ID创建...
问题i有我看不到一种自动化此任务的方法，因为在创建授权凭据时，在浏览器上显示同意屏幕，您必须选择要手动授予的帐户（也许是因为我在Google Cloud Platform中的应用程序仍在被审查）
有没有办法从凭据文件（client_secret.json）访问的Gmail帐户？有没有办法自动化这一点？
I have a web app which sends emails (gmail) in name of my users
When a user registers, she supplies gmail account and password. Also she has to enable access for Less Secure Apps (I recommend to create a new account for this)
Then I can open a gmail session
session = Session.getInstance(props, new javax.mail.Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication(user.getEmail(), user.getPassword());
}
});
and send emails on her behalf.
Unfortunately this is going to stop working next 30th May, when Google will allow only OAUTH2 access
I have followed Java Quickstart for Gmail API and I have code up and running for sending emails with OAUTH2: enable gmail api, create an application on google cloud platform, grant send permission, oauth2 client id credential created...
The problem I have is I can't see a way to automatize this task because when creating an authorized credential, a consent screen displays on browser and you have to select the account to be granted manually (maybe because my app in google cloud platform is still pending to be reviewed)
Is there a way to infer the gmail account you want to access from the credentials file (client_secret.json)? Is there a way to automatize this?
发布评论
评论（1）
不，或者是。这取决于。
OAuth2的全部目的是通过使用授权令牌而不是要求用户凭据来提高安全性。为此，用户必须对应用程序的访问请求同意，因此OAuth同意屏幕不能绕过。这是
在Google的。 com/workspace/guides/configure-oauth-consent“ rel =“ nofollow noreferrer”>文档。它与您的应用程序的评论状态无关，而是Oauth的工作方式。
但是，您仍然可以以类似的方式工作。而不是在用户注册时询问用户名和密码，而可以将其重定向到OAuth同意屏幕，以便他们可以授权您的应用程序。确保您的应用要求 offline 访问访问类型，然后您可以检索
access_token和refresh_token。这些本质上将作为您的凭据来工作，您可以使用刷新令牌在需要时在不需要每次通过同意屏幕的情况下生成新的访问令牌。刷新令牌没有“自然”到期，因此您可以无限期地使用它，但是在某些情况下，它会变成无效的，例如六个月未使用，用户更改密码（如果使用Gmail示波器），用户手动撤销访问等等。在这些情况下，您将需要再次将它们引导到同意屏幕上以重新授权您的应用程序。
从这个意义上讲，您的应用程序仍然可以自动工作，而无需用户输入，除了初始设置，当他们为您提供其凭据时，您已经必须处理。当用户更改当前工作流程中的密码时，甚至可以将刷新的令牌到期与您必须执行的操作进行比较。
一个例外是服务帐户。 If you and your users are part of a Google Workspace domain you can delegate< /a>域范围内访问它，然后该服务帐户将能够访问用户数据，而无需任何手动输入。当然，这是因为作为域管理员，您几乎拥有其中的所有帐户。但是，如果您正在使用公开可用的应用程序，则必须处理我上面提到的限制。
Sources:
No, or yes. It depends.
The whole point of OAuth2 is to improve security by working with authorization tokens rather than asking for user credentials. To do this the user has to consent to the app's access request, and thus the OAuth consent screen cannot be bypassed. This is
explained in Google's documentation. It's not related to your app's review status but rather it's the way OAuth works.
You can still work in a similar way, though . Instead of asking for username and password upon the user's registration you can redirect them to the OAuth consent screen so they can authorize your app. Make sure that your app is requesting offline access type and then you can retrieve an
access_tokenand arefresh_token. These will essentially work as your credentials and you can use the refresh token to generate new access tokens when needed without having the user go through the consent screen each time.The refresh token doesn't have a "natural" expiration so you can keep using it indefinitely, but there are a few scenarios where it will become invalid, such as it not being used for six months, the user changing passwords (if using Gmail scopes), the user manually revoking access, etc. In these cases you will need to direct them to the consent screen again to reauthorize your app.
In this sense, your app can still work automatically without user input except the initial setup, which you already had to deal with when they supplied you with their credentials. The refresh token expiration can even be compared to what you had to do when the users changed their passwords in your current workflow.
One exception to this are service accounts. If you and your users are part of a Google Workspace domain you can delegate domain-wide access to it, then the service account will be able to access user data without any manual input. Of course, this is because as the domain administrator you pretty much own all the accounts under it. But if you're working with a publicly available application you will have to deal with the limitations I mentioned above.
Sources: