This content originally appeared on Google Developers Blog and was authored by Google Developers
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.
Loopback IP address flow will be disallowed for native iOS, Android and Chrome OAuth client types
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.
What do I need to do
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.
- iOS clients: Google Sign-In for iOS SDK
- Android clients: Google Sign-In for Android SDK
- Chrome clients: Chrome Identity API
Key dates for compliance
- 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) flow will be deprecated
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.
What do I need to do
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.
- iOS clients: Google Sign-In for iOS SDK
- Android clients: Google Sign-In for Android SDK
- Chrome clients: Chrome Identity API
- Desktop clients: OAuth 2.0 for Desktop apps
Key dates for compliance
- 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
User-facing warning message
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_shutdownparameter 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_shutdownparameter with a value of the enforcement date: 2022-08-31. Example:ack_loopback_shutdown=2022-08-31
User-facing error message
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]
This content originally appeared on Google Developers Blog and was authored by Google Developers
Google Developers | Sciencx (2022-02-16T17:01:00+00:00) Making Google OAuth interactions safer by using more secure OAuth flows. Retrieved from https://www.scien.cx/2022/02/16/making-google-oauth-interactions-safer-by-using-more-secure-oauth-flows/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.