Spiegazione tecnica della Conditional UI di WebAuthn (Passkeys Autofill)

Cheatsheet Passkeys. Guide pratiche, pattern di distribuzione e KPI per programmi passkey.

Ottieni la cheatsheet

Con la rapida adozione delle passkey (e del protocollo WebAuthn sottostante), l'autenticazione è diventata più sicura e intuitiva per molti utenti. Uno dei progressi più evidenti delle passkey è stata l'integrazione della Conditional UI, spesso denominata "riempimento automatico passkey" o Mediazione Condizionale (di seguito manterremo il termine Conditional UI).

Nonostante la sua recente introduzione e la continua adozione da parte dei browser, c'è una notevole lacuna nella documentazione tecnica e nei consigli di implementazione per la Conditional UI. Questo articolo mira a colmare tale lacuna spiegando cos'è la Conditional UI, come funziona e come affrontare le sfide comuni durante la sua implementazione.

La Conditional UI rappresenta una nuova modalità per i processi di login tramite passkey / WebAuthn. Mostra selettivamente le passkey in un'interfaccia utente (UI) solo quando un utente ha una credenziale rilevabile (chiave residente), che è un tipo di passkey, registrata presso la relying party (il servizio online) e memorizzata nel suo autenticatore di un dispositivo (ad es. laptop, smartphone). Le passkey vengono visualizzate in un menu a discesa di selezione che si mescola con le password riempite automaticamente, fornendo una transizione senza interruzioni tra i sistemi di password tradizionali e l'avanzata autenticazione tramite passkey, in quanto gli utenti vedono entrambe nello stesso contesto. Questo approccio intelligente assicura che gli utenti non siano sopraffatti da opzioni inutili e possano navigare nel processo di login in modo più fluido.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

Le basi della Conditional UI si fondano su tre pilastri principali:

1. Rispetto della privacy dell'utente: Garantire la privacy dell'utente impedendo la divulgazione delle credenziali disponibili o la mancanza di consenso dell'utente per rivelare tali credenziali.
2. Ottima esperienza utente anche in assenza di passkey: Consentire alle relying party di implementare WebAuthn in modo opportunistico, assicurando che l'esperienza utente rimanga buona anche se le passkey non sono disponibili.
3. Transizione fluida dalle password alle passkey: Combinare le passkey con l'autenticazione basata su password per agevolare la transizione verso metodi di autenticazione senza password, sfruttando i paradigmi UX familiari agli utenti.

• Autenticazione semplificata: Il processo è più semplice ed efficiente, eliminando le complessità spesso associate all'utilizzo di metodi di autenticazione multipli.
• Riduzione degli errori degli utenti: Presentando solo le opzioni rilevanti, gli utenti sono meno inclini a commettere errori durante il processo di autenticazione.
• Migliore soddisfazione degli utenti: Rimuovere i passaggi non necessari significa che gli utenti possono accedere in modo più rapido e agevole, portando a una migliore soddisfazione.
• Semplice integrazione frontend: Una delle caratteristiche distintive della Conditional UI è la sua facilità di integrazione. Gli sviluppatori possono incorporarla in modo fluido nel frontend con poche righe di codice (vedi sotto).
• Login senza password e senza nome utente: Uno degli enormi vantaggi è che la Conditional UI promuove non solo l'autenticazione senza password, ma anche un'esperienza senza nome utente o senza account. Agli utenti viene risparmiato il carico mentale di ricordare il loro specifico indirizzo e-mail o il loro nome utente dalla fase di registrazione. Al contrario, possono fare affidamento sui suggerimenti del browser, che includono l'indirizzo e-mail o il nome utente associati alla passkey corrispondente nel menu di riempimento automatico.
• Risoluzione del dilemma dell'avvio: Passare dai tradizionali sistemi di nome utente e password alle passkey può essere scoraggiante. La Conditional UI affronta questa sfida di transizione. I siti web possono avviare una chiamata per passkey / WebAuthn insieme a un prompt per la password convenzionale senza preoccuparsi di potenziali errori della finestra di dialogo modale se un dispositivo non dispone delle credenziali necessarie.

Iscriviti al nostro Substack sulle passkey per le ultime novità.

Iscriviti

• Curva di apprendimento per gli sviluppatori: La Conditional UI introduce un nuovo paradigma, il che significa che c'è una curva di apprendimento per gli sviluppatori che non hanno familiarità con le sue complessità.
• Dipendenza dal dispositivo o dal browser: Il successo della Conditional UI dipende dalla compatibilità del dispositivo o del browser dell'utente. Poiché al momento non tutti i browser o dispositivi la supportano, ciò può limitarne l'applicazione.
• Gestori di password disabilitano il completamento automatico: Alcuni moderni gestori di password e le relative estensioni del browser modificano il DOM dei siti web e disabilitano o sovrascrivono il tag autocomplete nei campi di input a favore delle proprie funzionalità di completamento automatico. Questo può portare a un'esperienza utente incoerente e insoddisfacente. Poiché gli standard per la Conditional UI sono relativamente nuovi, speriamo che le cose migliorino, in modo che ad esempio non vengano sovrapposti due menu di riempimento automatico o che quello desiderato non venga mostrato affatto.

Di seguito, forniamo una ripartizione passo dopo passo delle singole fasi di un intero flusso della Conditional UI:

In generale, il flusso di processo della Conditional UI può essere suddiviso in due fasi. Durante la fase di caricamento della pagina, la logica della Conditional UI avviene in background, mentre nella fase operativa dell'utente, l'utente deve attivamente fare qualcosa.

1. Controllo della disponibilità della Conditional UI: Il client (browser) chiama la funzione isConditionalMediationAvailable() per rilevare se l'attuale combinazione di browser e dispositivo supporta la Conditional UI. Il processo continua solo se la risposta è true, altrimenti il processo della Conditional UI viene interrotto.
2. Chiamata all'endpoint della Conditional UI: Successivamente, il client chiama l'endpoint della Conditional UI del server per recuperare le PublicKeyCredentialRequestOptions.
3. Ricezione delle PublicKeyCredentialRequestOptions: Il server restituisce le PublicKeyCredentialRequestOptions che contengono la challenge e altre opzioni server WebAuthn (ad es. allowCredentials, extensions, userVerification).
4. Avvio dell'autenticazione locale: Chiamando credentials.get() con le PublicKeyCredentialRequestOptions ricevute e la proprietà mediation impostata su conditional, si avvia il processo per l'autenticazione locale sul dispositivo.
5. Visualizzazione della selezione di riempimento automatico: Appare il menu a discesa per le passkey. Lo stile specifico dipende dal browser e dal dispositivo (ad es. alcuni richiedono all'utente di posizionare il cursore nel campo di input, altri mostrano automaticamente il menu al caricamento della pagina, vedi sotto).
6. Autenticazione utente locale: L'utente seleziona dal menu di riempimento automatico la passkey che desidera utilizzare ed effettua l'autenticazione tramite la finestra di dialogo del suo dispositivo (ad es. tramite Face ID, Touch ID, Windows Hello).
7. Invio della risposta dell'autenticatore al server: Se l'autenticazione dell'utente a livello locale ha avuto esito positivo, la risposta dell'autenticatore viene rinviata al server.
8. Utente autenticato e reindirizzato: Una volta che il server riceve la risposta dell'autenticatore, convalida la firma rispetto alla chiave pubblica dell'account utente corrispondente nel database. Se la verifica ha esito positivo, all'utente viene concesso l'accesso, è connesso e viene reindirizzato alla pagina dopo l'accesso.

Seguendo questo flusso di processo, la Conditional UI offre un'esperienza di autenticazione fluida e intuitiva per l'utente.

Per far funzionare la Conditional UI, devono essere considerati alcuni aspetti generali:

• Specifiche delle credenziali: La Conditional UI è specificamente progettata per funzionare solo con chiavi residenti o credenziali rilevabili. Il motivo alla base è che gli autenticatori non memorizzano dati specifici dell'utente (ad es., nome, nome visualizzato) per chiavi non residenti o credenziali non rilevabili. Di conseguenza, utilizzare queste ultime per il riempimento automatico passkey non è possibile.
• Filtraggio delle credenziali: La funzionalità allowCredentials rimane supportata, facilitando i siti web che sono già a conoscenza dell'identità dell'utente (ad esempio, se è stato inviato un nome utente nella chiamata iniziale di mediazione perché potrebbe essere memorizzato nel LocalStorage del browser) nel perfezionare l'elenco di credenziali mostrato agli utenti durante il riempimento automatico.

Entra nella nostra community passkeys per aggiornamenti e supporto.

Unisciti

Per far funzionare la Conditional UI sul lato client, devono essere soddisfatti i seguenti requisiti:

• Browser compatibile: Assicurarsi che l'utente utilizzi un browser moderno che supporti la Conditional UI (vedi qui per l'ultima copertura dei browser).
• JavaScript abilitato: JavaScript deve essere abilitato per facilitare le operazioni della Conditional UI.
• Testare la disponibilità della Conditional UI: La relying party (il lato server) dovrebbe avere la certezza che la Conditional UI sia disponibile sul lato client, quando riceve la chiamata di mediazione WebAuthn per evitare di attivare eventuali errori visibili all'utente in scenari in cui la Conditional UI non è supportata. Per affrontare questo aspetto, è consigliato utilizzare il metodo isConditionalMediationAvailable() e verificare la disponibilità tecnica della Conditional UI (vedi sotto per maggiori dettagli).
• Campo di input HTML richiesto: Affinché la Conditional UI funzioni, è necessario disporre di un campo di input HTML nella propria pagina web. Se non se ne possiede uno, è necessario fornire supporto per il normale processo di login tramite passkey / WebAuthn attivato con un'interazione dell'utente, come il clic su un pulsante.
• Rimozione dei protocolli di timeout: I parametri di timeout (ad es. l'utente impiega molto tempo per decidere una passkey nel menu di riempimento automatico) dovrebbero essere ignorati in questa configurazione.

Per far funzionare la Conditional UI, devono essere soddisfatti alcuni requisiti anche sul lato server:

• Server WebAuthn in esecuzione: Poiché siamo ancora nel contesto delle passkey / WebAuthn, è necessario avere un server WebAuthn in esecuzione che gestisca le procedure di autenticazione.
• Fornire un endpoint di avvio della mediazione: Rispetto ai normali endpoint di login WebAuthn, è utile fornire un altro endpoint che abbia funzionalità simili ma che possa gestire un nome utente opzionale (ad es. indirizzo e-mail, numero di telefono, nome utente).

Dal rilascio ufficiale della Conditional UI alla fine del 2022 e dalle precedenti versioni beta, abbiamo testato e lavorato intensamente con essa. Di seguito, vogliamo condividere con voi suggerimenti pratici che ci hanno aiutato durante l'implementazione della Conditional UI.

Sperimenta i flussi passkey nel Passkeys Debugger.

Prova gratis

Un esempio di codice completo e minimalista per un metodo di Conditional UI si presenterebbe in questo modo:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // recupera le opzioni della richiesta (inclusa la challenge) dal server WebAuthn
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

Implementare il rilevamento della Conditional UI che assicuri che essa venga impiegata solo quando la combinazione di dispositivo e browser corrente la supporta. Questo dovrebbe funzionare senza presentare errori visibili all'utente in assenza di supporto per la Conditional UI. Incorporare il metodo isConditionalMediationAvailable() all'interno dell'interfaccia utente risolve questo problema. Se il supporto per la Conditional UI è presente, il processo di login della Conditional UI può essere avviato.

// source: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples
 
// Availability of `window.PublicKeyCredential` means WebAuthn is usable.
if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) {
    // Check if conditional mediation is available.
    const isCMA = await PublicKeyCredential.isConditionalMediationAvailable();
    if (isCMA) {
        // Call WebAuthn authentication start endpoint
 
        let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
        const credential = await navigator.credentials.get({
            publicKey: options.publicKeyCredentialRequestOptions,
            mediation: "conditional",
        });
        /*
        ...
        */
    }
}

Il campo di input dovrebbe ricevere un token HTML autofill per webauthn. Questo segnala al client di inserire le passkey nella richiesta in corso. Oltre alle passkey, potrebbero essere mostrati anche altri valori di riempimento automatico. Questi token di riempimento automatico possono essere accoppiati con altri token esistenti, ad es.:

• autocomplete="username webauthn": Oltre a visualizzare le passkey, questo suggerisce anche il riempimento automatico del nome utente.
• autocomplete="current-password webauthn": Oltre a visualizzare le passkey, questo richiede anche il riempimento automatico della password.

<label for="name">Nome utente:</label>
<input type="text" name="name" autocomplete="username webauthn" />
<label for="password">Password:</label>
<input type="password" name="password" autocomplete="current-password webauthn" />

Per maggiori dettagli, consigliamo di leggere questo post del blog che fornisce maggiori informazioni sui token di riempimento automatico / completamento automatico per passkey e password.

Per recuperare le passkey disponibili dopo aver ricevuto l'oggetto PublicKeyCredentialRequestOptions, dovrebbe essere chiamata la funzione navigator.credentials.get() (che serve sia passkey che password). L'oggetto PublicKeyCredentialRequestOptions deve avere il parametro mediation impostato su conditional per attivare la Conditional UI sul client. Per i casi in cui si desidera invece un prompt per la passkey modale, vedere la mediazione immediata.

const credential = await navigator.credentials.get({
    publicKey: options.publicKeyCredentialRequestOptions,
    mediation: "conditional",
});

Se non vi è alcuna passkey disponibile, o se l'utente ignora le passkey suggerite e inserisce la propria e-mail, il flusso della Conditional UI viene interrotto. Ciò sottolinea l'importanza di supportare sempre anche il normale processo di login tramite passkey / WebAuthn via finestra modale.

Un punto critico da sottolineare qui è la potenziale necessità di interrompere una richiesta di Conditional UI in corso. A differenza delle esperienze modali, i menu a discesa per il riempimento automatico mancano di un pulsante di annullamento. Secondo la progettazione di WebAuthn, solo una singola richiesta attiva di credenziali dovrebbe essere in corso in un dato momento. Lo standard WebAuthn suggerisce l'uso di un AbortController per annullare un processo WebAuthn, applicabile sia ai processi di login regolari che a quelli tramite Conditional UI (vedere qui per i dettagli).

Nella telemetria di produzione, questo percorso di annullamento è spesso un esito previsto del flusso di controllo, non un guasto del sistema. Se si osservano volumi elevati di errori, è necessario classificare i casi attesi da quelli imprevisti per tipo di operazione e tempistiche prima di trattarli come regressioni (vedere gli errori WebAuthn).

Il processo di login tramite Conditional UI si attiva non appena un utente accede alla pagina. L'attività iniziale dovrebbe essere quella di creare un oggetto AbortController con ambito globale. Questo agirà come segnale per il client per terminare la richiesta di riempimento automatico, in particolare se l'utente decide di eseguire il normale processo di login tramite passkey. Assicurarsi che l'AbortController possa essere invocato da altre funzioni e che venga ripristinato se il processo della Conditional UI deve essere riavviato. Utilizzare la proprietà signal all'interno della chiamata navigator.credentials.get(), incorporando il segnale dell'AbortController come suo valore. Questo segnala alla funzione per passkey / WebAuthn che la richiesta deve essere interrotta se il segnale viene annullato. Ricordarsi di impostare un nuovo AbortController ogni volta che si attiva la Conditional UI. L'utilizzo di un AbortController già annullato porterà all'annullamento immediato della funzione passkey / WebAuthn. I restanti passaggi sono in linea con un normale processo di login tramite passkey. Di seguito viene riportato un esempio di codice dei passaggi menzionati:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // recupera le opzioni della richiesta (inclusa la challenge) dal server WebAuthn
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

In assenza di supporto per la Conditional UI, indirizzare gli utenti verso il normale processo di login tramite passkey. Offrire questo percorso è importante per gli utenti che si affidano a chiavi di sicurezza hardware (ad es. YubiKey) o per coloro che sono costretti a utilizzare chiavi non residenti o credenziali non rilevabili a causa dei vincoli dell'autenticatore.

Scopri quante persone usano davvero le passkey.

Vedi dati di adozione

Quando si sviluppa un'app nativa, ad es. per iOS o Android, funziona anche la Conditional UI. Non importa se la si implementa nativamente in Flutter, Kotlin o Swift, o se si decide di utilizzare Chrome Custom Tabs CCT o SFSafariViewController o SFAuthenticationSession / ASWebAuthenticationSession. Entrambi gli approcci supportano la Conditional UI.

In generale, non abbiamo trovato quasi nessuna documentazione su come implementare il supporto alla Conditional UI per le app iOS. Tuttavia, durante le nostre ricerche, abbiamo scoperto due modi per aggiungere il supporto alla Conditional UI in un'app iOS, poiché anche l'esperienza utente sarà diversa.

Tipo A: Sovrapposizione / Popup su quasi tutto lo schermo

Il primo tipo A mostra una sovrapposizione o popup che si estende su quasi l'intero schermo. Qui, verranno visualizzate tutte le passkey disponibili per questa relying party. Un esempio noto che implementa la Conditional UI in questo modo è KAYAK. L'overlay o popup appare automaticamente quando l'utente apre la schermata corretta.

Tipo B: Riempimento automatico da tastiera

Il secondo tipo B visualizza una passkey adatta nella sezione di riempimento automatico della tastiera (dove vengono suggerite anche le password). Cliccando sul valore suggerito verrà eseguita l'autenticazione tramite Face ID e si accederà all'applicazione. Nell'attuale versione dell'app iOS del pannello per sviluppatori Corbado, lo abbiamo implementato in questo modo (si veda il messaggio Accedi con passkey per <relying party ID> insieme al nome utente WebAuthn). Per comparire, l'utente deve toccare all'interno del campo di input:

Questa funzione di riempimento automatico della passkey nella sezione della tastiera potrebbe presentare dei problemi quando iOS è stato appena installato poiché, apparentemente, si verifica in background un qualche tipo di memorizzazione nella cache che ricerca tutte le passkey disponibili per questa relying party.

Cliccando sull'icona a forma di chiave alla destra della passkey suggerita si accede alla nota schermata per la scelta di password o passkey in iOS:

Si prega di notare che non abbiamo trovato alcuna documentazione ufficiale e le nostre considerazioni si basano su nostre esperienze ed ipotesi piuttosto che su prove concrete della corretta implementazione.

In Android, la situazione per la Conditional UI è un po' più chiara, in quanto esiste un solo tipo per la Conditional UI e il riempimento automatico delle passkey che sfrutta l'API Android Credential Manager (vedere la documentazione qui). Poiché i provider su Android possono differire, monitorare gli errori relativi alle passkey nel Credential Manager separatamente rispetto ai pattern di errore WebAuthn validi solo per il browser.

L'apertura della pagina in cui è implementata la Conditional UI mostra la seguente schermata, in cui si troveranno diversi modi per accedere:

Facendo clic su Altri accessi salvati si ottengono ulteriori opzioni tra cui scegliere per l'accesso (inclusa l'autenticazione tra dispositivi e la selezione di una piattaforma di sincronizzazione passkey diversa, ad es. Samsung Pass o 1Password):

Per illustrare come appare la Conditional UI all'utente finale, abbiamo aggiunto diversi screenshot di un menu di riempimento automatico in Conditional UI utilizzando https://passkeys.eu.

Prova le passkey in una demo live.

Prova le passkey

Diamo un'occhiata ad alcuni scenari comuni in applicazioni di vita reale.

Se non è stata salvata alcuna passkey per un sito, la Conditional UI si comporterà in modo diverso a seconda del browser e del sistema operativo.

Su Chrome su macOS, facendo clic nel campo di input, viene visualizzato un menu a discesa per il riempimento automatico vuoto:

Su Safari su macOS, non viene visualizzato alcun menu a discesa: solo un'icona sottile nel campo di input:

Su Android o iOS, l'interfaccia di riempimento automatico appare solo se l'utente tocca il campo e il sistema operativo trova delle credenziali corrispondenti.

Questa variabilità è intenzionale ed è parte integrante del modello di privacy di WebAuthn: i siti web non possono rilevare se l'utente possiede una passkey, a meno che non ne selezioni attivamente una.

Se un utente ha installato più provider di passkey (ad es. Portachiavi iCloud, Google Password Manager, 1Password), il browser o il sistema operativo passerà solitamente al gestore delle credenziali principale dell'utente come impostazione predefinita.

Per un elenco di diversi provider di passkey o gestori delle credenziali che supportano le passkey, ti consigliamo di dare un'occhiata al seguente collegamento GitHub.

Su Android, il Credential Manager espone diversi provider, come Samsung Pass o 1Password.

1. Cliccando nel campo di immissione dell'identificativo utente, appare questo menu in cui l'utente può selezionare una passkey.

2. Se l'utente ha fatto clic su "Altre passkey" nella schermata precedente, compare una preselezione di altri gestori di credenziali, provider di passkey e altre passkey:

3. Se l'utente ha fatto clic su "Altri accessi salvati" nella schermata precedente, si apre un intero elenco da cui è possibile selezionare una passkey.

Su iOS, l'icona della chiave apre l'elenco completo delle passkey provenienti da diverse fonti.

1. All'inizio, su iOS 18 e versioni successive, appare la normale Conditional UI con il provider di passkey predefinito.

2. Cliccando sull'icona della tastiera, viene visualizzato il seguente menu di selezione.

3. Dopo aver selezionato un gestore di credenziali o un provider di passkey, l'utente può selezionare la passkey da utilizzare.

Le passkey, con la loro funzionalità di Conditional UI per il riempimento automatico, rappresentano il nuovo modo di autenticarsi online. Poiché stiamo passando a un'era in cui le password vengono sempre più sostituite dalle passkey, la necessità di meccanismi di transizione solidi e intuitivi è innegabile. Questo articolo ha aiutato a capire come implementare correttamente la Conditional UI, di grande aiuto nel processo di transizione, e a quali aspetti prestare particolare attenzione.

Chi siamo

Corbado è la Authentication Intelligence Platform per i team CIAM che gestiscono l'autenticazione consumer su larga scala. Ti aiutiamo a vedere ciò che i log IDP e gli strumenti di analytics generici non mostrano: quali dispositivi, versioni di OS, browser e gestori di credenziali supportano i passkey, perché gli enrollment non si trasformano in login, dove il flusso WebAuthn fallisce e quando un aggiornamento di OS o browser interrompe silenziosamente il login — tutto senza sostituire Okta, Auth0, Ping, Cognito o il tuo IDP interno. Due prodotti: Corbado Observe aggiunge osservabilità per i passkey e qualsiasi altro metodo di login. Corbado Connect introduce passkey gestiti con analytics integrato (insieme al tuo IDP). VicRoads gestisce i passkey per oltre 5M di utenti con Corbado (+80 % di attivazione passkey). Parla con un esperto di Passkey →

Chiama PublicKeyCredential.isConditionalMediationAvailable() e procedi solo se restituisce true. Questo controllo previene errori visibili all'utente su combinazioni di browser e dispositivi non supportate. Il metodo dovrebbe essere valutato a ogni caricamento della pagina prima di chiamare navigator.credentials.get() con mediation: "conditional".

Gli autenticatori memorizzano dati specifici dell'utente come nome e nome visualizzato solo per le chiavi residenti (credenziali rilevabili). Le chiavi non residenti non conservano queste informazioni, quindi il menu di riempimento automatico non può popolare i dettagli dell'account affinché l'utente possa selezionarli.

Il comportamento varia a seconda della piattaforma. Chrome su macOS mostra un menu a discesa di riempimento automatico vuoto, Safari su macOS mostra solo una piccola icona nel campo di input, e su Android o iOS l'interfaccia di riempimento automatico appare solo se il sistema operativo trova credenziali corrispondenti dopo che l'utente ha toccato il campo. Questa variabilità è intenzionale e fa parte del modello di privacy di WebAuthn: i siti web non possono rilevare se esiste una passkey a meno che l'utente non ne selezioni attivamente una.

Crea un AbortController con ambito globale e passa il suo segnale a navigator.credentials.get(). Chiama .abort() sul controller quando l'utente avvia un flusso di login modale. Istanzia sempre un nuovo AbortController ogni volta che la Conditional UI si riavvia, perché riutilizzare un controller già annullato causa la cancellazione immediata della richiesta WebAuthn.

La Conditional UI funziona in entrambe le app native per iOS e Android. iOS supporta due varianti: un popup in sovrimpressione a schermo intero e un suggerimento di riempimento automatico sulla tastiera. Android utilizza l'API Credential Manager, che può mostrare passkey di vari provider come Samsung Pass o 1Password.