Deadline looms: Google Workspace mandates OAuth by September 30
theregister.com
theregister.com
So you could go somewhere and effectively say "issue me a username and password that's just for my email client, which doesn't provide access to any other Google services".
EDIT: Looks like they do offer exactly that feature, they call it "app passwords": https://myaccount.google.com/apppasswords
Though it's weirdly open - that page says:
> Just like your normal password, this app password grants complete access to your Google Account. You won't need to remember it, so don't write it down or share it with anyone."
I don't want complete access, I just want access to email via IMAP!
App passwords also still seem to be a thing, and these work with literally everything that supports password-based authentication.
But why? Presumably, you want restricted access for greater security.
But then, why won't you switch to (a client that supports) OAuth for greater security?
For anyone else like myself who couldn't understand what was changing:
Examples of apps that don’t support modern security standards include:
Native mail, contacts, and calendar sync applications on older versions of iOS and OSX
Some computer mail clients, such as older versions of Microsoft Outlook
Although I'm still not understanding how these applications authenticate in the first place.
For anyone who needs to dig deeper, this so far seemed the most pointedly focused first-party documentation on the topic (though again, I'm not actively investigating it):
I don't think there's any reliable way Google can properly guide users to deal with apps they don't (and shouldn't) control. You and me would be properly horrified if Google could dictate how Outlook auth works and what exact steps will help the user transition, whatever the Outlook team decides to do on their own.
The most they can do will be to help the app developpers to prepare for the change, and vaguely gesturing at users about potentially impacted settings.
These applications authenticate with username and password directly – meaning the mail client will have knowledge of the password for your Google account. This is the method of authentication that Google will now disable.
With OAuth authentication, instead of using a password, the application receives an authentication token, which is typically valid for a limited time.
> If the app you are using does not support OAuth, you will need to switch to an app that offers OAuth or create an app password to access these apps.
Their "on-device encryption" concept [1] seems to heavily lean on passwords as a client-side key entropy source, and preventing applications from sending that entropy source to a Google server every time they want to fetch emails etc. (and likely storing it not-too-securely in the process) is probably a good idea with that in mind.
App-specific passwords are a much better idea for applications like that; there's no need an IMAP client should ever store the same password that can potentially grant an attacker access to somebody's password manager or credit card auto-fill data.
Hmm... No. ActiveSync remains available to Workspace (read " Enterprise" customers), as well as IMAP, xDAV etc. The key part is the pure basic auth, password auth, is deprecated. OAuth is fine, and all these protocols support OAuth just fine.
(Of course, OAuth can also mean username/password auth, but it is generally assumed that MFA comes in to play here).
Love the Register, but this poorly researched.
But also a massive problem for people who have scanners than send stuff via SMTP, they now need to work via OAuth.
I used to love The Register, but I sadly haven't seen a good article from them in many years.
Everything that I've seen is clickbait bad opinion or just outright wrong.
I now assume anything from them is rubbish and don't even waste my time clicking the link, which is a very sad state for them.
It's quite well understood by now we critique hardest where we know most and then make sweeping assumptions to correctness in the areas we know least, when reading the views of others.
My main problem with the reg, is the semi-cult-y nature of the community around dialect of british english and related humour.
my sense is that oauth requires centralization and is fairly complex for an OSS org to support? like the thunderbird team would still need to host one redirect and a private key to enable this
So instead of typing your password into your IMAP client, that IMAP client sends you to your browser to grant access for it in your Google account settings. At least personally I much prefer that flow anyway, as it doesn't bypass 2FA and doesn't leave my Google password hanging around in some (usually unencrypted) config file on my computer.
Wow. Microsoft's stupidity (Windows Hello) is contagious. /s