These questions and answers are specific to how OAuth 2.0 works with BitTitan products. The first section covers FAQs specific to OAuth/BitTitan. The second section covers more generic FAQs about OAuth.
What happened to end-user credentials?
Google no longer supports end-user credentials for migrations, due to security concerns. To migrate to or from any Google environment, including free GMail accounts, OAuth 2.0 or the Google GMail API is required. (We do not support migrations for any free Google environment.)
What is OAuth?
How is authentication handled with G Suite?
We use OAuth 2.0 in order to authenticate to G Suite accounts for all Google services. This includes email, contacts, calendars, and documents under Google Drive.
Note: Google also supports OpenID authentication methodology, but BitTitan does not support OpenID.
What type of accounts can use OAuth 2.0?
- OAuth 2.0 is used by all accounts, both paid and free. However, BitTitan only supports migrations for paid accounts.
- For administrative authentication, BitTitan uses OAuth 2.0 ServiceAccount workflow.
- For user authentication, BitTitan uses OAuth 2.0 WebApplication workflow.
How do I migrate using OAuth 2.0 with administrative authentication?
Follow the directions in the Knowledge Base article Enable access to G Suite using OAuth 2.0 to set up the G Suite account to use OAuth 2.0. In order to provide us administrative authentication access to your G Suite data, add certain allowed scopes to the MigrationWiz project, as described in the article. Also, the article shows how to enable API access, which is required for performing a Google Drive migration.
Here are some more generic (non-specific to MigrationWiz) questions and answers about OAuth and OAuth 2.0. These have been included here to provide some more detail about how it works.
How does OAuth 2.0 work?
To access protected data stored on Google services, use OAuth 2.0 for authorization. Google APIs support OAuth 2.0 flows for different types of client applications. In all of these flows, the client application requests an access token that is associated with only the client application and the owner of the protected data being accessed. The access token is also associated with a limited scope that defines the kind of data the client application has access to (for example, "Manage your tasks"). An important goal for OAuth 2.0 is to provide secure and convenient access to the protected data, while minimizing the potential impact if an access token is stolen.
The typical work flow for OAuth 2.0 requests:
- When a user first attempts to use functionality in your application that requires the user to be logged in to a Google Account or YouTube account, your application initiates the OAuth 2.0 authorization process.
- Your application directs the user to Google's authorization server. The link to that page specifies the scope of access that your application is requesting for the user's account. The scope specifies the resources that your application can retrieve, insert, update, or delete when acting as the authenticated user.
- If the user consents to authorize your application to access those resources, Google returns a token to your application. Depending on your application's type, it either validates the token or exchanges it for a different type of token.
- For example, a server-side web application exchanges the returned token for an access token and a refresh token. The access token lets the application authorize requests on the user's behalf, and the refresh token lets the application retrieve a new access token when the original access token expires.