VidToDoc
Read in EnglishSe connecter
C
Chrome for Developers
#FedCM#Web API#Authentification

FedCM : Gestion Fédérée des Identifiants pour une Authentification Web Sécurisée

Découvrez FedCM, l'API de gestion fédérée des identifiants qui simplifie et sécurise l'authentification des utilisateurs sur le web. Améliorez la confidentialité et l'expérience utilisateur.

5 min de lectureGuide IA

Introduction

Introduction
L'API Federated Credential Management (FedCM) offre une méthode médiatisée par le navigateur pour gérer l'identité fédérée, permettant aux utilisateurs d'accéder à plusieurs applications avec un seul ensemble d'identifiants. Elle vise à améliorer la confidentialité et la commodité du flux d'authentification pour les utilisateurs.

Précis de configuration

Élément Version / Lien
Langage / Runtime JavaScript (côté client)
Librairie principale API Web navigator.credentials.get()
APIs requises Federated Credential Management API (FedCM)
Clés / credentials nécessaires clientId, nonce (fournis par la Relying Party à l'IdP)

Guide étape par étape

Guide étape par étape

Étape 1 — L'appel FedCM côté Relying Party

La Relying Party (le site web visité par l'utilisateur) initie le flux d'authentification fédérée en demandant au navigateur de gérer la sélection et l'authentification de l'identité de l'utilisateur via un fournisseur d'identité.

// Exemple d'appel FedCM en mode passif
// Le SDK distribué par l'Identity Provider encapsule cet appel
async function signInWithFedCM() {
  try {
    const credential = await navigator.credentials.get({
      identity: {
        providers: [{
          configURL: 'https://fedcm-demo-idp.dev/fedcm.json', // URL de configuration de l'IdP
          clientId: 'demo-rp.dev', // ID client de la Relying Party
          nonce: 'nonce' // Valeur unique pour la protection contre les attaques par rejeu
        }]
      }
    });
    // Le token d'identité (credential.token) est maintenant disponible
    // pour être envoyé à la Relying Party pour vérification et connexion.
    console.log("Token d'identité reçu:", credential.token);
    // [Note de l'éditeur : Le code pour envoyer le token au backend de la RP et gérer la session utilisateur n'est pas inclus dans la vidéo.]
  } catch (error) {
    console.error("Erreur lors de l'authentification FedCM:", error);
  }
}

// Pour le mode actif, un geste utilisateur est requis avant d'appeler signInWithFedCM()
// Par exemple, un bouton "Se connecter avec Health-Provider"
// document.getElementById('signInButton').addEventListener('click', signInWithFedCM);

Étape 2 — Configuration de l'Identity Provider : le fichier .well-known

L'Identity Provider doit déclarer sa prise en charge de FedCM et fournir au navigateur les points d'accès nécessaires à sa configuration. Cela permet au navigateur de découvrir les services d'identité de l'IdP de manière sécurisée et standardisée.

L'IdP doit servir un fichier JSON à l'adresse /.well-known/web-identity.

// Contenu du fichier /.well-known/web-identity
{
  "accounts_endpoint": "/auth/accounts",
  "login_url": "/"
  // [Note de l'éditeur : D'autres champs de configuration peuvent être nécessaires selon la spécification FedCM et les besoins de l'IdP.]
}

Étape 3 — Implémentation des Endpoints de l'Identity Provider

Ces endpoints sont les interfaces par lesquelles le navigateur interagit avec l'Identity Provider pour gérer les comptes utilisateurs, l'authentification et la récupération des informations de profil.

L'IdP doit implémenter les endpoints suivants (les chemins sont des exemples et doivent correspondre à la configuration dans le fichier .well-known):

  • accounts_endpoint (ex: /auth/accounts):

    • Pourquoi: Permet au navigateur de récupérer la liste des comptes de l'utilisateur actuellement connectés à l'IdP, afin de les présenter dans le dialogue FedCM.
    • Exemple de réponse (JSON):
      // Réponse de l'accounts_endpoint
[
  {
    "id": "elisa.beckett@health-provider.example",
    "name": "Elisa Beckett",
    "email": "elisa.beckett@health-provider.example",
    "picture": "https://health-provider.example/elisa.jpg"
  },
  {
    "id": "beckett.bakery@yidp.com",
    "name": "Beckett Bakery",
    "email": "beckett.bakery@yidp.com",
    "picture": "https://yidp.com/bakery.jpg"
  }
]

  • id_assertion_endpoint:

    • Pourquoi: Après que l'utilisateur a sélectionné un compte dans le dialogue FedCM, le navigateur envoie une requête à cet endpoint. L'IdP vérifie l'identité de l'utilisateur et émet un jeton d'identité sécurisé (par exemple, un JWT) que la Relying Party peut utiliser pour authentifier l'utilisateur.
    • Exemple de réponse (JSON):
      // Réponse de l'id_assertion_endpoint
{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkVsaXNhIEJlY2tldHQiLCJpYXQiOjE1MTYyMzkwMjJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
}

  • login_url:

    • Pourquoi: Si l'utilisateur n'est pas actuellement connecté à l'Identity Provider, cet endpoint est utilisé pour afficher une page de connexion dans une fenêtre pop-up, permettant à l'utilisateur de s'authentifier directement auprès de l'IdP.
    • Code (côté IdP, exemple de page de connexion):
      <!-- Contenu HTML de la page de connexion de l'IdP -->
<!DOCTYPE html>
<html>
<head>
  <title>Health Provider IdP Sign-in</title>
</head>
<body>
  <h1>Sign-in</h1>
  <form action="/auth/login" method="POST">
    <label for="username">Username:</label>
    <input type="email" id="username" name="username" value="elisa.beckett@health-provider.example">
    <br>
    <button type="submit">Continue</button>
  </form>
</body>
</html>

  • client_metadata (optionnel):

    • Pourquoi: Permet à l'Identity Provider de fournir des éléments de branding (comme le logo de la Relying Party) et des liens vers des politiques (comme la politique de confidentialité de la Relying Party) au navigateur, afin d'améliorer l'expérience utilisateur et la transparence dans le dialogue FedCM.
    • Exemple de réponse (JSON):
      // Réponse de l'endpoint client_metadata
{
  "privacy_policy_url": "https://pharmacy.example/privacy-policy",
  "terms_of_service_url": "https://pharmacy.example/terms-of-service",
  "icon_url": "https://pharmacy.example/logo.png"
}

Tableaux comparatifs

Tableaux comparatifs

Comparaison des avantages de FedCM pour les différents acteurs

Caractéristique Utilisateurs Relying Parties Identity Providers
Expérience de connexion Expérience "one-tap" (mode passif), pas de redirections Taux de connexion plus élevés Pas de dépendance aux cookies tiers
Confidentialité Meilleure confidentialité, contrôle accru des données Résilience aux mitigations de suivi par rebond Pas de décorations de liens (résilience au suivi)
Interface utilisateur Transparence sur les données partagées UI non encombrée (pas de dizaines de boutons de connexion) Support pour plus d'utilisateurs (même avec cookies tiers désactivés)
Sécurité Résilience aux futures mitigations de suivi Moins de dépendance aux cookies tiers Gestion centralisée des mises à jour via SDK

⚠️ Erreurs fréquentes et pièges

  1. Absence du fichier .well-known/web-identity: Le navigateur ne peut pas découvrir les endpoints de l'IdP, empêchant le fonctionnement de FedCM. Solution: Assurez-vous que le fichier est accessible publiquement à la racine du domaine de l'IdP.
  2. Endpoints de l'IdP mal configurés ou inaccessibles: Si les endpoints spécifiés dans le fichier .well-known ne sont pas correctement implémentés ou renvoient des erreurs, le flux FedCM échouera. Solution: Vérifiez l'implémentation de chaque endpoint et assurez-vous qu'ils répondent aux requêtes du navigateur avec les formats de données attendus.
  3. Manque de geste utilisateur pour le mode actif: En mode actif, l'appel navigator.credentials.get() doit être déclenché par une interaction utilisateur (clic sur un bouton). Sans cela, le dialogue FedCM ne s'affichera pas. Solution: Associez l'appel FedCM à un événement utilisateur explicite, comme un clic sur un bouton de connexion.
  4. Utilisateur non connecté à l'IdP en mode passif: Le mode passif nécessite que l'utilisateur soit déjà connecté à l'Identity Provider pour offrir une expérience fluide. Si ce n'est pas le cas, le dialogue ne s'affichera pas automatiquement. Solution: Informez l'utilisateur ou basculez vers le mode actif si une session IdP n'est pas détectée.
  5. Problèmes de CORS ou de sécurité: Comme FedCM implique des interactions entre différents domaines, des problèmes de Cross-Origin Resource Sharing (CORS) ou d'autres configurations de sécurité peuvent bloquer le flux. Solution: Configurez correctement les en-têtes CORS sur les serveurs de l'IdP pour autoriser les requêtes du navigateur.

Glossaire

Identity Provider (IdP) : Un service qui stocke et gère les identités numériques des utilisateurs et fournit des services d'authentification à d'autres applications ou sites web.
Relying Party (RP) : Un site web ou une application qui s'appuie sur un Identity Provider pour authentifier ses utilisateurs, plutôt que de gérer ses propres identifiants.
Fédération d'Identité : Un système qui permet à un utilisateur de s'authentifier une seule fois auprès d'un Identity Provider et d'accéder ensuite à plusieurs applications ou services (Relying Parties) sans avoir à se reconnecter.

Points clés à retenir

  • FedCM est une API Web qui permet une authentification fédérée plus privée et conviviale.
  • Le navigateur agit comme un médiateur de confiance, offrant aux utilisateurs plus de transparence et de contrôle sur leurs données.
  • Il existe deux modes d'expérience utilisateur : actif (nécessite un geste utilisateur) et passif (connexion "one-tap" si l'utilisateur est déjà connecté à l'IdP).
  • FedCM élimine le besoin de redirections de haut niveau et de fenêtres pop-up intrusives pour le flux de connexion.
  • L'API est résiliente aux futures mitigations de suivi par rebond et ne dépend pas des cookies tiers.
  • Pour l'implémentation, l'Identity Provider doit servir un fichier .well-known/web-identity et implémenter des endpoints spécifiques (accounts_endpoint, id_assertion_endpoint, login_url, client_metadata).
  • Les Relying Parties bénéficient d'une UI moins encombrée et de taux de connexion potentiellement plus élevés.
  • Les Identity Providers peuvent gérer les mises à jour de l'implémentation de manière centralisée via un SDK.

Ressources

  • Documentation officielle FedCM: goo.gle/fedcm
  • Feuille de route FedCM: goo.gle/fedcm-roadmap
  • Lien pour les retours: goo.gle/fedcm-feedback
Tous les guidesRead in English →