You'll need to find another provider which doesn't care that much about preventing phishing attacks. Google accounts are a big target so it makes sense you move away from the masses.
In practice it just means faking the user-agent and other fingerprinting more enthusiastically. I'm not sure how google can win that without resorting to the same anti-cheat measures as games companies.
You'll try, but the first time you won't know what fingerprinting tests they are going to do. After a few iterations you'll succeed, but it will be obvious to Google that the account you've just been testing it on belongs to someone trying to break their auth restrictions...
OAuth tokens used in automation tools will continue to work. Entering in username & password through auth, to automate an OAuth flow (or any other traditionally manual flow) will stop working. Breaks some puppeteer scripts too - but those have been getting flaky for a while now.
Yes I would agree with that, except that if you change a password you know the scripts will fail, but if an OAuth token gets invalidated by the system and not you, then it will fail without warning.
And if your password gets reset by the system and not you, same story.
What makes you say oauth tokens are any less robust? Aside from the fact they usually have an expiration attached to them, there's not much difference.
However, I will say to counter my own point: it’s not all roses. Using password by necessity means that your password is now stored somewhere that is likely more easily compromised (In my case: secure passwords are stored in 1Password, but passwords for script usage are either stored in an ENV or in the script itself, neither of which are great from a security standpoint)
