Modernizing OAuth interactions in Native Apps for Better Usability and
Security
Posted by William Denniss, Product
Manager, Identity and Authentication
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:
demonstrating how to use the
browser to authenticate Google users in various Windows environments such as
Universal Windows Platform (UWP), console and desktop apps.
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.
