I'm sure there's a sensible answer to this, anyone know why they don't continue to support those older integrations (IMAP mail clients etc) through offering per-app passwords?
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".
> 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!
> In less than a month, many third-party apps (mail, calendar, etc.) will stop connecting to Workspace accounts.
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
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.
Worth noting this is completely nonstandard, meaning Google has completed EEE. Standards conforming clients are completely unable to interoperate with Google servers.
There's plenty enough stuff to blame Google for. I'm happy enough this time to blame my own lack of willingness to invest any more time, now that this feels certain that I'm unaffected :)
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):
Indeed. They should explicitly state either “App Passwords will no longer be accepted after <deadline>” or “App Passwords will still be accepted even after <deadline>” depending on which is true.
While Google is making the change and 100% responsible for the mess, the work to understand the impact and adapt to it lays on the application devs and users.
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.
Given the direction Google is moving in with passwords, this makes a lot of sense:
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.
That is an interesting aspect of thinking. I am wondering what is the drawback of allowing this entropy stream into their server besides the security concerns
> Mobile Device Management platforms that configure IMAP, CalDAV, CardDAV, POP or Exchange ActiveSync (Google Sync) are being phased out as well
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.
It isn't exactly the same, but this reminded me of Gell-Mann amnesia. A lot of comments about how people maintain faith in the news, despite seeing their own field of expertise misrepresented have this effect on me.
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.
last time I tried thunderbird for mail, it didn't support oauth and was still in the less secure apps flow
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
As far as I can tell, this is just the app using Google's OAuth.
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.
Thunderbird supports Google's custom auth protocol for Gmail at least. Yes, only at the discretion of Google which has to authorize Thunderbird to exist - welcome to chokepoint capitalism.
I didn’t ask you. But if you have found a better alternative to Google Workspace, good for you :) Feel free to share the name of the alternative product since 'beretguy was asking for recommendations.
Not sure what you mean, but if you're talking about auth'ing to Google Workspace with an external IdP with SAML (here is being talked about auth between the client and Google, like say with IMAP, over OAuth, which in turn can use whatever, including SAML), then no, you have nothing to worry.
Just another damn google profile that’ll be “signed into” my machine. I hate Google on outlook on Mac OS for this . It always wants my web browser signed into my Gsuite account. Piss off google
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!