Cette page a été traduite par l'API Cloud Translation.

Mises à jour FedCM: Phases d'évaluation pour le bundle de l'API Continuation et octroi automatique de l'API Storage Access

Eiji Kitamura

À partir de Chrome 126, les développeurs peuvent commencer à exécuter une phase d'évaluation pour un lot de l'API Federated Credential Management (FedCM) de bureau qui activent certaines Cas d'utilisation de l'autorisation Le bundle se compose de l'API Continuation et de l'API Continuation L'API Parameters, qui permet une expérience semblable à un flux d'autorisation OAuth impliquant une boîte de dialogue d'autorisation fournie par un fournisseur d'identité (IdP). Par ailleurs, inclut d'autres modifications telles que l'API Fields, les options Multiple configURLs et Custom Libellés de compte. À partir de Chrome 126, nous lançons également une phase d'évaluation pour le L'API Storage Access (SAA) accorde automatiquement les requêtes SAA si l'utilisateur a se sont déjà connectés à l'aide de FedCM par le passé.

Phase d'évaluation: lot d'API FedCM Continuation

Le bundle de l'API FedCM Continuation se compose de plusieurs extensions FedCM:

API Continuation
API Parameters
API Fields
Plusieurs URL de configuration
Libellés de compte personnalisés

API Continuation

</ph>

Un utilisateur se connecte au tiers assujetti à des restrictions, puis donne une autorisation via le mode Bouton.

Vous pouvez regarder une démonstration de l'API sur Glitch.

L'API Continuation permet Affirmation d'ID du fournisseur d'identité le point de terminaison éventuellement renvoyer une URL que FedCM affichera pour permettre à l'utilisateur de connexion en plusieurs étapes. Cela permet au fournisseur d'identité de demander à l'utilisateur d'accorder le des autorisations de tiers de confiance au-delà de ce qui est possible dans l'interface utilisateur existante de FedCM, comme l'accès aux ressources de l'utilisateur côté serveur.

En règle générale, le point de terminaison d'assertion d'ID renvoie un jeton requis pour l'authentification unique.

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

Toutefois, avec l'API Continuation, l'assertion d'ID point de terminaison renvoyer une propriété continue_on qui inclut un chemin d'accès absolu ou relatif vers le point de terminaison d'assertion d'ID.

{
  // In the id_assertion_endpoint, instead of returning a typical
  // "token" response, the IdP decides that it needs the user to
  // continue on a pop-up window:
  "continue_on": "/oauth/authorize?scope=..."
}

Dès que le navigateur reçoit la réponse continue_on, une nouvelle fenêtre pop-up s'ouvre et oriente l'utilisateur vers le chemin spécifié.

Après que l'utilisateur a interagi avec la page, par exemple en accordant d'autres autorisations pour partager des informations supplémentaires avec le tiers assujetti à des restrictions, la page du fournisseur d'identité peut appeler IdentityProvider.resolve() pour résoudre le problème d'origine navigator.credentials.get() appelle et renvoie un jeton en tant qu'argument.

document.getElementById('allow_btn').addEventListener('click', async () => {
  let accessToken = await fetch('/generate_access_token.cgi');
  // Closes the window and resolves the promise (that is still hanging
  // in the relying party's renderer) with the value that is passed.
  IdentityProvider.resolve(accessToken);
});

Le navigateur fermera alors la fenêtre pop-up et renverra le jeton à l'API. appelant.

Si l'utilisateur refuse la requête, vous pouvez fermer la fenêtre en appelant IdentityProvider.close()

IdentityProvider.close();

Si, pour une raison quelconque, l'utilisateur a changé de compte dans la fenêtre pop-up (par exemple, l'IdP propose un « changement d'utilisateur » ou dans les cas de délégation), la résolution utilise un second argument facultatif qui autorise un élément semblable à celui-ci:

IdentityProvider.resolve(token, {accountId: '1234');

API Parameters

L'API Parameters permet à la RP pour fournir des paramètres supplémentaires à l'assertion d'ID un seul point de terminaison. Avec l'API Parameters, les tiers assujettis à des restrictions peuvent transmettre des paramètres supplémentaires à l'IdP demander des autorisations pour des ressources autres que la connexion de base. L'utilisateur doit autoriser ces autorisations via un flux d'expérience utilisateur contrôlé par IdP, qui est lancé via le API Continuation :

Pour utiliser l'API, ajoutez des paramètres à la propriété params en tant qu'objet dans la Appel navigator.credentials.get().

let {token} = await navigator.credentials.get({
  identity: {
    providers: [{
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      // Key/value pairs that need to be passed from the
      // RP to the IdP but that don't really play any role with
      // the browser.
      params: {
        IDP_SPECIFIC_PARAM: '1',
        foo: 'BAR',
        ETC: 'MOAR',
        scope: 'calendar.readonly photos.write',
      }
    },
  }
});

Les noms de propriété de l'objet params sont précédés de param_. Dans Dans l'exemple ci-dessus, la propriété "params" contient IDP_SPECIFIC_PARAM en tant que '1', foo en tant que 'BAR', ETC en tant que 'MOAR' et scope en tant que 'calendar.readonly photos.write'. Il sera traduit en param_IDP_SPECIFIC_PARAM=1&param_foo=BAR&param_ETC=MOAR&param_scope=calendar.readonly%20photos.write dans le corps HTTP de la requête:

POST /fedcm_assertion_endpoint HTTP/1.1
Host: 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=234234&disclosure_text_shown=false&param_IDP_SPECIFIC_PARAM=1&param_foo=BAR&param_ETC=MOAR&param_scope=calendar.readonly%20photos.write

Obtenir les autorisations de manière dynamique

En général, pour les utilisateurs, il est plus utile de demander des autorisations lorsqu'ils plutôt que lorsque le développeur estime qu'il est plus facile à implémenter. Pour par exemple, demander l’autorisation d’accéder à une caméra lorsque l’utilisateur est sur le point de prendre une photo est préférable à la demande d'autorisation dès que l'utilisateur arrive sur sur votre site Web. La même pratique s'applique aux ressources de serveur. Demander des autorisations uniquement quand ils sont nécessaires pour l’utilisateur. C'est ce qu'on appelle l'"autorisation dynamique".

Pour demander l'autorisation de manière dynamique avec FedCM, le fournisseur d'identité peut:

Appeler navigator.credentials.get() avec les paramètres requis que le fournisseur d'identité peut comprendre, par exemple scope.
L'assertion d'ID point de terminaison confirme que l'utilisateur est déjà connecté et répond avec une URL continue_on.
Le navigateur ouvre une fenêtre pop-up sur la page d'autorisation de l'IdP demandant l'autorisation une autorisation supplémentaire correspondant aux champs d'application demandés.
Une fois autorisée via IdentityProvider.resolve() par l'IdP, la fenêtre est fermé et l'appel navigator.credentials.get() initial du tiers assujetti à des restrictions reçoit une ou un code d'autorisation afin que la partie concernée puisse l'échanger un jeton d'accès approprié.

API Fields

L'API Fields permet à la RP de déclarer les attributs de compte à demander à l'IdP afin que le navigateur puisse afficher une interface utilisateur de divulgation appropriée dans la boîte de dialogue de FedCM ; il incombe à l'IdP pour inclure les champs demandés dans le jeton renvoyé. Envisagez cette demande un "profil de base" dans OpenID Connect et les "habilitations" dans OAuth.

Pour utiliser l'API Fields, ajoutez des paramètres à la propriété fields sous forme de tableau dans la Appel navigator.credentials.get(). Les champs peuvent contenir les valeurs 'name' et 'email'. et 'picture' pour le moment, mais vous pouvez l'étendre pour inclure davantage de valeurs dans à venir.

Une requête avec fields ressemblerait à ceci:

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      fields: ['name', 'email', 'picture'],
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      params: {
        scope: 'drive.readonly calendar.readonly',
      }
    },
  }
  mediation: 'optional',
});

La requête HTTP à l'assertion d'ID point de terminaison inclut le paramètre fields spécifié par RP, avec le paramètre disclosure_text_shown défini sur true s'il ne s'agit pas d'un utilisateur connu, et les champs que le navigateur divulgué à l'utilisateur dans un paramètre disclosure_shown_for:

POST /id_assertion_endpoint HTTP/1.1
Host: 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=234234&disclosure_text_shown=true&fields=email,name,picture&disclosure_shown_for=email,name,picture

Si le tiers assujetti à des restrictions a besoin d'accéder à des données supplémentaires de l'IdP, comme l'accès à une Agenda, cette opération doit être gérée à l'aide d'un paramètre personnalisé, comme indiqué ci-dessus. La L'IdP renvoie une URL continue_on pour demander l'autorisation.

Si fields est un tableau vide, la requête se présente comme suit:

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      fields: [],
      clientId: '1234',
      configURL: 'https://idp.example/fedcm.json',
      params: {
        scope: 'drive.readonly calendar.readonly',
      }
    },
  }
  mediation: 'optional',
});

Si fields est un tableau vide, le user-agent ignore l'interface utilisateur de divulgation.

Le message de divulgation ne s'affiche pas en mode widget. Lors du flux du bouton, l'interface utilisateur du communiqué est complètement ignorée. — Le message de divulgation ne s'affiche pas en mode widget. Lors du parcours du bouton, l'interface utilisateur du communiqué est complètement ignorée.

Ceci est le cas même si la réponse de la fonction accounts point de terminaison ne contient pas d'ID client correspondant au RP dans approved_clients.

Dans ce cas, le disclosure_text_shown envoyé à l'assertion d'ID point de terminaison est "false" dans le corps HTTP:

POST /id_assertion_endpoint HTTP/1.1
Host: 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=234234&disclosure_text_shown=false

Plusieurs configURL

L'utilisation de plusieurs configURL permet d'autoriser les IdP. pour prendre en charge plusieurs fichiers de configuration pour un IdP, en spécifiant accounts_endpoint et login_url dans la classe fichier de la même manière que les fichiers de configuration.

Si accounts_endpoint et login_url sont ajoutés au fichier well-known, le Les provider_urls sont ignorés afin que le fournisseur d'identité puisse prendre en charge plusieurs fichiers de configuration. Si ce n'est pas le cas, provider_urls continue de s'appliquer pour être rétrogradé. compatibles.

Le fichier bien connu qui prend en charge plusieurs configURL peut se présenter comme suit:

{
  "provider_urls": [ "https://idp.example/fedcm.json" ],
  "accounts_endpoint": "https://idp.example/accounts",
  "login_url": "https://idp.example/login"
}

que nous utilisons aux fins suivantes :

Maintenir la rétrocompatibilité avec les fichiers connus existants et la version antérieure des navigateurs déjà déployés dans la nature.
disposer d'un nombre arbitraire de fichiers de configuration, à condition qu'ils pointent tous vers le accounts_endpoint et login_url identiques.
Impossible d'ajouter l'entropie à la requête d'extraction avec identifiants apportée à accounts_endpoint, car elle doit être spécifiée au niveau ".well-known" d'application.

La prise en charge de plusieurs configURL est facultative, et le gestionnaire les implémentations peuvent rester les mêmes.

Libellés de compte personnalisés

Les libellés de compte personnalisés permettent à FedCM de fonctionner. Les fournisseurs d'identité annotent les comptes afin que les tiers assujettis à des restrictions puissent les filtrer en spécifiant l'étiquette dans un fichier de configuration. Un filtrage similaire a été possible à l'aide du Domain Hint API et l'API Login Hint API en spécifiant lors de l'appel navigator.credentials.get(), mais les libellés de compte personnalisés vous pouvez filtrer les utilisateurs en spécifiant le fichier de configuration, ce qui est particulièrement utile plusieurs configURL sont utilisées. Les libellés de compte personnalisés sont également différente dans le fait qu'elles sont fournies par le serveur IdP, et non depuis le tiers assujetti à des restrictions, comme la connexion ou les indications de domaine.

Exemple

Un IdP est compatible avec deux URL de configuration (configURL) pour le grand public et pour l'entreprise, respectivement. La le fichier de configuration du client comporte le libellé 'consumer', alors que le fichier de configuration de l'entreprise est associé au libellé 'enterprise'.

Avec une telle configuration, le fichier bien connu inclut accounts_endpoint et login_url pour autoriser plusieurs configURL.

{
  "provider_urls": [ "https://idp.example/fedcm.json" ],
  "accounts_endpoint": "https://idp.example/accounts",
  "login_url": "https://idp.example/login"
}

Lorsque le accounts_endpoint est fourni dans le fichier well-known, le Les provider_urls sont ignorés. Le tiers assujetti à des restrictions peut pointer directement vers la configuration respective de fichiers dans l'appel navigator.credentials.get().

Le fichier de configuration du consommateur se trouve à l'emplacement https://idp.example/fedcm.json, ce qui inclut Propriété accounts qui spécifie 'consumer' à l'aide de include.

{
  "accounts_endpoint": "https://idp.example/accounts",
  "client_metadata_endpoint": "/client_metadata",
  "login_url": "https://idp.example/login",
  "id_assertion_endpoint": "/assertion",
  "accounts": {
    "include": "consumer"
  }
}

Le fichier de configuration de l'entreprise se trouve à l'emplacement https://idp.example/enterprise/fedcm.json. qui inclut la propriété accounts, qui spécifie 'enterprise' à l'aide de la propriété include

{
  "accounts_endpoint": "https://idp.example/accounts",
  "client_metadata_endpoint": "/enterprise/client_metadata",
  "login_url": "https://idp.example/login",
  "id_assertion_endpoint": "/assertion",
  "accounts": {
    "include": "enterprise"
  }
}

Les comptes IdP courants point de terminaison (dans cet exemple, https://idp.example/accounts) renvoie une liste de comptes inclut une propriété "étiquettes" avec la valeur labels attribuée dans un tableau pour chaque compte. Voici un exemple de réponse pour un utilisateur disposant de deux comptes. L'une pour grand public, et l'autre pour les entreprises:

{
 "accounts": [{
   "id": "123",
   "given_name": "John",
   "name": "John Doe",
   "email": "john_doe@idp.example",
   "picture": "https://idp.example/profile/123",
   "labels": ["consumer"]
  }], [{
   "id": "4567",
   "given_name": "Jane",
   "name": "Jane Doe",
   "email": "jane_doe@idp.example",
   "picture": "https://idp.example/profile/4567",
   "labels": ["enterprise"]
  }]
}

Lorsqu'un tiers assujetti à des restrictions souhaite autoriser les utilisateurs de 'enterprise' à se connecter, il peut spécifier le 'enterprise' configURL 'https://idp.example/enterprise/fedcm.json' dans Appel navigator.credentials.get():

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      clientId: '1234',
      nonce: '234234',
      configURL: 'https://idp.example/enterprise/fedcm.json',
    },
  }
});

Par conséquent, seul l'ID de compte '4567' est disponible pour que l'utilisateur puisse se connecter. po. L'ID de compte '123' est masqué en mode silencieux par le navigateur afin que l'utilisateur ne sera pas associé à un compte non compatible avec l'IdP sur ce site.

Phase d'évaluation: FedCM comme signal de confiance pour l'API Storage Access

Chrome 126 lance une phase d'évaluation de FedCM en tant que signal de confiance pour le Accès à l'espace de stockage API. Avec suite à ce changement, l'octroi d'une autorisation préalable via FedCM devient une raison valable approuver automatiquement une demande d'accès à l'Storage Access API.

Cette fonctionnalité est utile lorsqu'un iFrame intégré souhaite accéder à des ressources personnalisées: Par exemple, si "idp.example" est intégré à "rp.example" et qu'il doit afficher une ressource personnalisée. Si le navigateur restreint l'accès aux cookies tiers, même si l'utilisateur est connecté à rp.example via idp.example avec FedCM, le L'iFrame idp.example intégré ne pourra pas demander de ressources personnalisées car les requêtes n'incluront pas de cookies tiers.

Pour ce faire, idp.example doit obtenir une autorisation d'accès au stockage via son iFrame intégré au site Web, et cela ne peut être obtenu qu'à travers invite d'autorisation.

Avec FedCM comme signal de confiance pour l'accès au stockage API, Les vérifications d'autorisation de l'API Storage Access acceptent non seulement l'autorisation accordée est donnée par une invite d'accès au stockage, mais aussi l'autorisation accordée par invite FedCM.

// In top-level rp.example:

// Ensure FedCM permission has been granted.
const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/fedcm.json',
      clientId: '123',
    }],
  },
  mediation: 'optional',
});

// In an embedded IdP iframe:

// No user gesture is needed to call this, and the call will be auto-granted.
await document.requestStorageAccess();

// This returns `true`.
const hasAccess = await document.hasStorageAccess();

Une fois l'utilisateur connecté à FedCM, l'autorisation lui est accordée automatiquement tant que l'authentification FedCM est active. Cela signifie qu'une fois l'utilisateur déconnecté, demande l'autorisation affiche une invite.

Participer à la phase d'évaluation

Vous pouvez essayer le bundle d'API FedCM Continuation localement en activant un indicateur chrome://flags#fedcm-authz sur Chrome 126 ou version ultérieure. Vous pouvez également essayer le FedCM comme signal de confiance pour l'API Storage Access localement, en activant #fedcm-with-storage-access-api sous Chrome 126 ou version ultérieure.

Ces fonctionnalités sont également disponibles en phase d'évaluation. Les phases d'évaluation vous permettent de tester de nouvelles fonctionnalités et de donner votre avis sur leur facilité d'utilisation, leur utilité et leur efficacité. Pour en savoir plus, consultez Premiers pas avec les phases d'évaluation.

Pour essayer l'origine du bundle de l'API FedCM Continuation essai, créez deux jetons d'essai d'origine:

Inscrivez-vous à l'essai. Intégrer le jeton dans l'IdP l'origine.
Inscrivez-vous à la phase d'évaluation en cochant la case correspondante tierce. Suivez les instructions de la section Enregistrer une phase d'évaluation tierce pour la RP afin d'intégrer le jeton pour la RP.

Si vous souhaitez activer l'API Continuation en même temps que le bouton flux, activez le mode Bouton Origine de l'API essai ainsi que:

Inscrivez-vous à la phase d'évaluation en tant que tiers. Suivez les instructions fournies dans l'article Enregistrez une phase d'évaluation tierce pour la partie assujettie à des restrictions afin de l'intégrer. le jeton du tiers assujetti à des restrictions.

Pour essayer FedCM comme signal de confiance pour l'origine de l'API Storage Access essai:

Inscrivez-vous à la phase d'évaluation. Intégrer le jeton dans l'IdP l'origine.

La phase d'évaluation du bundle d'API Continuation et FedCM en tant que signal de confiance pour le La phase d'évaluation de l'API Storage Access est disponible à partir de Chrome 126.

Enregistrer une phase d'évaluation tierce pour le tiers assujetti à des restrictions

Accédez à la page d'inscription à la phase d'évaluation.
Cliquez sur le bouton Register (S'inscrire), puis remplissez le formulaire pour demander un jeton.
Saisissez l'origine du fournisseur d'identité (IdP) sur Web Origin (Origine Web).
Cochez la case "Correspondance tierce" pour injecter le jeton avec JavaScript sur d'autres origines.
Cliquez sur Envoyer.
Intégrez le jeton émis à un site Web tiers.

Pour intégrer le jeton sur un site Web tiers, ajoutez le code suivant au fichier Bibliothèque JavaScript ou SDK diffusé à partir de l'origine du fournisseur d'identité.

const tokenElement = document.createElement('meta');
tokenElement.httpEquiv = 'origin-trial';
tokenElement.content = 'TOKEN_GOES_HERE';
document.head.appendChild(tokenElement);

Remplacez TOKEN_GOES_HERE par votre propre jeton.