Passkeys & iframe: Bagaimana Cara Membuat & Login dengan Passkey?

Legenda
✅ = didukung ❌ = tidak didukung

Dari minggu ke minggu, semakin banyak organisasi yang mengumumkan peluncuran passkey mereka (misalnya, baru-baru ini Visa, Mastercard atau Vercel). Seiring para developer dan manajer produk dari perusahaan lain mengikuti jejak ini, semakin banyak kasus penggunaan implementasi passkey yang dibahas.

Salah satu kasus yang sering ditanyakan kepada kami adalah bagaimana passkey bekerja di dalam iframe, karena iframe banyak digunakan dalam pengembangan web modern untuk menyematkan konten dari berbagai sumber dengan mulus. Dalam konteks passkey dan WebAuthn, iframe memiliki tantangannya sendiri, terutama terkait keamanan dan interaksi pengguna.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Postingan blog ini menyediakan panduan komprehensif tentang penggunaan passkey dan WebAuthn di iframe. Kita akan:

• Menjelajahi kemampuan saat ini
• Membahas dukungan iframe lintas-asal
• Menyoroti manfaat integrasi iframe dan
• Menyediakan panduan implementasi langkah demi langkah

Di akhir postingan ini, kita akan memiliki pemahaman yang jelas tentang cara memanfaatkan passkey di dalam iframe.

iframe, atau inline frame, adalah elemen HTML yang memungkinkan developer menyematkan dokumen HTML lain di dalam dokumen saat ini. Kemampuan ini banyak digunakan untuk memasukkan konten dari sumber eksternal, seperti video, peta, dan halaman web lainnya, ke dalam sebuah situs web.

Mari kita lihat berbagai jenis iframe.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

iframe dasar adalah jenis yang paling umum digunakan. iframe ini hanya menyematkan konten dari URL lain di dalam halaman saat ini.

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

iframe dasar ini sering digunakan untuk menyertakan konten statis, seperti artikel, di dalam halaman web.

iframe responsif dirancang untuk menyesuaikan ukurannya berdasarkan ukuran layar atau kontainer tempatnya diletakkan. Ini memastikan bahwa konten yang disematkan terlihat bagus di semua perangkat, termasuk desktop, tablet, dan ponsel.

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

CSS media query juga dapat digunakan untuk membuat iframe menyesuaikan diri secara dinamis berdasarkan ukuran viewport.

Get a free passkey assessment in 15 minutes.

Book free consultation

iframe yang aman atau sandboxed membatasi tindakan yang dapat dilakukan di dalam iframe. Ini berguna untuk menyematkan konten dari sumber yang tidak tepercaya atau untuk meningkatkan keamanan.

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

Atribut sandbox dapat mencakup berbagai batasan, seperti:

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

Atribut sandbox memungkinkan skrip berjalan tetapi membatasi tindakan yang berpotensi berbahaya, seperti pengiriman formulir atau penggunaan plugin.

Become part of our Passkeys Community for updates & support.

Join

iframe lintas-asal (cross-origin) menyematkan konten dari domain yang berbeda. iframe ini umum digunakan untuk mengintegrasikan layanan pihak ketiga, seperti gateway pembayaran atau widget media sosial. Karena batasan keamanan, iframe ini memiliki akses terbatas ke konten halaman penyemat dan sebaliknya.

Lintas-asal berarti konten yang dimuat berasal dari origin yang berbeda, di mana sebuah origin didefinisikan oleh kombinasi skema (protokol), host (domain), dan nomor port. Misalnya, https://example.com dan http://example.com dianggap origin yang berbeda karena menggunakan skema yang berbeda (HTTP vs. HTTPS).

Demikian pula, subdomain diperlakukan sebagai origin yang terpisah dari domain induknya. Sebagai contoh, https://example.com dan https://sub.example.com adalah lintas-asal, meskipun keduanya berbagi domain dasar yang sama. Pemisahan ini memastikan bahwa skrip dan data dari satu subdomain tidak dapat berinteraksi langsung dengan yang dari subdomain lain tanpa izin eksplisit, sehingga meningkatkan keamanan.

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.

Perusahaan mempercayai Corbado untuk melindungi pengguna mereka dan membuat login lebih lancar dengan passkey. Dapatkan konsultasi passkey gratis Anda sekarang.

Dapatkan konsultasi gratis

Berikut adalah contoh untuk mengilustrasikan konsep lintas-asal dan asal-yang-sama:

Contoh lintas-asal:

Menyematkan konten dari https://payment.example.com ke dalam halaman web yang di-hosting di https://www.mystore.com. Keduanya lintas-asal karena memiliki domain yang berbeda.

Contoh asal-yang-sama:

Menyematkan konten dari https://www.example.com/shop ke dalam halaman web yang di-hosting di https://www.example.com/blog. Keduanya memiliki asal yang sama karena berbagi skema, host, dan port yang sama.

iframe lintas-asal berbeda dari iframe dasar karena sumbernya berasal dari domain lain, sedangkan iframe dengan situs yang sama memiliki sumber dari domain yang sama dengan tempatnya disematkan.

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

Menggunakan passkey di dalam iframe memperkenalkan kemampuan dan batasan baru yang perlu dipahami oleh para developer, terutama seputar pengaturan izin yang benar dan memastikan interaksi pengguna yang aman di dalam konteks yang disematkan.

Secara historis, Web Authentication API dinonaktifkan secara default di iframe lintas-asal, terutama karena masalah keamanan. Batasan ini berarti developer harus mengalihkan pengguna atau menggunakan jendela pop-up untuk autentikasi, yang menyebabkan pengalaman pengguna yang kurang mulus.

Dalam passkey / WebAuthn, ada dua operasi inti (juga disebut seremoni):

1. Mendaftar / membuat passkey
2. Mengautentikasi / login dengan passkey

Dua operasi ini tidak didukung secara setara di iframe lintas-asal:

Pada awalnya, login melalui iframe lintas-asal dimungkinkan tetapi pembuatan lintas-asal belum karena belum ada yang memiliki kasus penggunaan untuk itu.

Kemajuan terbaru (misalnya di Chrome 123) telah memperkenalkan dukungan untuk pembuatan passkey iframe lintas-asal dengan kondisi tertentu. Namun, per Mei 2024, tidak semua browser sepenuhnya mendukung pembuatan passkey melalui iframe lintas-asal, meskipun login sudah dimungkinkan di sebagian besar browser.

Selain itu, dukungan iframe lintas-asal (untuk operasi pendaftaran dan autentikasi) sudah dimasukkan ke dalam spesifikasi WebAuthn Level 3 yang sedang berjalan. Beberapa browser masih perlu mengejar spesifikasi tersebut (misalnya Safari). Sayangnya, Apple belum mengumumkan apakah dan kapan akan mengizinkan pendaftaran passkey lintas-asal di Safari. Hal ini akan menghilangkan batasan teknis paling signifikan untuk menggunakan passkey di iframe lintas-asal.

Di bagian selanjutnya dari postingan blog ini, kita akan mengasumsikan penggunaan iframe lintas-asal.

Want to find out how many people use passkeys?

View Adoption Data

Tabel berikut memberikan gambaran umum tentang dukungan browser/standar untuk autentikasi iframe dan login iframe melalui passkey dalam konteks iframe lintas-asal:

Per Mei 2024, pembuatan passkey di iframe lintas-asal belum dimungkinkan di semua browser. Tabel berikut memberikan gambaran umum tentang dukungan browser / standar untuk pendaftaran / pembuatan passkey di iframe lintas-asal:

Jika Anda tertarik dengan latar belakang lebih lanjut tentang pengembangan dan dukungan ini, kami merekomendasikan untuk melihat isu GitHub ini dan Pull Request ini.

Ada dua kasus penggunaan utama untuk mendukung passkey di iframe lintas-asal.

Mengaktifkan passkey di iframe lintas-asal sangat penting untuk skenario identitas terfederasi di mana beberapa domain terlibat tetapi akun pengguna yang sama harus digunakan.

Mari kita ambil skenario berikut. Anda adalah perusahaan multinasional seperti KAYAK dan memiliki domain yang berbeda untuk wilayah yang berbeda:

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

Namun, Anda memiliki satu sistem manajemen identitas pusat yang memungkinkan pengguna untuk login dengan akun dan kredensial yang sama di semua domain ini. Standar WebAuthn akan menjadi tantangan untuk skenario ini, karena passkey hanya dapat terikat pada satu domain (Relying Party ID), misalnya www.kayak.com.

Untuk mengatasi tantangan ini, Anda akan menggunakan iframe dari origin www.kayak.com di semua domain Anda yang lain. Jadi, Anda menyematkan iframe dengan origin www.kayak.com di www.kayak.us dan di www.kayak.de (iframe lintas-asal). Jika tidak, penggunaan passkey Anda yang terikat pada "www.kayak.com" di domain lain ini tidak akan mungkin karena sifat tahan-phishing dari passkey.

Sebagai catatan tambahan: Fitur baru WebAuthn yaitu Related Origin Requests (RoR) juga dapat digunakan sebagai alternatif. Fitur ini memungkinkan "origin terkait" untuk mengakses passkey tanpa iframe, tetapi belum ada dukungan di semua browser.

Juga untuk alur pembayaran yang mulus, penggunaan passkey di iframe lintas-asal memainkan peran penting. Pertimbangkan skenario berikut: Seorang pelanggan ingin membeli sepatu baru di situs web merchant (misalnya www.amazon.com). Situs web merchant ini memungkinkan pelanggan membayar melalui rekening bank (misalnya di www.revolut.com) dan dengan demikian mengharuskan pengguna untuk login ke situs web bank (ini adalah proses yang disederhanakan). Pengguna login ke situs web bank dengan passkey yang terikat pada Relying Party ID bank, misalnya "revolut.com".

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Untuk menghindari pengalihan pengguna dari situs web merchant (www.amazon.com) ke situs web bank (www.revolut.com) dalam proses checkout dan membiarkan pengguna login di sana ke akun bank, iframe lintas-asal dapat digunakan. Dengan ini, pengguna tetap di www.amazon.com dan menggunakan passkey di iframe lintas-asal untuk autentikasi yang mereka buat untuk www.revolut.com.

Dengan demikian, mengintegrasikan passkey melalui iframe lintas-asal dalam alur pembayaran memastikan transaksi yang aman dan efisien di antara konsumen, merchant, dan bank:

Dalam konteks pembayaran dan passkey, kami juga merekomendasikan untuk melihat postingan blog kami tentang Secure Payment Confirmation (SPC) dan dynamic linking dengan passkey. Pastikan juga untuk melihat batasan untuk konteks pihak ketiga di Aplikasi Native di bawah ini.

Selain itu, untuk pandangan yang lebih mendalam tentang alur pembayaran lintas-asal menggunakan passkey, lihat Passkey Penyedia Pembayaran: Cara Membangun SDK Pihak Ketiga.

Secara umum, mengintegrasikan passkey di dalam iframe menawarkan beberapa manfaat, terutama dengan meningkatkan UX dan keamanan. Berikut adalah rincian keuntungannya:

Pengalaman Pengguna yang Lebih Baik

1. Tanpa Pop-Up atau Pengalihan: Pengguna dapat melakukan autentikasi langsung di dalam konten yang disematkan tanpa pengalihan atau pop-up, menghasilkan pengalaman yang lebih lancar dan tidak mengganggu.
2. UX yang Konsisten di Seluruh Situs: Menyematkan alur autentikasi di dalam iframe memastikan pengalaman pengguna yang konsisten di berbagai bagian situs web atau di berbagai situs web yang menggunakan layanan autentikasi yang sama.

Keamanan yang Ditingkatkan

1. Transaksi Aman: Untuk skenario seperti pembayaran, passkey di iframe meningkatkan keamanan transaksi dengan memastikan bahwa autentikasi terjadi di dalam konteks yang aman dan disematkan.
2. Gunakan Akun Pengguna di Situs Web yang Berbeda: Dalam pengaturan identitas terfederasi, passkey di iframe lintas-asal memungkinkan verifikasi identitas yang aman dan efisien di berbagai domain.

Mengimplementasikan passkey di iframe melibatkan beberapa langkah kunci untuk memastikan keamanan dan fungsionalitas. Kami menyediakan panduan terperinci untuk para developer. Silakan lihat juga contoh implementasi di https://cross-origin-iframe.vercel.app/.

Header HTTP Permissions-Policy membantu mengizinkan atau menolak penggunaan fitur browser tertentu di dalam dokumen atau di dalam elemen iframe. Untuk mengaktifkan login passkey di iframe, Anda harus mengatur publickey-credentials-get dan publickey-credentials-create kebijakan izin (permission policies). Kebijakan ini memungkinkan konten yang disematkan untuk memanggil metode WebAuthn API yang diperlukan untuk mengautentikasi (navigator.credentials.get({publicKey})) dengan dan membuat passkey (navigator.credentials.create({publicKey})).

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

Permissions Policy HTTP sebelumnya disebut Feature Policy. Di bawah Feature Policy, Anda dapat memberikan fitur ke iframe lintas-asal dengan menambahkan origin ke daftar origin header atau menyertakan atribut allow di tag iframe. Dengan Permissions Policy, menambahkan frame lintas-asal ke daftar origin mengharuskan tag iframe untuk origin tersebut harus menyertakan atribut allow. Jika respons tidak memiliki header Permissions Policy, daftar origin akan default ke * (semua origin). Menyertakan atribut allow di iframe memberikan akses ke fitur tersebut.

Untuk memastikan bahwa iframe lintas-asal yang tidak ditentukan dalam daftar origin diblokir dari mengakses fitur tersebut, bahkan jika atribut allow ada, developer dapat secara eksplisit mengatur header Permissions Policy dalam respons.

Di Chrome 88+, Feature Policy masih dapat digunakan tetapi bertindak sebagai alias untuk Permissions Policy. Selain perbedaan sintaks, logikanya tetap sama. Ketika kedua header Permissions Policy dan Feature Policy digunakan secara bersamaan, header Permissions Policy akan lebih diutamakan dan akan menimpa nilai yang ditetapkan oleh header Feature Policy. Silakan lihat juga postingan blog oleh tim Chrome ini untuk detail implementasi lebih lanjut.

Pastikan header respons HTTP dari URL sumber iframe menyertakan [Permissions-Policy](/blog/iframe-passkeys-webauthn/enable-passkeys-iframe) yang relevan. Ini sangat penting untuk dukungan lintas-asal.

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

Untuk kontrol yang lebih terperinci, Anda dapat menentukan origin tertentu yang diizinkan untuk menyematkan konten iframe.

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

Pastikan konten iframe memerlukan tindakan pengguna untuk memicu autentikasi passkey. Ini dapat dilakukan menggunakan event listener untuk klik atau pengiriman formulir di dalam iframe. Proses ini juga disebut transient activation.

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);
        }
    });

Dalam konteks ini, lihat juga postingan blog kami tentang persyaratan gestur pengguna Safari.

Berikut ini, Anda akan menemukan cuplikan kode sampel lengkap dari file index.html yang di-hosting di https://cross-origin-iframe.vercel.com yang menggunakan iframe lintas-asal untuk passkey melalui 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>Cross-Origin iframe with Passkeys Demo</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>Cross-Origin iframe with Passkeys Demo</h1>
 
        <div class="iframe-container">
            <iframe
                src="https://passkeys.eu"
                allow="publickey-credentials-create; publickey-credentials-get"
            ></iframe>
        </div>
    </body>
</html>

Mengimplementasikan passkey di iframe dapat disertai dengan serangkaian tantangan yang perlu diatasi oleh para developer untuk memastikan pengalaman pengguna yang lancar dan aman. Berikut adalah pandangan terperinci tentang tantangan umum dan cara mengatasinya.

Masalah: Konfigurasi kebijakan izin yang salah dapat mencegah iframe mengakses 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.”

Jika Anda tidak menambahkan kebijakan izin dengan benar, browser akan menampilkan kesalahan berikut:

Solusi:

• Periksa Kembali Apakah Atribut allow dan Header HTTP Sudah Diatur: Pastikan atribut allow dan header HTTP diatur dengan benar. Periksa kembali bahwa izin publickey-credentials-get dan publickey-credentials-create disertakan baik di elemen iframe maupun di header respons HTTP server.
• Header Meta Alih-alih Header Server Web: Gunakan header <meta/> untuk mendefinisikan kebijakan izin alih-alih mengatur header di server web Anda.
• Titik Koma alih-alih Koma di Permissions-Policy: Sebelumnya, Permissions-Policy disebut Feature-Policy. Elemen tunggal dari Feature-Policy dipisahkan oleh koma alih-alih titik koma (yang merupakan standar untuk Permissions-Policy). Permissions-Policy iframe masih mengikuti sintaks Feature-Policy dan dengan demikian menggunakan koma. Atribut sandbox / allow masih dipisahkan dengan titik koma (lihat cuplikan kode di atas).

Tips: Untuk menguji dengan benar bahwa header Permission-Policy Anda diatur dengan benar, kami merekomendasikan untuk membuka alat developer browser Anda, akses Application (di sini: di alat developer Chrome), buka Frames dan cari origin iframe (di sini: passkeys.eu/). Jika Permissions-Policy diatur dengan benar, publickey-credential-create dan publickey-credential-get harus terdaftar di antara Allowed Features:

Masalah: Pembuatan passkey atau login passkey lintas-asal iframe tidak berfungsi, dan Anda melihat kesalahan berikut di konsol browser Anda.

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

Kesalahan ini muncul saat menggunakan browser Safari dan mencoba membuat passkey dari dalam iframe, karena Safari tidak mendukung pembuatan passkey iframe lintas-asal (lihat di atas).

Solusi: Di sini, Anda tidak bisa berbuat banyak karena Safari belum mendukung pembuatan passkey dari dalam iframe lintas-asal (untuk saat ini).

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.

Kesalahan ini tidak secara langsung terkait dengan passkey tetapi lebih ke iframe lintas-asal di Safari secara umum. Sebagai bagian dari inisiatif Safari / WebKit untuk memblokir cookie pihak ketiga atau akses ke LocalStorage dalam konteks pihak ketiga, sebagian logika JavaScript mungkin rusak.

Solusi: Di sini, Anda perlu memastikan bahwa Anda tidak menggunakan cookie pihak ketiga di dalam iframe Anda, karena ini menyebabkan kesalahan.

Masalah: Masalah kompatibilitas browser iframe muncul ketika browser yang berbeda memiliki tingkat dukungan yang bervariasi untuk WebAuthn, izin iframe, dan atribut keamanan, yang menyebabkan perilaku yang tidak konsisten.

Solusi: Untuk mengurangi masalah kompatibilitas browser iframe ini, uji implementasi di berbagai browser untuk memastikan kompatibilitas dan mengidentifikasi masalah spesifik browser.

Langkah-langkah:

1. Lakukan pengujian lintas-browser menggunakan alat seperti BrowserStack atau Sauce Labs.
2. Atasi setiap perbedaan dengan mengimplementasikan perbaikan atau fallback spesifik browser.

Masalah: Saat menggunakan iframe yang memerlukan passkey di dalam aplikasi native, perbedaan penting harus dibuat antara konteks pihak pertama dan pihak ketiga:

• Konteks pihak pertama: Passkey terikat pada domain yang sama dengan perusahaan yang menjalankan aplikasi. Misalnya, aplikasi e-commerce yang mengandalkan domainnya sendiri untuk autentikasi pengguna.
• Konteks pihak ketiga: Domain yang berbeda (misalnya, penyedia pembayaran atau penyedia identitas) menangani alur pembuatan passkey atau login.

Dalam embedded WebView (EWV) seperti WKWebView di iOS atau WebView Android - aplikasi pemanggil memiliki kontrol luas atas sesi web (misalnya, mencegat permintaan). Pengaturan ini biasanya hanya mendukung passkey jika domain passkey (ID Relying Party) cocok dengan domain aplikasi (pihak pertama). Namun, dalam skenario pihak ketiga - seperti alur lintas-asal penyedia pembayaran - WebView yang disematkan umumnya tidak dapat mengakses kredensial passkey yang dibutuhkan karena aplikasi merchant dan layanan penyedia pembayaran adalah origin yang berbeda. "Ikatan" yang diperlukan untuk passkey (antara domain, kredensial, dan origin) tidak akan cocok dalam konteks yang disematkan.

Batasan ini membuat banyak aplikasi mengadopsi pendekatan system WebView (misalnya, ASWebAuthenticationSession di iOS atau Custom Tabs di Android). WebView sistem mengisolasi situs pihak ketiga (misalnya, penyedia pembayaran) dalam lingkungan yang aman seperti browser yang memungkinkan passkey lintas-asal dengan benar—jika browser itu sendiri mendukungnya. Namun demikian, ingatlah bahwa batasan iframe yang ada di Safari juga berlaku untuk ASWebAuthenticationSession, jadi jika Safari tidak mengizinkan operasi passkey tertentu di iframe pihak ketiga, hal yang sama akan berlaku di WebView sistem. Saat ini tidak ada perbaikan "native"; praktik terbaik untuk alur kompleks - seperti checkout yang melibatkan penyedia pembayaran eksternal - adalah membuka WebView sistem daripada yang disematkan.

Solusi: Untuk penyedia pembayaran (dan pihak ketiga lainnya yang mengandalkan passkey di berbagai domain), rencanakan integrasi dengan cermat untuk memastikan pengguna dibawa keluar dari WebView yang disematkan dan masuk ke WebView sistem. Meskipun pengalamannya kurang mulus dibandingkan alur yang sepenuhnya disematkan, ini seringkali satu-satunya cara untuk menjamin bahwa fungsionalitas passkey akan berfungsi dengan layanan pihak ketiga.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Untuk detail lebih lanjut tentang penanganan passkey pihak ketiga di dalam aplikasi native dan WebView, lihat Passkey Penyedia Pembayaran: SDK Pembayaran Passkey Pihak Ketiga.

Meskipun topik yang dibahas di atas berlaku untuk berbagai skenario, topik ini sangat penting bagi penyedia pembayaran, di mana alur multi-domain (misalnya, situs merchant dan gateway pembayaran) harus menyematkan autentikasi pengguna di dalam iframe lintas-asal. Dalam pengaturan ini:

• Pengguna menginginkan checkout dalam halaman yang lancar tanpa pop-up pengalihan.
• Penyedia pembayaran harus menangani pendaftaran atau login passkey di domain mereka sendiri (misalnya, pay.provider.com), bahkan jika mereka disematkan di situs merchant.
• Batasan Safari dan batasan embedded WebView sering kali memblokir pembuatan passkey pihak ketiga di iframe.

Untuk mengatasi tantangan ini dan membangun pengalaman yang aman dan mulus mirip dengan Apple Pay, penyedia pembayaran sering mengadopsi pendekatan hibrida - menggabungkan integrasi berbasis iframe dengan fallback pengalihan untuk Safari (atau browser lama). Dalam beberapa kasus, alur browser sistem (misalnya, ASWebAuthenticationSession di iOS) menjadi wajib jika WebView yang disematkan tidak mengizinkan passkey sama sekali.

Untuk penyelaman mendalam ke dalam skenario spesifik pembayaran ini - termasuk perbandingan iframe vs. pengalihan, pertimbangan aplikasi native dan praktik terbaik untuk adopsi passkey yang tinggi, lihat artikel khusus kami:

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

Get free Whitepaper

Secara khusus:

• Strategi A: Menyematkan iframe Lintas-Asal menjelaskan cara menangani pembuatan dan login passkey secara inline, merujuk pada pengaturan Permissions-Policy yang diperkenalkan di sini.
• Strategi B: Pendekatan Berbasis Pengalihan menunjukkan integrasi yang lebih sederhana yang melewati sebagian besar jebakan lintas-asal, meskipun dengan biaya meninggalkan domain merchant.
• System WebView sangat penting untuk aplikasi native, karena WebView yang disematkan sering kali merusak alur passkey pihak ketiga.

Panduan pelengkap ini menyediakan strategi mendalam untuk mengamankan transaksi, mengatasi batasan lintas-asal Safari, dan mengoptimalkan penggunaan passkey dalam konteks pihak ketiga. Dengan menggabungkan langkah-langkah teknis dalam artikel ini dengan metode yang berfokus pada pembayaran tersebut, Anda dapat memberikan alur checkout yang lancar dan tahan-phishing langsung di dalam iframe, membuka tingkat keamanan dan UX berikutnya untuk pembayaran online.

Mengintegrasikan passkey di dalam iframe secara signifikan meningkatkan autentikasi pengguna dengan meningkatkan keamanan dan pengalaman pengguna. Ini memungkinkan autentikasi yang mulus tanpa perlu pengalihan atau pop-up, memastikan UX yang konsisten di berbagai bagian dan situs.

Implementasi di dunia nyata, seperti integrasi passkey Shopify di dalam komponen login mereka, menunjukkan manfaat praktis dan fleksibilitas dari pendekatan ini.