Google modifie la manière avec laquelle il accorde aux applications tierces l’accès aux comptes G Suite dans une démarche visant à améliorer la sécurité. Il souhaite éliminer ce qu’il appelle les “applications moins sécurisées” (LSA : less secure apps) en leur refusant l’accès à ses services.
Google définit les applications sécurisées selon un ensemble rigide de normes de sécurité. Pour être considérée comme sécurisée, une application tierce doit vous permettre de voir le niveau d’accès au compte que vous lui accordez, et ce avant toute connexion à votre compte Google. L’application doit également vous permettre d’accéder uniquement aux parties de votre compte Google que vous souhaitez, telles que votre messagerie ou votre calendrier, sans lui donner accès à tout le reste. Elle doit vous permettre de la déconnecter de votre compte Google, et ce à tout moment, et enfin elle doit vous permettre de la connecter à votre compte sans exposer votre mot de passe Google.
Les applications qui ne remplissent pas ces critères de sécurité sont considérées comme moins sécurisées, et le 29 juillet 2019, l’entreprise a annoncé qu’elle commencerait à limiter l’accès aux comptes G Suite, à partir de telles applications, à compter du 30 octobre. À cette date, Google a commencé à supprimer une option permettant aux administrateurs de G Suite de “forcer l’accès à des applications moins sécurisées pour tous les utilisateurs“. Cette limitation implique que les administrateurs ne peuvent plus simplement passer par des applications moins sécurisées au niveau du domaine. Au lieu de cela, les utilisateurs doivent autoriser eux-mêmes l’accès à ces applications si les administrateurs le leur permettent.
Ce changement devait être pleinement opérationnel pour la fin de cette année. Maintenant, l’entreprise passe à l’étape suivante : à savoir restreindre l’accès aux données de compte pour les LSA. Étant donné que ces applications s’appuient sur une technologie de mot de passe non sécurisée pour accéder aux données de compte Google sensibles, l’entreprise supprimera complètement leur capacité à accéder à ces dernières. Cette deuxième étape se déroulera en deux temps. Après le 15 juin 2020, les utilisateurs qui tentent de connecter les comptes Google à une LSA pour la première fois ne seront pas autorisés à le faire, mais ceux qui se sont déjà connectés à des LSA avant cette date seront toujours autorisés à le faire.
Mais ce délai de grâce ne durera pas éternellement. Après le 15 février 2021, l’accès aux LSA cessera pour tous les comptes G Suite, même ceux qui les utilisaient déjà auparavant.
Cette décision est une mauvaise nouvelle pour les applications qui utilisent l’accès par mot de passe pour échanger des données via des protocoles comme CalDAV, CardCAV, IMAP et Google Sync (en d’autres termes, les applications héritées de type calendrier, contact et messagerie). Les applications qui utilisent des mots de passe pour accéder aux comptes Google afin d’échanger des données à l’aide de ces protocoles seront directement concernées. En guise d’alternative, Google veut que les gens utilisent OAuth.
OAuth
OAuth est un mécanisme d’autorisation qui permet à une autorité tierce d’accorder à une application l’accès à un service, au nom de l’utilisateur. Il existe deux versions : OAuth 2.0, qui n’est pas compatible avec OAuth 1.0, est la norme en vigueur. Il s’agit de la version que Google prend en charge.
Une application OAuth 2.0 enverra une demande à un serveur d’autorisation ou AS (dans ce cas, géré par Google). La demande comprendra des informations sur les parties du compte auxquelles l’application devra avoir accès. L’AS enverra un message de consentement à l’utilisateur, lui indiquant ce que l’application sera et ne sera pas autorisée à faire. Si l’utilisateur est d’accord, l’AS enverra alors un jeton que l’application pourra utiliser pour se connecter au compte G Suite de l’utilisateur.
OAuth 2.0 satisfait aux critères de sécurité de Google, car ce protocole exige que la demande émanant de l’application n’autorise l’accès qu’à des éléments bien spécifiques. Il incite également à utiliser un jeton plutôt qu’un mot de passe, et il permet à ce dernier d’être facilement révoqué. Un tel système rend la sécurité bien meilleure que la saisie d’un mot de passe, au niveau de votre application, que vous avez sans doute utilisé ailleurs, ou encore le codage en dur d’une clé API dans un formulaire web, à un endroit bien précis mais que vous allez peut être oublier par la suite. Lorsque les développeurs d’applications l’implémenteront, ce système sera également plus pratique pour les utilisateurs.
Billet inspiré de Google to choke off ‘less secure applications’, sur Sophos nakedsecurity.