Guide du développeur de l'API Federated Credential Management

Découvrez comment utiliser FedCM pour la fédération d'identité protégeant la confidentialité.

FedCM (Federated Credential Management) est un service approche des services d'identité fédérée (comme "Se connecter avec...") où les utilisateurs peuvent se connecter à des sites sans partager leurs informations personnelles avec le le service d'identité ou le site.

Pour en savoir plus sur les cas d'utilisation de FedCM, les parcours utilisateur et la feuille de route des API, consultez le présentation de l'API FedCM.

Environnement de développement FedCM

Vous avez besoin d'un contexte sécurisé (HTTPS ou localhost) à la fois sur l'IdP et la RP dans Chrome pour utiliser FedCM.

Déboguer du code dans Chrome sur Android

Configurez et exécutez un serveur localement pour déboguer votre code FedCM. Vous pouvez accéder à ce serveur dans Chrome sur un appareil Android connecté à l'aide d'un câble USB avec port le transfert.

Vous pouvez utiliser les outils de développement sur ordinateur pour déboguer Chrome sur Android en suivant la instructions dans l'article Débogage à distance d'Android appareils mobiles.

Bloquer les cookies tiers sur Chrome

</ph>

Vous pouvez tester le fonctionnement de FedCM sans cookies tiers sur Chrome avant réellement appliquées.

Pour bloquer les cookies tiers, utilisez la navigation privée mode ou sélectionnez "Bloquer" "Cookies tiers" dans les paramètres de votre ordinateur, sur chrome://settings/cookies ou sur mobile en accédant à Paramètres > Paramètres des sites > Cookies :

Utiliser l'API FedCM

Vous intégrez FedCM en créant un fichier connu, fichier de configuration et points de terminaison pour les comptes list, émission d'assertion et et éventuellement des métadonnées client.

Ensuite, FedCM propose des API JavaScript que les tiers peuvent utiliser pour signer avec le fournisseur d'identité.

Créer un fichier connu

Pour empêcher les outils de suivi d'utiliser abusivement les API, un fichier bien connu doit être diffusé à partir de /.well-known/web-identity des l'eTLD+1 du IdP :

Par exemple, si les points de terminaison de l'IdP https://accounts.idp.example/, ils doivent diffuser un fichier connu à l'adresse https://idp.example/.well-known/web-identity ainsi qu'une configuration d'IdP fichier. Voici un exemple de contenu de fichier connu:

{
  "provider_urls": ["https://accounts.idp.example/config.json"]
}

Le fichier JSON doit contenir la propriété provider_urls avec un tableau des IdP fichier de configuration qui peut être spécifiée en tant que partie chemin d'accès configURL en navigator.credentials.get par les tiers assujettis à des restrictions. Le nombre de Le nombre de chaînes d'URL dans le tableau est limité à une, mais cela peut varier des commentaires à l'avenir.

Créer un fichier de configuration IdP et des points de terminaison

Le fichier de configuration de l'IdP fournit la liste des points de terminaison requis pour le navigateur. IdPs hébergera ce fichier de configuration, ainsi que les points de terminaison et les URL requis. Tous les fichiers JSON doivent être diffusées avec le type de contenu application/json.

L'URL du fichier de configuration est déterminée par les valeurs fournies au Appel navigator.credentials.get exécuté sur un tiers assujetti à des restrictions

const credential = await navigator.credentials.get({
  identity: {
    context: 'signup',
    providers: [{
      configURL: 'https://accounts.idp.example/config.json',
      clientId: '********',
      nonce: '******'
    }]
  }
});
const { token } = credential;

Indiquez l'URL complète de l'emplacement du fichier de configuration de l'IdP en tant que configURL. Quand ? navigator.credentials.get() est appelé sur la RP, le navigateur récupère le fichier de configuration avec une requête GET sans l'en-tête Origin ni le Referer. La requête n'a pas de cookies et ne suit pas les redirections. Cela empêche efficacement l'IdP de savoir qui a effectué la requête et quels Le tiers assujetti à des restrictions tente de se connecter. Exemple :

GET /config.json HTTP/1.1
Host: accounts.idp.example
Accept: application/json
Sec-Fetch-Dest: webidentity

Le navigateur attend une réponse JSON de l'IdP, qui inclut les éléments suivants : propriétés:

Le tiers assujetti à des restrictions peut modifier la chaîne dans l'interface utilisateur de la boîte de dialogue FedCM via la valeur identity.context pour navigator.credentials.get() afin de prendre en charge l'authentification prédéfinie différents contextes. La propriété facultative peut être "signin" (par défaut), "signup", "use" ou "continue".

</ph>

Voici un exemple de corps de réponse provenant du fournisseur d'identité:

{
  "accounts_endpoint": "/accounts.php",
  "client_metadata_endpoint": "/client_metadata.php",
  "id_assertion_endpoint": "/assertion.php",
  "disconnect_endpoint": "/disconnect.php",
  "login_url": "/login",
  "branding": {
    "background_color": "green",
    "color": "#FFEEAA",
    "icons": [{
      "url": "https://idp.example/icon.ico",
      "size": 25
    }]
  }
}

Une fois que le navigateur a récupéré le fichier de configuration, il envoie les requêtes suivantes au Points de terminaison du fournisseur d'identité:

</ph>

Point de terminaison des comptes

Le point de terminaison des comptes du fournisseur d'identité renvoie la liste des comptes dont l'utilisateur actuellement connecté au fournisseur d'identité. Si le fournisseur d'identité prend en charge plusieurs comptes, renvoie tous les comptes connectés.

Le navigateur envoie une requête GET avec des cookies avec SameSite=None, mais sans un paramètre client_id, l'en-tête Origin ou l'en-tête Referer. Ce empêche efficacement le fournisseur d'identité d'identifier le tiers assujetti à des restrictions que l'utilisateur tente de signer dans votre projet. Exemple :

GET /accounts.php HTTP/1.1
Host: accounts.idp.example
Accept: application/json
Cookie: 0x23223
Sec-Fetch-Dest: webidentity

À la réception de la requête, le serveur doit:

1. Vérifiez que la requête contient un en-tête HTTP Sec-Fetch-Dest: webidentity.
2. Faites correspondre les cookies de session avec les ID des comptes déjà connectés.
3. Répondez en fournissant la liste des comptes.

Le navigateur attend une réponse JSON incluant une propriété accounts. avec un tableau d'informations sur le compte, avec les propriétés suivantes:

Exemple de corps de réponse:

{
  "accounts": [{
    "id": "1234",
    "given_name": "John",
    "name": "John Doe",
    "email": "john_doe@idp.example",
    "picture": "https://idp.example/profile/123",
    "approved_clients": ["123", "456", "789"],
    "login_hints": ["demo1", "demo1@idp.example"]
  }, {
    "id": "5678",
    "given_name": "Johnny",
    "name": "Johnny",
    "email": "johnny@idp.example",
    "picture": "https://idp.example/profile/456",
    "approved_clients": ["abc", "def", "ghi"],
    "login_hints": ["demo2", "demo2@idp.example"],
    "domain_hints": ["corp.example"]
  }]
}

Si l'utilisateur n'est pas connecté, répondez avec le code HTTP 401 (Non autorisé).

La liste de comptes renvoyée est utilisée par le navigateur et ne sera pas accessible aux le tiers assujetti à des restrictions.

Point de terminaison des métadonnées client

Le point de terminaison des métadonnées client du fournisseur d'identité renvoie les métadonnées du tiers de confiance : les règles de confidentialité et les conditions d'utilisation du tiers assujetti à des restrictions. Les tiers assujettis à des restrictions doivent fournir des liens vers leurs règles de confidentialité et conditions d'utilisation au fournisseur d'identité. Ces liens sont affiché dans la boîte de dialogue de connexion lorsque l'utilisateur ne s'est pas inscrit auprès du tiers assujetti à des restrictions avec le fournisseur d'identité.

Le navigateur envoie une requête GET à l'aide de client_id. navigator.credentials.get sans cookies. Exemple :

GET /client_metadata.php?client_id=1234 HTTP/1.1
Host: accounts.idp.example
Origin: https://rp.example/
Accept: application/json
Sec-Fetch-Dest: webidentity

À la réception de la requête, le serveur doit:

1. Déterminez le tiers assujetti à des restrictions pour client_id.
2. Répondre avec les métadonnées du client

Les propriétés du point de terminaison des métadonnées du client incluent:

Le navigateur attend une réponse JSON du point de terminaison:

{
  "privacy_policy_url": "https://rp.example/privacy_policy.html",
  "terms_of_service_url": "https://rp.example/terms_of_service.html",
}

Les métadonnées client renvoyées sont utilisées par le navigateur et ne sont pas mis à la disposition du tiers assujetti à des restrictions.

Point de terminaison de l'assertion d'ID

Le point de terminaison d'assertion d'ID du fournisseur d'identité renvoie une assertion pour l'utilisateur connecté. Lorsque l'utilisateur se connecte à un site Web de tiers assujetti à des restrictions avec navigator.credentials.get() , le navigateur envoie une requête POST contenant des cookies SameSite=None et un type de contenu application/x-www-form-urlencoded pour ce point de terminaison avec les informations suivantes:

Exemple d'en-tête HTTP:

POST /assertion.php HTTP/1.1
Host: accounts.idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity

account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true&is_auto_selected=true

À la réception de la requête, le serveur doit:

1. Répondre à la requête avec CORS (Cross-Origin Resource) Partage).
2. Vérifiez que la requête contient un en-tête HTTP Sec-Fetch-Dest: webidentity.
3. Faites correspondre l'en-tête Origin avec l'origine de la RP déterminée par le client_id. Si ce n'est pas le cas, refusez-les.
4. Faites correspondre account_id avec l'ID du compte déjà connecté. Refuser si elles ne correspondent pas.
5. Répondre avec un jeton. Si la demande est rejetée, répondez par un message d'erreur réponse.

La manière dont le jeton est émis dépend de l'IdP, mais en général, il est signé avec telles que l'ID de compte, l'ID client, l'origine de l'émetteur, nonce, afin que la RP peut vérifier que le jeton est authentique.

Le navigateur attend une réponse JSON qui inclut la propriété suivante:

{
  "token": "***********"
}

Le navigateur transmet le jeton renvoyé au tiers assujetti à des restrictions afin que celui-ci puisse valider l'authentification.

Renvoyer une réponse d'erreur

Le id_assertion_endpoint peut également renvoyer une "erreur" qui comporte deux champs facultatifs:

• code: le fournisseur d'identité peut choisir l'une des erreurs connues dans le protocole OAuth 2.0 erreur spécifiée liste (invalid_request, unauthorized_client, access_denied, server_error et temporarily_unavailable) ou utiliser n'importe quelle chaîne arbitraire. Dans ce dernier cas, Chrome affiche l'interface utilisateur d'erreur avec un message d'erreur générique et transmet le code au tiers assujetti à des restrictions.
• url: identifie une page Web intelligible et contenant des informations sur la pour fournir aux utilisateurs des informations supplémentaires à son sujet. Ce champ est utile pour les utilisateurs, car les navigateurs ne peuvent pas afficher de messages d'erreur détaillés dans un une interface utilisateur native. Par exemple, des liens vers les étapes suivantes, les coordonnées du service client des informations, etc. Si un utilisateur souhaite en savoir plus sur les détails de l'erreur et comment y remédier, il peut consulter la page fournie à partir de l'interface utilisateur du navigateur pour plus de détails. L'URL doit correspondre au même site que l'IdP configURL.

// id_assertion_endpoint response
{
  "error" : {
     "code": "access_denied",
     "url" : "https://idp.example/error?type=access_denied"
  }
}

Déconnecter le point de terminaison

En appelant IdentityCredential.disconnect(), le navigateur envoie une requête multi-origine Requête POST avec des cookies avec SameSite=None et un type de contenu de application/x-www-form-urlencoded à ce point de terminaison de déconnexion avec le les informations suivantes:

POST /disconnect.php HTTP/1.1
Host: idp.example
Origin: rp.example
Content-Type: application/x-www-form-urlencoded
Cookie: 0x123
Sec-Fetch-Dest: webidentity

account_hint=account456&client_id=rp123

À la réception de la requête, le serveur doit:

1. Répondre à la requête avec CORS (Cross-Origin Resource) Partage).
2. Vérifiez que la requête contient un en-tête HTTP Sec-Fetch-Dest: webidentity.
3. Faites correspondre l'en-tête Origin avec l'origine de la RP déterminée par le client_id. Si ce n'est pas le cas, refusez-les.
4. Faites correspondre account_hint avec les ID des comptes déjà connectés.
5. Déconnectez le compte utilisateur du tiers assujetti à des restrictions.
6. Répondre au navigateur avec les informations de compte utilisateur identifiées dans un fichier JSON .

Voici un exemple de charge utile JSON de réponse:

{
  "account_id": "account456"
}

Si le fournisseur d'identité souhaite que le navigateur déconnecte tous les comptes associés à le tiers assujetti à des restrictions, transmettez une chaîne qui ne correspond à aucun ID de compte, par exemple "*".

URL de connexion

Avec l'API Login Status, le fournisseur d'identité doit informer l'utilisateur l'état de connexion au navigateur. Il se peut toutefois que l'état ne soit pas synchronisé, par exemple Lorsque la session expire. Dans un tel scénario, le le navigateur peut permettre à l'utilisateur de se connecter à l'IdP de façon dynamique via la page de connexion URL spécifiée avec la valeur login_url du fichier de configuration idp.

La boîte de dialogue FedCM affiche un message suggérant de se connecter, comme illustré dans le l'image suivante.

</ph>

Lorsque l'utilisateur clique sur le bouton Continuer, le navigateur ouvre une fenêtre pop-up. pour la page de connexion de l'IdP.

</ph>

La boîte de dialogue est une fenêtre de navigateur standard contenant des cookies propriétaires. Peu importe se produit dans la boîte de dialogue dépend de l'IdP, et aucun traitement de fenêtre n'est disponible pour envoyer une demande de communication multi-origines à la page du tiers assujetti à des restrictions. Une fois que l'utilisateur connecté, le fournisseur d'identité doit:

• Envoyez l'en-tête Set-Login: logged-in ou appelez la méthode navigator.login.setStatus("logged-in") pour informer le navigateur que utilisateur a été connecté.
• Appelez IdentityProvider.close() pour fermer la boîte de dialogue.

</ph>

Informer le navigateur de l'état de connexion de l'utilisateur auprès du fournisseur d'identité

L'API Login Status est un mécanisme Lorsqu'un site Web, en particulier un fournisseur d'identité, informe le navigateur de l'état de connexion de l'utilisateur sur le fournisseur d'identité. Grâce à cette API, le navigateur peut réduire le nombre de requêtes inutiles adressées au IdP et réduisez les potentielles attaques temporelles.

Les fournisseurs d'identité peuvent signaler l'état de connexion de l'utilisateur au navigateur en envoyant un en-tête HTTP ou en appelant une API JavaScript lorsque l'utilisateur est connecté sur le fournisseur d'identité ou lorsque le l'utilisateur est déconnecté de tous ses comptes IdP. Pour chaque IdP (identifié par son URL de configuration), le navigateur conserve une variable à trois états représentant l'état de connexion avec les valeurs possibles logged-in, logged-out et unknown. L'état par défaut est unknown.

Pour signaler que l'utilisateur est connecté, envoyez un en-tête HTTP Set-Login: logged-in. dans une navigation de premier niveau ou une requête de sous-ressource sur le même site au niveau de l'IdP origine:

Set-Login: logged-in

Vous pouvez également appeler l'API JavaScript navigator.login.setStatus("logged-in") depuis l'origine de l'IdP dans une navigation de premier niveau:

navigator.login.setStatus("logged-in")

Ces appels enregistrent l'état de connexion de l'utilisateur comme logged-in. Lorsque l'utilisateur se connecte si l'état est défini sur logged-in, la RP appelant FedCM envoie des requêtes au fournisseur d'identité le point de terminaison des comptes de service et affiche les comptes disponibles à l'utilisateur dans le .

Pour signaler que l'utilisateur est déconnecté de tous ses comptes, envoyez l'en-tête HTTP Set-Login: logged-out dans une navigation de premier niveau ou une sous-ressource du même site à l'origine du fournisseur d'identité:

Set-Login: logged-out

Vous pouvez également appeler l'API JavaScript navigator.login.setStatus("logged-out") depuis l'origine de l'IdP dans une navigation de premier niveau:

navigator.login.setStatus("logged-out")

Ces appels enregistrent l'état de connexion de l'utilisateur comme logged-out. Lorsque état de connexion est logged-out, l'appel à FedCM échoue automatiquement au point de terminaison des comptes du fournisseur d'identité.

L'état unknown est défini avant que le fournisseur d'identité n'envoie un signal via l'état de connexion API. Unknown a été introduit pour faciliter la transition, car un utilisateur peut avoir déjà connectés au fournisseur d'identité lors de l'expédition de cette API. Il se peut que le fournisseur d'identité ne dispose pas d'envoyer un message au navigateur au moment où FedCM est appelé pour la première fois. Dans ce Chrome envoie une requête au point de terminaison des comptes du fournisseur d'identité et met à jour en fonction de la réponse du point de terminaison des comptes:

• Si le point de terminaison renvoie la liste des comptes actifs, définissez l'état sur logged-in, puis ouvrez la boîte de dialogue FedCM pour afficher ces comptes.
• Si le point de terminaison ne renvoie aucun compte, définissez l'état sur logged-out, puis échouer à l'appel FedCM.

Permettre à l'utilisateur de se connecter via un flux de connexion dynamique

Même si le fournisseur d'identité continue d'informer le navigateur de l'état de connexion de l'utilisateur, il est susceptible d'être désynchronisé, par exemple à l'expiration de la session. Le navigateur tente envoyez une requête avec identifiants au point de terminaison du compte lorsque l'état de connexion est logged-in, mais le serveur ne renvoie aucun compte, car la session n'est plus disponibles. Dans un tel scénario, le navigateur peut permettre à l'utilisateur de se connecter de manière dynamique. à l'IdP via une fenêtre pop-up.

Se connecter au tiers de confiance avec le fournisseur d'identité

Une fois la configuration et les points de terminaison du fournisseur d'identité disponibles, les tiers assujettis à des restrictions peuvent appeler navigator.credentials.get() pour demander l'autorisation des utilisateurs à se connecter au tiers assujetti à des restrictions avec le fournisseur d'identité.

Avant d'appeler l'API, vous devez vérifier que [FedCM est disponible sur le navigateur de l'utilisateur]. Pour vérifier si FedCM est disponible, entourez ce code Implémentation dans FedCM:

if ('IdentityCredential' in window) {
  // If the feature is available, take action
}

Pour demander à autoriser les utilisateurs à se connecter à l'IdP depuis le RP, procédez comme suit : Par exemple:

const credential = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://accounts.idp.example/config.json',
      clientId: '********',
      nonce: '******'
    }]
  }
});
const { token } = credential;

La propriété providers accepte un tableau de IdentityProvider d'objets comportant les propriétés suivantes:

Le navigateur gère les cas d'utilisation des processus d'inscription et de connexion différemment selon les Présence de approved_clients dans la réponse de la liste des comptes point de terminaison. Le navigateur n'affichera pas de communiqué Envoyez "Pour continuer avec..." si l'utilisateur s'est déjà inscrit au tiers assujetti à des restrictions.

L'état d'inscription est déterminé si les conditions suivantes sont satisfaites ou non:

• Si approved_clients inclut le clientId du tiers assujetti à des restrictions.
• Si le navigateur se souvient que l'utilisateur s'est déjà inscrit au tiers assujetti à des restrictions.

Lorsque le tiers assujetti à des restrictions appelle navigator.credentials.get(), les activités suivantes prennent lieu:

1. Le navigateur envoie des requêtes et récupère plusieurs documents: <ph type="x-smartling-placeholder">
   </ph>
   1. Le fichier well-known et une configuration d'IdP qui déclare les points de terminaison.
   2. Une liste de comptes :
   3. Facultatif: URL des règles de confidentialité et des conditions d'utilisation du tiers assujetti à des restrictions récupéré à partir du point de terminaison des métadonnées du client.
2. Le navigateur affiche la liste des comptes que l'utilisateur peut utiliser pour se connecter, ainsi que les conditions d'utilisation et les règles de confidentialité, le cas échéant.
3. Une fois que l'utilisateur a choisi un compte avec lequel se connecter, une demande point de terminaison d'assertion est envoyé à l'IdP pour récupérer à partir d'un jeton d'accès.
4. La RP peut valider le jeton pour authentifier l'utilisateur.

</ph>

Les tiers assujettis à des restrictions doivent prendre en charge les navigateurs qui ne sont pas compatibles avec FedCM. Par conséquent, les utilisateurs doivent pouvoir se connecter à l'aide d'une procédure de connexion non FedCM existante. Jusqu'au les cookies tiers sont complètement abandonnés, sans problème.

Une fois le jeton validé par le serveur de la RP, celle-ci peut enregistrer l'utilisateur ou permettez-lui de se connecter et de démarrer une nouvelle session.

API Login Hint

Une fois l'utilisateur connecté, il arrive que le tiers de confiance lui demande de s'authentifier à nouveau. Toutefois, l'utilisateur ne sait peut-être pas avec certitude quel compte il a utilisé. Si le tiers assujetti à des restrictions peut spécifier le compte avec lequel se connecter, il est plus facile pour le de choisir un compte.

Les tiers assujettis à des restrictions peuvent sélectionner un compte spécifique en appelant navigator.credentials.get() avec la propriété loginHint avec l'une des valeurs suivantes : Valeurs login_hints extraites de la liste des comptes point de terminaison, comme illustré dans l'exemple de code suivant:

return await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: "https://idp.example/manifest.json",
      clientId: "123",
      nonce: nonce,
      loginHint : "demo1@example.com"
    }]
  }
});

Si aucun compte ne correspond à l'loginHint, la boîte de dialogue FedCM affiche une invite de connexion, qui permet à l'utilisateur de se connecter à un compte d'IdP correspondant à l'indice demandé par le tiers assujetti à des restrictions. Lorsque l'utilisateur appuie sur l'invite, une fenêtre pop-up s'ouvre avec l'option l'URL de connexion spécifiée dans le fichier de configuration. Le lien est alors avec l'indice de connexion et les paramètres de requête de l'optimisation du domaine.

API Domain Hint

Dans certains cas, le tiers assujetti à des restrictions sait déjà que seuls les comptes associés à certains domaines sont autorisés à se connecter au site. Cela est particulièrement courant dans scénarios d'entreprise où l'accès au site est restreint à une entreprise domaine. Afin d'améliorer l'expérience utilisateur, l'API FedCM autorise uniquement les tiers assujettis à des restrictions indiquent les comptes qui peuvent être utilisés pour se connecter au tiers assujetti à des restrictions. Cela permet d'éviter les scénarios Lorsqu'un utilisateur tente de se connecter au tiers assujetti à des restrictions à l'aide d'un compte extérieur à l'entreprise domaine, pour être diffusé ultérieurement avec un message d'erreur (ou être mis sous silence en cas de connexion n'a pas fonctionné), car vous n'avez pas utilisé le bon type de compte.

Les tiers assujettis à des restrictions peuvent afficher de manière sélective uniquement les comptes correspondants en appelant navigator.credentials.get() avec la propriété domainHint avec l'une des valeurs suivantes : Valeurs domain_hints extraites de la liste des comptes point de terminaison, comme illustré dans l'exemple de code suivant:

return await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: "https://idp.example/manifest.json",
      clientId: "abc",
      nonce: nonce,
      domainHint : "corp.example"
    }]
  }
});

Si aucun compte ne correspond à l'domainHint, la boîte de dialogue FedCM affiche une invite de connexion, qui permet à l'utilisateur de se connecter à un compte d'IdP correspondant à l'indice demandé par le tiers assujetti à des restrictions. Lorsque l'utilisateur appuie sur l'invite, une fenêtre pop-up s'ouvre avec l'option l'URL de connexion spécifiée dans le fichier de configuration. Le lien est alors avec l'indice de connexion et les paramètres de requête de l'optimisation du domaine.

</ph>

Afficher un message d'erreur

Parfois, l'IdP peut ne pas être en mesure d'émettre un jeton pour des raisons légitimes, telles que comme lorsque le client n'est pas autorisé, le serveur est temporairement indisponible. Si l'IdP renvoie une erreur le tiers assujetti à des restrictions peut l'intercepter, et Chrome avertit l'utilisateur en affichant une interface de navigateur avec les informations d'erreur fournies par le fournisseur d'identité.

</ph>

try {
  const cred = await navigator.credentials.get({
    identity: {
      providers: [
        {
          configURL: "https://idp.example/manifest.json",
          clientId: "1234",
        },
      ],
    }
  });
} catch (e) {
  const code = e.code;
  const url = e.url;
}

Réauthentifier automatiquement les utilisateurs après l'authentification initiale

Réauthentification automatique FedCM ("réauthentification automatique") peuvent permettre aux utilisateurs de se réauthentifier automatiquement lorsqu'ils revenir après leur authentification initiale à l’aide de FedCM. « Le début "Authentification unique" que l'utilisateur crée un compte ou se connecte site Web en appuyant sur le bouton Continuer en tant que dans la boîte de dialogue de connexion de FedCM pour la première fois sur la même instance de navigateur.

Si l'expérience utilisateur explicite a du sens avant que l'utilisateur ait créé la fédéré pour empêcher le suivi (qui est l'un des principaux objectifs de FedCM), elle devient inutilement fastidieuse après que l'utilisateur l'a passée une fois: après l'utilisateur accorde l'autorisation d'autoriser la communication entre le RP et le IdP, il n'y a aucun avantage en termes de confidentialité ou de sécurité à appliquer l'autorisation d'un autre utilisateur explicite une confirmation pour quelque chose qu’il a déjà confirmé.

Avec la réauthentification automatique, le navigateur change de comportement en fonction de l'option que vous spécifiez pour mediation lorsque vous appelez navigator.credentials.get().

const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: "https://idp.example/fedcm.json",
      clientId: "1234",
    }],
  },
  mediation: 'optional', // this is the default
});

// `isAutoSelected` is `true` if auto-reauthn was performed.
const isAutoSelected = cred.isAutoSelected;

mediation est une propriété de la page Gestion des identifiants l'API, son comportement est le même de manière que pour PasswordCredential et FederatedCredential et il est partiellement pris en charge par PublicKeyCredential . La propriété accepte les quatre valeurs suivantes:

• 'optional'(par défaut): réauthentification automatique si possible. Une médiation est requise dans le cas contraire. Mer nous vous recommandons de choisir cette option sur la page de connexion.
• 'required': une médiation est toujours nécessaire pour pouvoir continuer, par exemple en cliquant sur le bouton "Continuer" de l'interface utilisateur. Choisissez cette option si vos utilisateurs sont censés accorder explicitement l'autorisation chaque fois qu'ils doivent être authentifiés.
• 'silent': réauthentification automatique si possible, échec silencieux sans nécessiter de si ce n'est pas le cas. Nous vous recommandons de choisir cette option sur les pages autres que la page de connexion dédiée, mais sur laquelle vous souhaitez que les utilisateurs restent connectés, Il peut s'agir, par exemple, d'une page d'article sur un site Web de livraison ou d'une page d'article sur un site d'actualités. sur votre site Web.
• 'conditional': utilisé pour WebAuthn et non disponible pour FedCM pour le moment.

Avec cet appel, la réauthentification automatique s'effectue dans les conditions suivantes:

• FedCM est disponible. Par exemple, l'utilisateur n'a pas désactivé FedCM. soit de manière globale, soit pour le tiers assujetti à des restrictions dans les paramètres.
• L'utilisateur n'a utilisé qu'un seul compte avec l'API FedCM pour se connecter au site Web sur ce navigateur.
• L'utilisateur est connecté au fournisseur d'identité avec ce compte.
• La réauthentification automatique ne s'est pas produite au cours des 10 dernières minutes.
• Le tiers assujetti à des restrictions n'a pas appelé Puis navigator.credentials.preventSilentAccess() la précédente connexion.

Lorsque ces conditions sont remplies, une tentative de réauthentification automatique L'utilisateur démarre dès que l'navigator.credentials.get() FedCM est appelé.

Si la valeur est mediation: optional, la réauthentification automatique peut être non disponible pour les raisons suivantes : seul le navigateur connaît ; le tiers assujetti à des restrictions peut vérifier si en examinant la propriété isAutoSelected.

Cela permet d'évaluer les performances de l'API et d'améliorer l'expérience utilisateur en conséquence. De plus, lorsqu'il est indisponible, l'utilisateur peut être invité à se connecter avec la médiation des utilisateurs, qui est un flux avec mediation: required.

Appliquer la médiation avec preventSilentAccess()

La réauthentification automatique des utilisateurs immédiatement après leur déconnexion n'est pas très bonne expérience utilisateur. C'est pourquoi FedCM dispose d'une période silencieuse de 10 minutes après une réauthentification automatique pour éviter ce comportement. La réauthentification automatique a donc lieu au maximum toutes les 10 minutes, sauf si l'utilisateur se reconnecte sous 10 minutes. Le tiers assujetti à des restrictions doit appeler navigator.credentials.preventSilentAccess() pour demander explicitement au navigateur de désactiver la réauthentification automatique lorsqu'un utilisateur se déconnecte le tiers assujetti à des restrictions explicitement, par exemple en cliquant sur un bouton de déconnexion.

function signout() {
  navigator.credentials.preventSilentAccess();
  location.href = '/signout';
}

Les utilisateurs peuvent désactiver la réauthentification automatique dans les paramètres

Les utilisateurs peuvent désactiver la réauthentification automatique dans le menu des paramètres:

• Dans Chrome pour ordinateur, accédez à chrome://password-manager/settings > Se connecter automatiquement.
• Dans Chrome pour Android, accédez à Paramètres > Gestionnaire de mots de passe > Appuyez sur un roue dentée en haut à droite > Connexion automatique.

En désactivant l'option, l'utilisateur peut désactiver la réauthentification automatique ensemble. Ce paramètre est stocké et synchronisé sur tous les appareils, si l'utilisateur connecté à un compte Google sur l'instance Chrome, et la synchronisation est est activé.

Déconnecter l'IdP du tiers assujetti à des restrictions

Si un utilisateur s'est déjà connecté au tiers assujetti à des restrictions à l'aide du fournisseur d'identité via FedCM, le relation est mémorisée par le navigateur localement comme la liste des Google Cloud. Le tiers assujetti à des restrictions peut déclencher une déconnexion en appelant la méthode fonction IdentityCredential.disconnect(). Cette fonction peut être appelée à partir d'un cadre RP de premier niveau. Le tiers assujetti à des restrictions doit transmettre un configURL, le clientId qu'il utilise sous le fournisseur d'identité et un accountHint pour que celui-ci soit déconnecté. Un compte L'indice peut être une chaîne arbitraire tant que le point de terminaison de déconnexion peut identifier le compte, par exemple une adresse e-mail ou un ID utilisateur qui n'est pas nécessairement correspondent à l'ID de compte fourni par le point de terminaison de la liste de comptes:

// Disconnect an IdP account "account456" from the RP "https://idp.com/". This is invoked on the RP domain.
IdentityCredential.disconnect({
  configURL: "https://idp.com/config.json",
  clientId: "rp123",
  accountHint: "account456"
});

IdentityCredential.disconnect() renvoie un Promise. Cette promesse peut générer pour les raisons suivantes:

• L'utilisateur ne s'est pas connecté au tiers assujetti à des restrictions à l'aide du fournisseur d'identité via FedCM.
• L'API est appelée depuis un iFrame sans règle d'autorisation FedCM.
• La configURL n'est pas valide ou ne contient pas de point de terminaison de déconnexion.
• Échec de la vérification de la CSP (Content Security Policy).
• Une demande de dissociation est en attente.
• L'utilisateur a désactivé FedCM dans les paramètres du navigateur.

Lorsque le point de terminaison de déconnexion du IdP renvoie une , le RP et l'IdP sont déconnectés sur le navigateur et la promesse est faite. L'ID des comptes dissociés est spécifié dans la réponse de la déconnexion, point de terminaison unique.

Appeler FedCM depuis un iFrame d'origine différente

FedCM peut être appelé depuis un iFrame multi-origine à l'aide d'un Règle d'autorisation identity-credentials-get, si le cadre parent le permet. À ajoutez l'attribut allow="identity-credentials-get" au tag iFrame. comme suit:

<iframe src="https://fedcm-cross-origin-iframe.glitch.me" allow="identity-credentials-get"></iframe>

Pour le voir en action, consultez un exemple.

Si le frame parent veut limiter les origines à l'appel de FedCM, envoyez un en-tête Permissions-Policy avec une liste d'origines autorisées.

Permissions-Policy: identity-credentials-get=(self "https://fedcm-cross-origin-iframe.glitch.me")

Pour en savoir plus sur le fonctionnement de cette règle, consultez la page Contrôler fonctionnalités de navigateur avec autorisations Règlement.