Some customers have been concerned that the initial configuration of CubeBackup is too complicated, and they cannot understand why a simple authorization requires so many operations. In this post, I’d like to discuss OAuth 2.0 Service account and present a more detailed explanation of CubeBackup’s initial configuration.
Although it may seem complicated at first, the initial authorization process (described here) only consists of two steps:
1. Create a Service Account in Google Developers Console.
A Google OAuth 2.0 service account allows the administrator of the Google Apps domain to authorize an application to access user data on behalf of users in that domain. This authorization is also referred as “domain-wide authorization” or ” 2 Legged OAuth”. To create a service account, you need to login Google Developer Console with a personal account (e.g.: [email protected] or [email protected]). For the purposes of this step, you may consider yourself a developer of Google APIs.
2. Authorize Access to your Google Apps Domain for the Created Service Account.
Next, the Google Apps administrator should enable the service account created in the previous step to access the data in your Google Apps domain.
Q1. What is an OAuth 2.0 Service Account?
OAuth 2.0 enables a third-party application to obtain limited access to an HTTP service. Through OAuth 2.0, the application requests an access token from the specific HTTP service and then attach the token to the subsequent requests to that service. It is a modern, safe authorization standard which protects your credentials from being leaked to anyone else. OAuth 2.0 is the Google’s recommended login method for all third party applications.
A Google OAuth 2.0 service account is a variant of the standard OAuth 2.0, which enables data access to an entire Google Apps domain, not just a single Google account. This is also called 2-Legged OAuth 2.0. More detailed information is available at https://developers.google.com/identity/protocols/OAuth2ServiceAccount#overview.
Q2. Why are CubeBackup users required to create a service account themselves? Shouldn’t this be done automatically?
Service accounts could, of course, be created automatically, or even embedded within CubeBackup itself, but this would negate some very powerful advantages:
I) By manually creating a service account, users can tailor the account to their own needs by enabling/disabling Google APIs, setting up the request quotas, etc. They can also monitor API requests statistics in real time using Google Developer Console.
II) A single service account shared by multiple users might overrun quota limitations. For example, the default Google Drive API quota is 1,000,000,000 requests per day, which should be sufficient for a single organization in most cases. But if this service account is shared by hundreds of organizations, the quota could easily be reached.
III) Leaving the creation of service account to a third-party is always a potential security risk. The service account owner can monitor your requests, set request quota, and generally interfere with your business.
Q3. Why is CubeBackup’s configuration more complicated, when other web-based apps on Google Apps marketplace seem to easily integrate with Google Apps?
The situation with web-based apps is a little different. They need service account authorization to access Google Apps data, just like desktop apps, but most web-based apps/addons for Google Apps are installed through Google Apps marketplace, as explained by Google: “When you use Google Apps Marketplace to install an application for your domain, the required permissions are automatically granted to the application. You do not need to manually authorize the service accounts that the application uses.”
Unfortunately, this straightforward app integration is only available for web-based Google Apps tools, and not for desktop apps. One of the strengths of CubeBackup is its ability to backup all Google Apps data to local storage, which is simply impossible with web-based approaches, due to the security limitation of web browsers. The trade-off for this flexibility and power is that service account configuration and authorization must be done manually.