Passkey e iframe: come creare e accedere con una passkey?

Legenda
✅ = supportato ❌ = non supportato

Settimana dopo settimana, sempre più organizzazioni annunciano l'introduzione delle passkey (come di recente Visa, Mastercard o Vercel). Man mano che sviluppatori e product manager di altre aziende seguono questi modelli di riferimento, vengono discussi sempre più casi d'uso per l'implementazione delle passkey.

Un caso che ci viene costantemente richiesto riguarda il funzionamento delle passkey negli iframe, poiché gli iframe sono ampliamente utilizzati nello sviluppo web moderno per incorporare contenuti da diverse fonti in modo fluido. Nel contesto delle passkey e di WebAuthn, gli iframe presentano una serie di sfide proprie, soprattutto per quanto riguarda la sicurezza e le interazioni con l'utente.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Questo post del blog fornisce una guida completa all'uso di passkey e WebAuthn negli iframe. Nello specifico:

• Esploreremo le funzionalità attuali
• Discuteremo il supporto per iframe cross-origin
• Evidenzieremo i vantaggi dell'integrazione con iframe e
• Forniremo una guida all'implementazione passo-passo

Al termine di questo post, avremo una chiara comprensione di come sfruttare le passkey all'interno degli iframe.

Gli iframe, o inline frame, sono elementi HTML che consentono agli sviluppatori di incorporare un altro documento HTML all'interno del documento corrente. Questa funzionalità è ampiamente utilizzata per integrare contenuti da fonti esterne, come video, mappe e altre pagine web, in un sito.

Diamo un'occhiata ai diversi tipi di iframe.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

L'iframe di base è il tipo più comune. Incorpora semplicemente contenuti da un altro URL all'interno della pagina corrente.

<iframe src="https://example.com"></iframe>

Questo iframe di base è spesso utilizzato per includere contenuti statici, come un articolo, all'interno di una pagina web.

Gli iframe responsivi sono progettati per adattare le loro dimensioni in base alle dimensioni dello schermo o del contenitore in cui sono inseriti. Ciò garantisce che il contenuto incorporato abbia un bell'aspetto su tutti i dispositivi, inclusi desktop, tablet e telefoni cellulari.

<iframe src="https://example.com" style="width: 100%; height: 500px;"></iframe>

Le media query CSS possono anche essere utilizzate per far sì che l'iframe si adatti dinamicamente in base alle dimensioni del viewport.

Get a free passkey assessment in 15 minutes.

Book free consultation

Un iframe sicuro o sandboxed limita le azioni che possono essere eseguite al suo interno. È utile per incorporare contenuti da fonti non attendibili o per migliorare la sicurezza.

<iframe src="https://example.com" sandbox></iframe>

L'attributo sandbox può includere varie restrizioni, come:

<iframe src="https://example.com" sandbox="allow-scripts allow-same-origin"></iframe>

L'attributo sandbox consente l'esecuzione di script ma limita azioni potenzialmente pericolose, come l'invio di moduli o l'uso di plugin.

Become part of our Passkeys Community for updates & support.

Join

Gli iframe cross-origin incorporano contenuti da un dominio diverso. Sono comunemente usati per integrare servizi di terze parti, come gateway di pagamento o widget di social media. A causa delle restrizioni di sicurezza, questi iframe hanno un accesso limitato al contenuto della pagina che li incorpora e viceversa.

Cross-origin significa che il contenuto caricato proviene da un'origine diversa, dove un'origine è definita dalla combinazione di schema (protocollo), host (dominio) e numero di porta. Ad esempio, https://example.com e http://example.com sono considerate origini diverse perché utilizzano schemi diversi (HTTP vs. HTTPS).

Allo stesso modo, i sottodomini sono trattati come origini separate dai loro domini principali. Ad esempio, https://example.com e https://sub.example.com sono cross-origin, anche se condividono lo stesso dominio di base. Questa separazione garantisce che script e dati di un sottodominio non possano interagire direttamente con quelli di un altro senza un'autorizzazione esplicita, migliorando la sicurezza.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Le aziende si affidano a Corbado per proteggere i propri utenti e rendere gli accessi più fluidi con le passkey. Richiedi subito la tua consulenza gratuita sulle passkey.

Richiedi una consulenza gratuita

Ecco alcuni esempi per illustrare i concetti di cross-origin e same-origin:

Esempio cross-origin:

Incorporare contenuti da https://payment.example.com in una pagina web ospitata su https://www.mystore.com. Queste sono cross-origin perché hanno domini diversi.

Esempio same-origin:

Incorporare contenuti da https://www.example.com/shop in una pagina web ospitata su https://www.example.com/blog. Queste sono same-origin perché condividono lo stesso schema, host e porta.

Gli iframe cross-origin si differenziano dagli iframe di base in quanto la fonte proviene da un altro dominio, mentre un iframe same-site ha la sua fonte dallo stesso dominio in cui è incorporato.

<iframe src="https://anotherdomain.com"></iframe>

L'uso delle passkey negli iframe introduce nuove funzionalità e vincoli che gli sviluppatori devono comprendere, principalmente legati all'impostazione delle autorizzazioni corrette e alla garanzia di interazioni utente sicure nel contesto incorporato.

In passato, l'API Web Authentication era disabilitata di default negli iframe cross-origin, principalmente per motivi di sicurezza. Questa limitazione significava che gli sviluppatori dovevano reindirizzare gli utenti o utilizzare finestre pop-up per l'autenticazione, portando a un'esperienza utente meno fluida.

Nelle passkey / WebAuthn, ci sono due operazioni principali (chiamate anche cerimonie):

1. Registrare / creare una passkey
2. Autenticare / accedere con una passkey

Le due operazioni non erano e non sono supportate allo stesso modo negli iframe cross-origin:

Inizialmente, l'accesso tramite iframe cross-origin è stato reso possibile ma la creazione cross-origin non ancora perché non c'era nessuno con un caso d'uso.

Recenti progressi (ad esempio in Chrome 123) hanno introdotto il supporto per la creazione di passkey in iframe cross-origin a determinate condizioni. Tuttavia, a maggio 2024, non tutti i browser supportano pienamente la creazione di passkey tramite iframe cross-origin, sebbene l'accesso sia possibile con la maggior parte dei browser.

Inoltre, il supporto per iframe cross-origin (per le operazioni di registrazione e autenticazione) è già incorporato nella specifica WebAuthn Level 3 in corso di sviluppo. Alcuni browser devono ancora adeguarsi alla specifica (ad esempio Safari). Sfortunatamente, Apple non ha ancora annunciato se e quando consentirà la registrazione cross-origin di passkey all'interno di Safari. Questo eliminerebbe la più significativa limitazione tecnica all'uso delle passkey in iframe cross-origin.

Nelle prossime sezioni del post, assumeremo l'uso di iframe cross-origin.

Want to find out how many people use passkeys?

View Adoption Data

Le seguenti tabelle forniscono una panoramica del supporto di browser/standard per l'autenticazione tramite iframe e l'accesso tramite passkey in contesti di iframe cross-origin:

A maggio 2024, la creazione di una passkey in un iframe cross-origin non è ancora possibile in tutti i browser. La seguente tabella fornisce una panoramica del supporto di browser / standard per la registrazione / creazione di passkey in iframe cross-origin:

Se siete interessati a maggiori dettagli su questo sviluppo e supporto, vi consigliamo di dare un'occhiata a questa issue di GitHub e a questa Pull Request.

Ci sono due principali casi d'uso per il supporto delle passkey negli iframe cross-origin.

Abilitare le passkey negli iframe cross-origin è cruciale per gli scenari di identità federata in cui sono coinvolti più domini ma si dovrebbero utilizzare gli stessi account utente.

Prendiamo il seguente scenario. Siete un'azienda multinazionale come KAYAK e avete domini diversi per regioni diverse:

• www.kayak.com
• www.kayak.us
• www.kayak.de

Tuttavia, avete un sistema di gestione dell'identità centrale che consente agli utenti di accedere con lo stesso account e le stesse credenziali su tutti questi domini. Lo standard WebAuthn porrebbe una sfida a questi scenari, poiché le passkey possono essere legate a un solo dominio (ID del Relying Party), ad esempio www.kayak.com.

Per superare questa sfida, si utilizzerebbe un iframe dall'origine www.kayak.com su tutti gli altri domini. Quindi si incorpora un iframe con origine www.kayak.com su www.kayak.us e su www.kayak.de (iframe cross-origin). Altrimenti, l'uso delle vostre passkey legate a "www.kayak.com" su questi altri domini non sarebbe possibile a causa della resistenza al phishing delle passkey.

Nota a margine: anche la nuova funzionalità di WebAuthn Related Origin Requests (RoR) potrebbe essere utilizzata in alternativa. Questa funzionalità consente alle "origini correlate" di accedere alle passkey senza iframe, ma non è ancora supportata da tutti i browser.

Anche per flussi di pagamento fluidi, l'uso delle passkey in iframe cross-origin gioca un ruolo importante. Considerate il seguente scenario: un cliente vuole acquistare nuove scarpe sul sito di un esercente (ad esempio www.amazon.com). Il sito di questo esercente consente al cliente di pagare tramite il conto bancario (ad esempio su www.revolut.com) e quindi richiede all'utente di accedere al sito della banca (questo è un processo semplificato). L'utente accede al sito della banca con una passkey legata all'ID del Relying Party della banca, ad esempio "revolut.com".

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Per evitare di reindirizzare l'utente dal sito dell'esercente (www.amazon.com) al sito della banca (www.revolut.com) durante il processo di checkout e far accedere l'utente lì al conto bancario, si può utilizzare un iframe cross-origin. In questo modo, l'utente rimane su www.amazon.com e utilizza la passkey nell'iframe cross-origin per l'autenticazione che ha creato per www.revolut.com.

Quindi, integrare le passkey tramite iframe cross-origin nei flussi di pagamento garantisce transazioni sicure e ottimizzate tra consumatori, esercenti e banche:

Nel contesto dei pagamenti e delle passkey, consigliamo anche di dare un'occhiata al nostro post sul blog su Secure Payment Confirmation (SPC) e dynamic linking con le passkey. Assicuratevi di dare un'occhiata anche alle limitazioni per il contesto di terze parti nelle app native di seguito.

Inoltre, per una visione più approfondita dei flussi di pagamento cross-origin con le passkey, consultate il nostro articolo Passkey per fornitori di pagamenti: come creare un SDK di terze parti.

In generale, l'integrazione delle passkey all'interno degli iframe offre diversi vantaggi, principalmente migliorando la UX e la sicurezza. Ecco un'analisi di questi vantaggi:

Migliore esperienza utente (UX)

1. Nessun pop-up o reindirizzamento: Gli utenti possono autenticarsi direttamente all'interno del contenuto incorporato senza reindirizzamenti o pop-up, ottenendo un'esperienza più fluida e meno interruttiva.
2. UX coerente tra i siti: Incorporare i flussi di autenticazione all'interno di iframe garantisce un'esperienza utente coerente tra diverse sezioni di un sito web o tra siti web diversi che utilizzano lo stesso servizio di autenticazione.

Maggiore sicurezza

1. Transazioni sicure: Per scenari come i pagamenti, le passkey negli iframe migliorano la sicurezza delle transazioni garantendo che l'autenticazione avvenga all'interno di un contesto sicuro e incorporato.
2. Uso di un account utente su siti web diversi: Nelle configurazioni di identità federata, le passkey in iframe cross-origin consentono una verifica dell'identità sicura ed efficiente su più domini.

L'implementazione delle passkey negli iframe comporta alcuni passaggi chiave per garantire sicurezza e funzionalità. Forniamo una guida dettagliata per gli sviluppatori. Si veda anche l'implementazione di esempio su https://cross-origin-iframe.vercel.app/.

L'header HTTP Permissions-Policy aiuta a consentire o negare l'uso di determinate funzionalità del browser in un documento o all'interno di un elemento iframe. Per abilitare l'accesso con passkey in un iframe, è necessario impostare le permission policy publickey-credentials-get e publickey-credentials-create. Le policy consentono al contenuto incorporato di invocare il metodo API WebAuthn necessario per autenticarsi (navigator.credentials.get({publicKey})) e creare una passkey (navigator.credentials.create({publicKey})).

<iframe src="https://passkeys.eu" allow="publickey-credentials-get; publickey-credentials-create"></iframe>

La Permissions Policy HTTP era precedentemente chiamata Feature Policy. Con la Feature Policy, si poteva concedere una funzionalità a un iframe cross-origin aggiungendo l'origine all'elenco di origini dell'header o includendo un attributo allow nel tag iframe. Con la Permissions Policy, l'aggiunta di un frame cross-origin all'elenco di origini richiede che il tag iframe per quell'origine includa l'attributo allow. Se la risposta non ha un header Permissions Policy, l'elenco di origini assume il valore predefinito * (tutte le origini). L'inclusione dell'attributo allow nell'iframe concede l'accesso alla funzionalità.

Per garantire che gli iframe cross-origin non specificati nell'elenco di origini siano bloccati dall'accedere alla funzionalità, anche se l'attributo allow è presente, gli sviluppatori possono impostare esplicitamente l'header Permissions Policy nella risposta.

In Chrome 88+, la Feature Policy può ancora essere utilizzata, ma agisce come un alias per la Permissions Policy. A parte le differenze di sintassi, la logica rimane la stessa. Quando entrambi gli header Permissions Policy e Feature Policy vengono utilizzati contemporaneamente, l'header Permissions Policy ha la precedenza e sovrascriverà il valore impostato dall'header Feature Policy. Si veda anche questo post del blog del team di Chrome per maggiori dettagli sull'implementazione.

Assicurarsi che gli header della risposta HTTP dall'URL di origine dell'iframe includano la relativa [Permissions-Policy](/blog/iframe-passkeys-webauthn/enable-passkeys-iframe). Questo è cruciale per il supporto cross-origin.

Permissions-Policy: publickey-credentials-get=*, publickey-credentials-create=*

Per un controllo più granulare, è possibile specificare le origini particolari autorizzate a incorporare il contenuto dell'iframe.

Permissions-Policy: publickey-credentials-get=("https://passkeys.eu"), publickey-credentials-create=("https://passkeys.eu")

Assicurarsi che il contenuto dell'iframe richieda un'azione dell'utente per attivare l'autenticazione con passkey. Questo può essere fatto utilizzando event listener per i clic o l'invio di moduli all'interno dell'iframe. Questo processo è anche chiamato attivazione transitoria.

document.getElementById('loginPasskeyButton').addEventListener('click',
    async () => {
        try {
            const [publicKeyCredentialRequestOptions](/glossary/publickeycredentialrequestoptions) = { /* Configuration options */ };
 
            const credential = await navigator.credentials.get({publicKey: publicKeyCredentialRequestOptions});
            // Handle the created credential
        } catch (err) {
            console.error('Error authenticating via passkey:', err);
        }
    });

In questo contesto, si veda anche il nostro post del blog sui requisiti di interazione dell'utente in Safari.

Di seguito, trovate uno snippet di codice di esempio completo di un file index.html ospitato su https://cross-origin-iframe.vercel.com che utilizza un iframe cross-origin per le passkey tramite https://passkeys.eu.

<!doctype html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <meta
            http-equiv="Permissions-Policy"
            content="publickey-credentials-get=*; publickey-credentials-create=*"
        />
        <meta
            http-equiv="Content-Security-Policy"
            content="default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self'; img-src 'self'; frame-src https://passkeys.eu;"
        />
 
        <title>Demo di iframe cross-origin con passkey</title>
        <style>
            body {
                font-family: Arial, sans-serif;
                padding: 20px;
                display: flex;
                flex-direction: column;
                justify-content: center;
                align-items: center;
                height: 100vh;
                margin: 0;
            }
 
            h1 {
                width: 100%;
                text-align: center;
            }
 
            .iframe-container {
                width: 80%;
                max-width: 800px;
                height: 80%;
                max-height: 600px;
                border: 1px solid #ccc;
                box-shadow: 0 0 10px rgba(0, 0, 0, 0.1);
                margin-top: 20px;
            }
 
            iframe {
                width: 100%;
                height: 100%;
                border: none;
            }
 
            @media (max-width: 768px) {
                h1 {
                    width: 95%;
                }
 
                .iframe-container {
                    width: 95%;
                }
            }
        </style>
    </head>
    <body>
        <h1>Demo di iframe cross-origin con passkey</h1>
 
        <div class="iframe-container">
            <iframe
                src="https://passkeys.eu"
                allow="publickey-credentials-create; publickey-credentials-get"
            ></iframe>
        </div>
    </body>
</html>

L'implementazione delle passkey negli iframe può presentare una serie di sfide che gli sviluppatori devono affrontare per garantire un'esperienza utente fluida e sicura. Ecco un'analisi dettagliata delle sfide comuni e di come superarle.

Problema: Configurare in modo errato le permission policy può impedire all'iframe di accedere alle API WebAuthn.

“NotAllowedError - The 'publickey-credentials-create' feature is not enabled in this document. Permissions Policy may be used to delegate Web Authentication capabilities to cross-origin child frames.”

Se non si aggiungono correttamente le permission policy, il browser genererà il seguente errore:

Soluzione:

• Verificare che l'attributo allow e gli header HTTP siano impostati: Assicurarsi che l'attributo allow e gli header HTTP siano impostati correttamente. Verificare che le autorizzazioni publickey-credentials-get e publickey-credentials-create siano incluse sia nell'elemento iframe sia negli header della risposta HTTP del server.
• Meta header invece di header del server web: Usare i tag <meta/> per definire le permission policy invece di impostare gli header nel proprio server web.
• Punto e virgola invece della virgola in Permissions-Policy: In precedenza, Permissions-Policy si chiamava Feature-Policy. I singoli elementi di una Feature-Policy erano separati da una virgola invece che da un punto e virgola (che è lo standard per Permissions-Policy). La Permissions-Policy dell'iframe segue ancora la sintassi della Feature-Policy e quindi usa le virgole. Gli attributi sandbox / allow sono comunque separati da un punto e virgola (vedi lo snippet di codice sopra).

Suggerimento: Per testare correttamente che i vostri header Permission-Policy siano impostati correttamente, noi consigliamo di aprire gli strumenti per sviluppatori del browser, accedere ad Applicazione (qui: negli strumenti per sviluppatori di Chrome), andare su Frame e cercare l'origine dell'iframe (qui: passkeys.eu/). Se la Permissions-Policy è impostata correttamente, publickey-credential-create e publickey-credential-get dovrebbero essere elencati tra le Funzionalità consentite:

Problema: La creazione di passkey o l'accesso con passkey in un iframe cross-origin non funziona e nella console del browser viene visualizzato il seguente errore.

"NotAllowedError - The origin of the document is not the same as its ancestors."

Questo errore appare quando si utilizza il browser Safari e si tenta di creare una passkey dall'interno dell'iframe, poiché Safari non supporta la creazione di passkey in iframe cross-origin (vedi sopra).

Soluzione: In questo caso, non si può fare molto, poiché Safari non supporta (ancora) la creazione di una passkey dall'interno di un iframe cross-origin.

Blocked a frame with origin "https://passkeys.eu" from accessing a frame with origin "https://cross-origin-iframe.vercel.app". Protocols, domains, and ports must match.

Questo errore non è direttamente collegato alle passkey, ma più in generale agli iframe cross-origin in Safari. Come parte dell'iniziativa di Safari / WebKit per bloccare i cookie di terze parti o l'accesso a LocalStorage in un contesto di terze parti, parti della logica JavaScript potrebbero non funzionare.

Soluzione: In questo caso, è necessario assicurarsi di non utilizzare cookie di terze parti all'interno degli iframe, poiché ciò causa un errore.

Problema: I problemi di compatibilità degli iframe tra browser si verificano quando browser diversi hanno livelli di supporto variabili per WebAuthn, autorizzazioni iframe e attributi di sicurezza, portando a un comportamento incoerente.

Soluzione: Per mitigare questi problemi di compatibilità, testare l'implementazione su più browser per garantire la compatibilità e identificare eventuali problemi specifici del browser.

Passaggi:

1. Eseguire test cross-browser utilizzando strumenti come BrowserStack o Sauce Labs.
2. Risolvere eventuali discrepanze implementando correzioni o fallback specifici per il browser.

Problema: Quando si utilizzano iframe che richiedono passkey all'interno di app native, è necessario fare una distinzione cruciale tra contesti di prima parte e di terza parte:

• Contesto di prima parte: Le passkey sono legate allo stesso dominio dell'azienda che gestisce l'app. Ad esempio, un'app di e-commerce che si basa sul proprio dominio per l'autenticazione utente.
• Contesto di terza parte: Un dominio diverso (ad esempio, un fornitore di pagamenti o di identità) gestisce il flusso di creazione o di accesso con passkey.

In una WebView incorporata (EWV) come WKWebView su iOS o una WebView Android - l'app chiamante ha un controllo esteso sulla sessione web (ad esempio, intercettando le richieste). Questa configurazione supporta tipicamente le passkey solo se il dominio della passkey (l'ID del Relying Party) corrisponde al dominio dell'app (prima parte). Tuttavia, in uno scenario di terza parte - come il flusso cross-origin di un fornitore di pagamenti - una WebView incorporata generalmente non può accedere alle credenziali passkey necessarie perché l'app dell'esercente e il servizio del fornitore di pagamenti sono origini diverse. I "binding" richiesti per le passkey (tra dominio, credenziale e origine) non corrisponderanno nel contesto incorporato.

Questa limitazione porta molte app ad adottare un approccio basato su una system WebView (ad esempio, ASWebAuthenticationSession su iOS o Custom Tabs su Android). Le WebView di sistema isolano il sito di terze parti (ad esempio, il fornitore di pagamenti) in un ambiente sicuro, simile a un browser, che consente correttamente le passkey cross-origin, se il browser stesso lo supporta. Tuttavia, ricordate che le limitazioni esistenti di Safari per gli iframe si applicano anche a ASWebAuthenticationSession, quindi se Safari non permette certe operazioni con le passkey in iframe di terze parti, lo stesso varrà nella WebView di sistema. Attualmente non esiste una soluzione "nativa"; la best practice per i flussi complessi - come i checkout che coinvolgono fornitori di pagamento esterni - è aprire una system WebView piuttosto che una incorporata.

Soluzione: Per i fornitori di pagamenti (e altre terze parti che si affidano a passkey su più domini), pianificare attentamente l'integrazione per garantire che l'utente venga portato fuori da una WebView incorporata e dentro una di sistema. Sebbene sia un'esperienza meno fluida di un flusso puramente incorporato, è spesso l'unico modo per garantire che la funzionalità passkey funzioni con i servizi di terze parti.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Per maggiori dettagli sulla gestione delle passkey di terze parti all'interno di app native e WebView, consultate Passkey per fornitori di pagamenti: SDK di pagamento per passkey di terze parti.

Mentre gli argomenti discussi sopra si applicano a vari scenari, sono particolarmente importanti per i fornitori di pagamenti, dove i flussi multi-dominio (ad esempio, sito dell'esercente e gateway di pagamento) devono incorporare l'autenticazione utente all'interno di iframe cross-origin. In queste configurazioni:

• Gli utenti desiderano un checkout in-page e senza attriti, senza pop-up di reindirizzamento.
• I fornitori di pagamenti devono gestire la registrazione o l'accesso con passkey sul proprio dominio (ad esempio, pay.provider.com), anche se sono incorporati nel sito di un esercente.
• Le restrizioni di Safari e le limitazioni delle WebView incorporate spesso bloccano la creazione di passkey di terze parti negli iframe.

Per affrontare queste sfide e costruire un'esperienza sicura e fluida simile ad Apple Pay, i fornitori di pagamenti spesso adottano un approccio ibrido, combinando l'integrazione basata su iframe con un fallback basato su reindirizzamento per Safari (o browser più vecchi). In alcuni casi, i flussi basati su browser di sistema (ad esempio, ASWebAuthenticationSession su iOS) diventano obbligatori se una WebView incorporata non consente affatto le passkey.

Per un'analisi approfondita di questi scenari specifici per i pagamenti - inclusi confronti iframe vs. reindirizzamento, considerazioni sulle app native e best practice per un'alta adozione delle passkey, consultate il nostro articolo dedicato:

60-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

In particolare:

• Strategia A: Incorporare un iframe cross-origin spiega come gestire la creazione e l'accesso con passkey inline, facendo riferimento alle impostazioni Permissions-Policy introdotte qui.
• Strategia B: Approccio basato su reindirizzamento mostra un'integrazione più semplice che aggira la maggior parte delle insidie cross-origin, anche se al costo di lasciare il dominio dell'esercente.
• La System WebView è essenziale per le app native, poiché le WebView incorporate spesso interrompono i flussi di passkey di terze parti.

Questa guida complementare fornisce strategie approfondite per proteggere le transazioni, superare le restrizioni cross-origin di Safari e ottimizzare l'uso delle passkey in contesti di terze parti. Combinando i passaggi tecnici di questo articolo con i metodi incentrati sui pagamenti, è possibile offrire un flusso di checkout senza attriti e resistente al phishing direttamente all'interno di un iframe, sbloccando il livello successivo di sicurezza e UX per i pagamenti online.

L'integrazione delle passkey all'interno degli iframe migliora significativamente l'autenticazione utente migliorando sia la sicurezza che l'esperienza utente. Ciò consente un'autenticazione fluida senza la necessità di reindirizzamenti o pop-up, garantendo una UX coerente tra varie sezioni e siti.

Implementazioni reali, come l'integrazione delle passkey da parte di Shopify nel loro componente di login, dimostrano i vantaggi pratici e la flessibilità di questo approccio.