The integration between Google Drive and our backup software (Akeeba Backup for Joomla!, Akeeba Backup for WordPress, and Akeeba Solo) is undergoing some changes necessitated by policy updates on Google's side.
If you are using a personal Drive you will experience no change. If you are using a shared drive you will have to upgrade to our new releases, create a (free of charge) Google Drive API application, and re-authenticate your backup software against your own API application.
Why is this change necessary?
Google Drive uses the OAuth2 authentication method. This is a three party authentication involving the service provider (Google Drive), the user logging into the service (you), and an application with a predetermined URL which uses its public key to "sign" the login request, and uses its private key to retrieve the Access and Refresh Token from Google Drive. This "mediation" application is something we offer as a service to our clients and is hosted on our servers. Its secret and public keys are provided by a Google Drive API Application which is under Google's control.
The Google Drive API Application uses one or more API access scopes to determine what the resulting Access and Refresh Tokens can do with the user's account once they are issued.
Google has changed its policy regarding third party application accessing its services, classifying the API access scopes into three categories: Non-sensitive, Sensitive, and Restricted.
The API access scope we were using, https://www.googleapis.com/auth/drive, belongs to the Restricted category. This comes with a number of requirements which are an overkill for the kind of service we provide (a simple mediation service). Meeting them would have incurred a signifficant cost which we'd have to pass to our clients.
These requirements are no longer necessary if we choose to downgrade the scope of our Google Drive API Application to the Non-sensitive https://www.googleapis.com/auth/drive.file API access scope. The only downside is that the integration with shared drives would no longer be working.
Based on the number of tickets we see for shared versus personal Google Drive usage, we concluded that very few people use shared drives. Therefore, the option which makes the most business sense for us is to opt into downgrading our API access scope, even though this means that out-of-the-box integration with shared drives is no longer possible.
Please note that this DOES NOT mean that using shared drives is no longer possible; it only means that it will now require some additional, one-time configuration on your part. Read on for more information.
How does it affect users of personal drives?
You will not face any service disruption.
If you get authentication errors, they are unrelated to the changes we made, e.g. your refresh token may have expired because it has not been used in a while. If you do get an authentication error, edit the backup profile's Configuration and re-authenticate using the Authentication - Start Here button.
How does it affect users of shared drives?
Users who cannot upgrade past Akeeba Backup for Joomla! 9.9.3, Akeeba Backup for WordPress 8.2.2, or Akeeba Solo 8.2.2 will lose access to shared drives. This also applies to clients who are still on a CMS or PHP version for which our software is on extended security support, or completely out of support. We do not backport changes made to our software to address third party service changes into old versions of our software which are in extended security support, or completely out of support.
Users who can upgrade to at least the versions of our software noted above can set up the "Self-hosted OAuth2 helpers" feature in Akeeba Backup / Solo as per our documentation. You will be creating your own, free of charge Google Drive API Application with the wide-access https://www.googleapis.com/auth/drive scope, allowing you to access shared drives.
When you do that, you MUST NOT go through the application verification step, i.e. do NOT click on Publish in Google Cloud Control Panel. Using an unpublished application lets you link it with up to 100 Google accounts without being subject to the expensive and time-consuming requirements necessary when an application using Restricted API scopes is published. That's the entire reason why you can use a custom OAuth2 helper when we cannot provide this service ourselves; we have to go through verification of our API application since it has a lot more than 100 users.
IMPORTANT! You DO NOT need to that for each of your sites. You only need to set up the custom API application on one site only. Then, you can configure all of your other sites to use that first site's helper URL before authenticating. While there is a bit more work to be done, you only need to do it once.
How does it affect users whose subscription has expired?
Having an active subscription is a requirement for using our backup software's integration with Google Drive. Clients with expired subscriptions have already been unable to use our integration with Google Drive. Therefore, there is no change from the perspective of users with expired subscriptions.
What about users stuck on old PHP, Joomla, or WordPress versions?
If you are using a personal Google Drive you will not have any issues whatsoever.
If you are using a shared Google Drive you will lose access to it. You can either move to a personal drive, or a different storage provider. We recommend using an S3-compatible service such as Amazon S3, or Wasabi, or a cheap business-oriented storage provider such as BackBlaze B2.
Possible temporary service disruption
Switching the scope of our API application will cause a temporary service disruption of 1 to 3 business days while Google processes our request. During that time, trying to authenticate into Google Drive may be impossible, and/or you may see a warning that our application is "unverified".
This is normal. After changing the API scope we have to ask Google to "verify" our application all over again. In theory, using a Non-sensitive scope should allow Google to verify our application very fast, but there are no guarantees to that effect given, hence our warning here.