Google Forces Developers to Stop Using PHP IMAP Extension

Starting February 15, 2021, G Suite accounts will only allow access to apps using OAuth.

There is no way to use standard PHP IMAP extension to connect to Gmail via OAuth as imap_open function does not support suggested by Google SASL XOAUTH2 protocol.

It means all PHP projects using standrard PHP IMAP functions will need to redesign their projects to use Zend Mail library, which is able to use Google IMAP OAuth algorithm.

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

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). PHP IMAP is standard extension written in C, it is fast and reliable. And it is just weird to switch to a third-party library from the native PHP extension. When starting the project we’ve intentionally chosen PHP IMAP to make the app as fast as possible, but now Google makes the whole PHP world to stop using PHP IMAP extension…

Check out this 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.

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? 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.

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.

Here is the open request to Google from the FreeScout Team:

Google’s intention to make the world of IMAP more secure may be good, but it is done in an upside down way.

The proper procedure for this would be:

  1. Make sure PHP IMAP extension supports OAuth.
  2. Publish instructions for developers on how to authenticate via OAuth in PHP IMAP.
  3. Developers make minor changes in imap_open function calls.
  4. End users are happy.
  5. Everybody happy.

But in reality we’ve got an upside down workflow:

  1. Google did not make sure that PHP IMAP extension supports OAuth.
  2. Google suggested developers to switch from the official PHP IMAP extension to the third-party library.
  3. Developers suffer because of tons of work they have to do to migrate their projects from the official PHP IMAP extension to the third-party library (this means to change not just one function call, but to refactor the whole code).
  4. End users suffer because they get a performance drop due to switching from the native PHP extension written in C to the third-party library.
  5. Nobody is happy.

Google had many years to make sure transition to OAuth in PHP IMAP will go smoothly, but failed by some reason. So now it is developers and end users who have to suffer.




Free open source help desk & shared mailbox

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Free open source help desk & shared mailbox

More from Medium

How to Build a Robust web application with PHP and CodeIgniter

Why I built Waterfall, an open-source package to perform cascading deletes.

PHP and Node.js are used For an ERP system

How To Use Enums With Laravel 9?