How The Recent Google OAuth Changes Might Affect Your Application

In response to the recent phishing attack that impacted many Google Docs users, Google made security changes which affected some Context.IO clients. The main impact is the application name now displayed by Google is based on the redirect URI. If you are using our connect_tokens, the redirect URI passed to Google is Google displays the name of the domain, which is “”. Therefore, “” is now listed where your application name used to be.

Since the redirect must ultimately lead back to Context.IO, we are unable to change the redirect URI in our connect_tokens. We explored other workarounds for developers, but ultimately we felt those workarounds involved too much work on the developer’s end and defeated the purpose of connect_tokens.

Developers using connect_tokens now have a couple options:

Option #1: Continue using connect_tokens as is

Here’s an example of how the connection process would look when using connect_tokens. You’ll notice that the application is shown on our connect screens but once we redirect to Google, they use the domain of the redirect URI, which is

If you choose this option, we suggest you clearly state the email syncing is powered by Context.IO so users understand why our name appears on Google’s authentication screen. We also recommend not using the skip_oauth_splash param that skips the Context.IO branded screens, as that could provide more context to the end-user.

Step One: User notified they are being redirected to a screen where they can choose the proper account

Step Two: End user chooses which account to authenticate

Step Three: The end user approves access rights for your application

Step Four: Your end users might also receive an email notification from Google to confirm they consented to the app connection.

Option #2: Handle OAuth on your end so the redirect URI will be your domain.

This will ensure your name shows up on the Google authentication screen. After you connect, you simply pass us a provider_refresh_token and a provider_consumer_key to this endpoint.

Step one: The user chooses their email provider

Step Two: End user connect to email account

Step Three: End user approves access for your application

As these screens demonstrate, handling the OAuth integration on your end ensures that your name appears at each stage of the authentication process so there is no confusion for the end users. For more information on how to implement OAuth, check out these libraries and services that support OAuth 2.0.

Please contact us at if you have any questions, concerns, or comments!