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

> 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.

> Love the Register, but this poorly researched.

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 plausible that it's always been like this and you've educated yourself out of their target audience

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.

IMAP password authentication with generated app passwords still works too.

Scared me. I don't see anything about SAML being deprecated thankfully.

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.

Our nonprofit uses Google workspace. Is there a good alternative to migrate to?

Why do you need to migrate because of this change?

The reasons for migrating after manageable issue #25 occurs are issues #26, #27, #28 ... #145.

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.

> Deadline looms: Google Workspace mandates OAuth by September 30

Wow. Microsoft's stupidity (Windows Hello) is contagious. /s

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".

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!

They want you to use their client. All others are excluded by non compliance.

By "their client", do you mean things like Apple Mail or Thunderbird (these natively support OAuth)?

App passwords also still seem to be a thing, and these work with literally everything that supports password-based authentication.

> I don't want complete access, I just want access to email via IMAP!

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?

> 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

https://support.google.com/a/answer/6260879?hl=en

Although I'm still not understanding how these applications authenticate in the first place.

[Edit: Apparently incorrect, see below.]

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.

That's not entirely true -- Google has required you to generate an application-specific password for a long time.

Aha! So will they disable app passwords then…?

From the (less sensationalist) primary source linked in the article:

> 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.

Ah, got it. Like I thought then.

Probably - they already disabled them for Gmail.

Worth noting this is completely nonstandard, meaning Google has completed EEE. Standards conforming clients are completely unable to interoperate with Google servers.

What a terrible communication from Google if even tech savvy people can't understand what's exactly changing for them.

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):

https://support.google.com/a/answer/14114704

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.

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.

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 the oauth flow for quite a while now :-)

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.

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.

[1] https://support.google.com/accounts/answer/11350823

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