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.
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 use that.
What type of accounts can use OAuth 2.0?
- OAuth 2.0 is used by all accounts, i.e., both paid and non-paid G Suite accounts.
- For administrative authentication, BitTitan uses OAuth 2.0 ServiceAccount workflow.
- For user authentication, BitTitan uses OAuth 2.0 WebApplication workflow.
Note: Previously, OAuth 1.0 was only available to paid G Suite accounts, namely G Suite for Business and Education.
How do I migrate using OAuth 2.0 with administrative authentication?
Follow the directions in the Knowledge Base article KB005019 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.
What if I want to run a migration on a G Suite account without adding OAuth credentials?
If not using administrative authentication, then an OAuth 2.0 challenge requires user actions in order to authorize MigrationWiz to access their data. After submitting a migration for mailbox(es), MigrationWiz will send an email to each user mailbox in order to ask for access privileges. Once the user confirms access privileges, their migration will begin.
- Non-paid Google account migrations will also follow the above OAuth 2.0 challenge methodology. It is necessary to migrate these accounts using the individual user name and passwords for each account.
- Previously Google used "ClientLogin" for such migrations. This has been deprecated and replaced by OAuth 2.0.
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.
What is OAuth?
OAuth is an open standard for authorization. OAuth provides client applications a 'secure delegated access' to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner, or end user. The client then uses the access token to access the protected resources hosted by the resource server. OAuth is commonly used as a way for web surfers to log into third-party web sites using their Google, Facebook or Twitter accounts, without worrying about their access credentials being compromised.
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.