A partire da Chrome 122, è disponibile l'API Disconnetti per l'API FedCM (Federated Credential Management). 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, ci sono un paio di aggiornamenti alla gestione dello stesso sito 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'IDP 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, 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, gli IdP offrono un'API per disconnettere l'account da una parte soggetta a limitazioni. 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 parte soggetta a limitazioni, non esiste un'API browser che consenta all'RP di disconnettersi dall'IdP. Poiché potrebbero esserci più account IdP dello stesso IdP collegati a una determinata parte soggetta a limitazioni, 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 utente la volta successiva che tenta di accedere alla parte soggetta a limitazioni utilizzando l'IdP.
Scollegare l'IdP dall'RP
Se un utente ha già eseguito l'accesso alla parte soggetta a limitazioni utilizzando l'IdP tramite FedCM, la relazione viene memorizzata dal browser localmente come elenco degli account connessi. 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 alla parte soggetta a limitazioni utilizzando l'IdP tramite FedCM.
- L'API viene invocata da un iframe senza il criterio di autorizzazione FedCM.
- configURL non è valido o manca l'endpoint di disconnessione.
- Il controllo dei Criteri di sicurezza del contenuto (CSP) non va a buon fine.
- Esiste 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, la parte soggetta a limitazioni e l'IdP vengono disconnessi dal 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 della parte soggetta a limitazioni. |
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
Alla ricezione della richiesta, il server IdP deve:
- Rispondere alla richiesta con CORS (condivisione delle risorse tra origini).
- Verifica che la richiesta contenga un'intestazione HTTP
Sec-Fetch-Dest: webidentity. - Abbina l'intestazione
Originall'origine RP determinata dall'client_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 è simile al seguente:
{
"account_id": "account456"
}
Se l'IdP vuole che il browser scolleghi tutti gli account associati alla parte soggetta a limitazioni, trasmetti una stringa che non corrisponda ad alcun 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, mentre sia il server RP temporaneo che il server IdP temporaneo si trovano all'indirizzo staging.idp.example. Tuttavia, poiché il file noto deve essere posizionato
alla radice dell'eTLD+1 del server IdP, deve trovarsi all'indirizzo
idp.example/.well-known/web-identity e deve essere il server di produzione. Poiché gli sviluppatori non possono necessariamente inserire file nell'ambiente di produzione mentre sono in fase di sviluppo, non potranno testare FedCM.
A partire da Chrome 122, se il dominio RP e il dominio IdP sono uguali, Chrome salta la verifica del file noto. In questo modo gli sviluppatori potranno eseguire test in questo scenario.
Ora le sottorisorse possono impostare lo stato di accesso allo stesso sito
In precedenza, Chrome consentiva di impostare lo stato
dell'accesso (ad esempio, utilizzando l'intestazione Set-Login: logged-in) solo quando la richiesta è la stessa
origine
con tutti i predecessori. In questo modo sono stati impediti gli accessi tramite le richiestefetch() all'interno dello stesso sito che impostano lo stato di accesso.
Ad esempio, pensa a un sito web che consenta agli utenti di inserire nome utente e password su idp.example, ma le credenziali vengono pubblicate su login.idp.example con fetch(). Non è stato possibile registrare lo stato di accesso al browser utilizzando l'API Login Status, perché i due domini sono multiorigine e nello stesso sito.
Con questa modifica, abbiamo allentato il requisito che richiede che l'API Login Status sia lo stesso sito di tutti i predecessori e abbiamo reso possibile l'esempio precedente per impostare lo stato di accesso di login.idp.example utilizzando un'intestazione HTTP (Set-Login:
logged-in).
Riepilogo
Utilizzando l'API Disconnetti, FedCM ora può disconnettere la parte soggetta a limitazioni dall'IdP senza fare affidamento su cookie di terze parti. Per farlo, richiama
IdentityCredential.disconnect() nella parte soggetta a limitazioni. 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 quindi 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.