« Continuer avec Google » ou Apple : un clic au lieu d’un mot de passe… mais votre compte dépend désormais d’un autre service

Le bouton paraît supprimer le mot de passe. En réalité, il déplace surtout le problème.

Sur des milliers de sites et d’applications, l’inscription commence désormais par quelques boutons : « Continuer avec Google », « Continuer avec Apple », parfois Facebook, LinkedIn, GitHub ou X. Pour l’utilisateur, l’effet est immédiat : moins de formulaires, moins de mots de passe à inventer et souvent une connexion plus rapide.

Mais le social login ne supprime ni l’identité numérique ni la sécurité. Il délègue une partie de l’authentification à un fournisseur tiers, puis fait circuler des jetons entre ce fournisseur et le service auquel vous voulez accéder.

C’est ce déplacement qui rend le mécanisme intéressant : il réduit une friction visible tout en créant une dépendance beaucoup moins visible.

Ce qui se passe réellement quand vous cliquez sur « Continuer avec Google »

OAuth 2.0 est d’abord un cadre d’autorisation. Il permet à une application d’obtenir un accès limité à des ressources sans demander le mot de passe du compte tiers. Pour se connecter avec une identité, les services utilisent généralement OpenID Connect, une couche d’authentification construite au-dessus d’OAuth 2.0.

Le déroulé simplifié est le suivant : le site vous redirige vers le fournisseur d’identité ; celui-ci vous authentifie ; vous acceptez éventuellement certaines informations demandées ; puis le fournisseur renvoie au site des données cryptographiquement vérifiables, notamment via un ID Token dans OpenID Connect.

Le site ne reçoit donc pas votre mot de passe Google ou Apple. Il reçoit des jetons et des informations autorisées, puis crée ou retrouve votre compte local.

Pourquoi c’est si confortable pour l’utilisateur

Le premier bénéfice est mécanique : moins de champs à remplir. Le fournisseur connaît déjà votre identité et peut, selon les permissions accordées, transmettre un identifiant stable, un nom, une adresse e-mail ou d’autres informations de profil.

Le deuxième bénéfice est la réduction du nombre de mots de passe spécifiques au service. Le site peut éviter de vous demander d’en créer un nouveau et s’appuyer sur les mécanismes de sécurité du fournisseur d’identité, par exemple sa double authentification.

Cela ne signifie pas que le système devient automatiquement « plus sûr ». La sécurité se déplace. L’application doit encore protéger ses sessions, valider correctement les jetons, contrôler les redirections et suivre les bonnes pratiques OAuth et OIDC.

Votre compte devient aussi dépendant d’un tiers

Si votre compte Google, Apple ou autre devient inaccessible, si le fournisseur subit une panne, ou si l’intégration du service est mal configurée, l’accès à l’application peut être perturbé. La commodité repose donc sur une chaîne plus longue qu’elle n’en a l’air.

Cette dépendance explique l’intérêt d’une solution de secours : connexion par e-mail, lien magique, passkey ou autre méthode indépendante. Ce n’est pas une obligation universelle, mais c’est une stratégie de résilience utile pour éviter qu’un fournisseur unique ne devienne le seul chemin vers le compte.

Apple ajoute une autre couche : cacher votre vraie adresse e-mail

Avec Sign in with Apple, l’utilisateur peut choisir de masquer son adresse réelle. Apple génère alors une adresse relais qui transmet les messages vers l’adresse vérifiée de son compte Apple. Le service peut donc communiquer avec l’utilisateur sans connaître directement son adresse personnelle.

Côté App Store, Apple encadre aussi les apps qui utilisent des services de login tiers pour le compte principal : sa guideline 4.8 impose qu’une option équivalente répondant à certains critères de confidentialité soit proposée, avec des exceptions. La règle est donc plus précise que le raccourci « Sign in with Apple est toujours obligatoire ».

Le vrai casse-tête : une personne peut devenir plusieurs comptes

Supposons qu’une même personne s’inscrive avec Google lundi, avec Apple un mois plus tard, puis avec son e-mail. Si l’application traite chaque méthode comme une identité indépendante, elle peut créer plusieurs profils pour une seule personne.

Le problème est encore plus subtil avec Apple, puisque l’adresse relais peut être différente de l’adresse visible chez Google. Une simple comparaison d’e-mails ne suffit donc pas toujours à reconnaître la même personne.

Dans OpenID Connect, l’identité technique repose notamment sur l’émetteur et sur un identifiant de sujet stable. Pour relier plusieurs méthodes de connexion, un service doit mettre en place une vraie logique de liaison de comptes et vérifier que l’utilisateur contrôle bien les identités qu’il souhaite fusionner.

Fusionner automatiquement deux comptes uniquement parce qu’ils affichent la même adresse e-mail peut être risqué : une mauvaise vérification ou une différence de règles entre fournisseurs peut créer de la confusion d’identité, voire faciliter une prise de contrôle de compte. La liaison doit donc être conçue comme une opération de sécurité, pas comme un simple nettoyage de base de données.

Le mot « social » est devenu presque trompeur

Historiquement, ces boutons étaient associés aux réseaux sociaux. Aujourd’hui, le mécanisme dépasse largement Facebook ou X. Google et Apple sont des fournisseurs d’identité généralistes ; GitHub est particulièrement utile dans les services destinés aux développeurs ; LinkedIn peut avoir du sens dans des usages professionnels.

Le choix des fournisseurs doit donc suivre les usages réels du public, pas une liste standard de logos. Ajouter six boutons n’améliore pas forcément l’expérience si la majorité des utilisateurs n’en utilise qu’un ou deux.

Moins de données peut aussi être une meilleure architecture

Un social login n’autorise pas à collecter tout ce que le fournisseur sait sur l’utilisateur. Les scopes et claims demandés doivent être limités aux informations nécessaires au service. En Europe, les principes de transparence et de minimisation du RGPD poussent dans la même direction : expliquer les données traitées et ne collecter que ce qui est nécessaire et proportionné.

Dans beaucoup de cas, un identifiant stable et une adresse e-mail peuvent suffire. Demander une photo de profil, une liste de contacts ou d’autres données simplement parce que le fournisseur peut les transmettre augmente la surface de risque sans améliorer forcément le service.

Le social login est donc moins une suppression du mot de passe qu’une nouvelle architecture de confiance

Pour l’utilisateur, le résultat tient dans un bouton. Derrière, plusieurs systèmes doivent pourtant s’accorder : le site, le fournisseur d’identité, les jetons, la session locale, les règles de liaison de comptes et la protection des données.

La réussite du social login tient précisément à ce paradoxe : rendre cette complexité presque invisible. Le meilleur système n’est pas celui qui montre le plus de technologies ; c’est celui qui permet de revenir facilement, même si l’utilisateur change de méthode de connexion ou si un fournisseur tiers devient indisponible.