Aggiornamenti di FedCM: prova dell'origine dell'API Button Mode, CORS e SameSite

Eiji Kitamura

Da Chrome 125, l'API Button Mode sta avviando una prova dell'origine su computer. Con l'API Button Mode, i provider di identità possono utilizzare l'API FedCM anche se i loro utenti non hanno sessioni IdP attive al momento della chiamata API. Gli utenti possono quindi accedere a un sito web con il proprio account federato senza essere spostati sul sito dell'IdP. L'UI di FedCM in modalità pulsante è più in evidenza rispetto a quella del flusso dei widget esistente perché è controllata da un gesto dell'utente e riflette meglio l'intenzione dell'utente di accedere.

API Button Mode

L'interfaccia utente di FedCM è disponibile sotto forma di widget visualizzato nell'angolo in alto a destra sui computer o come riquadro inferiore sui dispositivi mobili, non appena viene richiamata l'API, ovvero quando l'utente arriva sulla parte richiedente. Questa è chiamata modalità widget. Per visualizzare il widget, l'utente deve aver eseguito l'accesso all'IdP prima di arrivare alla parte soggetta a limitazioni. FedCM di per sé non aveva un modo affidabile per consentire all'utente di accedere all'IdP prima di consentirgli di accedere alla parte soggetta a limitazioni utilizzando l'account disponibile nell'IdP. FedCM sta per aggiungere un modo per farlo.

Con la modalità widget, nell'angolo in alto a destra della versione desktop di Chrome viene visualizzata una finestra di dialogo senza l'attivazione da parte dell'utente.

La nuova API Button Mode aggiunge una nuova modalità UI denominata modalità button. A differenza della modalità widget, la modalità pulsante non deve essere richiamata non appena l'utente ottiene la parte soggetta a limitazioni. Deve invece essere richiamato quando l'utente avvia un flusso di accesso, ad esempio premendo un pulsante "Accedi con IdP".

Appena il pulsante viene premuto, FedCM controlla se l'utente ha eseguito l'accesso all'IdP tramite un recupero all'endpoint degli account o uno stato di accesso memorizzato nel browser. Se l'utente non ha ancora eseguito l'accesso, FedCM chiede all'utente di accedere all'IdP utilizzando una finestra popup per mezzo di login_url fornito dall'IdP. Se il browser sa che l'utente ha già eseguito l'accesso all'IdP o non appena l'utente accede all'IdP con la finestra popup, FedCM apre una finestra di dialogo modale in cui l'utente può scegliere un account IdP con cui accedere. Selezionando un account, l'utente può accedere alla RP utilizzando l'account IdP.

Con la modalità pulsante, viene visualizzata una finestra di dialogo modale in alto al centro su Chrome su desktop.

Prova anche tu con Chrome 125 all'indirizzo https://fedcm-rp-demo.glitch.me/button_flow.

Un utente accede alla parte soggetta a limitazioni utilizzando l'API Button Mode.

Per utilizzare l'API Button Mode:

• Attiva la funzionalità sperimentale FedCmButtonMode in chrome://flags.
• Assicurati di richiamare l'API dietro attivazione temporanea dell'utente, ad esempio un clic su un pulsante.
• Richiama l'API con il parametro mode in questo modo:

  return await navigator.credentials.get({
    identity: {
      providers: [{
        configURL: "https://idp.example/config.json",
        clientId: "123",
        nonce:"456",
      }],
      mode: "button"
    }
  });

Nota: al momento Chrome supporta solo "button" nella nuova proprietà mode. Altre proprietà come "widget" verranno aggiunte quando Chrome spedisce questa funzionalità.

Il browser invierà un nuovo parametro all'endpoint di asserzione ID che rappresenta il tipo di richiesta mediante l'inclusione di mode=button:

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=Ct60bD&disclosure_text_shown=true&is_auto_selected=false&mode=button

Nota: quando si verifica un problema, la chiamata all'API FedCM che utilizza la modalità pulsante risponde immediatamente, mentre con la modalità widget ritarda la risposta intenzionalmente. Questo perché lo stato di accesso dell'utente all'IdP è considerato come informazioni private e l'invio di un indicatore di errore fornisce presto alla RP un suggerimento sullo stato di accesso dell'IdP. Con la modalità a pulsante, all'utente viene chiesto di accedere comunque all'IdP, senza preoccuparsi di esporre lo stato di accesso dell'IdP alla parte soggetta a limitazioni.

Nota: gli utenti possono disattivare la modalità del widget FedCM nelle impostazioni di Chrome. Questo non interessa l'API Button Mode perché la richiesta di accesso viene avviata da un gesto utente e il browser dovrebbe assistere gli utenti a completare il flusso di accesso.

Usa un'altra opzione per l'account

La parte soggetta a limitazioni può consentire agli utenti di "utilizzare altri account" nel selettore account, ad esempio quando gli IdP supportano più account o sostituiscono l'account esistente.

Per attivare l'opzione per utilizzare un altro account:

• Abilita la funzionalità sperimentale FedCmUseOtherAccount in chrome://flags o registra la prova dell'origine dell'API Button Mode.
• L'IdP specifica quanto segue nel file di configurazione IdP:

{
  "accounts_endpoint" : ...,
  "modes: {
    "button": {
      "supports_use_other_account": true,
    }
  }
}

Partecipare alla prova dell'origine

Puoi provare l'API Button Mode in locale attivando un flag di Chrome chrome://flags#fedcm-button-mode su Chrome 125 o versioni successive.

Gli IdP possono anche attivare la modalità pulsante registrando una prova dell'origine:

• Registra una prova dell'origine di terze parti per la parte soggetta a limitazioni.

Le prove dell'origine ti consentono di provare nuove funzionalità e fornire feedback sulla loro usabilità, praticità ed efficacia alla community degli standard web. Per ulteriori informazioni, consulta la Guida alle prove dell'origine per sviluppatori web.

La prova dell'origine dell'API Button Mode è disponibile da Chrome 125 a Chrome 127.

1. Vai alla pagina di registrazione della prova dell'origine.
2. Fai clic sul pulsante Registrati e compila il modulo per richiedere un token.
3. Inserisci l'origine dell'IdP come Origine web.
4. Seleziona la corrispondenza di terze parti per inserire il token con JavaScript su altre origini.
5. Fai clic su Invia.
6. Incorpora il token emesso su un sito web di terze parti.

Per incorporare il token su un sito web di terze parti, aggiungi il codice seguente alla libreria JavaScript o all'SDK dell'IdP pubblicato dall'origine dell'IdP.

const tokenElement = document.createElement('meta');
tokenElement.httpEquiv = 'origin-trial';
tokenElement.content = 'TOKEN_GOES_HERE';
document.head.appendChild(tokenElement);

Sostituisci TOKEN_GOES_HERE con il tuo token.

Nota: se l'API FedCM viene richiamata dalla parte soggetta a limitazioni, non tramite script caricato dall'IdP, quest'ultima deve registrare l'origine autonomamente ed eseguire la prova dell'origine proprietaria.

CORS e SameSite=None saranno necessari in Chrome 125

CORS

Chrome applicherà CORS all'endpoint assertion ID a partire da Chrome 125.

CORS (Cross-Origin-Resource-Sharing) è un sistema costituito dalla trasmissione di intestazioni HTTP che determina se i browser impediscono al codice JavaScript di frontend di accedere alle risposte per le richieste multiorigine. L'endpoint dell'asserzione ID sul server IdP deve rispondere alla richiesta con intestazioni aggiuntive. Di seguito è riportato un esempio di intestazione della risposta a una richiesta di https://fedcm-rp-demo.glitch.me:

Access-Control-Allow-Origin: https://fedcm-rp-demo.glitch.me
Access-Control-Allow-Credentials: true

Nota: poiché Access-Control-Allow-Credentials è impostato su true, Access-Control-Allow-Origin deve restituire un dominio in modo esplicito e non può utilizzare un carattere jolly indicato da *.

SameSite=Nessuno

Il parametro SameSite dei cookie dichiara se il cookie è limitato a un contesto proprietario o dello stesso sito. Se specifichi che è None, il cookie può essere inviato a un dominio di terze parti.

In FedCM, Chrome invia i cookie all'endpoint account, all'endpoint di asserzione ID e all'endpoint di disconnessione. A partire da Chrome 125, Chrome invierà le richieste con credenziali con solo i cookie contrassegnati esplicitamente come SameSite=None.