À 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 type="x-smartling-placeholder">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¶m_foo=BAR¶m_ETC=MOAR¶m_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¶m_IDP_SPECIFIC_PARAM=1¶m_foo=BAR¶m_ETC=MOAR¶m_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 exemplescope
. - 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'appelnavigator.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.
<ph type="x-smartling-placeholder">![Message de divulgation en mode widget.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/blog/fedcm-126-with-disclosure-widget.jpg?authuser=19&hl=fr)
![Message de divulgation en mode bouton.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/blog/fedcm-126-with-disclosure-button.jpg?authuser=19&hl=fr)
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.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/blog/fedcm-126-without-disclosure-widget.jpg?authuser=19&hl=fr)
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
etlogin_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.