The following questions and answers are specific to how OAuth 2.0 works with BitTitan products for Google migrations.
What is 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.
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.
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. The article also explains how to enable API access, which is required for performing a Google Drive migration.
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.
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.
- 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.
OAuth Domain Locking
Domain locking is a security feature designed to ensure secure OAuth authentication. Domain locking ensures that any OAuth access you grant to MigrationWiz can only be used for migration projects that you own. When creating a project using OAuth authentication, you should list all domains for which MigrationWiz has been granted rights.
Instances where a domain locking is required include:
- When creating a MigrationWiz connector whose Source or Destination requires OAuth credentials.
- When creating a project whose Source requires OAuth credentials.