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.
Posted by William Denniss, Product Manager, Identity and Authentication
Support for ClientLogin, OAuth 1.0 (3LO1), AuthSub, and OpenID 2.0 has ended, and the shutdown process has begun. Clients attempting to use these services will begin to fail and must be migrated to OAuth 2.0 or OpenID Connect immediately.
To migrate a sign-in system, the easiest path is to use the Google Sign-in SDKs (see the migration documentation). Google Sign-in is built on top of our standards-based OAuth 2.0 and OpenID Connect infrastructure and provides a single interface for authentication and authorization flows on Web, Android and iOS. To migrate server API use, we recommend using one of our OAuth 2.0 client libraries.
We are moving away from legacy authentication protocols, focusing our support on OpenID Connect and OAuth 2.0. These modern open standards enhance the security of Google accounts, and are generally easier for developers to integrate with.
13LO stands for 3-legged OAuth where there's an end-user that provides consent. In contrast, 2-legged (2LO) correspond to Enterprise authorization scenarios such as organizational-wide policies control access. Both OAuth1 3LO and 2LO flows are deprecated, but this announcement is specific to OAuth1 3LO.
The easiest way to migrate to these new standards is to use the Google Sign-in SDKs (see the migration documentation). Google Sign-in is built on top of our OAuth 2.0 and OpenID Connect infrastructure and provides a single interface for authentication and authorization flows on Web, Android and iOS.
If the migration for applications using these deprecated protocols is not completed before the deadline, the application will experience an outage in its 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, it is critical that you work to migrate prior to the shutdown date.
If you need to migrate your integration with Google:
If you have any technical questions about migrating your application, please post questions to Stack Overflow under the tag google-oauth or google-openid.
1 3LO stands for 3-legged OAuth: There's an end-user that provides consent. In contrast, 2-legged (2LO) correspond to Enterprise authorization scenarios: organizational-wide policies control access. Both OAuth1 3LO and 2LO flows are deprecated.
If your app allows users to save music playlists to Google Drive, you can ask for basic profile info at startup, and only ask for Google Drive permissions when they’re ready to save their first mix. Likewise: you can ask for Google Calendar permissions only when users RSVP to an event, and so on.
More and more websites are enhancing their login systems to include buttons for identity providers such as Google, Yahoo, Facebook, Twitter, Microsoft, etc. Users generally prefer this approach because it makes it easier for them to sign up for a new site that they visit. However if a user already has an account at a website, and they are used to logging in with their email and password, then it is hard to get them to switch to using an identity provider.
Google has recently released a sample site that shows how a website can migrate users away from password based logins, and instead have them leverage an identity provider. This sample site incorporates many of the ideas of the Internet Identity community, as well as feedback from numerous websites who have been on the cutting edge of applying these techniques. The following video provides highlights of some elements of the user experience.
The sample site is at openidsamplestore.com, but we suggest first reading this FAQ which describes the site and has links to additional videos of some of the features. We hope website developers will use these techniques to reduce the need for passwords on their site.
Some websites use the OpenID standard so that users don’t even need to type a password to sign in. While Google does not yet support the usage of OpenID for replacing passwords on its own sites, we are involved in the OpenID community’s efforts to research how to best implement that type of support.
As a next step in those community efforts, we announced today the use of OpenID for the Google signup process.
Currently, Google only offers this feature for Yahoo! users. However, as it is based on an Internet standard, we plan to use it in the future with other email providers that add support for this usage of OpenID and related standards like OAuth, such as in the Microsoft Live identity APIs.
Other websites that need to verify a user’s email address can also implement this technique using Yahoo!’s OpenID API. In addition, it can be used to verify the addresses of Gmail and Google Apps users because those email systems expose the necessary APIs for OpenID. For example, Plaxo is one of the many websites that takes advantage of this feature of Gmail and Yahoo! Mail.
