Gmail OAuth and Standard PHP IMAP

[freescout-helpdesk]

• Starting February 15, 2021, G Suite accounts will only allow access to apps using OAuth
• June 15, 2020 - Users who try to connect to an LSA (non-oauth) for the first time will no longer be able to do so.

(freescout-help-desk/freescout#390)

1. There is no way to use standard PHP IMAP extension https://www.php.net/manual/en/ref.imap.php to connect to Gmail using OAuth?

2. It will be impossible to access Gmail also via POP3 protocol without OAuth?

[freescout-helpdesk]

If both are true, it means all PHP projects using standrard PHP IMAP functions will need to redesign their projects to use Zend Mail.

Just on the GitHub currently there are 121,653 scripts using standard PHP IMAP functions.

Most of them will not bother to redesign their projects to use Zend Mail, they will just ask G Suite users to stay away from their apps.

PHP IMAP is standard extension written in C, it is fast and reliable. It is just weird to switch to third-party library.

So if since February 15, 2021 all IMAP requests to G Suite will be made via OAuth why don't Google just allow to pass OAuth token as an IMAP password (https://developers.google.com/gmail/imap/xoauth2-protocol)? In this case all existing IMAP libraries will continue to function.

Why to reinvent the bicycle and force the whole world to use SASL XOAUTH2 protocol when the goal can be achieved within the standard IMAP authentication?

All Google need to do is to receive OAuth token in IMAP password for G Suite accounts. This is very simple, obvious, logical and elegant solution causing minumum headache to other developers. Google even can keep using SASL XOAUTH2.

[TomasVotruba]

Most of them will not bother to redesign their projects to use Zend Mail, they will just ask G Suite users to stay away from their apps.

That can be solved by automated upgrade tools.
Number of projects using old technology is not a valid reason to not use better one. Once there were more horses than cars. But is that a reason to walk to another state?

What I'm more interested are the reasons behind it. Could you share them?

[freescout-helpdesk]

That can be solved by automated upgrade tools.

We are afraid, not in this case. Zend Mail and PHP IMAP are not compatible. For some projects it will lead to months of development, debugging and bugfixing (like in case of our project).

What I'm more interested are the reasons behind it. Could you share them?

We don't want to waste time switching to the third-party library when the native PHP extension can be used. This is ridiculous... When starting the project we've intentionally chosen PHP IMAP to make the app as fast as possible and now Google makes the whole PHP world to stop using PHP IMAP extension. Should we sacrifce performance and common sense and abandon PHP IMAP extension?

Number of projects using old technology is not a valid reason to not use better one.

This is an example when the new authorization technology (OAuth) can be used within the standard IMAP authorization without causing a big headache to thouthands of developers.

[TomasVotruba]

We are afraid, not in this case. Zend Mail and PHP IMAP are not compatible.

Refactoring/migration isn't about compatibility. It's about transition from A to B.
They're both mailing concepts, which allows transition. It's not perfect, it will require some work, but it's possible to apply over whole Github code bases for every single use.

[freescout-helpdesk]

Check out https://packagist.org/packages/php-imap/php-imap package with over 1M installs. It is using standard PHP IMAP. More than 1M projects utilizing this package will be unable to connect to G Suite Gmail accounts via IMAP, because G Suite OAuth is not compatible with PHP IMAP.

The idea to make IMAP interaction more secure is good, but it can be implemented in a more considerate way.

@TomasVotruba are you in contact with Google developers? It would be good to know what is the reason not to pass OAuth token as IMAP password when OAuth token does serve as a password during IMAP authentication.

[TomasVotruba]

Again, the number of installs and spread is irelevant for innovation.
I know it sucks, but that how innovation works. People don't like change, that's how our brains work.

If you're able to show me migration path, I can help with automation for all Github repositories that use it.

[tedivm]

This isn't "innovation", this is Google breaking standards. Innovating would be evolving the standards- this is just a power grab by Google.

[tedivm]

@freescout-helpdesk - my imap package only has half a million installs, but I've already been getting requests to deal with this situation.

It's not just a programming issue either. My company is currently using Google Suites, and we have to turn off this OAuth requirement for our users to be able to use their existing calendar and email clients.

[molbal]

This is not evolving and not innovation. This is forcing one standard and dropping support of another tool (The IMAP library) If using IMAP would be a real security risk or it had known vulnerabilities I would understand this move from Google. Developers will gain nothing from switching to another library, because most (or all?) functions can be done with IMAP too.

But if this rule gets enforced then thousands of developers will have to work hours just to RETAIN current functionality. It might be automatized, or it might be manual work or somewhere in between, but even if it's just 20 minutes of work, that 20 minutes could go towards improving the project and not refacing part of a project forced by a 3rd party.