Tag Archives: oauth

Saying goodbye to OAuth 1.0 (2LO)

Originally posted on Google Apps Developers Blog

Posted by Vartika Agarwal, Technical Program Manager, Identity & Authentication, and Wesley Chun, Developer Advocate, Google

As we indicated several years ago, we are moving away from the OAuth 1.0 protocol in order to focus our support on the current OAuth standard, OAuth 2.0, which increases security and reduces complexity for developers. OAuth 1.0 (3LO)1 was shut down on April 20, 2015. During this final phase, we will be shutting down OAuth 1.0 (2LO) on October 20, 2016. The easiest way to migrate to the new standard is to use OAuth 2.0 service accounts with domain-wide delegation.

If the migration for applications using these deprecated protocols is not completed before the deadline, those applications will experience an outage in their ability to connect with Google, possibly including the ability to sign-in, until the migration to a supported protocol occurs. To avoid any interruptions in service for your end-users, it is critical that you work to migrate your application(s) prior to the shutdown date.

With this step, we continue to move away from legacy authentication/authorization protocols, focusing our support on modern open standards that enhance the security of Google accounts and that are generally easier for developers to integrate with. If you have any technical questions about migrating your application, please post them to Stack Overflow under the tag google-oauth.


1 3LO stands for 3-legged OAuth: there's an end-user that provides consent. In contrast, 2-legged (2LO) doesn’t involve an end-user and corresponds to enterprise authorization scenarios such as enforcing organization-wide policy control access.

Saying goodbye to OAuth 1.0 (2LO)

Posted by Vartika Agarwal, Technical Program Manager, Identity & Authentication, and Wesley Chun, Developer Advocate, Google

As we indicated several years ago, we are moving away from the OAuth 1.0 protocol in order to focus our support on the current OAuth standard, OAuth 2.0, which increases security and reduces complexity for developers. OAuth 1.0 (3LO)1 was shut down on April 20, 2015. During this final phase, we will be shutting down OAuth 1.0 (2LO) on October 20, 2016. The easiest way to migrate to the new standard is to use OAuth 2.0 service accounts with domain-wide delegation.

If the migration for applications using these deprecated protocols is not completed before the deadline, those applications will experience an outage in their ability to connect with Google, possibly including the ability to sign-in, until the migration to a supported protocol occurs. To avoid any interruptions in service for your end-users, it is critical that you work to migrate your application(s) prior to the shutdown date.

With this step, we continue to move away from legacy authentication/authorization protocols, focusing our support on modern open standards that enhance the security of Google accounts and that are generally easier for developers to integrate with. If you have any technical questions about migrating your application, please post them to Stack Overflow under the tag google-oauth.


1 3LO stands for 3-legged OAuth: there's an end-user that provides consent. In contrast, 2-legged (2LO) doesn’t involve an end-user and corresponds to enterprise authorization scenarios such as enforcing organization-wide policy control access.

Registering OAuth clients for Google Sign-In

Posted by Isabella Chen, Software Engineer, and Laurence Moroney, Developer Advocate

Starting with Google Play services 8.3, we did a major revamp of the Google Sign-In APIs, supporting both client and server auth. Behind the scenes, these APIs use OAuth 2.0 tokens to ensure secure authentication and authorization. To maintain security, we provide tools in the Google Developers Console to register the clients using these tokens.

In this post, we’ll discuss the important task of registering OAuth clients for Google Sign-In, and the tools that we offer to make this as easy as possible.

Here are some scenarios that might apply to you:

  1. Start by creating a project in the Google Developers Console, which registers the client app on your behalf.
  2. If you have a backend server in your project, you’ll need an OAuth client ID for it, too.
  3. And don't forget to register OAuth clients for other test and release versions of your app, too!

In this post, we’ll cover some details on this process and address common pitfalls.

Getting Started - Create a Project in the Google Developers Console.

If you have not used Google Sign-In before, you can start integrating the API into your app by following the ‘Get a configuration file’ steps on this site. You’ll be taken to a setup wizard that will create an OAuth 2.0 client ID as shown in Figure 1.

Figure 1. Configuring your app

Once you’ve specified your app, you’ll be taken to a screen to choose and configure services such as Google Sign-In, Cloud Messaging or Google Analytics that you want your app to be able to use.

Choose Google Sign-In. In order to use it, you’ll need to get the SHA-1 of the signing certificate for your Android app. This can either be a debug or a release certificate, and for the purposes of this blog you’ll look at a debug one, but keep in mind that you’ll need to repeat this process for each package / certificate pair you end up using (described in the last section below).

You can get the debug SHA-1 using the keytool command like this:

keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android

Once you have your SHA-1, enter it as seen in Figure 2.

Figure 2. Enabling Google Sign-in

Now that your project is set up, you can get started with integrating the Sign-In API. But if you need to configure your project to work with a backend server or additional package name / keystores, keep reading the sections below.

Server Config - Ensure your server is registered within the same project.

If you have your own web or cloud server with data for your application, you’ll need OAuth credentials for your backend. Details on doing this can be found in the ID token and server auth code documentation.

Before using these flows, you’ll need to make sure you register your web server correctly in the Google Developers Console. Once there, you’ll be asked to select your project. See Figure 3.

Figure 3. Going directly to a project in the Google Developers Console.

Once you’ve selected your project, press the ‘Continue’ button, and you’ll go directly to the Credentials tab where all credential types are managed. Check the “OAuth 2.0 client IDs” section, and you will see the “Web client” and “Android client for com.my.package.name” that were created for you by the setup wizard. See Figure 4.

Figure 4. The Credentials Tab on the Developers Console - Web server OAuth client info

Take note of the Client ID for for your Web client, you’ll need it for both your app and server as illustrated below. (If you’ve created your project in the past and there’s no OAuth 2.0 client ID with Type “Web application”, then you will need to create one by selecting ‘New Credentials’ -> ‘OAuth client ID’.)

If you use an ID token flow for backend authentication, when you start developing your Android app, request an ID token in your GoogleSignInOptions, supplying the web client ID for your server:

GoogleSignInOptions gso =
    new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
        .requestIdToken(serverClientId)
  .requestEmail()
  .build();

And then on your server, set the same OAuth client ID for your web application to be the audience:

GoogleIdTokenVerifier verifier =
    new GoogleIdTokenVerifier.Builder(transport, jsonFactory)
        .setAudience(Arrays.asList(serverClientId))
        .setIssuer("https://accounts.google.com")
        .build();

Successful verification will allow you to authenticate and issue a session for this newly signed-in user.

Alternatively, if you are using the server auth code flow for backend access to Google APIs, request a server auth code in your GoogleSignInOptions on Android, again supplying the web client ID for your server:

GoogleSignInOptions gso =
    new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
        .requestScopes(new Scope(Scopes.DRIVE_APPFOLDER))
  .requestServerAuthCode(serverClientId)
  .requestEmail()
  .build();

And then on the server, both the OAuth client ID and the “Client secret” will be useful. The server SDK from Google can directly consume a downloaded JSON configuration file. You can click the download icon to download the JSON file (as shown in Figure 4) and use below code to construct GoogleClientSecrets:

GoogleClientSecrets clientSecrets =
    GoogleClientSecrets.load(
        JacksonFactory.getDefaultInstance(),
        new FileReader(PATH_TO_CLIENT_SECRET_FILE));

At which point you can access authenticated Google APIs on behalf of the signed-in user. Note that the “client secret” is really a secret that you should never reveal in your Android client.

Handling multiple environments - Registering other client IDs for your project.

Note that it can be common for apps to have different package names as well as different certificates (and thus SHA-1 keys) for various types of environment (such for different developers or test and release environments). Google uses your package name together with SHA-1 signing-certificate fingerprint to uniquely identify your Android application. It’s important to register every package name + SHA1 fingerprint pair in Google Developers Console.

For example, to register the release version of this package, you can do so by selecting ‘New Credentials’ -> ‘OAuth client ID’, shown in Figure 5 below, and then following the steps to add the package name and production keystore SHA-1.

Figure 5. The Credentials Tab on the Developers Console - create additional OAuth client ID

Now you are ready to handle the different environments where your app might be running and release to your users!

Hopefully, this has been helpful to you in understanding how to register for OAuth keys to keep your apps and servers secure. For more information, check out the Google Developers homepage for Identity.

New guide for setting up AdWords API authorization using the OAuth 2.0 Playground

For those of you who’d prefer to generate an OAuth refresh token using only a browser, there's a new guide on how to use the OAuth 2.0 Playground:

https://developers.google.com/adwords/api/docs/guides/oauth_playground

The guide walks you through the authorization setup required by the AdWords API for a Web application--via a browser session--without the need to execute any command-line scripts.

More OAuth resources
Still have questions? Feel free to visit us on the AdWords API Forum or our Google+ page.

Changes to OAuth in Apps Script

Posted by Eric Koleda, Developer Platform Engineer

OAuth is the de facto standard for authorization today and is used by most modern APIs. Apps Script handles the OAuth flow automatically for dozens of built-in and advanced services, but until recently only had limited support for connecting to other OAuth-protected APIs such as Twitter, etc. The URL Fetch service’s OAuthConfig class only works with the older OAuth 1.0 standard and only allows the developer of the script (not its users) to grant access to their data. To address this, we’ve create two new open source libraries:

With only a few clicks, you can add these libraries to your scripts. The full source code is available on GitHub if you need to tinker with how they work. These libraries allow for greater control over the OAuth flow, including the ability for users to grant access separately, a long standing feature request from the community.

We believe that these open libraries are a better alternative to our previous solution, and therefore we are deprecating the OAuthConfig class. The class will continue to function until June 26, 2015, after which it will be removed completely and any scripts that use it will stop working We’ve prepared a migration guide that walks you through the process of upgrading your existing scripts to use these new libraries.

Separate from these changes in Apps Script and as announced in 2012, all Google APIs will stop supporting OAuth 1.0 for inbound requests on April 20, 2015. If you use OAuthConfig to connect to Google APIs, you will need to migrate before that date. Update your code to use the OAuth2 library or the API’s equivalent Advanced Service if one exists.


OAuthConfig Connecting ToMigrate ToMigration Deadline
Google API (Calendar, Drive, etc)OAuth2 for Apps Script or Advanced ServiceApril 20, 2015
Non-Google API (Twitter, etc)OAuth1 for Apps ScriptJune 26, 2015

We see Apps Script and Sheets as the perfect hub for connecting together data inside and outside of Google, and hope this additional OAuth functionality makes it an even more compelling platform.

Updates on Authentication for Gmail IMAP, POP, and SMTP

We’d like to highlight some recent and upcoming changes around authentication for Gmail IMAP, POP, and SMTP.

Additional Scrutiny for Password Authentication 
As previously announced, Google has begun increasing the security checks that occur when logging in with a user’s Google password. This includes access via Gmail IMAP, POP, and SMTP-MSA. It does not apply when authenticating with OAuth 2.0 via the XOAUTH2 mechanism.

If the checks detect anything suspicious about a password login attempt, our servers may deny login and return an error message requesting that the user first login to Google through a web browser. They may also require the user to explicitly enable “Less Secure Apps” on their account. Applications that perform password authentication to IMAP, POP, or SMTP are examples of "Less Secure Apps".

We strongly encourage developers to use OAuth 2.0 (via the XOAUTH2 mechanism for IMAP, POP, and SMTP) in order to better protect their users.

XOAUTH support ends May 5, 2015 
The OAuth 1.0 XOAUTH authentication mechanism for Gmail IMAP and SMTP-MSA is deprecated and will stop being supported on May 5, 2015. Developers must migrate to XOAUTH2 in order to continue authenticating to Gmail after that date. You can migrate existing users without their intervention by following the instructions in this migration guide. Instructions for developing your XOAUTH2 code are in the XOAUTH2 documentation.

Posted by Jamie Nicolson, Gmail Software Engineer

AdWords and DoubleClick Ad Exchange API users – Only 3 weeks left to migrate from ClientLogin to OAuth 2.0!

ClientLogin authentication support for the AdWords API and the DoubleClick Ad Exchange API will sunset along with v201309 on July 21st, 2014. You only have 3 weeks left to migrate!

We have plenty of resources to help you migrate. It might take longer than you expect to migrate to OAuth 2.0, especially if you don't already use a single top-level MCC to manage your AdWords accounts or if you are a DoubleClick Ad Exchange customer.

Start your migration as soon as possible and reach out to us early on the AdWords API Forum or the DoubleClick Ad Exchange API Forum with any questions.

AdWords and DoubleClick Ad Exchange SOAP API users – Only two months left to migrate from ClientLogin to OAuth 2.0!

ClientLogin authentication support for the AdWords API and the DoubleClick Ad Exchange SOAP API will sunset along with v201309 on July 21st, 2014. You only have two months left to migrate - don’t wait until the last minute!

We have plenty of resources to help you migrate. It might take longer than expected to migrate to OAuth2, especially if you don't already use a single top-level MCC to manage your AdWords accounts or if you are a DoubleClick Ad Exchange customer.

Start your migration as soon as possible and reach out to us early on the AdWords API Forum or the DoubleClick Ad Exchange API Forum with any questions.

AdWords API users – don’t wait to migrate from ClientLogin to OAuth 2.0!

ClientLogin authentication support for the AdWords API will sunset along with v201309 on July 21st, 2014. But it doesn’t mean you should wait till the last minute to migrate!

We have plenty of resources to help you migrate. It might take longer than expected to migrate to OAuth2, especially if you don't already use a single top-level MCC to manage your AdWords accounts.

Start your migration as soon as possible and reach out to us early on the AdWords API Forum with any questions.

AdWords API: Start your migration from ClientLogin to OAuth 2.0 now

Is your AdWords API client application still using ClientLogin? If so, you should start your migration from ClientLogin to OAuth 2.0 as soon as possible.

Your AdWords API client applications must be fully migrated to OAuth 2.0 before ClientLogin is sunset in June 2014, as previously announced. If you don't migrate by then, your client applications will fail -- they won't be able to access your MCC account or any AdWords account via the API.

How do I get started?

We have prepared a ClientLogin to OAuth 2.0 migration guide which includes:

  • Detailed migration strategies based on use cases
  • Code samples to automate parts of the migration
  • Client library-specific migration videos, code, and pertinent OAuth 2.0 documentation

You don't want to worry about your applications failing, so get started now. For most developers with a single top level MCC, this migration will involve only a few configuration and code changes. But if you run into any issues with your particular application or AdWords accounts, you'll be glad you left plenty of time before the sunset to work things out.

We are here to help

If you run into any issues, or if you have any questions, please reach out to us on the AdWords API Forum.