[ath0]

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.

[dleslie]

Thus making it even more cumbersome for users; now they simply login, in the future they'll have to know how to get the oauth token.

[detaro]

It's OAuth. The application can launch a normal browser for the OAuth flow and have the user complete it.

[bxk1]

For plenty of applications the whole purpose is not to run "a normal browser" and possibly not even have it installed.

[detaro]

You can also use a browser on a different device if your thing can't run a browser itself. OAuth covers a large space of options.

[Dylan16807]

They can spit out a url for you to copy into a normal browser, then.

[joshspankit]

And, OAuth tokens can be revoked meaning scripts will just suddenly fail.

[scrollaway]

What's your point? Passwords can change and sessions can get invalidated, which all has the same effect.

[joshspankit]

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.

[scrollaway]

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.

[joshspankit]

Also fair point.

What makes me say that? Experience.

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)