Trasporti WebAuthn: Trasporto interno e ibrido

Whitepaper Passkey enterprise. Guide pratiche, pattern di distribuzione e KPI per programmi passkey.

Ottieni il whitepaper

Nota: in conformità alle specifiche WebAuthn, una sequenza di trasporti vuota significa che le informazioni sui trasporti non sono disponibili o sono omesse per motivi di privacy. Spesso è considerata dai browser come se tutti i trasporti potessero essere possibili.

Quando si implementano le passkey su più piattaforme, gli sviluppatori si trovano di fronte a una decisione importante:

• Come dovresti gestire i trasporti WebAuthn, in particolare i trasporti internal e hybrid, per garantire esperienze di autenticazione cross-device ottimali?

La risposta risiede nella comprensione dei trasporti WebAuthn: un dettaglio tecnico che determina come gli autenticatori comunicano con le relying party. Sebbene i trasporti sembrino semplici in teoria, la loro implementazione varia in modo significativo tra browser web, applicazioni native iOS e applicazioni native Android, in particolare per la gestione dei trasporti internal e hybrid.

Questo articolo esamina come funzionano i trasporti WebAuthn su piattaforme diverse e presenta due approcci distinti alla gestione dei trasporti internal e hybrid, ciascuno con i propri compromessi.

I trasporti WebAuthn definiscono i metodi di comunicazione tra gli autenticatori e i dispositivi client. Le specifiche WebAuthn Level 3 definiscono sei tipi di trasporto:

usb: Utilizzato da chiavi di sicurezza hardware che si connettono tramite porte USB, come YubiKey o altri token di sicurezza FIDO2.

nfc: Abilita la comunicazione con gli autenticatori tramite Near Field Communication, consentendo agli utenti di avvicinare le proprie chiavi di sicurezza o dispositivi abilitati NFC.

ble: Facilita l'autenticazione tramite Bluetooth Low Energy, consentendo la comunicazione wireless con autenticatori esterni.

smart-card: Utilizzato dai lettori di smart card, consentendo l'autenticazione tramite smart card.

hybrid: Abilita l'autenticazione cross-device, tipicamente in cui un utente scansiona un codice QR per autenticarsi tra dispositivi, ad esempio utilizzando un telefono per autenticarsi su un browser desktop o viceversa. Questo trasporto può attivare richieste di codici QR sia sui dispositivi desktop che su quelli mobili, il che potrebbe non essere sempre desiderabile a seconda del contesto. Nota: hybrid è stato aggiunto in WebAuthn Level 3.

internal: L'autenticatore è integrato nel dispositivo stesso, come il Portachiavi iCloud (verificato tramite Face ID o Touch ID) su iPhone, Windows Hello su PC o Google Password Manager sui dispositivi Android. Questi sono autenticatori di piattaforma.

Quando viene creata una passkey, l'autenticatore segnala quali trasporti supporta. Questa informazione viene inviata alla relying party (il tuo backend), che dovrebbe persisterla insieme alla credenziale. Durante l'autenticazione, la relying party rinvia questi trasporti al client nell'elenco allowCredentials, aiutando il browser o la piattaforma a determinare quali metodi di autenticazione offrire all'utente.

La gestione dei trasporti differisce in modo significativo a seconda delle piattaforme, creando le sfide di compatibilità che gli sviluppatori devono affrontare.

I browser ricevono le informazioni sui trasporti dagli autenticatori e le onorano durante i flussi di autenticazione. Quando crei una passkey in Chrome, Safari o Edge, il gestore delle credenziali del browser fornisce dati di trasporto che variano in base all'autenticatore sottostante:

Autenticatori di piattaforma: Windows Hello fornisce solo ["internal"], riflettendo la sua natura legata al dispositivo. Tuttavia, quando Chrome utilizza Google Password Manager come autenticatore, fornisce ["internal", "hybrid"] perché Google Password Manager supporta l'autenticazione cross-device tramite telefoni Android.

Chiavi di sicurezza hardware: Forniscono trasporti specifici come ["usb", "nfc"] in base alle loro effettive capacità.

Gestori di credenziali sincronizzati nel cloud: Il Portachiavi iCloud in Safari e Google Password Manager in Chrome forniscono in genere ["internal", "hybrid"] per supportare sia flussi di autenticazione locali che cross-device.

Queste informazioni fluiscono in modo affidabile nei contesti web, sebbene i trasporti specifici dipendano dall'autenticatore selezionato dal browser per l'archiviazione delle credenziali.

Documentazione: Specifiche W3C WebAuthn

L'API Credential Manager di Android si comporta in modo simile ai browser web. Durante la creazione di passkey nelle app Android native, il Credential Manager fornisce informazioni sui trasporti che rispecchiano il comportamento web: gli autenticatori di piattaforma segnalano accuratamente le loro capacità e il sistema gestisce coerentemente i dati dei trasporti. Gli sviluppatori Android possono fare affidamento su queste informazioni senza una gestione speciale.

Documentazione: Credential Manager di Android

iOS presenta una situazione più complessa. Il framework AuthenticationServices di Apple gestisce i trasporti in modo diverso a seconda del tipo di autenticatore:

Autenticatori di piattaforma (Portachiavi iCloud, verificato tramite Face ID o Touch ID): Restituiscono spesso array di trasporti vuoti durante la creazione della passkey. Questo indica che le informazioni sui trasporti non sono disponibili o sono omesse per motivi di privacy: secondo le specifiche WebAuthn, gli user agent possono restituire sequenze vuote quando le informazioni sui trasporti sono sconosciute o per preservare la privacy. Le relying party dovrebbero considerare i trasporti come suggerimenti piuttosto che come garanzie.

Chiavi di sicurezza: Forniscono effettivamente informazioni sui trasporti (ad es., ["usb"], ["nfc"]) quando utilizzate con i dispositivi iOS, seguendo il pattern previsto.

Documentazione: AuthenticationServices di Apple

I dati di produzione dal mondo reale provenienti da applicazioni web e native rivelano i seguenti pattern di trasporto, ordinati per frequenza. Nota che queste distribuzioni sono influenzate da specifiche di implementazione e caratteristiche demografiche del client (uso mobile rispetto a desktop, disponibilità di app native), ma forniscono indicazioni preziose sull'uso tipico dei trasporti:

Punti chiave:

Dominano gli autenticatori di piattaforma: La stragrande maggioranza delle passkey utilizza il trasporto internal, spesso combinato con hybrid per il supporto dell'autenticazione cross-device. Questo riflette l'attenzione del mondo consumer verso gli autenticatori di piattaforma (Portachiavi iCloud, Google Password Manager).

Gli array vuoti sono comuni: Le applicazioni native iOS restituiscono frequentemente array di trasporti vuoti per gli autenticatori di piattaforma, rappresentando una porzione significativa delle credenziali in produzione. Come discusso nella sezione 2.2.3, questi indicano informazioni sui trasporti non disponibili piuttosto che un supporto di trasporto completo.

Le chiavi di sicurezza sono rare: Le chiavi di sicurezza hardware (usb, nfc) rappresentano una minima frazione delle passkey in produzione, indicando il loro uso primario in scenari aziendali o ad alta sicurezza piuttosto che in applicazioni consumer.

Esistono variazioni di ordine: L'ordine dei trasporti negli array (["internal", "hybrid"] rispetto a ["hybrid", "internal"]) varia a seconda della piattaforma e dell'implementazione dell'autenticatore, ma non comporta differenze funzionali: entrambi indicano il supporto per gli stessi metodi di trasporto.

Terminologia legacy: L'identificatore del trasporto cable compare occasionalmente nelle implementazioni precedenti ed è sinonimo di hybrid (caBLE = cloud-assisted Bluetooth Low Energy, il nome originale per il trasporto hybrid).

Questa distribuzione rafforza l'importanza di gestire correttamente i trasporti internal e hybrid, poiché rappresentano la stragrande maggioranza delle implementazioni reali di passkey.

La disponibilità del trasporto mostra ciò che riportano gli autenticatori, non se il flusso risultante viene completato. L'analisi del completamento dell'autenticazione cross-device del Corbado Passkey Benchmark 2026 misurava il completamento del trasporto hybrid nel 1° trimestre 2026 tra il 60 e il 78 % sul web in Windows e tra il 66 e l'86 % sul web in macOS in generale, suddividendosi nel 79-98 % (Win) / 83-98 % (macOS) per gli avvisi sullo stesso dispositivo (same-device nudge) rispetto al 52-67 % (Win) / 59-76 % (macOS) per i flussi identifier-first. Considera hybrid come il trasporto a costo più elevato nella logica di instradamento e preferisci i flussi che mantengono l'utente sul dispositivo che detiene la credenziale.

Lo stesso autenticatore segnala spesso pattern di trasporto diversi in base a piattaforma, versione e contesto di implementazione. Questa variazione è normale e attesa:

Il Portachiavi iCloud presenta tre pattern:

• ["internal", "hybrid"] - Il più comune, in genere dai browser web
• [] (array vuoto) - Molto comune, da app native iOS
• ["hybrid", "internal"] - Meno comune, variazione di ordine
• ["internal"] o solo ["hybrid"] - Casi limite rari

Google Password Manager mostra la maggiore variazione:

• ["hybrid", "internal"] - Pattern più comune
• ["internal", "hybrid"] - Ordinamento alternativo comune
• ["internal", "cable"] - Implementazioni legacy (cable = vecchio termine per hybrid)
• [] (array vuoto) - Da determinati contesti nativi
• Singoli trasporti (raramente)

Windows Hello è il più coerente:

• ["internal"] - Pattern dominante (legato al dispositivo per progettazione)

Gestori di password come 1Password, Bitwarden, Dashlane e LastPass mostrano tutti pattern di variazione simili:

• Entrambi gli ordinamenti ["internal", "hybrid"] e ["hybrid", "internal"]
• Array vuoti [] da contesti di app native
• Occasionalmente solo ["internal"]

Samsung Pass (ecosistema Android) utilizza principalmente:

• ["hybrid", "internal"] e ["internal", "hybrid"] - Entrambi gli ordinamenti comuni

Differenze di piattaforma: Lo stesso autenticatore si comporta in modo diverso sul web rispetto alle app native, iOS rispetto ad Android, o Windows rispetto a macOS.

Evoluzione della versione: La segnalazione dei trasporti si è evoluta nel tempo. Versioni precedenti potevano utilizzare cable anziché hybrid, o segnalare combinazioni diverse.

Scelte di implementazione: Alcuni autenticatori danno priorità prima a internal, altri a hybrid. L'ordine non ha alcun impatto funzionale, ma varia in base all'implementazione.

Sensibilità al contesto: Le app native, soprattutto su iOS, ricevono spesso array vuoti anche da autenticatori che segnalano trasporti completi nei contesti web.

Punto fondamentale: Non presumere che gli array di trasporti siano coerenti per un determinato autenticatore. Progetta la tua implementazione per gestire tutte le variazioni in modo elegante, concentrandoti sulla presenza di trasporti specifici piuttosto che sull'esatta corrispondenza dell'array.

Gli sviluppatori si trovano di fronte a una scelta: seguire rigorosamente le specifiche o ottimizzare i trasporti internal e hybrid per l'esperienza utente. Ogni approccio ha pregi e difetti.

Questo approccio è in linea con le specifiche WebAuthn: utilizzare i trasporti esattamente come forniti dall'autenticatore durante la registrazione delle credenziali e reinviarli inalterati durante l'autenticazione.

Implementazione: Quando viene creata una passkey, persisti l'array transports dalla risposta dell'autenticatore. Durante l'autenticazione, includi questi trasporti esatti nell'elenco allowCredentials:

{
    "allowCredentials": [
        {
            "id": "credential-id-base64",
            "type": "public-key",
            "transports": ["internal", "hybrid"]
        }
    ]
}

Vantaggi:

• Conformità alle specifiche: Segue esattamente gli standard WebAuthn, garantendo la compatibilità con i futuri aggiornamenti della piattaforma
• Affidabilità delle chiavi di sicurezza: Funziona perfettamente per le chiavi di sicurezza hardware (YubiKey, ecc.) che forniscono sempre informazioni accurate sui trasporti
• Previene opzioni non valide: Evita di offrire metodi di autenticazione che in realtà non sono supportati (ad esempio, non attiverà i codici QR per le credenziali di Windows Hello)

Svantaggi:

• Comportamento dell'array vuoto di iOS: Gli autenticatori di piattaforma su iOS restituiscono trasporti vuoti, il che indica che le informazioni sui trasporti non sono disponibili: le piattaforme possono interpretare questo aspetto in modo diverso quando determinano quali opzioni di autenticazione mostrare
• Potrebbe mostrare opzioni indesiderate: Potrebbe presentare opzioni per le chiavi di sicurezza (USB, NFC) in applicazioni consumer in cui non sono previste
• Esperienza utente incoerente: Piattaforme diverse offrono opzioni di autenticazione diverse per lo stesso account

Ideale per: Applicazioni che danno priorità alla conformità agli standard, ambienti aziendali con diversi tipi di autenticatori.

Questo approccio dà priorità all'esperienza utente modificando in modo selettivo i trasporti internal e hybrid in base a specifici obiettivi di ottimizzazione. Piuttosto che una regola generale, considera questi scenari comuni di ottimizzazione:

Problema: Gli autenticatori di piattaforma iOS restituiscono array di trasporti vuoti. Se lasciati vuoti o compilati dai backend, gli utenti potrebbero vedere richieste di chiavi di sicurezza (USB, NFC) accanto alle opzioni della piattaforma, creando confusione nelle applicazioni consumer.

Soluzione: Imposta esplicitamente i trasporti su ["hybrid", "internal"] per gli autenticatori di piattaforma iOS. In questo modo ti assicuri che vengano offerte solo l'autenticazione tramite piattaforma e i flussi cross-device, nascondendo le opzioni della chiave di sicurezza.

// Quando si persistono le credenziali dell'autenticatore di piattaforma iOS
if (platform === "iOS" && authenticatorAttachment === "platform") {
    transports = ["hybrid", "internal"];
}

Risultato: Interfaccia utente di autenticazione pulita senza richieste di chiavi di sicurezza per le passkey create su iOS.

Problema: Durante l'autenticazione su dispositivi mobili, mostrare codici QR per l'autenticazione cross-device crea una cattiva UX: gli utenti si trovano già su un dispositivo mobile con le loro passkey disponibili.

Soluzione: Rimuovi il trasporto hybrid quando l'utente si sta autenticando da un dispositivo mobile, lasciando solo ["internal"].

// Quando si costruisce allowCredentials per l'autenticazione
const transports = isMobileDevice
    ? credentials.transports.filter((t) => t !== "hybrid")
    : credentials.transports;

Risultato: Gli utenti di dispositivi mobili vedono solo le opzioni di autenticazione diretta senza inutili richieste di codici QR.

⚠️ Attenzione: La manipolazione dei trasporti non produce sempre risultati coerenti tra le piattaforme. Test estesi mostrano che le combinazioni di browser e sistema operativo gestiscono i trasporti in modo diverso:

• Alcune piattaforme mostrano codici QR anche quando hybrid è escluso dai trasporti
• Altre nascondono i codici QR anche quando hybrid è incluso
• Il comportamento varia in modo significativo tra Chrome, Edge, Safari e Firefox su Windows, macOS e iOS

Rischio di vicoli ciechi: Un filtraggio dei trasporti eccessivamente restrittivo può creare vicoli ciechi nell'autenticazione, dove gli utenti non riescono ad accedere del tutto. Ad esempio, la rimozione di hybrid potrebbe impedire scenari legittimi di autenticazione cross-device in cui un utente deve autenticarsi da un dispositivo in prestito. Fornisci sempre metodi di autenticazione di fallback e testa in modo approfondito sulle tue piattaforme target prima di distribuire ottimizzazioni dei trasporti.

Questi sono suggerimenti per l'ottimizzazione: WebAuthn fornisce altri meccanismi per ottimizzare l'UX di autenticazione oltre alla manipolazione dei trasporti, come gli hints.

Il comportamento del trasporto è imprevedibile: L'autenticazione cross-device (CDA) tramite il trasporto hybrid mostra un comportamento incoerente in diverse combinazioni di browser e OS. I test reali dimostrano che i valori dei trasporti non garantiscono un comportamento specifico dell'interfaccia utente: le piattaforme interpretano e gestiscono i trasporti in modo diverso, portando a risultati inaspettati.

Complessità specifica della piattaforma: Quando controlli esplicitamente i trasporti, devi tenere conto delle differenze tra le piattaforme:

• iOS: Invia array vuoti per gli autenticatori di piattaforma; richiede il popolamento
• Windows Hello: Deve rimanere solo ["internal"]; l'aggiunta di hybrid attiva codici QR indesiderati
• Web e Android: Generalmente forniscono informazioni sui trasporti accurate
• Variazioni CDA: Le richieste di codici QR possono apparire o scomparire indipendentemente dalla presenza di hybrid nell'array dei trasporti

È necessaria una comprensione end-to-end: Controllare esplicitamente i trasporti significa assumersi la responsabilità dell'intero flusso. Devi capire come si comporta ogni combinazione di trasporti su tutte le tue piattaforme target e testarle in modo approfondito. La manipolazione dei trasporti può creare vicoli ciechi in cui non esiste alcun percorso di autenticazione valido per gli utenti.

Vantaggi:

• UX su misura: Controlla esattamente quali opzioni di autenticazione vedono gli utenti in contesti specifici
• Risolve il problema dell'array vuoto di iOS: Definisce esplicitamente i trasporti dove iOS non ne fornisce alcuno
• Ottimizzazione sensibile al contesto: Adatta l'interfaccia utente di autenticazione in base al tipo di dispositivo

Svantaggi:

• Comportamento imprevedibile: La manipolazione dei trasporti non garantisce un comportamento coerente dell'interfaccia utente: test estesi mostrano che le piattaforme interpretano i trasporti in modo diverso, a volte mostrando o nascondendo le opzioni indipendentemente dai valori dei trasporti
• Rischio di vicoli ciechi di autenticazione: Un filtraggio dei trasporti eccessivamente restrittivo può impedire completamente agli utenti di autenticarsi, soprattutto negli scenari cross-device
• Deviazione dalle specifiche: Si allontana dalle raccomandazioni delle specifiche, causando potenzialmente problemi con future modifiche alla piattaforma
• Carico di manutenzione: Richiede logiche specifiche per la piattaforma e aggiornamenti continui man mano che le piattaforme si evolvono
• Complessità: Devi gestire manualmente array vuoti di iOS, i vincoli di Windows Hello e altre peculiarità della piattaforma
• Carico di test: Ogni regola di ottimizzazione necessita di verifica tra tutte le combinazioni di piattaforme

Ideale per: Applicazioni consumer con requisiti UX specifici, team con le risorse per mantenere la logica specifica della piattaforma, scenari che privilegiano flussi di autenticazione semplificati rispetto alla rigorosa conformità alle specifiche.

La gestione dei trasporti WebAuthn non esiste isolatamente: è un pezzo della tua strategia generale di implementazione delle passkey. Negli scenari di produzione emergono due approcci comuni, ciascuno con diverse implicazioni per l'uso dei trasporti internal e hybrid.

Questo approccio dà priorità alla flessibilità e alla conformità agli standard, consentendo agli utenti di autenticarsi con qualsiasi autenticatore compatibile.

Caratteristiche dell'implementazione:

• Interfaccia utente di autenticazione: Il pulsante per la passkey appare accanto alle opzioni di accesso esistenti (nome utente/password)
• allowCredentials: Impostato su array vuoto [], per consentire a qualsiasi credenziale di corrispondere
• Tipi di autenticatore: Chiavi di sicurezza, autenticazione cross-device (codici QR), autenticatori di piattaforma, tutti supportati
• Requisiti dell'app nativa: Deve supportare tutti i metodi di autenticazione, incluse le chiavi di sicurezza
• preferImmediatelyAvailableCredentials: Non può essere utilizzato, poiché esclude per definizione le chiavi di sicurezza e gli accessi tramite codice QR
• Gestione dei trasporti: Deve accogliere tutti i tipi di trasporto, inclusi i trasporti per le chiavi di sicurezza (usb, nfc, ble)

Implicazioni sui trasporti:

Con allowCredentials vuoto, i trasporti diventano meno critici durante l'autenticazione: la piattaforma mostra tutte le opzioni disponibili. Tuttavia, ciò significa che gli utenti possono vedere contemporaneamente richieste di chiavi di sicurezza, codici QR e opzioni di piattaforma, il che può creare una "paralisi decisionale" nelle applicazioni consumer.

Ideale per: Ambienti aziendali, applicazioni con base utenti eterogenea che richiedono supporto per chiavi di sicurezza, scenari che privilegiano la massima flessibilità di autenticazione.

Questo approccio ottimizza per l'UX consumer limitando la creazione di passkey agli autenticatori di piattaforma e utilizzando flussi identifier-first.

Caratteristiche dell'implementazione:

• Creazione della passkey: I suggerimenti (nudge) avviati dall'utente (richieste post-login, flussi di creazione automatica) utilizzano authenticatorAttachment: "platform" per concentrarsi sugli autenticatori immediatamente disponibili
• Supporto della chiave di sicurezza: Disponibile tramite le impostazioni dell'account web senza restrizioni authenticatorAttachment, consentendo agli utenti esperti (power users) di selezionare qualsiasi autenticatore incluse le chiavi di sicurezza
• Flusso di autenticazione: Identifier-first (l'utente inserisce e-mail/nome utente prima dell'autenticazione)
• allowCredentials: Popolato con le credenziali specifiche dell'utente (non vuoto) una volta noto l'identificatore
• Tipi di autenticatore: Autenticatori di piattaforma e autenticazione cross-device hanno la priorità; chiavi di sicurezza supportate ma non promosse nei flussi principali
• Ottimizzazione per app native: Utilizza preferImmediatelyAvailableCredentials per un'autenticazione immediata e invisibile senza richieste di chiavi di sicurezza o codici QR
• Autenticazione cross-device: Disponibile sul web; volutamente esclusa nelle app native quando si utilizza preferImmediatelyAvailableCredentials (gli utenti si autenticano in genere sul dispositivo in cui risiedono le loro passkey)
• Gestione dei trasporti: Focus primario sui trasporti internal e hybrid

Implicazioni sui trasporti:

Poiché allowCredentials contiene credenziali specifiche con i relativi trasporti, la gestione dei trasporti diventa cruciale per ottimizzare le esperienze di autenticazione.

La realtà delle chiavi di sicurezza: Le chiavi di sicurezza rappresentano una frazione estremamente piccola dell'utilizzo delle passkey nelle implementazioni consumer su larga scala, principalmente per utenti esperti o utenti con requisiti di sicurezza specifici. L'approccio pensato per i consumatori riconosce questa realtà supportando le chiavi di sicurezza senza ottimizzare i flussi principali attorno ad esse.

Strategia di creazione a due livelli: Le implementazioni possono bilanciare la compatibilità delle chiavi di sicurezza con l'UX consumer ottimizzata attraverso doppi percorsi di creazione:

• Nudge per l'utente e richieste: I prompt post-login e i flussi di creazione automatica utilizzano authenticatorAttachment: "platform", guidando gli utenti verso passkey immediatamente disponibili con elevati tassi di successo
• Impostazioni dell'account web: Offre la creazione senza authenticatorAttachment, consentendo agli utenti esperti di selezionare chiavi di sicurezza, gestori di password di terze parti o qualsiasi autenticatore disponibile

Questo pattern appare nelle principali implementazioni: le chiavi di sicurezza sono supportate e funzionali tramite impostazioni, ma i nudge rivolti agli utenti sono ottimizzati per il caso d'uso dominante: gli autenticatori di piattaforma che forniscono un'autenticazione istantanea e silenziosa.

Ideale per: Applicazioni consumer, app native per dispositivi mobili, scenari che privilegiano un'UX semplificata rispetto alla flessibilità dell'autenticatore, piattaforme in cui esistono già flussi identifier-first.

Per le piattaforme che rivelano già l'esistenza dell'account o utilizzano flussi identifier-first (l'utente inserisce l'e-mail prima di vedere le opzioni di accesso), l'approccio orientato al consumatore si allinea in modo naturale. Una volta che l'utente ha fornito il proprio identificatore:

1. Il backend interroga per cercare eventuali passkey esistenti
2. Restituisce allowCredentials con credenziali specifiche e i relativi trasporti
3. La piattaforma può ottimizzare l'interfaccia utente di autenticazione in base ai trasporti
4. Nessun ulteriore rischio di enumerazione dell'account (l'identificatore è già stato fornito)

In questi scenari, i trasporti possono diventare uno strumento di ottimizzazione piuttosto che un problema di sicurezza. Puoi adattare le opzioni di autenticazione in base al contesto del dispositivo (mobile rispetto a desktop) e alle capacità delle credenziali.

Raccomandazione: Per le piattaforme che utilizzano già flussi identifier-first o in cui l'enumerazione dell'account non è un problema, l'approccio pensato per i consumatori, unito alla gestione esplicita dei trasporti, fornisce un'UX superiore, in particolare nelle applicazioni native per dispositivi mobili dove preferImmediatelyAvailableCredentials consente un'autenticazione biometrica senza attriti.

Indipendentemente dall'approccio che scegli per la gestione dei trasporti internal e hybrid, segui queste pratiche per ridurre al minimo i problemi:

Persisti i trasporti durante la registrazione: Archivia sempre l'array transports dalla risposta dell'autenticatore insieme all'ID della credenziale e alla chiave pubblica. Questi dati sono essenziali per i flussi di autenticazione.

Gestisci con grazia gli array vuoti: Quando ricevi un array di trasporti vuoto dagli autenticatori di piattaforma iOS:

• Conforme alle specifiche: Lascia vuoto o ometti la proprietà trasporti (indica che le informazioni sui trasporti non sono disponibili; le piattaforme determineranno le opzioni disponibili)
• Approccio di ottimizzazione: Riempi con ["internal", "hybrid"] per controllare quali opzioni di autenticazione vengono mostrate

Strategie di trasporto web vs native: Differenzia la gestione dei trasporti in base al contesto:

• Autenticazione web: Includi tutti i trasporti, consentendo un supporto più ampio degli autenticatori, comprese le chiavi di sicurezza tramite USB/NFC
• Autenticazione app nativa: Usa preferImmediatelyAvailableCredentials per un'autenticazione silenziosa; trasporti inviati così come archiviati
• Pagine di gestione/impostazioni: Supporta tutti i tipi di autenticatori per gli utenti esperti

Gestisci l'autenticazione con chiave di sicurezza: Quando gli utenti hanno registrato chiavi di sicurezza:

• Web: Rileva i trasporti della chiave di sicurezza nelle credenziali archiviate e assicurati che i flussi di autenticazione possano accoglierli
• App native: Valuta la possibilità di fornire metodi di autenticazione di fallback o di indirizzare gli utenti al web per l'autenticazione della chiave di sicurezza
• Approccio ibrido: Le app native si ottimizzano per gli autenticatori di piattaforma, mentre il web supporta la completa flessibilità degli autenticatori

Testa in tutte le piattaforme di destinazione: Crea una matrice di test che copra tutte le combinazioni:

• Registrazione: Web, Nativo iOS, Nativo Android
• Autenticazione: Web, Nativo iOS, Nativo Android
• Verifica che l'autenticazione silenziosa funzioni con preferImmediatelyAvailableCredentials
• Conferma che le chiavi di sicurezza funzionino nei flussi di impostazioni senza authenticatorAttachment
• Convalida che i codici QR vengano visualizzati solo in contesti appropriati

Comprendi la semantica dei trasporti: Riconosci le differenze tra i valori di trasporto vuoti e mancanti:

• Array di trasporti vuoto []: Indica che le informazioni sui trasporti non sono disponibili o sono tenute nascoste per motivi di privacy. Gli user agent possono fornire sequenze vuote quando non possono, o scelgono di non segnalare le funzionalità di trasporto. Questo non equivale a "tutti i trasporti supportati"; trattale come indizi laddove le informazioni non sono disponibili.
• Proprietà trasporti mancante: Quando i trasporti vengono omessi dai descrittori delle credenziali, gli user agent determinano i metodi di autenticazione disponibili in base ad altri fattori. Il contesto conta: nelle risposte di registrazione rispetto alle opzioni di richiesta di autenticazione, le implicazioni differiscono.
• Suggerimenti di trasporto (hints): Secondo le specifiche, i trasporti dovrebbero essere considerati come suggerimenti per aiutare gli user agent a ottimizzare l'interfaccia utente di autenticazione, e non come garanzie autorevoli di determinate capacità.

Monitora le modifiche della piattaforma: Le implementazioni WebAuthn si evolvono. Apple, Google e Microsoft aggiornano regolarmente il comportamento dei loro autenticatori. Rimani informato sui cambiamenti che potrebbero influire sulla gestione dei trasporti.

I trasporti WebAuthn, in particolare i trasporti internal e hybrid, sono dettagli tecnici con un impatto pratico significativo sull'autenticazione cross-device. La tua strategia di gestione dei trasporti dovrebbe essere in linea con il tuo approccio più ampio all'implementazione delle passkey e alle piattaforme di destinazione.

Le decisioni sui trasporti vivono in una strategia più ampia: Il modo in cui gestisci i trasporti dipende dal fatto che tu stia creando per la massima flessibilità (allowCredentials vuoto) o per la UX dei consumatori (identifier-first con credenziali specifiche). Questo secondo aspetto rende i trasporti critici per l'ottimizzazione.

Le differenze tra le piattaforme richiedono gestione: Il web e Android forniscono informazioni affidabili sui trasporti, mentre gli autenticatori di piattaforma iOS restituiscono array vuoti. Windows Hello invia solo ["internal"]. Comprendere queste differenze è essenziale per le distribuzioni in produzione.

Due approcci di trasporto validi: La conformità alle specifiche (fidarsi dei trasporti degli autenticatori) funziona bene per gli scenari aziendali e di massima flessibilità. Il controllo esplicito (ottimizzazione dei trasporti) è adatto alle applicazioni consumer con flussi identifier-first e app mobili native.

Identifier-First abilita l'ottimizzazione del trasporto: Quando gli utenti forniscono prima il loro identificatore, la gestione dei trasporti diventa un potente strumento di UX. Puoi prevenire codici QR indesiderati sui dispositivi mobili, nascondere le opzioni delle chiavi di sicurezza e semplificare l'autenticazione, senza ulteriori preoccupazioni sull'enumerazione degli account.

Per l'azienda / Massima flessibilità:

• Usa allowCredentials vuoto per supportare tutti i tipi di autenticatori
• Confida nei trasporti forniti dall'autenticatore
• Accetta che gli utenti vedano più opzioni di autenticazione
• Implementazione più semplice, più ampia compatibilità

Per applicazioni consumer / App native:

• Implementa il flusso di autenticazione identifier-first
• Nudge per gli utenti (post-login, avvisi automatici): Utilizza authenticatorAttachment: "platform" per un'autenticazione immediata ad alto successo
• Impostazioni dell'account web: Consenti la creazione senza authenticatorAttachment per gli utenti esperti che necessitano di chiavi di sicurezza
• Utilizza allowCredentials con credenziali specifiche e trasporti ottimizzati
• App native: Abilita preferImmediatelyAvailableCredentials per l'autenticazione silenziosa
• Riempi gli array vuoti di iOS con ["hybrid", "internal"]
• Autenticazione web: Supporta tutti i trasporti, incluse le chiavi di sicurezza
• Filtra hybrid sui dispositivi mobili per evitare i codici QR ove appropriato
• UX superiore con opzioni di autenticazione semplificate pur mantenendo la compatibilità

Per piattaforme che dispongono già di flussi Identifier-First:

• L'enumerazione degli account è già un non-problema
• L'approccio pensato per i consumatori si allinea in modo naturale all'UX esistente
• L'ottimizzazione dei trasporti offre vantaggi immediati all'UX
• Approccio raccomandato per la maggior parte delle applicazioni consumer

Inizia in conformità alle specifiche, quindi ottimizza in base alla tua strategia:

1. Persisti i trasporti esattamente come ricevuti durante la registrazione
2. Decidi la tua strategia complessiva (massima flessibilità vs pensato per i consumatori)
3. Se pensata per i consumatori: implementa un flusso identifier-first e ottimizza i trasporti
4. Gestisci gli array vuoti di iOS in modo appropriato in base alla strategia scelta
5. Testa accuratamente tra le piattaforme web, iOS nativo e Android nativo

Il panorama WebAuthn continua ad evolversi. I fornitori di piattaforme aggiornano regolarmente le loro implementazioni e specifiche come WebAuthn Level 3 introducono nuove funzionalità. Costruire sistemi flessibili che allineino la gestione dei trasporti alla tua più ampia strategia di autenticazione assicura che la tua implementazione della passkey rimanga solida e offra eccellenti esperienze utente man mano che l'ecosistema matura.

Chi siamo

Corbado è la Passkey 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 →

AuthenticationServices di iOS omette le informazioni sui trasporti per gli autenticatori di piattaforma come il Portachiavi iCloud, restituendo array vuoti in conformità alle disposizioni sulla privacy delle specifiche WebAuthn. Le chiavi di sicurezza su iOS forniscono invece i dati di trasporto, come ["usb"] o ["nfc"]. Le relying party dovrebbero considerare tutti i trasporti come suggerimenti piuttosto che come garanzie assolute di funzionalità.

cable è una terminologia legacy sinonimo di hybrid, che sta per caBLE (cloud-assisted Bluetooth Low Energy). Entrambi descrivono l'autenticazione cross-device, come la scansione di un codice QR per autenticare una sessione desktop utilizzando un telefono. hybrid è il termine attuale introdotto in WebAuthn Level 3 e dovrebbe essere utilizzato nelle nuove implementazioni.

Per le applicazioni consumer che utilizzano flussi identifier-first, imposta esplicitamente i trasporti su ["hybrid", "internal"] per gli autenticatori di piattaforma iOS che hanno restituito array vuoti durante la registrazione. Ciò impedisce la visualizzazione delle richieste di chiavi di sicurezza USB e NFC nell'interfaccia utente di autenticazione. L'alternativa conforme alle specifiche è lasciare gli array vuoti o omettere completamente la proprietà dei trasporti.

La rimozione del trasporto hybrid sui dispositivi mobili impedisce la visualizzazione delle richieste di codici QR quando gli utenti si trovano già su un dispositivo in cui risiedono le loro passkey. Tuttavia, la manipolazione dei trasporti produce risultati incoerenti: alcune piattaforme mostrano codici QR anche quando hybrid è escluso e altre li nascondono a prescindere. Testa sempre sulle piattaforme di destinazione e fornisci metodi di autenticazione di fallback per evitare di creare vicoli ciechi.

Un array allowCredentials vuoto supporta tutti i tipi di autenticatori, incluse le chiavi di sicurezza e l'autenticazione cross-device, ma riduce la rilevanza del trasporto e può presentare agli utenti più opzioni simultanee. Il popolamento con credenziali utente specifiche rende la gestione dei trasporti fondamentale per l'ottimizzazione dell'interfaccia utente, consentendo ai flussi identifier-first di filtrare i codici QR sui dispositivi mobili e di nascondere le richieste di chiavi di sicurezza nei contesti consumer.