The Identity team is constantly striving to help Google users sign-in to third-party applications with their Google account in a secure and seamless way, and enable users to share select information from their account such as their calendar or contact information with other apps, when they wish to do so.
Under the hood these interactions happen via OAuth requests, and over the years Google has supported a number of ways for developers to implement OAuth flows with us. With improved security and usability in mind, we will soon be ending the support for one of these ways. In the coming months, we will no longer allow OAuth requests to Google in embedded browsers known as “web-views”, such as the WebView UI element on Android and UIWebView/WKWebView on iOS, and equivalents on Windows and OS X.
Using the device browser for OAuth requests instead of an embedded web-view can improve the usability of your apps significantly: users only need to sign-in to Google once per device, improving conversion rates of sign-in and authorization flows in your app. Modern “in-app browser tab” patterns available on some operating systems, such as Chrome Custom Tabs on Android and SFSafariViewController on iOS offer further UX improvements for browser-based OAuth flows.
In contrast, the outdated method of using embedded browsers for OAuth means a user must sign-in to Google each time, instead of using the existing logged-in session from the device. The device browser also provides improved security as apps are able to inspect and modify content in a web-view, but not content shown in the browser.
To help you migrate, we offer libraries and samples that follow modern best practices which you can use:
- Google Sign-In for Android and iOS, our recommended SDK for sign-in and OAuth with Google Accounts.
- AppAuth for Android, iOS, and OS X, an open source OAuth client library that can be used with Google and other OAuth providers. We also offer GTMAppAuth (for iOS and OS X), a library which enables AppAuth support for the Google APIs Client Library for Objective-C, and the GTM Session Fetcherprojects.
- Google Sign-in and OAuth Examples for Windows, examples
You can also read protocol-level documentation for our standards-based support of OAuth for Native Apps, and an IETF best current practice draft on this topic.
Versions of Google Sign-In on iOS prior to version 3.0 don’t support the current industry best practices of the in-app browser tab, and therefore are also deprecated. If you use Google Sign-In, please update to the latest version to get all the recent security and usability improvements. For now, this policy does not remove our support of WebView on iOS 8, however we may start to display notices encouraging users to upgrade their device for better security.
The rollout schedule for the deprecation of web-views for OAuth requests to Google is as follows. Starting October 20, 2016, we will prevent new OAuth clients from using web-views on platforms with a viable alternative, and will phase in user-facing notices for existing OAuth clients. On April 20, 2017, we will start blocking OAuth requests using web-views for all OAuth clients on platforms where viable alternatives exist.
If you have any questions with the migration, please post to Stack Overflow tagged with “google-oauth”.
Update
On November 1, 2016 we added a notification on our iOS consent page alerting developers of this deprecation. On March 1, 2017 we posted the same notification on the Android consent page and on April 1, we posted the notification for applications retrieving an OAuth token from "https://accounts.google.com/o/oauth2/programmatic_auth". Developers can acknowledge the deprecation and remove this notice from the consent page by including a URL parameter "suppress_webview_warning=true" in the request.
