Relying Party ID (rpID) WebAuthn & Kunci Sandi: Domain & Aplikasi Native

Autentikasi kunci sandi (passkey) dengan cepat menjadi standar seiring dengan raksasa teknologi seperti TikTok, GitHub, WhatsApp, X (Twitter), LinkedIn, dan Amazon meluncurkannya atau sudah melakukannya. Jelas bahwa dunia teknologi mengakui pentingnya autentikasi yang sederhana dan aman.

Selain pengalaman pengguna yang mulus dalam melakukan autentikasi dengan Face ID, Touch ID, atau Windows Hello, kunci sandi menawarkan keamanan yang tak tertandingi dibandingkan dengan metode autentikasi tradisional seperti kata sandi. Salah satu fitur yang menonjol adalah ketahanannya yang kuat terhadap phishing.

Cheatsheet Passkeys. Panduan praktis, pola peluncuran, dan KPI untuk program passkeys.

Dapatkan cheat sheet

Coba passkeys dalam demo live.

Coba passkeys

Serangan phishing adalah serangan di mana korban dijebak untuk memberikan kredensial ke situs palsu yang meniru situs asli. Sebagai contoh, bayangkan Anda menerima email dari yang tampak seperti bank Anda, meminta Anda untuk masuk. Anda mengeklik tautan tersebut, dan situs webnya terlihat sah, sehingga Anda memasukkan kredensial dan penyerang dapat menggunakannya untuk masuk ke situs aslinya. Hal ini semakin menjadi masalah di era digital dan bahkan perusahaan besar seperti Okta (penyedia autentikasi!) atau Retool telah menjadi korban serangan spear-phishing (bentuk khusus dari phishing di mana target individu disasar dengan trik phishing yang sangat pribadi), menekankan perlunya langkah-langkah keamanan yang kuat.

Sebaliknya, jika Anda menggunakan kunci sandi, dan situs tersebut palsu, autentikasi Anda akan gagal. Ini karena kunci sandi terikat ke domain tempat mereka dibuat melalui Relying Party ID.

Mekanisme ini tertanam di WebAuthn, standar web yang mendasari kunci sandi untuk autentikasi tanpa kata sandi. WebAuthn dibangun di atas dua prosesi inti: prosesi pendaftaran dan prosesi autentikasi.

Selama prosesi pendaftaran (sign-up), kunci sandi baru dibuat untuk layanan online (Relying Party) melalui aplikasi web atau native. Dalam proses ini, domain (Relying Party ID) tempat kunci sandi dibuat disimpan di dalam kunci sandi tersebut.

Hal ini memungkinkan prosesi autentikasi (login) untuk memeriksa apakah layanan online (Relying Party), yang dimiliki oleh aplikasi web atau native, cocok dengan Relying Party ID yang disimpan di dalam kunci sandi.

Pada bagian berikut, kita akan melihat secara detail bagaimana proses pencocokan domain ini bekerja dan bagaimana, secara khusus, aplikasi native diamankan.

Relying Party ID pada dasarnya adalah domain yang disimpan dalam kunci sandi, yang memastikan bahwa kunci sandi hanya berfungsi jika URL peramban saat ini (origin pengguna yang otomatis dikirimkan pada setiap permintaan) cocok dengannya (lihat pendekatan aplikasi native di bawah). Ini merupakan komponen penting dari spesifikasi WebAuthn, yang dapat Anda pelajari lebih lanjut di sini. Relying Party ID dapat berupa root domain (mis. corbado.com) atau subdomain (auth.corbado.com). Anda tidak dapat menyimpan root domain sebagai Relying Party ID jika ia terdapat dalam daftar sufiks publik (temukan daftar dan pustaka untuk deteksi sufiks publik di sini). Mengubah Relying Party ID untuk sebuah layanan online akan merusak kunci sandi yang sudah ada (pengecualian: Relying Party ID yang baru adalah subdomain dari Relying Party ID yang lama, atau Related Origin Requests dikonfigurasi melalui .well-known/webauthn untuk mengizinkan penggunaan ulang kunci sandi di berbagai domain terkait).

Selama proses autentikasi, Relying Party ID akan diperiksa berdasarkan URL peramban (origin pengguna) untuk memastikan kecocokannya. Pencocokan dalam hal ini berarti salah satu dari:

• URL peramban (origin pengguna) sama persis dengan Relying Party ID ATAU
• URL peramban (origin pengguna) adalah subdomain yang cocok dengan Relying Party ID dan domain induknya dapat didaftarkan (mis. com atau domain apa pun yang ada di Public Suffix List tidak akan berfungsi)

Berikut adalah garis besar detail mengenai originalHost mana (kolom kedua) yang diizinkan mengakses domain induknya:

Di bawah ini, Anda dapat melihat PublicKeyCredentialCreationOptions yang telah diurai:

{
    "publicKey": {
        "attestation": "direct",
        "authenticatorSelection": {
            "authenticatorAttachment": "platform",
            "requireResidentKey": false,
            "userVerification": "preferred"
        },
        "challenge": "qNqrdXUrk5S7dCM1MAYH3qSVDXznb-6prQoGqiACR10=",
        "excludeCredentials": [],
        "pubKeyCredParams": [
            {
                "alg": -7,
                "type": "public-key"
            }
        ],
        "rp": {
            "id": "corbado.com",
            "name": "Corbado"
        },
        "timeout": 30000,
        "user": {
            "displayName": "Pengguna Corbado",
            "id": "bz9ZDfHzOBLycqISTAdWwWIZt8VO-6mT3hBNXS5jwmY="
        }
    }
}

rp adalah singkatan dari Relying Party.

Salah satu manfaat utama Relying Party ID adalah pencegahan terhadap serangan phishing. Bayangkan skenario berikut:

1. Seorang penyerang membuat klon PayPal yang merupakan situs web palsu yang mencoba mencuri kredensial PayPal Anda untuk masuk atas nama Anda dan mengirim uang ke akun penyerang. Situs PayPal palsu ini di-host pada domain paybal.com (sehingga pada awalnya sering kali tidak terlihat bahwa itu adalah domain yang berbeda).
2. Anda telah membuat kunci sandi sebelumnya untuk situs PayPal yang sah. Kunci sandi ini menyimpan Relying Party ID paypal.com.
3. Anda mengunjungi situs web PayPal palsu di paybal.com (saat Anda mengunjungi situs ini, origin permintaan Anda adalah paybal.com*) dan situs tersebut mengirimkan perangkat Anda (autentikator) sebuah tantangan (challenge) untuk Relying Party ID paypal.com (di sini ia mencoba mengelabui Anda) dan meminta Anda untuk menandatanganinya dengan kunci sandi Anda untuk Relying Party ID paypal.com.
4. Perangkat Anda (autentikator) memeriksa apakah origin permintaan (paypal.com) dan Relying Party ID yang disimpannya dalam kunci sandi (paypal.com) cocok.
5. Karena keduanya jelas tidak cocok, autentikasi gagal dan hal ini menyelamatkan Anda dari memberikan akses ke akun PayPal Anda kepada penyerang.

Diagram berikut mengilustrasikan mekanisme pencegahan phishing ini.

Dalam kasus aplikasi native, penanganan origin berbeda di setiap platform: Di Android, origin diformat sebagai android:apk-key-hash:<SHA256_fingerprint>. Di iOS, origin WebAuthn adalah web-origin RP (mis. https://paypal.com). Pada kedua kasus, kepercayaan antara aplikasi native dan server Anda diverifikasi melalui file asosiasi yang bersesuaian (lihat di bawah). Untuk detail lebih lanjut tentang bagaimana validasi origin bekerja untuk aplikasi native, lihat panduan khusus kami tentang validasi origin WebAuthn untuk aplikasi native.

Bergabunglah dengan komunitas passkeys kami untuk update dan dukungan.

Gabung

Untuk mengimplementasikan kunci sandi pada aplikasi native, seorang pengembang dapat memilih antara menambahkannya melalui WebView atau secara native. Mari kita periksa kelebihan dan kekurangan dari kedua pendekatan tersebut di bawah ini.

Menggunakan WebView* untuk mengintegrasikan kunci sandi berarti menyematkan peramban web ke dalam aplikasi native untuk menangani proses autentikasi. Pendekatan ini pada dasarnya menampilkan halaman web di dalam aplikasi, sehingga memudahkan penggunaan kembali alur autentikasi berbasis web tanpa perlu menulis ulang untuk platform native. Namun, ada beberapa kelemahan. WebView mungkin tidak mendukung semua fitur kunci sandi, dan ada potensi risiko serangan "man-in-the-middle" jika tidak diimplementasikan dengan aman. Selain itu, pengalaman pengguna mungkin tidak semulus integrasi native, dan dapat ada tantangan dalam mempertahankan perilaku yang konsisten di berbagai perangkat dan versi OS.

*Ada beberapa jenis WebView: Di iOS (WKWebView, SFSafariViewController, atau SFAuthenticationSession / ASWebAuthenticationSession untuk alur autentikasi berbasis OAuth/OpenID Connect) dan Android (WebView, CCT-Chrome Custom Tabs). Lihat pos blog ini untuk lebih detail. Kami menyarankan untuk menggunakan SFSafariViewController/ ASWebAuthenticationSession dan Chrome Custom Tabs dalam konteks kunci sandi jika Anda tidak menginginkan integrasi native.

Lihat berapa banyak orang yang benar-benar memakai passkeys.

Lihat data adopsi

Integrasi native melibatkan pembangunan fungsionalitas kunci sandi langsung ke dalam aplikasi iOS atau Android menggunakan API dan pustaka khusus platform. Metode ini menawarkan pengalaman pengguna yang lebih mulus, karena tidak perlu berpindah antara aplikasi native dan WebView. Ini juga memungkinkan performa yang lebih baik dan tampilan serta nuansa yang lebih konsisten. Dari sudut pandang keamanan, integrasi native dapat menawarkan perlindungan yang ditingkatkan terhadap jenis serangan tertentu, terutama saat dikombinasikan dengan fitur keamanan khusus platform. Namun, upaya implementasi bisa lebih tinggi, karena pengembang harus menulis dan memelihara kode terpisah untuk setiap platform (Android dan iOS). Selain itu, untuk tetap mengikuti perkembangan dengan spesifikasi WebAuthn / kunci sandi terbaru mungkin memerlukan pembaruan aplikasi yang lebih sering.

Berikut ini, kami fokus pada integrasi kunci sandi native.

Lihat berapa banyak orang yang benar-benar memakai passkeys.

Lihat data adopsi

Aplikasi native (misalnya aplikasi iOS atau Android) menghadirkan tantangan dibandingkan dengan aplikasi web. Tidak seperti aplikasi web, tidak ada URL peramban yang dapat dicocokkan dengan Relying Party ID. Meskipun demikian, untuk memastikan tingkat keamanan yang sama, domain terhubung ke aplikasi native melalui file asosiasi, sehingga kepercayaan antara domain dan aplikasi native dapat terbangun.

Hal ini sangat penting jika kunci sandi dibuat di aplikasi web dan seharusnya digunakan untuk Relying Party ID yang sama pada aplikasi native (dan sebaliknya).

iOS menggunakan file apple-app-site-association. File ini berisi berbagai hak (entitlement), tetapi untuk WebAuthn dan kunci sandi, hak webcredentials yang penting.

{
    "webcredentials": {
        "apps": ["9RF9KY88B2.com.corbado.passkeys"]
    }
}

Dalam webcredentials.apps, Anda perlu menyimpan Awalan Pengenal Aplikasi Anda (mis. 9RF9KY77B2) dan Pengenal Bundel Anda (mis. com.corbado.passkeys).

Agar aplikasi native iOS berfungsi, file apple-app-site-association harus disimpan di bawah direktori /.well-known milik Relying Party ID (https://<Relying Party ID>/.well-known/apple-app-site-association).

Lihat contoh langsung di sini.

Android menggunakan file assetlinks.json, yang mana, sama seperti rekan iOS-nya, memerlukan konfigurasi khusus untuk WebAuthn dan kunci sandi.

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.corbado.passkeys.pub",
            "sha256_cert_fingerprints": [
                "F8:90:4E:9A:99:01:71:75:25:38:D5:36:16:2D:B3:65:EB:41:51:D4:53:9A:72:BC:4B:56:C5:16:43:62:E2:C0"
            ]
        }
    }
]

Anda harus menyetel nilai relation delegate_permission/common.handle_all_urls dan delegate_permission/common.get_login_creds. Selain itu, Anda perlu menambahkan nama paket dan sidik jari SHA-256 dari sertifikat penandatanganan Anda.

Untuk memungkinkan berbagi kunci sandi antara aplikasi native dan aplikasi web, Anda perlu menambahkan dua entri. Satu untuk namespace web dan satu lagi untuk namespace android_app.

Lihat contoh langsung di sini.

Agar aplikasi Android berfungsi, file assetlinks.json harus disimpan di bawah direktori /.well-known milik Relying Party ID https://<Relying Party ID>/.well-known/assetlinks.json - yang mana sangat mirip dengan di iOS).

Simak pos blog ini untuk melihat contoh implementasi yang berbagi kunci sandi antara aplikasi native Android / iOS dan sebuah aplikasi web.

Eksperimen dengan alur passkey di Passkeys Debugger.

Coba gratis

Proses untuk menjalin kepercayaan antara aplikasi iOS dan aplikasi web adalah sebagai berikut:

1. Pengembang aplikasi iOS harus menentukan daftar domain yang ingin dia kaitkan dengan aplikasi native. Domain-domain ini di-hardcode di dalam hak (entitlements) aplikasi iOS, misal:

• webcredentials:auth.Corbado.com
• webcredentials:*.Corbado.com

2. Setiap kali aplikasi iOS diinstal atau diperbarui, iOS akan mengunduh file apple-app-site-association untuk setiap entri dalam daftar hak aplikasi iOS tersebut.

3. Saat sebuah kredensial (mis. kunci sandi) dibuat di dalam aplikasi iOS, aplikasi iOS memvalidasi apakah domain server relying party tersebut terkait dengan aplikasi iOS dengan memeriksa dua aspek berikut:

• Apakah terdapat file apple-app-site-association untuk domain server relying party ini yang ada pada perangkat?
• Apakah aplikasi iOS tersebut tercantum dalam file apple-app-site-association tersebut?

Jika, dan hanya jika, kedua pertanyaan tersebut dapat dijawab dengan ya, kunci sandi dapat dibuat di dalam aplikasi iOS.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

Proses untuk menjalin kepercayaan antara aplikasi Android dan aplikasi web adalah sebagai berikut:

1. Pengembang aplikasi Android harus menentukan daftar domain yang ingin dia kaitkan dengan aplikasi Android. Domain-domain ini disimpan sebagai target dengan namespace web di dalam file assetlinks.json. Untuk menyatakan bahwa aplikasi Android dan aplikasi web berbagi kredensial, delegate_permission/common.get_login_creds harus dispesifikasikan. Temukan detailnya di sini.

2. Jika kunci sandi dibuat di dalam aplikasi Android, aplikasi Android memvalidasi apakah Relying Party ID dikaitkan dengan aplikasi Android dengan memeriksa assetlinks.json:

• Apakah ada file assetlinks.json untuk Relying Party ID ini pada https://<Relying Party ID>./well-known/assetlinks.json
• Apakah aplikasi Android didefinisikan dengan benar sebagai sebuah target.

3. Jika, dan hanya jika, kedua pertanyaan tersebut dapat dijawab dengan ya, kunci sandi dapat dibuat di dalam aplikasi Android.

Diagram di bawah membandingkan proses jalinan kepercayaan ini secara berdampingan.

Berlangganan Passkeys Substack kami untuk berita terbaru.

Berlangganan

Berikut ini, kami menyediakan ringkasan terperinci tentang berbagai pengaturan yang diperlukan untuk menyiapkan autentikasi kunci sandi dengan benar pada aplikasi native.

Untuk Flutter, masing-masing aturan dari Android atau iOS berlaku. Satu-satunya pengaturan khusus Flutter adalah pendaftaran file asosiasi, di mana Anda harus menambahkan:

• Untuk Android: flutter_deeplinking_enabled ke AndroidManifest.xml
• Untuk iOS: FlutterDeepLinkingEnabled true ke Info.plist

Berdasarkan pengalaman kami, berurusan dengan Relying Party ID, berbagai level dari (sub-)domain dan CNAME dapat menjadi tantangan yang cukup berat, kami menyajikan empat contoh berbeda dan menjelaskan alasan dan cara kerjanya.

Perhatikan bahwa baris tabel CNAME tidak diperlukan untuk autentikasi kunci sandi dan hanya merupakan hasil dari riset kami yang ingin kami tambahkan.

Pada contoh ini, file apple-app-site-association / assetlinks.json untuk Corbado.com dapat diunduh tanpa masalah apa pun ketika aplikasi native diinstal / diperbarui, karena file tersebut berada di lokasi yang sama dengan Relying Party ID.

Kunci sandi untuk Relying Party ID dapat dibuat.

Pada contoh ini, file apple-app-site-association / assetlinks.json untuk auth.corbado.com dapat diunduh tanpa masalah apa pun ketika aplikasi native diinstal / diperbarui, karena file tersebut berada di lokasi Relying Party ID, lantaran CNAME mengarah dari Relying Party ID ke lokasi yang disimpan.

Kunci sandi untuk Relying Party ID dapat dibuat.

Pada contoh ini, file apple-app-site-association / assetlinks.json untuk auth.corbado.com dapat diunduh tanpa masalah ketika aplikasi native diinstal / diperbarui, karena file tersebut, berkat CNAME, berada di lokasi di mana auth.corbado.com mengharapkannya.

TETAPI: File apple-site-association-file / assetlinks.json untuk corbado.com tidak dapat diunduh ketika aplikasi native diinstal / diperbarui, karena file tersebut tidak ada pada https://corbado.com/.well-known/apple-app-site-association / https://corbado.com/.well-known/assetlinks.json, lokasi di mana file tersebut diharapkan dan tidak ada CNAME yang mengarah ke sana.

Kunci sandi untuk Relying Party ID tidak dapat dibuat.

Pada contoh ini, file apple-app-site-association untuk corbado.com dapat diunduh tanpa masalah, ketika aplikasi native diinstal / diperbarui, karena file tersebut berada di lokasi yang diharapkan dan hak webcredentials (*.corbado.com) cocok dengan Relying Party ID (auth.corbado.com). Perhatikan bahwa contoh ini tidak berlaku untuk Android, karena Android tidak bekerja dengan sesuatu seperti (wildcard) entitlements. Secara umum, cara mendefinisikan Relying Party ID ini tidak disarankan.

Kunci sandi untuk Relying Party ID dapat dibuat.

Bergabunglah dengan komunitas passkeys kami untuk update dan dukungan.

Gabung

Kesalahan:

Anda mulai mengembangkan dan mendefinisikan subdomain (misal login.acme.com) sebagai Relying Party ID Anda. Pengguna awal membuat kunci sandi untuk Relying Party ID ini. Kemudian, Anda menyadari bahwa Anda juga memerlukan kunci sandi ini untuk autentikasi di subdomain lain (misal app.acme.com). Karena origin dari pengguna dan Relying Party ID untuk subdomain baru tersebut tidak cocok, pengguna tidak dapat masuk dengan kunci sandi tersebut. Mengubah Relying Party ID dalam pengaturan WebAuthn Anda menjadi acme.com akan membatalkan semua kunci sandi yang ada, karena origin baru dan Relying Party ID yang disimpan di dalam kunci sandi tersebut tidak cocok.

Solusi:

Lakukan pengecekan ganda pada awalnya ketika mendefinisikan Relying Party ID Anda karena ini kurang lebih bersifat final. Jika Anda merasa tidak yakin dan ingin siap untuk masa depan, yang berarti bahwa subdomain lain di masa mendatang mungkin memerlukan kunci sandi untuk autentikasi, kami sarankan untuk menggunakan root domain (misal acme.com) sebagai Relying party ID kecuali jika itu ada dalam Public Suffix List.

Kesalahan:

Anda mengembangkan aplikasi native dan web secara bersamaan. Untuk mempercepat proses, Anda menggunakan dua server WebAuthn berbeda (dengan Relying Party ID yang berbeda untuk aplikasi native dan web). Saat pengguna Anda membuat kunci sandi pertama mereka, masing-masing Relying Party ID disimpan di dalam kunci sandi. Memungkinkan login lintas-perangkat / lintas-platform dengan kunci sandi yang sama, misal dengan kunci sandi yang dibuat dalam aplikasi web dan mencoba masuk di dalam aplikasi native, tidak dimungkinkan lagi. Menggabungkan dua server WebAuthn akan membuang kunci sandi yang terdaftar dengan server WebAuthn lama (Relying Party ID lama) dan pengguna Anda tidak akan bisa masuk menggunakan kunci sandi tersebut.

Solusi:

Jika Anda memiliki beberapa aplikasi (misal aplikasi web dan aplikasi native), pastikan hanya memiliki satu server WebAuthn dan definisikan hanya satu Relying Party ID untuk semua aplikasi Anda. Mengaitkan aplikasi ini dapat dilakukan melalui langkah-langkah yang dijelaskan di atas.

Kesalahan:

Anda mulai mengembangkan aplikasi Anda, mengonfigurasi file asosiasi dan menyebarkannya ke server Anda. Untuk beberapa alasan, Anda tetap mendapatkan pesan kesalahan dan tidak menemukan akar penyebabnya.

Solusi:

Potensi penyebab pesan kesalahan tersebut mungkin adalah file asosiasi yang salah format atau tidak dapat diakses. Sebelum menyebarkan file asosiasi apa pun ke server, kami sangat menyarankan untuk memeriksa validitas dan jangkauan aksesibilitasnya (seringkali file ini mungkin berada di balik VPN yang kuat atau tembok api yang mencegah akses dengan benar untuk bot perayap Apple dan Google) atas sebuah file asosiasi melalui alat yang disediakan untuk iOS dan Android.

Kesalahan:

Anda menyebarkan file apple-app-site-association Anda ke server Anda dan ingin segera mulai membuat kunci sandi di perangkat pengujian Anda. Untuk beberapa alasan, Anda tidak dapat membuat kunci sandi dan mendapatkan pesan kesalahan.

Solusi:

Alasan di balik pesan kesalahan ini adalah bahwa perangkat iOS mengunduh file apple-app-site-association untuk memvalidasi Relying Party. Untuk melakukannya, perangkat iOS tidak mengirim permintaan langsung ke server Anda tetapi malah menggunakan CDN. Baik perangkat maupun CDN akan menyimpan file apple-app-site-association ke dalam cache setelah berhasil diambil. Karena fungsionalitas caching ini, perubahan baru pada file apple-app-site-association Anda tidak langsung terwujud dalam aplikasi Anda. Hal ini dapat memakan waktu hingga 24 jam sampai CDN menyimpan file apple-app-site-association tersebut ke dalam cache. Untuk mengatasi batasan ini saat masa pengembangan, Anda dapat menambahkan ?mode=developer pada Relying Party ID dan menonaktifkan caching sepenuhnya (misal Relying Party ID menjadi acme.com?mode=developer).

Kesalahan:

Anda mulai mengembangkan aplikasi Android dan ingin mengujinya di emulator Android. Untuk beberapa alasan, Anda mendapatkan pesan kesalahan, meskipun Anda telah menyiapkan emulator Android dengan benar dan aplikasi lain tampaknya berjalan lancar di atasnya.

Solusi:

Versi Android, dukungan Play Store, dan versi API memainkan peranan besar saat menguji sebuah aplikasi kunci sandi. Selain itu, Anda harus masuk ke akun Google Anda. Silakan lihat bagian penyelesaian masalah (troubleshooting) kami untuk detailnya.

Rekomendasi keseluruhan kami adalah memilih Relying Party ID Anda secara saksama berdasarkan lanskap dan kebutuhan aplikasi Anda. Di bawah ini, kami telah mengumpulkan kasus penggunaan yang paling umum, tetapi rekomendasi umum kami adalah Anda harus bertujuan untuk memilih root domain Anda sebagai Relying Party ID Anda dan mengonfigurasi autentikasi Anda dengan cara ini. Bersama Corbado, kami juga telah mengonfigurasikannya dengan cara ini untuk Anda (sebagai bagian dari pendekatan kami untuk menawarkan autentikasi kunci sandi yang mulus untuk semua pengaturan teknis. Komponen antarmuka (UI components) dan SDK kami sudah dipersiapkan untuk digunakan dengan root domain Anda sebagai Relying Party ID).

Berikut ini, kami menyediakan pohon keputusan yang sangat spesifik yang akan membantu Anda menentukan Relying Party ID yang tepat serta bagaimana seharusnya Anda menangani / meng-host file asosiasi ketika menggunakan Corbado sebagai solusi kunci sandi Anda.

Keputusan pertama adalah apakah Anda sedang berada dalam lingkungan pengembangan atau produksi. Tingkat keputusan Anda selanjutnya yang harus Anda buat didasarkan pada lanskap aplikasi Anda: apakah Anda hanya memiliki sebuah aplikasi native atau memiliki aplikasi native dan web.

Untuk lingkungan pengembangan, kami asumsikan bahwa Anda ingin memulai pengembangan dan pengujian secara cepat. Relying Party ID dapat diubah nanti jika Anda ingin meluncurkannya.

• Atur Relying Party ID = pro-XXX.frontendapi.cloud.corbado.io (nilai bawaan)
• Corbado meng-host file asosiasi untuk Anda
• Tidak ada ToDo DNS untuk Anda

Tidaklah mudah menguji aplikasi web dan aplikasi native secara bersamaan

Opsi 1:

Anda dapat menyetel Relying Party ID = pro-XXX.frontendapi.cloud.corbado.io (aplikasi native berfungsi) ATAU setel Relying Party ID = localhost (aplikasi web berfungsi)

Opsi 2:

Satu-satunya solusi untuk menjalankan aplikasi native dan aplikasi web secara bersamaan adalah dengan menggunakan proksi terbalik lokal (ini merupakan sebuah solusi yang cukup rumit):

• Setel Relying Party ID = acme-dev.com
• Atur CNAME dari acme-dev.com => pro-XXX.frontendapi.cloud.corbado.io
• Tambahkan entri /etc/hosts lokal localhost acme-dev.com
• Tambahkan proksi terbalik (nginx) dengan aturan untuk acme-dev.com => localhost:3000 (sebagai contoh)

Dalam lingkungan produksi, Anda harus memutuskan apakah Anda baik-baik saja dengan subdomain sebagai Relying Party ID (misal auth.acme.com) atau jika Anda menginginkan root domain sebagai Relying Party ID (misal acme.com)

• Setel Relying Party ID = auth.acme.com
• Corbado meng-host file asosiasi untuk Anda
• Atur CNAME dari auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io

• Setel Relying Party ID = auth.acme.com
• Corbado meng-host file asosiasi untuk Anda
• Atur CNAME dari auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io (juga dibutuhkan supaya kuki berfungsi jika Anda menggunakan manajemen sesi Corbado)

• Setel Relying Party ID = acme.com
• Host sendiri file asosiasi Anda di server Anda sendiri pada acme.com/.well-known/<association file>
• Tidak ada ToDo DNS untuk Anda

• Setel Relying Party ID = acme.com
• Host sendiri file asosiasi Anda di server Anda sendiri pada acme.com/.well-known/<association file>
• Jika Anda menggunakan, manajemen sesi Corbado, Anda perlu mengatur CNAME dari auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io agar kuki bekerja (CNAME ini tidak diperlukan untuk Relying Party ID dan semata-mata hanya untuk manajemen sesi)

Pohon keputusan berikut merangkum seluruh alur konfigurasi.

Relying Party ID adalah dasar dari WebAuthn serta autentikasi berbasis kunci sandi yang memberikan ketahanan yang kuat terhadap phishing. Mengonfigurasikannya dengan tepat, memahami seluk beluk pencocokan domain, dan memastikan penyebaran yang benar pada aplikasi native sangatlah krusial. Blog ini telah menunjukkan kepada Anda bagaimana cara menyiapkannya dengan benar dan bagaimana menangani berbagai kesalahan. Begitu konfigurasi rpID Anda telah solid, fokuslah untuk mengoptimalkan alur pembuatan kunci sandi Anda serta alur login kunci sandi untuk mendorong adopsi yang sebenarnya. Untuk wawasan mendalam mengenai persiapan kunci sandi untuk aplikasi native, kami menyarankan untuk membaca tentang kunci sandi pada Flutter.

Jika Anda memiliki pertanyaan lebih lanjut atau memerlukan bantuan, jangan ragu untuk menghubungi kami.

Tentang Corbado

Corbado adalah Passkey Intelligence Platform untuk tim CIAM yang menjalankan autentikasi consumer dalam skala besar. Kami membantu Anda melihat apa yang tidak bisa ditunjukkan oleh log IDP dan tool analytics generik: device, versi OS, browser, dan credential manager mana yang mendukung passkey; mengapa enrollment tidak menjadi login; di mana flow WebAuthn gagal; dan kapan update OS atau browser diam-diam merusak login — semuanya tanpa mengganti Okta, Auth0, Ping, Cognito, atau IDP internal Anda. Dua produk: Corbado Observe menambah observability untuk passkey dan metode login lainnya. Corbado Connect menghadirkan managed passkey dengan analytics terintegrasi (berdampingan dengan IDP Anda). VicRoads menjalankan passkey untuk 5M+ pengguna dengan Corbado (aktivasi passkey +80%). Bicara dengan pakar Passkey →

Autentikator membandingkan origin aktual peramban dengan Relying Party ID yang disimpan di dalam kunci sandi. Jika penyerang meng-host situs palsu di domain yang berbeda, ketidakcocokan origin menyebabkan autentikasi otomatis gagal, bahkan jika tantangan yang dipalsukan mengklaim RP ID yang sah. Keterikatan ini berarti kunci sandi yang didaftarkan pada paypal.com tidak dapat digunakan pada domain mirip seperti paybal.com.

Mengubah RP ID membatalkan semua kunci sandi yang ada karena RP ID yang disimpan di setiap kredensial tidak lagi cocok dengan nilai baru. Pengecualiannya adalah saat RP ID baru merupakan subdomain dari yang lama atau ketika Related Origin Requests dikonfigurasi melalui .well-known/webauthn. Pilih root domain sebagai RP ID sejak awal untuk menghindari masalah yang tidak dapat diubah ini.

iOS tidak mengambil file apple-app-site-association langsung dari server Anda. Ia menggunakan CDN Apple, yang dapat memakan waktu hingga 24 jam untuk menyimpan cache file yang baru disebarkan atau diperbarui. Selama pengembangan, tambahkan ?mode=developer ke Relying Party ID untuk sepenuhnya melewati cache.

Menggunakan root domain (misal, acme.com) disarankan karena kunci sandi yang dibuat di subdomain mana pun dapat mengautentikasi seluruh subdomain dari root tersebut. RP ID subdomain membatasi penggunaan kunci sandi ke subdomain tersebut dan turunannya, yang mana dapat memecah aliran lintas subdomain di kemudian hari. Jika Anda memiliki banyak root domain seperti acme.com dan acme.co.uk, konfigurasikan Related Origin Requests melalui .well-known/webauthn untuk mengizinkan penggunaan ulang kunci sandi di antaranya.