Aggiornamenti di FedCM: API Disconnetti e due aggiornamenti

Eiji Kitamura

Da Chrome 122, l'API Disconnetti per Credenziale federata L'API di gestione (FedCM) è disponibile. La L'API Disconnetti consente alle parti coinvolte di disconnettere i propri utenti l'account del provider di identità senza fare affidamento su cookie di terze parti. Inoltre, sono un paio di aggiornamenti alla gestione dello stesso sito di FedCM.

API Disconnetti

Quando un utente crea un account su una parte coinvolta (RP, il sito utilizzando il provider di identità per l'autenticazione) tramite la federazione delle identità, IdP (il servizio che fornisce informazioni sull'account e sull'autenticazione). ad altre parti) registra generalmente la connessione sul proprio server. Lo spazio di archiviazione consente all'IdP di tenere traccia delle parti soggette a limitazioni a cui l'utente ha eseguito l'accesso ottimizzare la propria esperienza. Ad esempio, per avere un'esperienza migliore quando in seguito torna alla parte soggetta a limitazioni, l'account utente con l'IdP viene considerato di ritorno sull'account, il che consente funzionalità quali la riautenticazione automatica 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 il 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 è disponibile API per la disconnessione della parte soggetta a limitazioni dall'IdP. Poiché possono esserci più IdP dello stesso IdP collegato a una determinata parte soggetta a limitazioni, il flusso di disconnessione per sapere quale account viene scollegato.

La disconnessione dell'API consente all'utente di disconnettere l'account IdP dalla parte soggetta a limitazioni sul browser, a quello del server IdP, segnalandolo all'endpoint specificato. L'utente ha bisogno di aver superato la federazione delle identità utilizzando la credenziale federata l'API di gestione (FedCM). Una volta disconnesso, l'utente viene considerato come un nuovo utente la volta successiva che tenta di accedere alla parte soggetta a limitazioni utilizzando l'IdP.

Scollega 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, viene memorizzata dal browser localmente come elenco . La parte soggetta a limitazioni può avviare una disconnessione richiamando il metodo Funzione IdentityCredential.disconnect(). Questa funzione può essere chiamata da un frame RP di primo livello. La parte soggetta a limitazioni deve superare un configURL, il valore clientId che usa nell'IdP e un accountHint per la disconnessione dell'IdP. Un account il hint 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 corrisponda 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ò generare 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.
• configURL non è valido o manca l'endpoint di disconnessione.
• Controllo del Criterio di sicurezza del contenuto (CSP) non riuscito.
• Esiste una richiesta di disconnessione in attesa.
• L'utente ha disattivato FedCM nelle impostazioni del browser.

Quando l'endpoint di disconnessione dell'IdP restituisce un personalizzata, la parte soggetta a limitazioni e l'IdP sono disconnessi del browser e la promessa viene risolta. Gli account utente che si disconnettono specificato nella risposta alla disconnessione endpoint.

Configura il file di configurazione dell'IdP

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

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

Disconnetti l'account sull'endpoint di disconnessione

Se richiama IdentityCredential.disconnect(), il browser invia una richiesta multiorigine Richiesta POST con cookie e un tipo di contenuti application/x-www-form-urlencoded a questo endpoint di disconnessione con le seguenti informazioni:

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:

1. Rispondere alla richiesta con CORS (risorsa interorigine) condivisione).
2. Verifica che la richiesta contenga un'intestazione HTTP Sec-Fetch-Dest: webidentity.
3. Abbina l'intestazione Origin all'origine della parte soggetta a limitazioni determinata dal client_id. Rifiuta se non corrispondono.
4. Trova l'account che corrisponde a account_hint.
5. Scollega l'account utente dall'elenco degli account collegati della parte soggetta a limitazioni.
6. Rispondi al browser con il account_id dell'utente identificato in un file JSON formato.

Un esempio di payload JSON di risposta è simile al seguente:

{
  "account_id": "account456"
}

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

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

Durante lo sviluppo di un sistema FedCM, i domini dei server RP in fase di test o gestione temporanea potrebbero essere la nei sottodomini del server IdP di produzione. Ad esempio, il server IdP di produzione si trova all'indirizzo idp.example e sia il server RP temporaneo sia il server IdP temporaneo si trovano alle ore staging.idp.example. Tuttavia, poiché il file noto deve essere posizionato alla radice dell'eTLD+1 del server IdP, deve trovarsi idp.example/.well-known/web-identity ed è il server di produzione. Dal giorno non è necessariamente possibile per gli sviluppatori inserire file nell'ambiente di produzione, in fase di sviluppo, questo impedisce loro di testare FedCM.

A partire da Chrome 122, se il dominio RP e quello IdP sono uguali, Chrome salta il controllo del file noto. In questo modo, gli sviluppatori potranno eseguire test questo scenario.

Ora le sottorisorse possono impostare lo stato di accesso allo stesso sito

In precedenza, Chrome consentiva di impostare soltanto l'accesso standard (ad ad esempio utilizzando l'intestazione Set-Login: logged-in) quando la richiesta è stessa origine con tutti i predecessori. Questo ha impedito gli accessi tramite stesso sito Richieste di fetch() che impostano lo stato di accesso.

Ad esempio, pensa a un sito web che consenta agli utenti di inserire il proprio nome utente password su idp.example, ma le credenziali vengono pubblicate su login.idp.example con fetch(). Registrazione dello stato di accesso nel browser utilizzando lo stato di accesso L'API non è stata possibile perché i due domini sono multiorigine e nello stesso sito.

Con questa modifica abbiamo allentato il requisito che richiede che l'API Login Status il stesso sito con tutti i predecessori e rende possibile l'impostazione dell'esempio precedente 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 sui cookie di terze parti. A questo scopo, chiama 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 connessione sul server e poi sul browser.

Abbiamo annunciato che il controllo /.well-known/web-identity è stato ignorato al momento della parte soggetta a limitazioni e l'IdP si trovano nello stesso sito, a scopo di test. Inoltre, l'impostazione di dati di accesso tramite un'intestazione della risposta HTTP dalla risorsa secondaria IdP dello stesso sito è ora possibile.