Bottom line of this piece is: If you are using gmail, you should be using two-factor identification security anyway and WP Issues CRM works with an app specific password.
WP Issues CRM supports both reading and sending of email through industry standard SSL/TLS encrypted connections. For incoming email, it uses the standard PHP extension that implements the industry standard Internet Message Access Protocol. For sending email, it support several different protocols, most importantly, SMTP which allows you to connect with essentially any outgoing mail server.
Gmail supports access for both sending and receiving using IMAP and SMTP over SSL. Google has also been part of an industry effort to develop a new login (“authentication”) approach for initiating IMAP and SMTP connections over SSL. That approach is known as Oauth. WP Issues CRM does not, at this time, support Oauth.
The central idea of Oauth is to allow apps to access to user-specific data (e.g. email messages ) that reside at Google without actually sharing Google login passwords with the apps. Instead, the app developer manually registers with Google and when users want to grant the app access to Google data, they do so directly from their Google account and Google then sends a unique access token to the app.
This approach is most important in the case of centralized apps like say your favorite sports activity logging application which you might want to give access to your Google (or Facebook) account to gather some personal data. Without Oauth, your sports app would have to know your Google account password and everyone else’s Google account password. So would every app that wanted to get Google information about you. The result would be multiple copies of login information for Google users residing on lots of servers and Google would be much less secure.
Oauth is not so relevant in the case of a WordPress plugin like WP Issues CRM. WP Issues CRM does not store information in any central place. You get your own copy of WP Issues CRM and it does not “phone home” to send data about you in any way. It is not like an app that runs on your phone and interfaces with a central server that supports other users. Your copy of WP Issues CRM only supports you.
WP Issues CRM does store the passwords that you supply for logging in to email and if your WordPress server was hacked, they could be exposed. But at that point, the app specific credentials that you get through the Oauth process would also be exposed. So, although the marginal security advantage offered by Oauth is not zero for a WordPress plugin like WP Issues CRM, it is much less than in it is for an app that is served centrally.
The best alternative to Oauth to protect your password is to use two-factor identification. That way if someone ever does steal your password, they will have a hard time logging into your account. Once you set up two factor security on your account, you can also get an application specific password that allows WP Issues CRM to login.
So, for now, if you wish to use WP Issues CRM to access a gmail account, you should be using two-factor identification to protect your password, but cannot use Oauth.
We’ve researched what would be entailed to add Oauth support to WP Issues CRM — overall, it would force big changes. On the outgoing side, it is not hard. It is easy enough, using standard libraries that could be packaged with the plugin, to access Google to obtain Oauth credentials. It is also straightforward to use those credentials for outgoing email. The standard PHPMailer, which is packaged with WordPress and which WP Issues CRM uses for SMTP outgoing mail, does support Oauth. However, the IMAP functions in PHP, which we use for reading email do not support Oauth, so we would have to switch to using a completely different library of IMAP functions. The only candidate we know about, the Zend framework does not support all actions that WP Issues CRM currently takes through IMAP (e.g., folder creation). Additionally, it does not appear to support message access by UID.
An interesting alternative would be to depart completely from the IMAP/SMTP framework and use the direct GMail API but Google does not seem to recommend this for heavier read/send activities.
One additional reason that adding Oauth for WP Issues CRM does not make sense is the burden involved for users. Since there is no central app, each copy of WP Issues CRM is its own app from the standpoint of Oauth. Each person who installed WP Issues CRM would have to master the Google credentialing process to create their app credentials. Google has made the process clearer, but it is still involves many steps in an environment that is unfamiliar to most users.
Given the availability of two factor identification as a password protection approach, it doesn’t seem like the benefit remotely approaches the cost and uncertainty involved in getting away from the PHP IMAP functions. That is especially the case since Oauth is not truly a standard, it is really an approach and the development involved for Google Oauth would not necessarily improve the interface with any other email provider. The main reason for us to do it would be to avoid having Google call us a “less-secure” app, but that labeling advantage does not seem like enough reason to invest in it.
But let us know if we are wrong — we’d be very interested to hear if you feel Oauth support would be valuable for you and why.
