It would appear that the new Safari cross-site tracking functionality is interfering with Google's OAuth2 implementation (at least in google sign-in for websites). I'm experiencing this issue with a project I'm currently developing, and would appreciate advice from anyone who has ran into the same problem.
Further details:
With all cache/cookies cleared, the sign-in flow works properly on first login.
Upon refreshing, entering the sign-in flow recognizes you are already authenticated with the OAuth provider, opens a popup and immediately closes it (this is expected behaviour for already allowed sources).
after the popup closes, the finality of the auth flow is broken, and silently fails with no errors thrown inside the code, and no logged in user returned.
Unchecking the "prevent cross-site tracking" option allows the sign-in flow to behave as intended.
Unfortunately, I experienced the same problem with Safari.
In my case, as others reported on the issue you created on GitHub, I was using the redirect flow.
In a recent attempt, I changed the ux_mode to "popup", and it worked.
It is really bad that Google left this abandoned for two years.
Related
We are migrating from deprecated Google Sign-in (basically gapi.auth and gapi.auth2 methods) into the new Google identity services (google.accounts.oauth2). More info here
We are using the authorization solely for Google picker. The problem is, beforehand (it seems) the library didn't return access_token in their gapi.auth.authorize, which was an indication that something wrong is going on and we've displayed "3rd party cookies blocked" message.
After the migration, the Google identity does not need any cookies, whatsoever, Google picker is somewhat unaware and stops working with 3rd party cookies blocked.
After the picker is successfully loaded, he prompts the user to SignIn (even though it just received a working token via setOAuthToken). After clicking the SignIn twice in the iframe, there is some malfunction error. Nothing is ever opened. NO callbacks are aware of this, no errors can be caught.
This behavior can be directly controled by the 3rd party cookie block. If the cookies are allowed. The exact same flow (and code) opens google drive picker (via build and setVisible) and everything works as expected.
The question is.
How to catch this 3rd party cookie error? Or any errors in the iframe whatsoever.
Why the picker requires 3rd party cookies?
Should I do something on the picker side for the migration as well?
Drive Picker and Drive API Third-party cookies
This has been reported as an issue from the community, I would highly suggest to also provide the feedback and insight regarding your concerns and future alternatives:
https://issuetracker.google.com/issues/188699186
Replying to your questions:
How to catch this 3rd party cookie error? Or any errors in the iframe whatsoever?
As suggested over the Issue tracker, it is not possible to catch information about the matter.
Why the picker requires 3rd party cookies?
It would be a great idea to request a better documentation on why over the issue tracker, as it was also suggested on a previous old post:
https://issuetracker.google.com/164130212
I notice that other types of Drive API process that can be troubleshooted generally recommend enabling or as an alternative to add an exception for accounts.google.com.
Should I do something on the picker side for the migration as well?
It seems you have followed the process of migration correctly, this is only a limitation from Drive Picker itself or the Drive API needing access to those cookies to run properly, might be a good test the exception suggested in the previous answer.
References:
https://developers.google.com/drive/api/troubleshoot-authentication-authorization
https://developers.google.com/identity/sign-in/web/troubleshooting#third-party_cookies_and_data_blocked
I've been developing authentication flow on php lib: googleapis/google-api-php-client v2.9.1. Everything was working fine, but after some time while trying to authenticate the google started displaying "Something went wrong" message with 500 in console and after pressing next button "The server cannot process the request because it is malformed. It should not be retried. That’s all we know." with 400 code. But everything works fine if I use incognito mode.
The similar issue is described here and it only occurs on chrome and when user is logged in into several google accounts, works fine if you delete accounts.google.com domain cookies or use Incognito mode.
Is there a way to solve it ?
So to answer my own question the solution was quite simple - after you apply for verification and Google verifies your app this issue disappears without any additional efforts.
I assume that main issue is that if you have multiple google accounts connected to your chrome and you add only some of them to an app as a tester or etc. Google can't handle not connected accounts for security measures and returns an error. Of course the error itself could be handled little bit better.
I hope this answer saves some time for everyone else who is struggling with this issue.
I maintain an application written in C++Builder 2009. Part of it involves using a TWebBrowser control (based on Internet Explorer) to send users to a Google login page in order to obtain an OAuth key. This has worked well for a while, but now Google, bless their hearts, has implemented some kind of security upgrade, and now my users get to a page that says "Couldn't sign you in, this browser or app may not be secure". FYI, I am already setting a Registry key that is supposed to make IE run in version 11 emulation mode.
I do have a couple of workarounds: If the user runs IE first in admin mode, signs on, leaves it up while running my application, we don't get the problem. Second, I can start up the default browser - Chrome, IE, whatever - and send them to the URL for OAuth, then it avoids the error message.
The problem with this solution is that without being able to hook into TWebBrowser events, I don't have any way to automatically retrieve the OAuth key - it is necessary for the user to cut/paste it into my application. I'd like to avoid these clunky solutions.
I should also mention, this problem occurs only for certain Gmail accounts. I have no idea what the difference is between accounts that work and don't work. Any ideas on that?
So, is there any way to configure IE or TWebBrowser so this security issue is bypassed? Or, if I was to update to a modern version of C++Builder and use TWebBrowser (or something else?), would this problem be avoided? Any other ideas to fix this problem?
The latest C++Builder supports Google's Chromium engine, it's probably safe to say it'll be compatible with Google's security upgrades.
Powerful Chromium Based WebView Component To Host Web Content In Your Delphi/C++ Builder FireMonkey Apps
So I'm trying to register a new client on the instagram API. I have a business account and have done the proper steps prior to this. Everytime I fill out the "Register New Client ID" form and submit it, I get an error "The captcha solution was not correct. Please try again." But no there is no captcha for me to fill out!! Looking at the console errors it says the CSP page setting's are blocking this source https://www.google.com/recaptcha/api.js. I'm gonna take a wild guess and say that has the captcha I need that's not appearing..lol.
Anyway, I've disabled all my content blocking settings and JS is enabled on firefox (oh I'm using firefox developer edition btw) and no change. I've also tried this in chrome and safari, no change. I don't have this issue with other sites that use captchas.
Anyone have any idea what's going on?
'preciate it!
Had the same issue here on Google Chrome. Used IE11 (version 11.345.17134.0 to be exact), and captcha displayed instantly. I've successfully registered a new client
I suggest to wait until Instagram team realizes to upgrade their whatever scripts & parameters.
I found myself in the same scenario:
I'm logged on Instagram
I land to instagram.com/developer/clients/register/ over Google Chrome 70.0.3538.102 (no extensions)
No captcha. And I get the following from the console:
ps: I tried figuring out how to submit this specific report, but after several searches I find myself loosing too much time... to make them aware.
Our web app allows users to log in via Facebook. Technically, we are using Facebook OAuth2. We have implemented this login process two years ago. It worked fine until 13th November 2015 but since that day it does not. When our server sends the request
https://graph.facebook.com/oauth/access_token
with appropriate parameters (client_id, redirect_uri, client_secret, code), the response from Facebook has HTTP status 400. The response body is a HTML page saying "Sorry, something went wrong".
On 13th November, there was some problem on Facebook probably.
I have found the following message:
http://www.independent.co.uk/life-style/gadgets-and-tech/news/facebook-down-site-breaks-for-many-people-though-not-for-everyone-a6732906.html
However, our server still gets this error response after a week. We have an instance of the system deployed in the production environment and one more instance in the test environment (with different Facebook account, i.e. with different client_id and client_secret). Currently, Facebook login works fine in the test environment. I am not sure if it worked on 13th November.
Do you have any experience with recovery from such problem? Why does Facebook login work in test environment and does not work in the production environment in the same app? Why did the production instance break on a particular day and is still broken a week later?
Thanks for any help.
I had the same issue. I believe that the issue stems from passing in invalid scope in your authentication requests. Try removing the scopes in your authentication request to see if that works.
One more corner case I found in 2022:
In the App Dashboard, if you choose Facebook login for Business, same error happens. It will go away as soon as you select Facebook Login one.
Finally, the issue was resolved by restarting the servlet container (Tomcat 7). However, I have no idea why.
All of this is using exclusively the login button. Not the API serverside and not FB.login(). It would work for me sometimes and sometimes not and I couldn't figure out why. I would open a new window and it may work, or may not - but it seemed like once broken it was broken.
There appears to be an issue when using the Chrome 'Device simulator'.
Looking at the SDK Javascript (that's to say the SDK that the Facebook Login button uses) it checks to see if the device is a 'touch' device and if so it will use the m.facebook.com domain when requesting the oauth token.
This domain fails m.facebook.com:
However if the mobile device mode isn't activated when the page loads then it uses www.facebook.com and succeeds:
So for me the current workaround is:
Assuming you are developing with the console active.
When you need to reload your page press Ctrl + Shift + M to deactivate the mobile device mode.
Refresh the page
Once the button has initialized press Ctrl + Shift + M to reactivate it again.
If you see m.facebook.com then you didn't do it fast enough, or maybe you're using something like Angular with hot reload and you need to manually refresh.