Passkey per app native: Implementazione nativa vs. WebView

Questo articolo spiega come implementare le passkey nelle app native (iOS + Android). Scoprirai quale tipo di WebView è consigliato per l'autenticazione con passkey.

Our mission is to make the Internet a safer place, and the new login standard passkeys provides a superior solution to achieve that. That's why we want to help you understand passkeys and its characteristics better.

1. Scelte di implementazione delle passkey per app native#

L'autenticazione funge da sentinella, salvaguardando i dati degli utenti e garantendo interazioni sicure all'interno delle app native. L'avvento delle passkey ha rivoluzionato questo settore, offrendo un meccanismo di autenticazione robusto e di facile utilizzo. Esistono due modi principali per integrare le passkey in un'app nativa: tramite implementazione nativa o tramite WebView. Vediamo prima come si confrontano i due metodi.

1.1 Implementazione nativa: ottima UX#

Un'implementazione nativa è spesso considerata la soluzione che offre la migliore esperienza utente all'interno di un'app. È caratterizzata da interazioni utente fluide, integrate e coese, adattate precisamente all'ambiente del sistema operativo, che si tratti di iOS o Android. Il requisito per un'implementazione 100% nativa è diventare 100% senza password ed essere veramente passkey-native. Questo approccio ti libera dal potenziale attrito della transizione tra l'app nativa e il contenuto web (visualizzato tramite una WebView).

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

1.2 Implementazione WebView: esperienza simile a un browser#

Quando si sviluppa un'app nativa, il percorso per diventare completamente nativi non è sempre possibile. In scenari in cui è ancora necessario supportare l'autenticazione basata su password utilizzando OAuth2, un'integrazione completamente nativa potrebbe non essere fattibile, rendendo le implementazioni WebView l'unica alternativa praticabile. WebView funge da ponte, incorporando contenuti web direttamente all'interno della tua app, fornendo un'esperienza utente simile a quella di un browser durante la navigazione tra le pagine web. Ciò è particolarmente pertinente se sei tu stesso un provider di OAuth2, se la tua soluzione di autenticazione sottostante è basata su OAuth2 o se la tua soluzione di login utilizza accessi social tramite terze parti, come Google o GitHub. In questi casi, l'impiego di una WebView diventa inevitabile a causa della necessità di interagire con i contenuti web e di gestire vari flussi di autenticazione utente, specialmente quando sono richieste associazioni di app native.

In sostanza, mentre le implementazioni native offrono un'esperienza utente fluida e senza pari, potrebbero non essere sempre un'opzione praticabile, specialmente se abbinate a soluzioni di autenticazione basate su password o OAuth2. D'altra parte, le implementazioni WebView forniscono un percorso flessibile, anche se leggermente meno fluido, per integrare contenuti web e gestire l'autenticazione utente all'interno della tua app, garantendo la possibilità di navigare tra le complessità dei vari flussi di autenticazione e degli accessi di terze parti.

Le prossime sezioni di questo articolo si concentrano sull'implementazione tramite WebView. Per saperne di più sull'integrazione nativa delle passkey, consulta questo articolo.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

Oltre 10.000 sviluppatori si affidano a Corbado e rendono Internet più sicuro con le passkey. Hai domande? Abbiamo scritto più di 150 articoli sulle passkey.

Unisciti alla community delle passkey

2. Panoramica delle opzioni WebView#

Navigando nel labirinto dell'autenticazione nelle app native, sviluppatori e product manager si trovano di fronte a una decisione cruciale: implementare l'autenticazione con passkey in modo nativo o tramite WebView. Se si opta per quest'ultima, sia le piattaforme iOS che Android offrono due tipi distinti di WebView, ciascuno con i propri attributi unici e potenziali casi d'uso.

2.1 WebView per iOS#

WKWebView
SFSafariViewController
SFAuthenticationSession / ASWebAuthenticationSession (specificamente progettato per flussi di autenticazione basati su OAuth / OpenID Connect)

2.1 WebView per Android#

WebView
Chrome Custom Tabs (CCT)

Nelle sezioni seguenti, approfondiremo questi tipi di WebView e, infine, ti guideremo verso una decisione informata su quale WebView utilizzare per l'autenticazione con passkey nelle tue app native (se un'implementazione puramente nativa non è un'alternativa).

Subscribe to our Passkeys Substack for the latest news.

3. WebView in iOS#

Le WebView di iOS sono WKWebView o SFSafariViewController (se si lavora con OAuth / OIDC, si tratta di SFAuthenticationSession / ASWebAuthenticationSession).

Per testare il diverso comportamento delle WebView in iOS, consigliamo l'app WebView - WKWebView and UIWebView rendering.

3.1 WKWebView#

WKWebView è un'opzione WebView potente e versatile disponibile per gli sviluppatori iOS. Introdotta con iOS 8, consente agli sviluppatori di incorporare contenuti web direttamente all'interno di un'app, fornendo un'ampia gamma di opzioni di personalizzazione e configurazione. WKWebView è rinomata per le sue prestazioni, utilizzando lo stesso motore di rendering web di Safari e offrendo un ricco set di API per interagire con i contenuti web, gestire la navigazione, le interazioni dell'utente e altro ancora.

3.2 SFSafariViewController#

SFSafariViewController è una WebView che consente agli sviluppatori di sfruttare le funzionalità di Safari direttamente all'interno delle loro app. Fornisce un'esperienza utente fluida utilizzando le impostazioni Safari dell'utente, come password salvate, passkey, cookie e altro, garantendo una navigazione web coerente, poiché in realtà viene eseguita come applicazione Safari. SFSafariViewController non è personalizzabile come WKWebView, ma offre funzionalità di sicurezza avanzate e facilità d'uso, rendendola una scelta preferita per la visualizzazione di contenuti web semplici all'interno delle app.

	WKWebView	SFSafariViewController
Esperienza utente	- Sensazione nativa: Gli utenti potrebbero percepire il contenuto web come una parte nativa dell'app perché gli sviluppatori possono personalizzare l'aspetto per abbinarlo al design dell'app. - Completamento automatico: È possibile il completamento automatico con i dati di Safari	- Fluida: Esperienza utente fluida che utilizza le impostazioni Safari dell'utente, garantendo una navigazione web coerente tra l'app nativa e il browser.
Esperienza sviluppatore	- Altamente personalizzabile: Ampia personalizzazione e configurazione disponibili - Flessibile: Molte API per interagire con i contenuti web	- Mediamente personalizzabile: Opzioni di personalizzazione limitate, specialmente rispetto a WKWebView, - Semplice: Più semplice da implementare rispetto a WKWebView
Prestazioni	- Piuttosto lento: A seconda dell'implementazione e del contenuto web, le velocità di caricamento possono essere ottimizzate, ma potrebbero comunque essere più lente rispetto a SFSafariViewController a causa dell'elaborazione aggiuntiva di funzionalità e interazioni personalizzate.	- Piuttosto veloce: Offre tipicamente prestazioni migliori poiché sfrutta il motore di Safari, ottimizzato per velocità ed efficienza, fornendo tempi di caricamento rapidi per le pagine web.
Fiducia e riconoscimento	- Visualizzazione dell'URL non richiesta: WKWebView spesso non mostra l'URL, rendendo più difficile per gli utenti verificare la pagina web. Potenziale per app dannose di imitare questo comportamento e fare phishing di credenziali.	- Esperienza simile a un browser: Esegue il rendering delle pagine web utilizzando Safari, fornendo un'esperienza "simile a un browser". Gli utenti possono vedere l'URL e accedere alle funzionalità di completamento automatico di Safari, infondendo potenzialmente più fiducia grazie all'interfaccia familiare.
Isolamento	- Separati: Cookie e sessioni sono separati da Safari; gli utenti non verranno automaticamente autenticati in una WKWebView.	- Separati: Anche cookie e sessioni sono separati da Safari; gli utenti non verranno automaticamente autenticati in SFSafariViewController.
Vulnerabilità	- Sicuro: Intrinsecamente sicuro grazie al sandboxing delle app di Apple, ma il comportamento e la sicurezza dipendono dall'implementazione dell'app. Potenziali vulnerabilità se non implementato correttamente.	- Più sicuro: Beneficia delle funzionalità di sicurezza integrate di Safari, inclusi avvisi anti-phishing e siti web dannosi. Generalmente considerato più sicuro per la visualizzazione di contenuti web rispetto a WKWebView grazie a queste funzionalità e alla familiarità dell'utente con Safari.
Altro	- Funzionalità non disponibili: Alcune funzionalità del browser (ad es. WebAuthn) potrebbero non essere completamente accessibili a causa di problemi di sicurezza e del fatto che WKWebView viene eseguito nel contesto dell'applicazione. - Iniezione di JavaScript: Alcune app, ad es. TikTok, iniettano JavaScript di tracciamento nella loro WKWebView in-app o limitano il controllo dell'utente (ad es. Facebook) - Problemi di privacy: Maggiori feedback dalla community riguardo alla privacy	- Nessuna iniezione di JavaScript: Non consente l'esecuzione di JavaScript dall'app, migliorando la sicurezza e la privacy. Inoltre, non supporta avvisi o conferme JavaScript, il che potrebbe influire sull'esperienza utente su determinate pagine web. - Modalità lettura: Fornisce una modalità lettura per una versione pulita e di facile lettura degli articoli.

3.3 SFAuthenticationSession / ASWebAuthenticationSession#

SFAuthenticationSession e ASWebAuthenticationSession sono WebView specificamente progettate per flussi di autenticazione basati su OAuth / OpenID Connect. Forniscono uno spazio sicuro e isolato per l'autenticazione dell'utente, salvaguardando le credenziali dell'utente e garantendo che le informazioni private non vengano condivise inavvertitamente con l'app. Queste sessioni condividono cookie e dati del sito web con Safari, fornendo un'esperienza utente coerente e fluida, specialmente durante i processi di autenticazione.

Pro:

Autenticazione dedicata: Progettato specificamente per flussi di autenticazione basati su OAuth / OpenID Connect, garantendo un processo di autenticazione semplificato.
Protezione della privacy: Garantisce la privacy dei dati dell'utente non condividendo cookie o dati del sito web con l'app.
Supporto SSO: Supporta il Single Sign-On, fornendo un'esperienza utente comoda.

Contro:

Caso d'uso limitato: Principalmente focalizzato sull'autenticazione OAuth / OpenID Connect, che potrebbe non essere adatta a tutti i casi d'uso.

Quando il compito principale è l'autenticazione dell'utente, specialmente quando si implementa il SSO o si interagisce con i provider OAuth, si dovrebbe usare SFAuthenticationSession / ASWebAuthenticationSession invece di SFSafariViewController.

Want to find out how many people use passkeys?

View Adoption Data

4. WebView in Android#

Le WebView di Android sono WebView o Chrome Custom Tabs (CCT). Per testare il diverso comportamento delle WebView in Android, consigliamo l'app WebView vs Chrome Custom Tabs.

4.1 Android WebView#

WebView su Android è un componente completo che consente agli sviluppatori di visualizzare contenuti web come parte dell'interfaccia utente dell'app. È versatile, offre una vasta gamma di opzioni di personalizzazione e fornisce agli sviluppatori la flessibilità di configurare la WebView per soddisfare varie esigenze. WebView fornisce un ricco set di API per interagire con i contenuti web, gestire le interazioni dell'utente e persino gestire dialoghi JavaScript, certificati client e richieste di autorizzazione.

4.2 Chrome Custom Tabs (CCT)#

Chrome Custom Tabs (CCT) offre un modo fluido, sicuro ed efficiente per integrare i contenuti web direttamente nella tua app. Sfruttando le capacità e le funzionalità di sicurezza di Chrome, CCT offre un'esperienza utente coerente e ad alte prestazioni.

CCT è un componente del browser Chrome, progettato per integrarsi con il framework Android, consentendo alle app di aprire contenuti web in un processo leggero e dedicato. In particolare, si apre più velocemente di un browser convenzionale e, se precaricato tramite la sua chiamata di riscaldamento, può potenzialmente superare le prestazioni di una WebView. Sebbene esegua JavaScript, opera nel suo processo, proteggendo le app dall'esecuzione di codice dannoso. Inoltre, l'interfaccia utente di CCT fornisce una barra delle azioni, che mostra l'URL e un'icona di lucchetto per la verifica SSL per le pagine sicure, rassicurando così gli utenti sull'autenticità e la sicurezza della pagina caricata.

In generale, si può dire che iOS WKWebView e Android WebView, così come SFSafariViewController e Chrome Custom Tabs (CCT) sono simili.

Funzionalità	WebView	Chrome Custom Tab
Esperienza utente	- Flessibilità: Fornisce un ricco set di API per interagire con i contenuti web e gestire le interazioni dell'utente, inclusa la gestione dei dialoghi JavaScript e delle richieste di autorizzazione. - Coerenza: Gestire un'esperienza utente coerente, specialmente con contenuti web variegati, può essere impegnativo.	- Funzionalità del browser: Condivide funzionalità come il Risparmio dati e il completamento automatico sincronizzato tra i dispositivi. - Pulsante Indietro: Consente agli utenti di tornare facilmente all'app con un pulsante Indietro integrato. - Dipendenza: Si basa sull'app Chrome, che potrebbe non essere disponibile o aggiornata su tutti i dispositivi degli utenti. - Reindirizzamento al browser: Alcune funzionalità potrebbero reindirizzare gli utenti all'app Chrome, interrompendo potenzialmente l'esperienza utente. - Schede personalizzate parziali: Solo una parte dello schermo può essere utilizzata per la Chrome Custom Tab mentre il resto mostra l'app nativa. - Foglio laterale: In modalità orizzontale e su dispositivi a schermo grande, la Chrome Custom Tab viene visualizzata solo su un lato dello schermo, mentre il resto dello schermo mostra l'app nativa.
Esperienza sviluppatore	- Altamente personalizzabile: Offre ampie opzioni/esigenze di personalizzazione. - Interattività: Fornisce numerose API per interagire con i contenuti web e gestire le interazioni dell'utente.	- Personalizzabile: Consente la personalizzazione del colore della barra degli strumenti, del pulsante di azione, della barra degli strumenti inferiore, delle voci di menu personalizzate e delle animazioni di ingresso/uscita. - Callback: Fornisce un callback all'applicazione in caso di navigazione esterna. - Funzionalità di sicurezza: Fornisce funzionalità pronte all'uso, eliminando la necessità di gestire richieste, concessioni di autorizzazioni o archivi di cookie.
Prestazioni	- Prestazioni mediocri: Potrebbe non offrire lo stesso livello di prestazioni delle Chrome Custom Tabs (CCT).	- Pre-riscaldamento: Include il pre-riscaldamento del browser in background e il caricamento speculativo degli URL per migliorare il tempo di caricamento della pagina. - Priorità: Impedisce che le app che avviano una Custom Tab vengano terminate durante il loro utilizzo elevando la loro importanza al livello "primo piano".
Fiducia e riconoscimento	- URL e SSL non visibili: L'URL e le informazioni SSL non sono intrinsecamente visibili in una WebView. A meno che lo sviluppatore dell'app non implementi queste funzionalità, gli utenti non sapranno se si trovano sul sito web corretto o su uno di phishing.	- URL e SSL visibili: Utilizza il browser Chrome effettivo per il rendering delle pagine. Gli utenti possono vedere l'URL e il certificato SSL (che indica se la connessione è sicura). Ciò può dare agli utenti la certezza di non trovarsi su un sito di phishing.
Isolamento	- Eseguito nel processo dell'app: Se un'app ha una vulnerabilità che consente l'esecuzione di codice dannoso, c'è il rischio che la WebView possa essere compromessa. Tuttavia, anche la WebView riceve aggiornamenti, ma il suo comportamento e la sua sicurezza possono dipendere maggiormente dall'app che la utilizza. - Nessuna condivisione di cookie/sessioni: Non condivide cookie o sessioni con il browser principale del dispositivo, offrendo isolamento ma richiedendo potenzialmente agli utenti di effettuare nuovamente l'accesso.	- Eseguito nel processo di Chrome: Essendo parte di Chrome, le Custom Tabs vengono eseguite nello stesso processo e hanno gli stessi aggiornamenti di sicurezza e le stesse funzionalità di Chrome. - Condivisione di cookie e modello di autorizzazioni: Assicura che gli utenti non debbano accedere nuovamente ai siti o concedere nuovamente le autorizzazioni. - Impostazioni e preferenze di Chrome: Utilizza le impostazioni e le preferenze di Chrome.
Vulnerabilità	- Callback per rubare le credenziali: Le potenziali vulnerabilità includono il fatto che a volte è richiesto JavaScript, il che apre la porta ad altre app per eseguire codice dannoso, come la registrazione di callback che tentano di intercettare nomi utente e password. - Phishing: Inoltre, un'app dannosa potrebbe aprire un'altra pagina web che imita il flusso di Link in un tentativo di phishing.	- Navigazione sicura di Google: Impiega la Navigazione sicura di Google per proteggere sia l'utente che il dispositivo da siti pericolosi. - Decorazione sicura del browser: Assicura che l'utente veda sempre l'URL esatto con cui sta interagendo e possa visualizzare le informazioni sul certificato del sito web, riducendo il rischio di phishing. Inoltre, le schede personalizzate non consentono l'iniezione di JavaScript.
Altro	- Google ha vietato le WebView per l'accesso degli utenti agli account Google.

5. Raccomandazione per l'implementazione delle passkey nelle app native#

I nostri clienti ci chiedono continuamente come implementare le passkey nelle app native. In gran parte, questi clienti possono essere suddivisi in diversi gruppi:

Gruppo A:

Clienti che iniziano a costruire la loro app nativa da zero e possono utilizzare direttamente la nostra autenticazione senza password (non esistono password legacy).

Gruppo B:

Clienti con utenti esistenti e una soluzione di autenticazione esistente. Spesso hanno già un'app web esistente che deve anche aggiungere le passkey al suo processo di autenticazione. Qui molte aziende decidono di seguire un processo in due fasi:

Aggiungere le passkey al flusso di autenticazione WebView esistente (è così che Google e GitHub le hanno implementate nelle loro app native)
Aggiungere le passkey tramite implementazione nativa in aggiunta. Questa implementazione nativa delle passkey controlla, prima della vecchia WebView (ad es. per accessi social e password), se l'utente può accedere con una passkey (è così che KAYAK l'ha implementata nella sua app nativa).

Determina il tuo gruppo

Per fornire ai tuoi utenti la migliore implementazione di passkey in un'app nativa, devi decidere a quale gruppo appartieni, in base alla tua attuale configurazione tecnica e a come vuoi promuovere le passkey (questa domanda è rilevante per le aziende del gruppo B).

Raccomandazione per il Gruppo A: Implementazione nativa

Se stai costruendo un'app completamente nuova (gruppo A), ti consigliamo di optare per un'implementazione nativa delle passkey e di passare subito al senza password (quindi non viene utilizzato alcun tipo di WebView). Utilizza gli SDK e le API native per iOS e Android (ad es. tramite il pacchetto Flutter per passkey). Leggi anche questo articolo sugli ID della Relying Party.

Raccomandazione per il Gruppo B: Prima WebView, poi implementazione nativa

Se oggi non puoi implementare le passkey in modo nativo per qualsiasi motivo (gruppo B), puoi iniziare con un'implementazione WebView e poi passare in futuro a un'implementazione nativa delle passkey (questo funziona tramite la creazione di file di associazione, come apple-app-site-association per le app iOS e assetlinks.json per le app Android). I motivi per scegliere un'implementazione WebView potrebbero includere:

Offri già un'autenticazione basata su OAuth2 e vuoi continuare a offrirla ai tuoi utenti (OAuth2 non funziona in modo nativo, vedi lo standard qui)
Vuoi offrire l'autenticazione con passkey nella stessa finestra/schermata in cui offri gli altri metodi di autenticazione (ad es. password, accessi social, OAuth2)

Questo è il modo in cui Google o GitHub hanno attualmente implementato l'autenticazione con passkey nelle loro app native. Consulta la raccomandazione di seguito per configurare correttamente le WebView per l'autenticazione con passkey. Tuttavia, consigliamo di considerare un'implementazione nativa delle passkey come ha fatto KAYAK e di iniziare direttamente con il passaggio 2.

Se appartieni al gruppo B e non puoi implementare le passkey in modo nativo, la nostra raccomandazione pende verso l'utilizzo di SFAuthenticationSession / ASWebAuthenticationSession per iOS e Chrome Custom Tabs per Android (altrimenti le passkey non funzioneranno comunque).

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Di seguito, elenchiamo i motivi di questa raccomandazione:

SFAuthenticationSession / ASWebAuthenticationSession condividono cookie e dati del sito web con Safari, fornendo un'esperienza utente fluida durante i processi di autenticazione. Lo stesso vale per le Chrome Custom Tabs su Android.

Gli utenti beneficiano delle loro password salvate, dei dati di completamento automatico e di altre informazioni memorizzate nel browser, rendendo il processo di autenticazione più fluido e veloce.

5.2 Sicurezza migliorata#

SFAuthenticationSession / ASWebAuthenticationSession su iOS e Chrome Custom Tabs su Android forniscono uno spazio sicuro e isolato per l'autenticazione dell'utente, garantendo che le credenziali sensibili dell'utente siano salvaguardate e non condivise inavvertitamente con l'app o altri siti web.

Aderiscono ai rigorosi protocolli di sicurezza di Apple e Google, garantendo che i dati degli utenti siano gestiti in modo sicuro e che la privacy sia mantenuta.

Inoltre, questa scelta di progettazione beneficia degli aggiornamenti e dei miglioramenti continui della sicurezza di Safari e Chrome, garantendo l'adesione ai più recenti standard e protocolli di sicurezza.

5.3 Esperienza utente#

SFAuthenticationSession / ASWebAuthenticationSession su iOS e Chrome Custom Tabs su Android forniscono un'interfaccia utente coerente e familiare, poiché gli utenti sono abituati all'esperienza utente del browser. Inoltre, vengono applicate le impostazioni e le preferenze utente di Safari e Chrome.

Fornisce una transizione fluida tra il contenuto dell'app e il contenuto web, garantendo che gli utenti non siano disturbati dal passaggio tra le interfacce.

5.4 Prestazioni#

Le Chrome Custom Tabs sfruttano le prestazioni di Chrome, garantendo un'esperienza utente fluida e reattiva, particolarmente cruciale durante i processi di autenticazione per prevenire la frustrazione o l'abbandono dell'utente.

Le prestazioni di CCT sono spesso superiori alle opzioni di Android WebView (lo stesso vale per SFAuthenticationSession / ASWebAuthenticationSession su iOS), garantendo che i contenuti web e i flussi di autenticazione siano gestiti in modo rapido e fluido.

Vedi anche questo confronto di Google per percepire le differenze di prestazioni tra Chrome Custom Tabs, Android WebView e il browser Chrome standard.

5.5 Dedicato ai flussi di autenticazione#

SFAuthenticationSession / ASWebAuthenticationSession è specificamente progettato per gestire flussi di autenticazione basati su OAuth / OpenID Connect, garantendo un processo semplificato e sicuro per questi protocolli di autenticazione ampiamente utilizzati. È anche il modo consigliato per l'autenticazione WebAuthn / passkey.

Su Android, non esiste una classe dedicata per i flussi di autenticazione, ma un comportamento simile può essere implementato con Chrome Custom Tabs e Android App Links.

Inoltre, ci aspettiamo che più app introducano le passkey come TikTok, semplicemente raccogliendole quando l'utente è autenticato. Questo può essere fatto in modo nativo (implementazione di TikTok) o tramite un'implementazione WebView. Un approccio adatto è attivare la Conditional UI in modo nativo. Se non funziona, si visualizza l'implementazione WebView.

6. Conclusione#

Nel panorama moderno dell'autenticazione digitale, l'implementazione delle passkey tramite WebView nelle app native emerge come un faro di pratica sicura e user-friendly. Sebbene il percorso per la scelta della WebView ottimale possa essere complesso, è fondamentale allineare le scelte tecnologiche con l'esperienza utente e la sicurezza.