A partire da Chrome 122, è disponibile l'API Disconnect per l'API Federated Credential Management (FedCM). L'API Disconnect consente alle parti interessate di scollegare i propri utenti dall'account del fornitore di servizi di identità senza fare affidamento su cookie di terze parti. Inoltre, sono stati apportati alcuni aggiornamenti alla gestione della funzionalità SameSite di FedCM.
Scollegare l'API
Quando un utente crea un account su una terza parte attendibile (RP, il sito che utilizza il fornitore di identità per l'autenticazione) tramite la federazione delle identità, il fornitore di identità (IdP, il servizio che fornisce l'autenticazione e i dati dell'account ad altre parti) registra in genere la connessione sul proprio server. La connessione memorizzata consente all'SP di tenere traccia degli RP a cui l'utente ha eseguito l'accesso e di ottimizzare la sua esperienza. Ad esempio, per offrire un'esperienza migliore quando l'utente fa ritorno all'RP in un secondo momento, l'account utente con l'IDP viene trattato come un account di ritorno, il che consente funzionalità come la ricognizione automatica e i pulsanti personalizzati che mostrano l'account utilizzato.
A volte, le IdP offrono un'API per scollegare l'account da un RP. Tuttavia, un flusso di disconnessione è autenticato e richiede i cookie dell'IdP. In un mondo senza cookie di terze parti, quando l'utente visita la RP, non esiste un'API del browser che consenta alla RP di disconnettersi dall'IdP. Poiché potrebbero esserci più account IdP dello stesso IdP collegati a un determinato RP, il flusso di disconnessione richiede di sapere quale account viene disconnesso.
L'API Disconnect consente all'utente di scollegare l'account IdP dall'RP sia sul browser sia sul server IdP segnalandolo all'endpoint specificato. L'utente deve aver eseguito la federazione delle identità utilizzando l'API Federated Credential Management (FedCM). Una volta disconnesso, l'utente viene considerato come nuovo quando tenta di accedere nuovamente all'RP utilizzando l'IdP.
Scollegare l'IdP dall'RP
Se un utente ha già eseguito l'accesso all'RP utilizzando l'IdP tramite FedCM, la relazione viene memorizzata localmente dal browser come elenco degli account collegati. L'RP può avviare una disconnessione chiamando la funzione IdentityCredential.disconnect(). Questa funzione può essere chiamata da un frame RP di primo livello. L'RP deve passare un configURL, il clientId che utilizza
sotto l'IdP e un accountHint per scollegare l'IdP. Un indicazione per l'account può essere una stringa arbitraria, purché l'endpoint di disconnessione possa identificare l'account, ad esempio un indirizzo email o un ID utente che non corrisponde necessariamente all'ID account fornito dall'endpoint dell'elenco di account:
// 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() restituisce un Promise. Questa promessa potrebbe generare un'eccezione per i seguenti motivi:
- L'utente non ha eseguito l'accesso all'RP utilizzando l'IdP tramite FedCM.
- L'API viene invocata da un iframe senza il criterio di autorizzazione FedCM.
- L'URL di configurazione non è valido o manca l'endpoint di disconnessione.
- Il controllo dei Criteri di sicurezza del contenuto (CSP) non va a buon fine.
- È presente una richiesta di disconnessione in attesa.
- L'utente ha disattivato FedCM nelle impostazioni del browser.
Quando l'endpoint di disconnessione dell'IdP restituisce una risposta, l'RP e l'IdP vengono disconnessi nel browser e la promessa viene risolta. Gli account utente da scollegare sono specificati nella risposta dell'endpoint di disconnessione.
Configura il file di configurazione dell'IdP
Per supportare l'API Disconnect, l'IdP deve supportare un endpoint di disconnessione e fornire la proprietà disconnect_endpoint e il relativo percorso nel file di configurazione IdP.
{
"accounts_endpoint": "/accounts",
"id_assertion_endpoint": "/assertion",
...
"disconnect_endpoint: "/disconnect"
}
Scollegare l'account nell'endpoint di disconnessione
Se viene invocato IdentityCredential.disconnect(), il browser invia una richiesta POST cross-origin con cookie e un tipo di contenuto application/x-www-form-urlencoded a questo endpoint di disconnessione con le seguenti informazioni:
| Proprietà | Descrizione |
|---|---|
account_hint |
Un suggerimento per l'account IdP. |
client_id |
L'identificatore client dell'RP. |
POST /disconnect 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
Al ricevimento della richiesta, il server dell'IDP deve:
- Rispondere alla richiesta con CORS (Cross-Origin Resource Sharing).
- Verifica che la richiesta contenga un'intestazione HTTP
Sec-Fetch-Dest: webidentity. - Abbina l'intestazione
Originall'origine RP determinata daclient_id. Rifiuta se non corrispondono. - Trova l'account corrispondente a
account_hint. - Scollega l'account utente dall'elenco degli account collegati dell'RP.
- Rispondere al browser con il
account_iddell'utente identificato in formato JSON.
Un esempio di payload JSON di risposta è il seguente:
{
"account_id": "account456"
}
Se l'IdP vuole che il browser scolleghi tutti gli account associati all'RP, deve passare una stringa che non corrisponda a nessun ID account, ad esempio "*".
Il controllo /.well-known/web-identity viene ora saltato quando l'RP e l'IDP si trovano nello stesso sito
Quando sviluppi un sistema FedCM, i domini dei server RP di test o di staging possono essere i sottodomini del server IdP di produzione. Ad esempio, il server IdP di produzione si trova all'indirizzo idp.example e sia il server RP di staging sia il server IdP di staging si trovano all'indirizzo staging.idp.example. Tuttavia, poiché il file well-known deve essere posizionato nel percorso principale dell'eTLD+1 del server dell'IdP, deve trovarsi in idp.example/.well-known/web-identity ed è il server di produzione. Poiché
non è necessariamente possibile per gli sviluppatori inserire file nell'ambiente
di produzione durante lo sviluppo, ciò impedisce loro di testare FedCM.
A partire da Chrome 122, se il dominio RP e il dominio IdP sono uguali, Chrome salta la verifica del file well-known. In questo modo, gli sviluppatori potranno eseguire test in questo tipo di scenario.
Ora le risorse secondarie possono impostare lo stato di accesso nello stesso sito
In precedenza, Chrome consentiva di impostare solo lo stato di accesso (ad esempio utilizzando l'intestazione Set-Login: logged-in) quando la richiesta era della stessa origine di tutti gli antenati. In questo modo, sono stati impediti gli accessi tramite le richiestefetch() all'interno dello stesso sito che impostano lo stato di accesso.
Ad esempio, immagina un sito web che consente agli utenti di inserire il nome utente e la password su idp.example, ma le credenziali vengono pubblicate su login.idp.example con fetch(). Non è stato possibile registrare lo stato di accesso nel browser utilizzando l'API Login Status perché i due domini sono cross-origin e nello stesso sito.
Con questa modifica, abbiamo allentato il requisito che l'API Stato di accesso debba essere
sulla stessa pagina
con tutti gli antenati e nell'esempio riportato sopra è possibile impostare
lo stato di accesso di login.idp.example utilizzando un'intestazione HTTP (Set-Login:
logged-in).
Riepilogo
Grazie all'API Disconnect, FedCM ora può scollegare l'RP dall'IDP
senza fare affidamento sui cookie di terze parti. Per farlo, chiama
IdentityCredential.disconnect() sull'RP. Con questa funzione, il browser invia una richiesta all'endpoint di disconnessione dell'IdP in modo che l'IdP possa terminare la connessione sul server e poi sul browser.
Abbiamo annunciato che il controllo /.well-known/web-identity viene saltato quando l'RP
e l'IDP si trovano nello stesso sito, a scopo di test. Inoltre, ora è possibile impostare un stato di accesso tramite un'intestazione di risposta HTTP della risorsa secondaria dell'IDP nello stesso sito.