Trasporti WebAuthn: Trasporto Interno e Ibrido

Passkeys for Super Funds and Financial Institutions
Join our Webinar on 7th November to learn how Super Funds and Financial Institutions can implement passkeys

Join now

Nota: Secondo le specifiche WebAuthn, un elenco di trasporti vuoto significa che tutti i trasporti sono supportati.

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

• Come dovremmo gestire i trasporti WebAuthn, in particolare quelli interni e ibridi, per garantire un'esperienza di autenticazione cross-device ottimale?

La risposta sta nel comprendere i trasporti WebAuthn, un dettaglio tecnico che determina come gli authenticator comunicano con le relying party. Sebbene in teoria i trasporti sembrino semplici, la loro implementazione varia in modo significativo tra browser web, applicazioni native per iOS e native per Android, in particolare per quanto riguarda la gestione dei trasporti interni e ibridi.

Questo articolo esamina come funzionano i trasporti WebAuthn su diverse piattaforme e presenta due approcci distinti per la gestione dei trasporti interni e ibridi, ognuno con i propri compromessi.

Questo articolo tratta:

1. Trasporti WebAuthn: interni, ibridi e authenticator di piattaforma su web, iOS e Android
2. Due approcci: gestione dei trasporti interni e ibridi conforme alle specifiche vs. ottimizzata
3. Best practice e raccomandazioni per l'implementazione dell'autenticazione cross-device

I trasporti WebAuthn definiscono i metodi di comunicazione tra gli authenticator e i dispositivi client. La specifica WebAuthn Level 3 definisce sei tipi di trasporto:

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

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

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

smart-card: Utilizzato per lettori di smart card, permettendo l'autenticazione tramite smart card.

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

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

Quando viene creata una passkey, l'authenticator segnala quali trasporti supporta. Questa informazione viene inviata alla relying party (il vostro backend), che dovrebbe salvarla insieme alla credenziale. Durante l'autenticazione, la relying party invia nuovamente questi trasporti al client nella lista allowCredentials, aiutando il browser o la piattaforma a determinare quali metodi di autenticazione offrire all'utente.

La gestione dei trasporti differisce notevolmente tra le piattaforme, creando le sfide di compatibilità che gli sviluppatori devono affrontare.

I browser ricevono le informazioni sui trasporti dagli authenticator e le rispettano durante i flussi di autenticazione. Quando si crea una passkey in Chrome, Safari o Edge, il gestore di credenziali del browser fornisce dati sui trasporti che variano in base all'authenticator sottostante:

Authenticator di piattaforma: Windows Hello fornisce solo ["internal"], riflettendo la sua natura legata al dispositivo. Tuttavia, quando Chrome utilizza Google Password Manager come authenticator, 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 tipicamente ["internal", "hybrid"] per supportare sia i flussi di autenticazione locali che quelli cross-device.

Queste informazioni fluiscono in modo affidabile nei contesti web, sebbene i trasporti specifici dipendano da quale authenticator il browser seleziona per l'archiviazione delle credenziali.

Documentazione: Specifica WebAuthn W3C

La Credential Manager API di Android si comporta in modo simile ai browser web. Quando si creano passkey in app native Android, il Credential Manager fornisce informazioni sui trasporti che rispecchiano il comportamento web: gli authenticator di piattaforma segnalano le loro capacità in modo accurato e il sistema gestisce i dati sui trasporti in modo coerente. Gli sviluppatori Android possono fare affidamento su queste informazioni senza una gestione speciale.

Documentazione: Android Credential Manager

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

Authenticator di piattaforma (Portachiavi iCloud, verificato tramite Face ID o Touch ID): Spesso restituiscono array di trasporti vuoti durante la creazione della passkey. Questo non significa che la passkey non abbia capacità di trasporto, ma semplicemente che iOS non le riporta esplicitamente. Secondo lo standard WebAuthn, omettere i trasporti significa che qualsiasi trasporto è accettabile, quindi l'autenticazione ibrida funzionerà comunque.

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

Documentazione: Apple AuthenticationServices

Gli sviluppatori devono scegliere: seguire rigorosamente le specifiche o ottimizzare i trasporti interni e ibridi per l'esperienza utente. Ogni approccio ha vantaggi e svantaggi.

Questo approccio si allinea alla specifica WebAuthn: utilizzare i trasporti esattamente come forniti dall'authenticator durante la registrazione della credenziale e inviarli di nuovo invariati durante l'autenticazione.

Implementazione: Quando viene creata una passkey, salvare l'array transports dalla risposta dell'authenticator. Durante l'autenticazione, includere questi esatti trasporti nella lista 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 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 non sono realmente supportati, ad esempio non attiverà codici QR per le credenziali di Windows Hello.

Svantaggi:

• Comportamento dell'array vuoto di iOS: Gli authenticator di piattaforma su iOS restituiscono trasporti vuoti, il che secondo le specifiche significa "qualsiasi trasporto". Questo potrebbe mostrare tutte le opzioni di autenticazione, incluse le chiavi di sicurezza.
• Può mostrare opzioni indesiderate: Potrebbe presentare opzioni per chiavi di sicurezza (USB, NFC) in applicazioni consumer dove non sono previste.
• Esperienza utente incoerente: Piattaforme diverse offrono opzioni di autenticazione diverse per lo stesso account.

Ideale per: Applicazioni che privilegiano la conformità agli standard, ambienti enterprise con diversi tipi di authenticator.

Questo approccio dà la priorità all'esperienza utente modificando selettivamente i trasporti interni e ibridi in base a specifici obiettivi di ottimizzazione. Piuttosto che una regola generale, consideriamo questi scenari di ottimizzazione comuni:

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

Soluzione: Impostare esplicitamente i trasporti a ["hybrid", "internal"] per gli authenticator di piattaforma iOS. Ciò garantisce che vengano offerte solo l'autenticazione di piattaforma e i flussi cross-device, nascondendo le opzioni delle chiavi di sicurezza.

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

Risultato: Un'interfaccia di autenticazione pulita senza richieste di chiavi di sicurezza per le passkey create su iOS.

Problema: Quando ci si autentica su dispositivi mobili, mostrare codici QR per l'autenticazione cross-device crea una pessima esperienza utente: gli utenti sono già su un dispositivo mobile con le loro passkey disponibili.

Soluzione: Rimuovere 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 mobili vedono solo opzioni di autenticazione diretta senza inutili richieste di codice QR.

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

• Alcune piattaforme mostrano i 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 in cui gli utenti non riescono affatto ad accedere. Ad esempio, rimuovere hybrid potrebbe impedire scenari legittimi di autenticazione cross-device in cui un utente deve autenticarsi da un dispositivo preso in prestito. Fornire sempre metodi di autenticazione di fallback e testare a fondo su tutte le piattaforme target prima di implementare ottimizzazioni dei trasporti.

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

Il comportamento dei trasporti è imprevedibile: L'autenticazione cross-device (CDA) tramite trasporto hybrid mostra un comportamento incoerente tra le combinazioni di browser e sistema operativo. 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 si controllano esplicitamente i trasporti, è necessario tenere conto delle differenze tra le piattaforme:

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

Richiesta una comprensione end-to-end: Controllare esplicitamente i trasporti significa assumersi la responsabilità dell'intero flusso. È necessario capire come ogni combinazione di trasporti si comporta su tutte le piattaforme target e testare a fondo. La manipolazione dei trasporti può creare vicoli ciechi nell'autenticazione in cui non esiste un percorso di autenticazione valido per gli utenti.

Vantaggi:

• UX personalizzata: Controllare 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.
• Ottimizzazione contestuale: Adattare l'interfaccia di autenticazione in base al tipo di dispositivo.

Svantaggi:

• Comportamento imprevedibile: La manipolazione dei trasporti non garantisce un comportamento coerente dell'interfaccia utente. Test approfonditi mostrano che le piattaforme interpretano i trasporti in modo diverso, a volte mostrando o nascondendo opzioni indipendentemente dai valori dei trasporti.
• Rischio di vicoli ciechi nell'autenticazione: Un filtraggio dei trasporti troppo restrittivo può impedire completamente agli utenti di autenticarsi, specialmente in scenari cross-device.
• Devia dalle specifiche: Si allontana dalle raccomandazioni delle specifiche, potendo causare problemi con futuri cambiamenti della piattaforma.
• Onere di manutenzione: Richiede una logica specifica per piattaforma e aggiornamenti continui man mano che le piattaforme evolvono.
• Complessità: È necessario gestire manualmente gli array vuoti di iOS, i vincoli di Windows Hello e altre stranezze della piattaforma.
• Sovraccarico di test: Ogni regola di ottimizzazione necessita di verifica su tutte le combinazioni di piattaforme.

Ideale per: Applicazioni consumer con requisiti UX specifici, team con risorse per mantenere logiche specifiche per piattaforma, scenari che privilegiano flussi di autenticazione semplificati rispetto alla stretta conformità alle specifiche.

La gestione dei trasporti WebAuthn non esiste in isolamento: è un pezzo della vostra strategia complessiva di implementazione delle passkey. Emergono due approcci comuni nelle implementazioni di produzione, ognuno con diverse implicazioni per l'uso dei trasporti interni e ibridi.

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

Caratteristiche dell'Implementazione:

• UI di autenticazione: Il pulsante passkey appare accanto alle opzioni di login esistenti (username/password).
• allowCredentials: Impostato su un array vuoto [], permettendo a qualsiasi credenziale di corrispondere.
• Tipi di authenticator: Chiavi di sicurezza, autenticazione cross-device (codici QR), authenticator di piattaforma, tutti supportati.
• Requisiti delle app native: Devono 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 i login con codice QR.
• Gestione dei trasporti: Deve accogliere tutti i tipi di trasporto, inclusi quelli delle 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, questo significa che gli utenti potrebbero vedere contemporaneamente richieste per chiavi di sicurezza, codici QR e opzioni di piattaforma, il che può creare paralisi decisionale nelle applicazioni consumer.

Ideale per: Ambienti enterprise, applicazioni con basi di utenti diverse che richiedono il supporto delle chiavi di sicurezza, scenari che privilegiano la massima flessibilità di autenticazione.

Questo approccio ottimizza l'esperienza utente per i consumatori limitando la creazione di passkey agli authenticator di piattaforma e utilizzando flussi identifier-first.

Caratteristiche dell'Implementazione:

• Creazione di passkey: Consentiti solo gli authenticator di piattaforma tramite authenticatorAttachment: "platform".
• Flusso di autenticazione: Identifier-first: gli utenti inseriscono email/username prima dell'autenticazione.
• allowCredentials: Popolato con le credenziali specifiche dell'utente (non vuoto) una volta che l'identificatore è noto.
• Tipi di authenticator: Authenticator di piattaforma e autenticazione cross-device; le chiavi di sicurezza sono tipicamente escluse.
• Ottimizzazione delle app native: Può utilizzare preferImmediatelyAvailableCredentials, che per definizione esclude le chiavi di sicurezza e l'autenticazione cross-device.
• Autenticazione cross-device: Disponibile sul web; non disponibile quando si usa preferImmediatelyAvailableCredentials nelle app native, ma questo scenario è raro (gli utenti di solito hanno le passkey sul dispositivo che stanno usando).
• Gestione dei trasporti: Focalizzata solo sui trasporti internal e hybrid.

Implicazioni sui Trasporti:

Poiché allowCredentials contiene credenziali specifiche con i loro trasporti, la gestione dei trasporti diventa cruciale.

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

Per le piattaforme che già rivelano l'esistenza di un account o utilizzano flussi identifier-first (l'utente inserisce l'email prima di vedere le opzioni di login), l'approccio su misura per i consumatori si allinea naturalmente. Una volta che l'utente ha fornito il proprio identificatore:

1. Il backend cerca le passkey esistenti.
2. Restituisce allowCredentials con credenziali specifiche e i loro trasporti.
3. La piattaforma può ottimizzare l'interfaccia di autenticazione in base ai trasporti.
4. Nessun rischio aggiuntivo di enumerazione degli account (l'identificatore è già stato fornito).

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

Raccomandazione: Per le piattaforme che utilizzano già flussi identifier-first o dove l'enumerazione degli account non è una preoccupazione, l'approccio su misura per i consumatori con una gestione esplicita dei trasporti offre una UX superiore, specialmente nelle applicazioni native mobili dove preferImmediatelyAvailableCredentials abilita un'autenticazione biometrica fluida.

Indipendentemente dall'approccio scelto per la gestione dei trasporti interni e ibridi, seguite queste pratiche per ridurre al minimo i problemi:

Salvare i Trasporti Durante la Registrazione: Memorizzare sempre l'array transports dalla risposta dell'authenticator insieme al credential ID e alla chiave pubblica. Questi dati sono essenziali per i flussi di autenticazione.

Gestire con Garbo gli Array Vuoti: Quando si riceve un array di trasporti vuoto dagli authenticator di piattaforma iOS:

• Approccio conforme alle specifiche: Lasciare vuoto o omettere la proprietà transports, il che significa che "qualsiasi trasporto" è accettabile.
• Approccio di ottimizzazione: Riempire con ["internal", "hybrid"] per controllare quali opzioni di autenticazione vengono mostrate.

Testare su Tutte le Piattaforme Target: Creare una matrice di test che copra tutte le combinazioni:

• Registrazione: Web, iOS Nativo, Android Nativo
• Autenticazione: Web, iOS Nativo, Android Nativo
• Verificare che i codici QR appaiano quando previsto e siano nascosti quando inappropriato.

Comprendere la Differenza tra Array Vuoto e Proprietà Mancante: Sia un array di trasporti vuoto [] sia una proprietà transports mancante sono tipicamente trattati come "qualsiasi trasporto è accettabile" secondo le specifiche. Tuttavia, i dettagli di implementazione variano tra le piattaforme.

Monitorare i Cambiamenti delle Piattaforme: Le implementazioni di WebAuthn evolvono. Apple, Google e Microsoft aggiornano regolarmente il comportamento dei loro authenticator. Rimanere informati sui cambiamenti che potrebbero influenzare la gestione dei trasporti.

I trasporti WebAuthn, in particolare quelli interni e ibridi, sono dettagli tecnici con un impatto pratico significativo sull'autenticazione cross-device. La vostra strategia di gestione dei trasporti dovrebbe allinearsi al vostro approccio più ampio di implementazione delle passkey e alle piattaforme target.

Le Decisioni sui Trasporti Rientrano in una Strategia Più Ampia: Il modo in cui gestite i trasporti dipende dal fatto che stiate costruendo per la massima flessibilità (allowCredentials vuoto) o per l'esperienza utente consumer (identifier-first con credenziali specifiche). Quest'ultimo rende i trasporti critici per l'ottimizzazione.

Le Differenze tra Piattaforme Richiedono una Gestione: Web e Android forniscono informazioni affidabili sui trasporti, mentre gli authenticator di piattaforma iOS restituiscono array vuoti. Windows Hello invia solo ["internal"]. Comprendere queste differenze è essenziale per le implementazioni di produzione.

Due Approcci Validi per i Trasporti: Quello conforme alle specifiche (fidarsi dei trasporti dell'authenticator) funziona bene per scenari enterprise e di massima flessibilità. Il controllo esplicito (ottimizzare i trasporti) si adatta alle applicazioni consumer con flussi identifier-first e app native per dispositivi mobili.

L'Identifier-First Abilita l'Ottimizzazione dei Trasporti: Quando gli utenti forniscono prima il loro identificatore, la gestione dei trasporti diventa un potente strumento di UX. È possibile prevenire codici QR indesiderati su mobile, nascondere le opzioni delle chiavi di sicurezza e semplificare l'autenticazione, senza ulteriori preoccupazioni di enumerazione degli account.

Per Enterprise / Massima Flessibilità:

• Usare allowCredentials vuoto per supportare tutti i tipi di authenticator.
• Fidarsi dei trasporti forniti dall'authenticator.
• Accettare che gli utenti vedano più opzioni di autenticazione.
• Implementazione più semplice, compatibilità più ampia.

Per Applicazioni Consumer / App Native:

• Implementare un flusso di autenticazione identifier-first.
• Limitarsi agli authenticator di piattaforma (authenticatorAttachment: "platform").
• Usare allowCredentials con credenziali specifiche e trasporti ottimizzati.
• Abilitare preferImmediatelyAvailableCredentials nelle app native.
• Riempire gli array vuoti di iOS con ["hybrid", "internal"].
• Filtrare hybrid sui dispositivi mobili per prevenire i codici QR.
• UX superiore con opzioni di autenticazione semplificate.

Per Piattaforme con Flussi Identifier-First Già Esistenti:

• L'enumerazione degli account non è già un problema.
• L'approccio su misura per i consumatori si allinea naturalmente con l'UX esistente.
• L'ottimizzazione dei trasporti offre vantaggi immediati per la UX.
• Approccio raccomandato per la maggior parte delle applicazioni consumer.

Iniziare in modo conforme alle specifiche, poi ottimizzare in base alla vostra strategia:

1. Salvare i trasporti esattamente come ricevuti durante la registrazione.
2. Decidere la vostra strategia generale (massima flessibilità vs. su misura per i consumatori).
3. Se su misura per i consumatori: implementare il flusso identifier-first e ottimizzare i trasporti.
4. Gestire gli array vuoti di iOS in modo appropriato per la strategia scelta.
5. Testare a fondo su piattaforme Web, iOS Native e Android Native.

Il panorama WebAuthn continua a evolversi. I fornitori di piattaforme aggiornano regolarmente le loro implementazioni e specifiche come WebAuthn Level 3 introducono nuove capacità. Costruire sistemi flessibili che allineano la gestione dei trasporti con la vostra strategia di autenticazione più ampia garantisce che la vostra implementazione di passkey rimanga robusta e offra esperienze utente eccellenti man mano che l'ecosistema matura.