Google OAuth embedded webview

[Dani]

I received this email:

Hello Google Developer,

We're writing to let you know that we detected the use of an embedded webview in requests to Google's OAuth 2.0 authorization endpoint in the past 120 days associated with one or more of your OAuth client IDs listed in this email.

Any affected authorization endpoint requests will be blocked with a disallowed_useragent error starting July 24, 2023. Affected requests to our authorization endpoint will display a user-facing warning message starting in May until July 24, 2023.

What do you need to know?

Embedded webview libraries are highly customizable, which can expose Google's login and account authorization pages to potential "man-in-the-middle" attacks. Google's OAuth 2.0 "Use secure browsers" policy helps us protect users from these and other types of attacks.

Examples of affected embedded webview libraries include android.webkit.WebView on Android and WKWebView on iOS or macOS.

What do you need to do?

Review our June 2021 Google Developers blog post, Security changes to Google's OAuth 2.0 authorization endpoint in embedded webviews, to determine potential next steps.
Consider how enterprise and educational users might be impacted by embedded webviews in your app(s).
If you are able to modify the authorization requests of your app, you can choose to test your application for compatibility with our "Use secure browsers" policy after making the necessary changes.
Note: Suppression of the user-facing warning message is not supported.

However, I don't understand what it means or what to do about it. I use Google OAuth 2 here on my website, but I am not an Android developer, nor am I using embedded webviews. I am perplexed by the email because I was under the impression that our CORS policy specifically prevented embedded webviews already, so I don't understand how they were detected?

What do I do? How do I resolve this?

[Dani]

Oh, also, I went ahead and tested for compatibility with ?disallow_webview=true and it still worked. Should I just ignore the email?

[AndreRet]

Hi Dani, sorry only saw the mail now... I did some research as I never encountered the same issue and I hope the below will help -

The message you received indicates that there is an embedded webview being used in requests to Google's OAuth 2.0 authorization endpoint. This message is usually displayed when using certain libraries or frameworks that employ an embedded webview to handle the OAuth 2.0 authorization flow.

To turn off the use of the embedded webview and resolve this issue, you'll need to modify the way you handle the OAuth 2.0 authorization flow in your application. Instead of using an embedded webview, you should switch to using a system browser for the authorization process. Here's a general guide on how to achieve that:

Identify the library or framework you're using for OAuth 2.0 authorization. This could be a specific OAuth library or part of a larger framework like a mobile development framework.

Consult the documentation or guides for the library or framework to see if there are specific instructions on how to switch to using the system browser for authorization. Look for options or configuration settings related to the authorization flow.

If you can't find specific instructions, consider searching for community resources or forums related to the library or framework. Often, other developers have encountered similar issues and may have provided solutions or workarounds.

As a general approach, you'll typically need to change the OAuth 2.0 authorization request code to open the authorization URL in the system browser instead of an embedded webview. This way, the user will be redirected to their default web browser for authorization.

Once the authorization process is complete, the user will be redirected back to your application with an authorization code or access token. You'll need to modify your code to handle the response from the system browser and extract the necessary authorization details.

Remember that the exact steps and code modifications will depend on the specific library or framework you're using. The documentation should help as well.

You can switch to the system browser for authorizations using php by generating the appropriate HTML code to redirect the user to the authorization URL, which will open in their system browser. The following is some examples, I hope it helps...

$authorizationUrl = 'YOUR_AUTHORIZATION_URL';

// Generate HTML code for the redirection
$html = '<html>';
$html .= '<head>';
$html .= '<script>';
$html .= 'window.location.href = "' . $authorizationUrl . '";';
$html .= '</script>';
$html .= '</head>';
$html .= '<body>';
$html .= '</body>';
$html .= '</html>';

// Output the HTML code
echo $html;

Replace 'YOUR_AUTHORIZATION_URL' with the actual URL for authorization. When this PHP code is executed, it will output the HTML code that triggers an automatic redirect to the authorization URL. This will open the system browser with the authorization flow.

After the user completes the authorization process in the system browser, your application will receive the authorization callback through a callback URL or a redirect URL. You'll need to handle this callback in your PHP code and extract the authorization code or access token according to your OAuth 2.0 implementation.

To handle the callback in php -

// Check if the callback contains the authorization code or access token
if (isset($_GET['code'])) {
    // Authorization code flow
    $authorizationCode = $_GET['code'];
    // Perform further processing with the authorization code
    // ...
} elseif (isset($_GET['access_token'])) {
    // Implicit or client credentials flow
    $accessToken = $_GET['access_token'];
    // Perform further processing with the access token
    // ...
} else {
    // Handle error conditions or invalid responses
    // ...
}

Depending on your OAuth 2.0 provider and requirements, you may need to perform additional validations and follow the appropriate authorization flow steps as per the documentation...

[Dani]

To turn off the use of the embedded webview and resolve this issue, you'll need to modify the way you handle the OAuth 2.0 authorization flow in your application. Instead of using an embedded webview, you should switch to using a system browser for the authorization process. Here's a general guide on how to achieve that:

That's the thing. I have never used an embedded webview, and I am only using a system browser for the OAuth authorization process.

The only thing I can think of is that someone who is using our API is using an embedded webview, which, now that I think about it, seems likely.