Deadline looms: Google Workspace mandates OAuth by September 30

https://www.theregister.com/2024/09/03/google_workspace_third_party_apps/

by Bender • 2 years ago

44 35 2 years ago

486sx33• 2 years ago

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

amaccuish2• 2 years ago

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.

suprjami• 2 years ago

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.

kibibu• 2 years ago

It's plausible that it's always been like this and you've educated yourself out of their target audience

veeti• 2 years ago

IMAP password authentication with generated app passwords still works too.

hooverd• 2 years ago

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

amaccuish2• 2 years ago

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.

beretguy• 2 years ago

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

cpach6• 2 years ago

Why do you need to migrate because of this change?

whatshisface• 2 years ago

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

hulitu• 2 years ago

Deadline looms: Google Workspace mandates OAuth by September 30

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

simonw• 2 years ago

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!

Horffupolde• 2 years ago

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

lxgr4• 2 years ago

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.

Ferret7446• 2 years ago

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?

boneitis2• 2 years ago

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.

siva7• 2 years ago

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

boneitis2• 2 years ago

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

makeitdouble• 2 years ago

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.

cpach6• 2 years ago

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.

cpach6• 2 years ago

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

ori_b• 2 years ago

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

immibis3• 2 years ago

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

awinter-py• 2 years ago

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

lxgr4• 2 years ago

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.

universa1• 2 years ago

Thunderbird supports the oauth flow for quite a while now :-)

immibis3• 2 years ago

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.

lxgr4• 2 years ago

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

Summerbud• 2 years ago

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

Deadline looms: Google Workspace mandates OAuth by September 30

Related Stories