Making Google OAuth interactions safer by using more secure OAuth flows
Posted by Vikrant Rana, Product Manager and Badi Azad, Group Product Manager,
Google
At Google, we constantly strive to provide safer ways for users to sign-in and share their
Google account data with third-party applications. In the spirit of that work, we will be
rolling out a set of protections against phishing and app impersonation attacks during the
OAuth interactions.
The Google sign-in and authorization flows are powered by the
Google OAuth
platform
and over the years we have developed and supported a number of ways for app
developers to integrate with supported OAuth flows. With the goal of keeping users safer
online, we will end support for two legacy flows and will require developers to migrate to
alternative implementation methods that offer greater protections.
To ensure a smooth transition and avoid any service interruption we will give ample time to
implement and meet the compliance dates which are specified below. We will share further
updates on this rollout via email so please make sure your support email address is up to date
in project settings on the Google API
console
.
The
Loopback
IP address
flow is vulnerable to
man in the middle
attack where a malicious app, accessing the same loopback interface on some operating systems,
may
intercept the
OAuth response
and gain access to the authorization code. We intend to remove this
threat vector by disallowing this flow for iOS, Android and Chrome app OAuth client types. The
existing clients will be able to migrate to more
secure
implementation methods
. New clients will be unable to use this flow starting on
March 14, 2022.
Determine if your app is using the Loopback IP address flow
You can inspect your app code or the outgoing network call (in case your app is using an OAuth
library) to determine if the Google OAuth
authorization
request
your app is making has the following values for “redirect_uri” parameter.
redirect_uri=http://127.0.0.1:port or http://[::1]:port">http://[::1]:port or
http://localhost:port
Migrate to an alternative flow
If your app is using the Loopback IP address method you need to migrate to another method
which is more secure by default. Please consider the following alternative methods for
migration.
- Mar 14, 2022 - new OAuth usage will be blocked for the Loopback IP address flow
- Aug 1, 2022 - a user-facing warning message may be displayed to non-compliant OAuth
requests one month before the compliance date
- Aug 31, 2022 - the Loopback IP address flow is blocked for existing clients
OAuth
out-of-band
(OOB) is a legacy flow developed to support native clients which do not have a redirect URI
like web apps to accept the credentials after a user approves an OAuth consent request. The
OOB flow poses a remote phishing risk and clients must migrate to an alternative method to
protect against this vulnerability. New clients will be unable to use this flow starting on
Feb 28, 2022.
Determine if your app is using the OOB flow
You can inspect your app code or the outgoing network call (in case your app is using an OAuth
library) to determine if the Google OAuth
authorization
request
your app is making has the following values for “redirect_uri” parameter.
redirect_uri=urn:ietf:wg:oauth:2.0:oob
or
urn:ietf:wg:oauth:2.0:oob:auto
or
oob
Migrate to an alternative flow
If your app is using the OOB method you need to migrate to another method which is more secure
by default. Please consider the following alternative methods for migration.
- Feb 28, 2022 - new OAuth usage will be blocked for the OOB flow
- Sep 5, 2022 - a user-facing warning message may be displayed to non-compliant OAuth
requests
- Oct 3, 2022 - the OOB flow is deprecated for existing clients
A user-facing warning message may be displayed for non-compliant requests one month before the
aforementioned OAuth methods are due to be blocked. The message will convey to the users that
the app may be blocked soon while displaying the support email that you have registered in the
OAuth consent
screen in Google API Console
.
[Sample user-facing
warning]
The developers can acknowledge the user-facing warning message and suppress it by passing a
query parameter in the authorization call as shown below.
- Go to the code in your app where you send requests to
Google's
OAuth 2.0 Authorization Endpoint
.
- Add a parameter with a value of the enforcement date
- For OOB: Add an
ack_oob_shutdown
parameter with a value
of the enforcement date: 2022-10-03. Example:
ack_oob_shutdown=2022-10-03
- For Loopback IP address: Add an
ack_loopback_shutdown
parameter with a
value of the enforcement date: 2022-08-31. Example:
ack_loopback_shutdown=2022-08-31
If an app is not updated to meet compliance by the required date the authorization requests
will be blocked and users may encounter an invalid request error screen (sample shown below).
[Sample user-facing
error]