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