---
url: 'https://www.corbado.com/it/blog/spiegazione-tecnica-conditional-ui-webauthn-passkeys-autofill'
title: 'Spiegazione tecnica della Conditional UI di WebAuthn (Passkeys Autofill)'
description: 'La Conditional UI (Mediazione Condizionale o Riempimento automatico passkey) è una nuova funzionalità delle passkey. Questo articolo spiega cos''è, come funziona e come implementarla.'
lang: 'it'
author: 'Vincent Delitz'
date: '2026-07-03T07:10:05.823Z'
lastModified: '2026-07-03T07:11:02.903Z'
keywords: 'passkey autofill, riempimento automatico passkey, conditional mediation, conditional ui, webauthn, login senza password'
category: 'WebAuthn Know-How'
---
# Spiegazione tecnica della Conditional UI di WebAuthn (Passkeys Autofill)
## Key Facts
- Le **credenziali rilevabili (chiavi residenti)** sono necessarie per la Conditional UI:
gli autenticatori non memorizzano dati specifici dell'utente per le chiavi non residenti, rendendo il riempimento automatico
impossibile con esse.
- **`isConditionalMediationAvailable()`** deve essere chiamato prima di avviare qualsiasi flusso di Conditional
UI per prevenire errori visibili all'utente su browser o dispositivi non supportati.
- Il token **`autocomplete="username webauthn"`** su un campo di input HTML segnala al
browser di mostrare le passkey insieme ai suggerimenti per le password nel menu a discesa del riempimento automatico.
- L'impostazione di **`mediation: "conditional"`** nella chiamata a `navigator.credentials.get()`
attiva il riempimento automatico delle passkey senza interrompere gli utenti con una finestra di dialogo modale bloccante.
- Un **`AbortController`** è richiesto per annullare le richieste di Conditional UI in corso perché
i menu a discesa di riempimento automatico, a differenza dei prompt modali, non dispongono di un pulsante di annullamento integrato.
## 1. Introduzione
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.
## 2. Cos'è la Conditional UI?
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.
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.
## 3. Vantaggi e svantaggi della Conditional UI
### 3.1 Vantaggi
- **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.
### 3.2 Svantaggi
- **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.
## 4. Come funziona la Conditional UI?
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.
## 5. Requisiti tecnici per la Conditional UI
### 5.1 Requisiti generali
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](https://www.w3.org/TR/webauthn-2/#dom-publickeycredentialrequestoptions-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.
### 5.2 Lato client
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](https://caniuse.com/mdn-api_publickeycredential_isconditionalmediationavailable_static) 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](#browser-compatibility-check) 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.
### 5.3 Lato server
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).
## 6. Suggerimenti pratici per la programmazione
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.
### 6.1 Esempio completo di Conditional UI
Un esempio di codice completo e minimalista per un metodo di Conditional UI si presenterebbe in questo modo:
```html
Conditional UI
```
### 6.2 Verifica della compatibilità del browser
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.
```javascript
// 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",
});
/*
...
*/
}
}
```
### 6.3 Token Autocomplete per WebAuthn nei campi di input
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.
```html
```
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.
### 6.4 Proprietà Mediation nella chiamata Get dell'API WebAuthn
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.
```javascript
const credential = await navigator.credentials.get({
publicKey: options.publicKeyCredentialRequestOptions,
mediation: "conditional",
});
```
### 6.5 Annullamento del flusso della Conditional UI
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](https://github.com/w3c/webappsec-credential-management/issues/206)
dovrebbe essere in corso in un dato momento. Lo standard WebAuthn suggerisce l'uso di un
[AbortController](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) per
annullare un processo WebAuthn, applicabile sia ai processi di login regolari che a quelli tramite
Conditional UI (vedere [qui](https://w3c.github.io/webauthn/#sctn-sample-aborting) 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:
```html
Conditional UI
```
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.
### 6.6 Conditional UI nelle app native
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.
#### 6.6.1 Conditional UI nelle app iOS
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 `` 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.
#### 6.6.2 Conditional UI nelle app Android
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](https://developer.android.com/training/sign-in/passkeys)). 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):
## 7. Esempi di Conditional UI su diversi dispositivi e browser
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](https://passkeys.eu).
### 7.1 Conditional UI in Windows 11 (22H2) e Chrome 118
### 7.2 Conditional UI in macOS Ventura (13.5.1) e Chrome 118
### 7.3 Conditional UI in macOS Ventura (13.5.1) e Safari 16.6
### 7.4 Conditional UI in Android 13 e Chrome 118
### 7.5 Conditional UI in iOS 17.1 e Safari 17.1
## 8. La Conditional UI in casi limite
Diamo un'occhiata ad alcuni scenari comuni in applicazioni di vita reale.
### 8.1 Conditional UI in assenza di passkey
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.
#### 8.1.1 Conditional UI senza passkey in Chrome su macOS
Su **Chrome su macOS**, facendo clic nel campo di input, viene visualizzato un menu a discesa
per il riempimento automatico vuoto:
#### 8.1.2 Conditional UI senza passkey in Safari su macOS
Su **Safari su macOS**, non viene visualizzato alcun menu a discesa: solo un'icona
sottile nel campo di input:
#### 8.1.3 Conditional UI senza passkey su Android o iOS
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.
### 8.2 Conditional UI e l'uso di più Credential Manager o Provider di Passkey
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](https://passkeydeveloper.github.io/passkey-authenticator-aaguids/explorer/).
#### 8.2.1 Conditional UI e utilizzo di più gestori di credenziali su Android
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.
#### 8.2.2 Conditional UI e utilizzo di più gestori di credenziali su iOS
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.
> Come app o sito web, non puoi controllare quale gestore delle credenziali
> viene utilizzato: il sistema operativo gestisce quella scelta per preservare
> la privacy dell'utente.
## 9. Conclusione
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.
## Domande frequenti (FAQ)
### Come faccio a verificare se un browser supporta la Conditional UI prima di avviare il flusso di riempimento automatico della 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"`.
### Perché la Conditional UI funziona solo con credenziali rilevabili e non con tutte le passkey?
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.
### Cosa succede nella Conditional UI quando un utente non ha registrato alcuna passkey per un sito?
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.
### Come posso annullare una richiesta di Conditional UI in corso quando un utente passa al login con passkey modale?
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 nelle app native per iOS e Android o solo nei browser web?
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.