Questa pagina è stata tradotta dall'API Cloud Translation.

Aggiornamenti di FedCM: API Disconnetti e due aggiornamenti

Eiji Kitamura

A partire da Chrome 122, è disponibile l'API Disconnetti per l'API Federated Credential Management (FedCM). L'API Disconnetti consente alle parti affidabili di disconnettere i propri utenti dall'account del provider di identità senza fare affidamento sui cookie di terze parti. Ci sono anche un paio di aggiornamenti alla gestione dello stesso sito di FedCM.

API Disconnetti

Quando un utente crea un account su una parte attendibile (RP, il sito che utilizza il provider di identità per l'autenticazione) tramite la federazione delle identità, il provider di identità (IdP, il servizio che fornisce informazioni sull'autenticazione e sull'account ad altre parti) registra in genere la connessione sul suo server. La connessione archiviata consente all'IdP di tenere traccia delle RP a cui l'utente ha eseguito l'accesso e di ottimizzare la sua esperienza. Ad esempio, per avere un'esperienza migliore quando l'utente in seguito torna alla parte soggetta a limitazioni, l'account utente con l'IdP viene considerato come un account di ritorno, il che consente funzionalità come la riautenticazione automatica e i pulsanti personalizzati che mostrano l'account utilizzato.

A volte, gli IdP offrono un'API per scollegare 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 questa possa disconnettere 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 Disconnetti consente all'utente di disconnettere l'account IdP dalla RP sul browser e sul server IdP segnalandolo all'endpoint specificato. L'utente deve aver eseguito la federazione delle identità utilizzando l'API FedCM (Federated Credential Management). Una volta disconnesso, l'utente viene considerato come nuovo la volta successiva che tenta di accedere alla parte soggetta a limitazioni utilizzando l'IdP.

Disconnetti l'IdP dalla parte soggetta a limitazioni

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. La parte soggetta a limitazioni potrebbe avviare una disconnessione richiamando la funzione IdentityCredential.disconnect(). Questa funzione può essere chiamata da un frame RP di primo livello. La parte soggetta a limitazioni deve passare un configURL, il clientId che utilizza sotto l'IdP e un accountHint affinché l'IdP venga disconnesso. Un suggerimento per l'account può essere una stringa arbitraria, purché l'endpoint di disconnessione sia in grado di 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 può rappresentare 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 richiamata dall'interno di un iframe senza norme relative alle autorizzazioni FedCM.
Il parametro 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 disconnesse sul browser e la promessa viene risolta. Gli account utente che si disconnettono vengono specificati nella risposta dall'endpoint di disconnessione.

Configura file di configurazione IdP

Per supportare l'API Disconnetti, l'IdP deve supportare un endpoint di disconnessione e fornire la proprietà disconnect_endpoint e il relativo percorso nel relativo file di configurazione IdP.

{
  "accounts_endpoint": "/accounts",
  "id_assertion_endpoint": "/assertion",
  ...
  "disconnect_endpoint: "/disconnect"
}

Scollegare l'account sull'endpoint di disconnessione

Richiamando IdentityCredential.disconnect(), il browser invia una richiesta POST multiorigine 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`	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:

Rispondi alla richiesta con CORS (condivisione delle risorse tra origini).
Verifica che la richiesta contenga un'intestazione HTTP Sec-Fetch-Dest: webidentity.
Abbina l'intestazione Origin all'origine della parte soggetta a limitazioni determinata dal valore client_id. Rifiuta se non corrispondono.
Trova l'account corrispondente a account_hint.
Scollega l'account utente dall'elenco degli account collegati della parte soggetta a limitazioni.
Rispondere al browser con il codice account_id dell'utente identificato in formato JSON.

Avviso: la richiesta CORS è credenziale, il che significa che l'intestazione della risposta Access-Control-Allow-Credentials: true deve essere inviata e l'intestazione della risposta Access-Control-Allow-Origin deve indicare in modo esplicito un'origine consentita, anziché utilizzare un carattere jolly "*".

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://rp.example
Access-Control-Allow-Credentials: true

Un esempio di payload JSON di risposta ha il seguente aspetto:

{
  "account_id": "account456"
}

Se l'IdP vuole che il browser disconnetta invece tutti gli account associati alla parte soggetta a limitazioni, trasmetti una stringa che non corrisponde ad alcun ID account, ad esempio "*".

Il controllo di `/.well-known/web-identity` viene ignorato quando la parte soggetta a limitazioni e l'IdP sono dello stesso sito

Durante lo sviluppo di un sistema FedCM, i domini dei server RP di test o gestione temporanea possono essere i sottodomini del server IdP di produzione. Ad esempio, il server IdP di produzione si trova su idp.example e sia il server RP di gestione temporanea che il server IdP di gestione temporanea si trovano su staging.idp.example. Tuttavia, poiché il file noto deve essere posizionato nella directory radice dell'eTLD+1 del server IdP, deve essere in idp.example/.well-known/web-identity e deve corrispondere al server di produzione. Poiché per gli sviluppatori non è necessariamente possibile 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 gli stessi, Chrome non controlla il 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 di accesso (ad esempio, utilizzando l'intestazione Set-Login: logged-in) solo quando la richiesta ha la stessa origine con tutti i predecessori. Ciò ha impedito l'impostazione dello stato di accesso attraverso le richieste same-site fetch().

Ad esempio, pensa a un sito web che consente 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 dell'accesso al browser utilizzando l'API Login Status, perché i due domini sono multiorigine e dello stesso sito.

Con questa modifica, abbiamo ridotto il requisito che prevede che l'API Login Status sia lo stesso sito di tutti i predecessori e abbiamo reso possibile l'impostazione dello stato di accesso di login.idp.example utilizzando un'intestazione HTTP (Set-Login: logged-in).

Riepilogo

Utilizzando l'API Disconnetti, FedCM può ora disconnettere la parte soggetta a limitazioni dall'IdP senza fare affidamento su cookie di terze parti. Per farlo, chiama IdentityCredential.disconnect() sulla parte soggetta a limitazioni. Con questa funzione, il browser invia una richiesta all'endpoint di disconnessione dell'IdP in modo che possa terminare la connessione sul server e poi sul browser.

Abbiamo annunciato che, a fini di test, il controllo /.well-known/web-identity viene ignorato quando la parte soggetta a limitazioni e l'IdP sono lo stesso sito. Inoltre, è ora possibile impostare uno stato di accesso tramite un'intestazione di risposta HTTP dalla risorsa secondaria IdP dello stesso sito.