ICS Email and OAuth2

[Angus Robertson 577]

In June 2022 Google stopped accepting traditional authentication methods for it's SMTP and POP3 email servers, instead requiring OAuth2, and I believe Microsoft is doing the same from October 2022.

 

The main different with OAuth2 is the application does not store the account password so is unable to share it.  Instead the user is directed to a sign-in web page from Google or Microsoft where the account details are entered and the application receives limited life tokens that are used instead of the password.  For this to work, the developer needs an application account at Google or Microsoft to obtain a application client ID and secret, which need to saved securely and sent as part of the OAuth2 sign-in. In theory, Google and Microsoft need to approve applications using the account client details, and will give warnings during sign-in after a grace period.

 

If sign-in works, the application receives an access token usually with a life of a few hours, and a refresh token that may be stored securely like a password and may have a life of several months and which may be used to obtain a new access token without a new sign-in.  Note the refresh token may be cancelled at any time requiring a new sign-in.  The refresh token may also be shared between different applications using the same client details and email account, for instance with servers where interaction is not possible.

 

ICS added support for OAuth2 with version V8.65 in November 2020 to the TSslSmtpCli, TSslPop3Cli and TIcsMailQueue email components, by adding the TIcsRestEmail component to projects with some extra code, as illustrated in the samples OverbyteIcsMailQuTst, OverbyteIcsSslMailSnd and OverbyteIcsSslMailRcv.

 

But the ICS server samples using email were not updated at the time, so have now been done for the forthcoming V8.70 release which is available from SVN and the overnight zip, OverbyteIcsSslMultiWebServ, OverbyteIcsDDWebService and OverbyteIcsSslMultiFtpServ.

 

Since other developers may similarly need to add OAuth2 support for email applications, this is a quick guide.

 

1 - For the TSslSmtpCli, TSslPop3Cli or TIcsMailQueue component, add an onOATokenEvent handler.

2 - Drop a TIcsRestEmail component named IcsRestEmail and add onEmailNewTokenEvent and onEmailProgEvent handlers.  The LoginTimeout property defines how long the component will wait for an interactive browser OAuth2 login, if necessary, defaulting to 30 seconds.  If this happens the onEmailNewTokenEvent is called allowing the application to save the new refresh token to avoid further interaction.

3 - In the onOATokenEvent event, call the IcsRestEmail.GetNewToken method and set the handler properties Token, TokExpireDT and TokAccount, see any of the samples.

4 - Set the IcsRestEmail component properties RestEmailType, ClientId, ClientSecret, and RefrToken, there is a function IcsLoadRestEmailFromIni that does this from an INI file for the server samples (without encryption).

5 - Set SMTP AuthType to smtpAuthXOAuth2 or POP3 AuthType to popAuthXOAuth2 with the appropriate host.  This causes onOATokenEvent to be called when an access token is needed.

 

Angus

 

[rvk 44]

13 hours ago, Angus Robertson said:

In June 2022 Google stopped accepting traditional authentication methods for it's SMTP and POP3 email servers, instead requiring OAuth2, and I believe Microsoft is doing the same from October 2022.

Just FYI. Once again (to eliminate any confusion). Google is not requiring OAuth2. You can still create app passwords and use them with your username for sending and accessing mail. OAuth2 is just another option (besides the app passwords) of doing it. App passwords work without any modification of existing code.

 

OAuth2 is always handy if it's implemented but it isn't the only option for Gmail. Even after the change on May 30, 2022.

 

 

Edited July 7, 2022 by rvk

[Angus Robertson 577]

Quote

Google is not requiring OAuth2

I have two Gmail accounts, one had high security and always required OAuth2, the second I never upgraded and worked with plain authentication until June 2022 when password authentication started failing.  So my experience is that plain password support was automatically removed without my changing anything. 

 

Do you have a Goggle reference that states in what circumstances plain passwords are supported?

 

Angus

[rvk 44]

16 minutes ago, Angus Robertson said:

Do you have a Goggle reference that states in what circumstances plain passwords are supported?

Google never stated that plain passwords are not supported anymore altogheter.

BUT they DID state that you own Google password can't be used anymore for mail (that was the "Less secure apps"-options).

This change was implemented on May 30, 2022.

 

If you have enabled 2FA you can still create an App password here:

https://myaccount.google.com/security

(just try it yourself, but you do need 2FA enabled on that account, so you can try it with your high security account :))

 

The steps are explained in this post:

https://support.google.com/accounts/thread/163639845?hl=en&msgid=163700497

 

Quote

Option 2: Continue using a legacy email client
Going forward, you will need to follow the steps below if you want to continue to access your Gmail using a legacy mail client. By following these steps. you should be aware that your Google account is less secure because it's linked to a mail client that doesn't support modern authentication.

 

Other help page of Google for Signing in with App passwords:

https://support.google.com/mail/answer/185833?hl=en-GB

 

So... yes, Google has removed the "Less secure apps" options where you could still login with your Google username and Password, but the options of App passwords still remains and will continue to work because Google never stated that App passwords will go away.

 

Edited July 8, 2022 by rvk

[Angus Robertson 577]

I never setup 2FA unless I can not avoid it.  The 'Google App Password' concept seems like a bodge, effectively it's an App Token being used without client secrets, so legacy applications can cope, I assume mainly for large corporates.  

 

Angus