Google Sign-In avec les API FedCM

Ce guide explique l'adoption des API FedCM par la bibliothèque de la plate-forme de connexion Google. Les sujets abordés incluent le calendrier et les étapes suivantes pour une mise à jour rétrocompatible de la bibliothèque, comment effectuer une évaluation de l'impact et vérifier que la connexion des utilisateurs continue de fonctionner comme prévu, et si nécessaire, des instructions pour mettre à jour votre application Web. Des options pour gérer la période de transition et pour obtenir de l'aide sont également abordées.

État de la bibliothèque

Les nouvelles applications Web ne sont plus autorisées à utiliser la bibliothèque de la plate-forme Google Sign-in obsolète, tandis que les applications qui l'utilisent peuvent continuer à le faire jusqu'à nouvel ordre. Aucune date d'abandon définitif n'a été fixée pour la bibliothèque. Pour en savoir plus, consultez la page Abandon et abandon de l'assistance.

Une mise à jour rétrocompatible ajoute les API FedCM à la bibliothèque Google Sign-In. Bien que la plupart des modifications soient transparentes, cette mise à jour introduit des différences au niveau des invites utilisateur, des paramètres iFrame permissions-policy et de Content Security Policy (CSP). Ces modifications peuvent affecter votre application Web et nécessiter des modifications du code de l'application et de la configuration du site.

Pendant la période de transition, une option de configuration détermine si les API FedCM sont utilisées ou non lors de la connexion des utilisateurs.

Après la période de transition, les API FedCM sont obligatoires pour toutes les applications Web utilisant la bibliothèque de connexion Google.

Chronologie

Dernière mise à jour : septembre 2024

Voici les dates et les modifications qui affectent le comportement de connexion des utilisateurs:

  • Mars 2023 : abandon de la prise en charge de la bibliothèque de plate-forme Google Sign-In.
  • La période de transition de juillet 2024 commence, et la bibliothèque de plate-forme Google Sign-In est compatible avec les API FedCM. Par défaut, Google contrôle le pourcentage de requêtes de connexion des utilisateurs à l'aide de FedCM pendant cette période. Les applications Web peuvent explicitement remplacer ce comportement par le paramètre use_fedcm.
  • Adoption obligatoire en mars 2025 des API FedCM par la bibliothèque de plate-forme Google Sign-In. Passé cette date, le paramètre use_fedcm sera ignoré et toutes les requêtes de connexion des utilisateurs utiliseront FedCM.

Étapes suivantes

Vous avez le choix entre trois options:

  1. Effectuez une évaluation de l'impact et, si nécessaire, mettez à jour votre application Web. Cette approche permet d'évaluer si les fonctionnalités qui nécessitent des modifications de votre application Web sont utilisées. Vous trouverez des instructions dans la section suivante de ce guide.
  2. Déplacer vers la bibliothèque Google Identity Services (GIS). Nous vous recommandons vivement de passer à la dernière bibliothèque de connexion compatible. Pour ce faire, suivez ces instructions.
  3. Ne rien faire. Votre application Web sera automatiquement mise à jour lorsque la bibliothèque Google Sign-in passera aux API FedCM pour la connexion des utilisateurs. Il s'agit de la solution la moins fastidieuse, mais il existe un risque que les utilisateurs ne puissent pas se connecter à votre application Web.

Réaliser une évaluation d'impact

Suivez ces instructions pour déterminer si votre application Web peut être facilement mise à jour via une mise à jour rétrocompatible ou si des modifications sont nécessaires pour éviter que les utilisateurs ne puissent se connecter lorsque la bibliothèque de la plate-forme Google Sign-In adopte complètement les API FedCM.

Configuration

Les API du navigateur et la dernière version de la bibliothèque de la plate-forme Google Sign-In sont nécessaires pour utiliser FedCM lors de la connexion des utilisateurs.

Avant de continuer:

  • Installez la dernière version de Chrome pour ordinateur. Chrome pour Android nécessite la version M128 ou ultérieure et ne peut pas être testé avec des versions antérieures.

  • Ouvrez chrome://flags et définissez les fonctionnalités suivantes sur ces valeurs:

    • #fedcm-authz Activé
    • #tracking-protection-3pcd Activée
    • #third-party-cookie-deprecation-trial Désactivé
    • #tpcd-metadata-grants Désactivé
    • #tpcd-heuristics-grants Désactivé

    puis relancez Chrome.

  • Définissez use_fedcm sur true lorsque vous initialisez la bibliothèque de la plate-forme Google Sign-In dans votre application Web. En règle générale, l'initialisation se présente comme suit:

    • gapi.client.init({use_fedcm: true}) ou
    • gapi.auth2.init({use_fedcm: true}) ou
    • gapi.auth2.authorize({use_fedcm: true}).

  • Invalidez les versions mises en cache de la bibliothèque de plate-forme Google Sign-in. En règle générale, cette étape n'est pas nécessaire, car la dernière version de la bibliothèque est téléchargée directement dans le navigateur en incluant api.js, client.js ou platform.js dans une balise <script src> (la requête peut utiliser l'un de ces noms de bundle pour la bibliothèque).

  • Confirmez les paramètres OAuth de votre ID client OAuth:

    1. Ouvrir la page "Identifiants" de Google API Console

    2. Vérifiez que l'URI de votre site Web est inclus dans la liste Origines JavaScript autorisées. L'URI inclut uniquement le schéma et le nom d'hôte complet. Exemple :https://www.example.com

    3. Les identifiants peuvent éventuellement être renvoyés par le biais d'une redirection vers un point de terminaison que vous hébergez plutôt que via un rappel JavaScript. Dans ce cas, vérifiez que vos URI de redirection sont inclus dans URI de redirection autorisés. Les URI de redirection incluent le schéma, le nom d'hôte complet et le chemin d'accès, et doivent respecter les règles de validation des URI de redirection. Exemple : https://www.example.com/auth-receiver.

Tests

Après avoir suivi les instructions de configuration:

Localiser la requête de la bibliothèque Google Sign-In

Vérifiez si des modifications de la stratégie d'autorisation et de la Content Security Policy sont nécessaires en inspectant la requête pour la bibliothèque de la plate-forme Google Sign-In. Pour ce faire, recherchez la requête à l'aide du nom et de l'origine de la bibliothèque:

  • Dans Chrome, ouvrez le panneau Réseau des outils de développement, puis actualisez la page.
  • Utilisez les valeurs des colonnes Domain (Domaine) et Name (Nom) pour localiser la requête de bibliothèque :
    • Le domaine est apis.google.com et
    • Le nom est api.js, client.js ou platform.js. La valeur spécifique de "Name" dépend du bundle de bibliothèque demandé par le document.

Par exemple, filtrez sur apis.google.com dans la colonne Domain et sur platform.js dans la colonne Name.

Vérifier la stratégie d'autorisations pour les iFrames

Votre site peut utiliser la bibliothèque de plate-forme Google Sign-in dans un iframe inter-origine. Si c'est le cas, une mise à jour est nécessaire.

Après avoir suivi les instructions de la section Rechercher la requête de la bibliothèque Google Sign-In, sélectionnez la requête de la bibliothèque Google Sign-In dans le panneau Network (Réseau) de DevTools, puis recherchez l'en-tête Sec-Fetch-Site dans la section Request Headers (En-têtes de requête) de l'onglet Headers (En-têtes). Si la valeur de l'en-tête est:

  • same-site ou same-origin, les règles inter-origines ne s'appliquent pas et aucune modification n'est nécessaire.
  • Des modifications de cross-origin peuvent être nécessaires si une iFrame est utilisée.

Pour vérifier si un iFrame est présent, procédez comme suit:

  • Sélectionnez le panneau Éléments dans Chrome DevTools.
  • Appuyez sur Ctrl+F pour rechercher une iframe dans le document.

Si une iframe est détectée, inspectez le document pour rechercher des appels aux fonctions gapi.auth2 ou aux directives script src qui chargent la bibliothèque Google Sign-In dans l'iframe. Dans ce cas :

Répétez ce processus pour chaque iframe du document. Les iframes peuvent être imbriquées. Veillez donc à ajouter la directive d'autorisation à toutes les iframes parentes environnantes.

Vérifier Content Security Policy

Si votre site utilise une Content Security Policy, vous devrez peut-être la mettre à jour pour autoriser l'utilisation de la bibliothèque Google Sign-In.

Après avoir suivi les instructions Localiser la requête de bibliothèque Google Sign-in, sélectionnez la requête de bibliothèque Google Sign-in dans le panneau Network (Réseau) des outils de développement, puis localisez l'en-tête Content-Security-Policy dans la section Response Headers (En-têtes de réponse) de l'onglet Headers (En-têtes).

Si l'en-tête n'est pas trouvé, aucune modification n'est nécessaire. Sinon, vérifiez si l'une de ces directives CSP est définie dans l'en-tête CSP et mettez-la à jour en procédant comme suit:

  • Ajout de https://apis.google.com/js/, https://accounts.google.com/gsi/ et https://acounts.google.com/o/fedcm/ à toute directive connect-src, default-src ou frame-src.

  • Ajout de https://apis.google.com/js/bundle-name.js à la directive script-src. Remplacez bundle-name.js par api.js, client.js ou platform.js en fonction du groupe de bibliothèques demandé par le document.

Vérifier les modifications apportées aux invites utilisateur

Le comportement des invites utilisateur est différent. FedCM ajoute une boîte de dialogue modale affichée par le navigateur et met à jour les exigences d'activation de l'utilisateur.

Image de la boîte de dialogue modale FedCM

Inspectez la mise en page de votre site pour vous assurer que le contenu sous-jacent peut être superposé et masqué temporairement par la boîte de dialogue modale du navigateur. Si ce n'est pas le cas, vous devrez peut-être ajuster la mise en page ou la position de certains éléments de votre site Web.

Activation de compte utilisateur

FedCM inclut des exigences d'activation des utilisateurs mises à jour. Appuyer sur un bouton ou cliquer sur un lien sont des exemples de gestes utilisateur qui permettent à des origines tierces d'effectuer des requêtes réseau ou de stocker des données. Avec FedCM, le navigateur demande l'autorisation de l'utilisateur lorsque:

  • un utilisateur se connecte d'abord à une application Web à l'aide d'une nouvelle instance de navigateur ; ou
  • GoogleAuth.signIn est appelé.

Aujourd'hui, si l'utilisateur s'est déjà connecté à votre site Web, vous pouvez obtenir ses informations de connexion lors de l'initialisation de la bibliothèque Google Sign-In à l'aide de gapi.auth2.init, sans autre interaction. Cela n'est plus possible, sauf si l'utilisateur a d'abord effectué la procédure de connexion à FedCM au moins une fois.

En activant FedCM et en appelant GoogleAuth.signIn, la prochaine fois que le même utilisateur visitera votre site Web, gapi.auth2.init pourra obtenir ses informations de connexion lors de l'initialisation sans interaction de l'utilisateur.

Cas d'utilisation courants

La documentation destinée aux développeurs de la bibliothèque Google Sign-In inclut des guides et des exemples de code pour les cas d'utilisation courants. Cette section explique comment FedCM affecte leur comportement.

  • Intégrer Google Sign-In à votre application Web

    Dans cette démonstration, un élément <div> et une classe affichent le bouton. Pour les utilisateurs déjà connectés, l'événement onload de la page renvoie les identifiants utilisateur. Une interaction de l'utilisateur est requise pour se connecter et établir une nouvelle session.

    L'initialisation de la bibliothèque est effectuée par la classe g-signin2, qui appelle gapi.load et gapi.auth2.init.

    Un geste utilisateur, un événement onclick d'élément <div>, appelle auth2.signIn lors de la connexion ou auth2.signOut lors de la déconnexion.

  • Créer un bouton Google Sign-In personnalisé

    Dans la première démonstration, des attributs personnalisés sont utilisés pour contrôler l'apparence du bouton de connexion. Pour les utilisateurs déjà connectés, l'événement onload de la page renvoie les identifiants de l'utilisateur. Une interaction utilisateur est requise pour se connecter et établir une nouvelle session.

    L'initialisation de la bibliothèque est effectuée via un événement onload pour la bibliothèque platform.js, et le bouton est affiché par gapi.signin2.render.

    Un geste de l'utilisateur, appuyant sur le bouton de connexion, appelle auth2.signIn.

    Dans la deuxième démonstration, un élément <div>, des styles CSS et une image personnalisée sont utilisés pour contrôler l'apparence du bouton de connexion. Une interaction utilisateur est requise pour se connecter et établir une nouvelle session.

    L'initialisation de la bibliothèque est effectuée lors du chargement du document à l'aide d'une fonction de démarrage qui appelle gapi.load, gapi.auth2.init et gapi.auth2.attachClickHandler.

    Un geste utilisateur, un événement onclick d'élément <div>, appelle auth2.signIn à l'aide de auth2.attachClickHandler lors de la connexion ou de auth2.signOut lors de la déconnexion.

  • Surveiller l'état de la session de l'utilisateur

    Dans cette démonstration, l'utilisateur appuie sur un bouton pour se connecter et se déconnecter. Une interaction de l'utilisateur est requise pour se connecter et établir une nouvelle session.

    L'initialisation de la bibliothèque s'effectue en appelant directement gapi.load, gapi.auth2.init et gapi.auth2.attachClickHandler() après le chargement de platform.js à l'aide de script src.

    Un geste utilisateur, un événement onclick d'élément <div>, appelle auth2.signIn à l'aide de auth2.attachClickHandler lors de la connexion ou de auth2.signOut lors de la déconnexion.

  • Demander des autorisations supplémentaires

    Dans cette démo, un appui sur un bouton permet de demander des champs d'application OAuth 2.0 supplémentaires, d'obtenir un nouveau jeton d'accès et, pour les utilisateurs déjà connectés, l'événement de page onload renvoie les identifiants utilisateur. Une interaction utilisateur est requise pour se connecter et établir une nouvelle session.

    L'initialisation de la bibliothèque est effectuée par l'événement onload pour la bibliothèque platform.js via un appel à gapi.signin2.render.

    Un geste de l'utilisateur, qui clique sur un élément <button>, déclenche une requête de champs d'application OAuth 2.0 supplémentaires à l'aide de googleUser.grant ou auth2.signOut lors de la déconnexion.

  • Intégrer Google Sign-In à l'aide d'écouteurs

    Dans cette démonstration, pour les utilisateurs déjà connectés, l'événement onload de la page renvoie les identifiants utilisateur. Une interaction utilisateur est requise pour se connecter et établir une nouvelle session.

    L'initialisation de la bibliothèque s'effectue lors du chargement du document à l'aide d'une fonction de démarrage qui appelle gapi.load, gapi.auth2.init et gapi.auth2.attachClickHandler. Ensuite, auth2.isSignedIn.listen et auth2.currentUser.listen permettent de configurer la notification des changements d'état de la session. Enfin, auth2.SignIn est appelé pour renvoyer les identifiants des utilisateurs connectés.

    Un geste utilisateur, un événement onclick d'élément <div>, appelle auth2.signIn à l'aide de auth2.attachClickHandler lors de la connexion ou de auth2.signOut lors de la déconnexion.

  • Google Sign-In pour les applications côté serveur

    Dans cette démonstration, un geste de l'utilisateur est utilisé pour demander un code d'autorisation OAuth 2.0, et un rappel JS effectue un appel AJAX pour envoyer la réponse au serveur backend pour validation.

    L'initialisation de la bibliothèque est effectuée à l'aide d'un événement onload pour la bibliothèque platform.js, qui utilise une fonction de démarrage pour appeler gapi.load et gapi.auth2.init.

    Un geste utilisateur, en cliquant sur un élément <button>, déclenche une demande de code d'autorisation en appelant auth2.grantOfflineAccess.

  • Authentification unique multiplate-forme

    FedCM nécessite le consentement pour chaque instance de navigateur, même si les utilisateurs Android se sont déjà connectés. Un consentement unique est nécessaire.

Gérer la période de transition

Pendant la période de transition, un pourcentage de connexions utilisateur peut utiliser FedCM. Ce pourcentage exact peut varier et changer au fil du temps. Par défaut, Google contrôle le nombre de requêtes de connexion qui utilisent FedCM, mais vous pouvez choisir d'activer ou de désactiver FedCM pendant la période de transition. À la fin de la période de transition, le FedCM devient obligatoire et est utilisé pour toutes les demandes de connexion.

Si vous choisissez d'activer la fonctionnalité, l'utilisateur suit le parcours de connexion FedCM, tandis que si vous choisissez de la désactiver, il suit le parcours de connexion existant. Ce comportement est contrôlé à l'aide du paramètre use_fedcm.

Activer

Il peut être utile de contrôler si toutes les tentatives de connexion à votre site ou seulement certaines d'entre elles utilisent les API FedCM. Pour ce faire, définissez use_fedcm sur true lors de l'initialisation de la bibliothèque de la plate-forme. Dans ce cas, la requête de connexion de l'utilisateur utilise les API FedCM.

Désactiver

Pendant la période de transition, un pourcentage de tentatives de connexion des utilisateurs à votre site utilisera les API FedCM par défaut. Si vous avez besoin de plus de temps pour apporter des modifications à votre application, vous pouvez désactiver temporairement l'utilisation des API FedCM. Pour ce faire, définissez use_fedcm sur false lors de l'initialisation de la bibliothèque de la plate-forme. Dans ce cas, la requête de connexion de l'utilisateur n'utilise pas les API FedCM.

Une fois l'adoption obligatoire effectuée, tous les paramètres use_fedcm sont ignorés par la bibliothèque de la plate-forme Google Sign-In.

Obtenir de l'aide

Effectuez une recherche ou posez des questions sur StackOverflow à l'aide du tag google-signin.