If you’re entering a username and password to give an app access to a G Suite account, beware: you won’t be able to do it for much longer.
Google is changing the way that it grants third-party apps access to G Suite accounts as it tries to improve security. It is weeding out what it calls ‘less secure apps’ (LSAs) by denying them access to its services.
Google defines secure apps according to a rigid set of security standards. To be considered secure, a third-party app must let you see what level of account access you are giving it before you connect it to your Google account. The app must also let you access only the parts of your Google account that you want, such as your email or calendar, without giving it access to everything else. It must allow you to disconnect it from your Google account at any time, and it must let you connect it to your account without exposing your Google password.
Apps that don’t meet these security criteria are considered less secure, and on 29 July 2019, the company announced it would begin limiting access to G Suite accounts from those apps beginning on 30 October. On that date, it began removing an option for G Suite administrators to ‘enforce access to less secure apps for all users’. That meant admins could no longer just wave through less secure apps at the domain level. Instead, users would have to grant access to these apps themselves if admins let them.
That move was due to be complete by the end of this year. Now, the company is moving on to the next step: restricting access to account data for LSAs. Because these apps rely on insecure password technology to access sensitive Google account data, the company will be cutting off their ability to access G Suite account data altogether. It will happen in two stages. After 15 June 2020, users who try to connect the Google accounts to an LSA for the first time won’t be allowed to, but those who have already connected to LSAs before that date will still be permitted.
That grace period won’t last forever, though. After 15 February 2021, access to LSAs will cease for all G Suite accounts, even those that were already using them.
All this is bad news for apps that rely on password access to exchange data via protocols like CalDAV, CardCAV, IMAP, and Google Sync (in other words, legacy calendar, contact, and email apps). Apps that rely on passwords to gain access to Google accounts so that they can exchange data using these protocols will suffer. Instead, Google wants people to use OAuth.
OAuth is an authorisation mechanism that lets a third party authority grant an application access to a service on the user’s behalf. There are two versions: OAuth 2.0, which isn’t compatible with OAuth 1.0, is the de-facto standard. It’s what Google supports.
An OAuth 2.0 app will send a request to an authorisation server or AS (in this case, run by Google). The request includes information about the bits of the account that the app should have access to. The AS sends a consent dialogue to the user, telling them what the app will and won’t be allowed to do. If the user agrees, the AS sends a token that the app can use to log into the user’s G Suite account.
OAuth 2.0 satisfies Google’s security criteria because it demands that the app request only allows access to specific things. It also makes it use a token rather than a password, and it allows that password to be easily revoked. That makes it better for security than entering a password into your app that you might have used elsewhere, or hard coding an API key into a web form somewhere and forgetting about it. When app developers implement it, it will also be more convenient for users.
7 comments on “Google to choke off ‘less secure applications’”
“OAuth is an authentication mechanism”
OAuth is specifically an authorization mechanism, and is not recommended for authentication. See the standard’s website for an explanation.
How does this affect those who use good old POP3 and people who use emails apps on their phone such as Nine
I guess it depends on what services you use POP3 to access…
…doesn’t sound as though Google will stop you accessing other services without OAuth, just its own.
It is not clear that google is looking to secure your use of gmail or chrome, but to corral you into relying ONLY on their product: this is clear from the way the notices come about a possible breach: “someone just used your password to try to sign in to your account.Google blocked them, but you should check what happened.” First it would be highly unlikely that someone DID have my password – a strong long and senseless one- but if they did, they would probably actually get in, and the message would be: ” a sign in on a new device was detected”, and they would have a record of which device it was and it’s ID number, too; so they are twisting the notification words to say a different event than is actually happening: Someone might have tried to sign in to my account, but they could not do that.It should be: “someone just tried to use your password to try to sign in to your account. Google blocked them, but you should check what happened.” This may have more to do with them wanting to get more $ from apps which they are competitive with and want to eliminate. Why can’t I just find out WHICH apps they consider ‘less secure’ so I can CHOOSE whether to drop them or raise the security? I do know that they would not let me send an email to myself unless I used one app they consider ‘less secure’ and it might have had to do with the IMAP, it took days to find out why emails were not coming to my box but were stacking up elsewhere.
1. I want google to let me know which apps of the ones I happen to have are the less secure ones.
2. I want their message to say someone tried to enter your account, not that they HAD MY PASSWORD (an untruth).
3. I want them to collect the id of the device used in the entry attempt and send it to me.
Sending you the ID of someone who tried to login to your account but failed is never going to be acceptable, for the simple reason that failed logins can happen by mistake.
Idiotic. Outlook is a “less secure app”?