--- url: 'https://www.corbado.com/id/blog/webauthn-relying-party-id-rpid-kunci-sandi' title: 'Relying Party ID (rpID) WebAuthn & Kunci Sandi: Domain & Aplikasi Native' description: 'Blog ini menjelaskan Relying Party ID WebAuthn untuk autentikasi kunci sandi. Artikel ini menguraikan konfigurasi yang tepat, pencocokan domain & aplikasi native.' lang: 'id' author: 'Vincent Delitz' date: '2026-06-15T13:55:44.872Z' lastModified: '2026-06-16T06:06:44.297Z' keywords: 'relying party id, webauthn, kunci sandi, aplikasi native, pencocokan domain, phishing' category: 'WebAuthn Know-How' --- # Relying Party ID (rpID) WebAuthn & Kunci Sandi: Domain & Aplikasi Native ## Key Facts - **Relying Party ID** adalah domain yang disematkan dalam setiap kunci sandi. Autentikasi akan gagal jika origin peramban tidak cocok, membuat kunci sandi sangat tahan terhadap phishing. - **RP ID** tidak boleh berada di **Public Suffix List** dan mengubahnya akan membatalkan semua kunci sandi yang ada. Gunakan root domain secara bawaan untuk memastikan fungsinya di masa depan. - Aplikasi iOS memerlukan file **apple-app-site-association** pada `/.well-known/` di bawah RP ID. Android memerlukan **assetlinks.json** pada jalur yang sama. File baru mungkin memakan waktu hingga 24 jam untuk masuk ke dalam cache. - Beberapa root domain memerlukan **Related Origin Requests** melalui `.well-known/webauthn` untuk berbagi kunci sandi. Gunakan satu server WebAuthn dengan satu RP ID untuk semua aplikasi, baik web maupun native. ## 1. Pendahuluan [Autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) [kunci sandi](https://www.corbado.com/id/glossary/cda) (passkey) dengan cepat menjadi standar seiring dengan raksasa teknologi seperti [TikTok](https://www.corbado.com/blog/tiktok-passkeys), GitHub, [WhatsApp](https://www.corbado.com/blog/whatsapp-passkeys), X (Twitter), [LinkedIn](https://www.corbado.com/blog/linkedin-passkeys), dan Amazon meluncurkannya atau sudah melakukannya. Jelas bahwa dunia teknologi mengakui pentingnya [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) yang sederhana dan aman. Selain pengalaman pengguna yang mulus dalam melakukan [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) dengan [Face ID](https://www.corbado.com/faq/is-face-id-passkey), Touch ID, atau [Windows Hello](https://www.corbado.com/glossary/windows-hello), [kunci sandi](https://www.corbado.com/id/glossary/cda) menawarkan keamanan yang tak tertandingi dibandingkan dengan metode autentikasi tradisional seperti [kata sandi](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android). Salah satu fitur yang menonjol adalah ketahanannya yang kuat terhadap [phishing](https://www.corbado.com/glossary/phishing). Serangan [phishing](https://www.corbado.com/glossary/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](https://www.darkreading.com/application-security/okta-flaw-involved-mgm-resorts-breach-attackers-claim) (penyedia autentikasi!) atau [Retool](https://retool.com/blog/mfa-isnt-mfa/) telah menjadi korban serangan spear-[phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/id/glossary/cda), dan situs tersebut palsu, autentikasi Anda akan gagal. Ini karena kunci sandi terikat ke domain tempat mereka dibuat melalui **Relying Party ID**. > Anda tidak dapat masuk dengan kunci sandi di situs lain mana pun, yang membuat kunci > sandi sangat tahan terhadap phishing (meskipun tidak ada sistem yang benar-benar kebal > terhadap semua vektor serangan). Mekanisme ini tertanam di WebAuthn, standar web yang mendasari kunci sandi untuk [autentikasi tanpa kata sandi](https://www.corbado.com/id/blog/revolut-passkey). 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](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql) 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](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql) atau native, cocok dengan [Relying Party](https://www.corbado.com/glossary/relying-party) ID yang disimpan di dalam kunci sandi. Pada bagian berikut, kita akan melihat secara detail bagaimana proses [pencocokan domain](#what-relying-party-id) ini bekerja dan bagaimana, secara khusus, [aplikasi native](https://www.corbado.com/id/blog/passkey-aplikasi-native) diamankan. ## 2. Apa itu Relying Party ID? [**Relying Party ID**](https://www.w3.org/TR/webauthn-2/#relying-party-identifier) 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](https://www.corbado.com/id/blog/passkey-aplikasi-native) [di bawah](#integration-options-native-apps)). Ini merupakan komponen penting dari spesifikasi WebAuthn, yang dapat Anda pelajari lebih lanjut [di sini](https://www.w3.org/TR/webauthn-2/). [Relying Party](https://www.corbado.com/glossary/relying-party) ID dapat berupa root domain (mis. `corbado.com`) atau subdomain (`auth.corbado.com`). Anda tidak dapat menyimpan root domain sebagai [Relying Party](https://www.corbado.com/glossary/relying-party) ID jika ia terdapat dalam daftar sufiks publik (temukan daftar dan pustaka untuk deteksi sufiks publik [di sini](https://publicsuffix.org/learn/)). 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: ![tabel relying party id](https://www.corbado.com/website-assets/relying_party_id_table_4c98cc04f4.jpg) Di bawah ini, Anda dapat melihat [**PublicKeyCredentialCreationOptions**](https://www.w3.org/TR/webauthn-2/#iface-pkcredential) yang telah diurai: ```json { "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](https://www.corbado.com/blog/paypal-passkeys) yang merupakan situs web palsu yang mencoba mencuri kredensial [PayPal](https://www.corbado.com/blog/paypal-passkeys) Anda untuk masuk atas nama Anda dan mengirim uang ke akun penyerang. Situs [PayPal](https://www.corbado.com/blog/paypal-passkeys) 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:`. 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](#configuring-relying-party-native-apps)). Untuk detail lebih lanjut tentang bagaimana validasi origin bekerja untuk aplikasi native, lihat panduan khusus kami tentang validasi origin WebAuthn untuk aplikasi native._ ## 3. Dua Opsi Integrasi Berbeda untuk Aplikasi Native Untuk mengimplementasikan kunci sandi pada [aplikasi native](https://www.corbado.com/id/blog/passkey-aplikasi-native), seorang pengembang dapat memilih antara menambahkannya melalui [WebView](https://www.corbado.com/blog/native-app-passkeys) atau secara native. Mari kita periksa kelebihan dan kekurangan dari kedua pendekatan tersebut di bawah ini. ### 3.1 Integrasi Kunci Sandi melalui WebView ![Integrasi Kunci Sandi WebView (GitHub)](https://www.corbado.com/website-assets/650c601b1eb462e25702a870_android_webview_passkey_github_8bc81d9852.jpg) 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](https://www.corbado.com/blog/native-app-passkeys) 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._ ### 3.2 Integrasi Kunci Sandi Native ![Integrasi Kunci Sandi Native (Kayak)](https://www.corbado.com/website-assets/650c625cac723f594137a029_android_native_passkey_kayak_0f689e761e.jpg) **Integrasi native** melibatkan pembangunan fungsionalitas kunci sandi langsung ke dalam aplikasi [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) atau [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) menggunakan API dan pustaka khusus platform. Metode ini menawarkan pengalaman pengguna yang lebih mulus, karena tidak perlu berpindah antara aplikasi native dan [WebView](https://www.corbado.com/blog/native-app-passkeys). 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](https://www.corbado.com/blog/how-to-enable-passkeys-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. ## 4. Mengonfigurasi Relying Party untuk Aplikasi Native Aplikasi native (misalnya aplikasi iOS atau [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) menghadirkan tantangan dibandingkan dengan [aplikasi web](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql). 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). ### 4.1 File Asosiasi di iOS: apple-app-site-association iOS menggunakan file apple-app-site-association. File ini berisi berbagai hak (entitlement), tetapi untuk WebAuthn dan kunci sandi, hak webcredentials yang penting. ```json { "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:///.well-known/apple-app-site-association`). Lihat contoh langsung [di sini](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/apple-app-site-association). ### 4.2 File Asosiasi di Android: assetlinks.json [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) menggunakan file `assetlinks.json`, yang mana, sama seperti rekan iOS-nya, memerlukan konfigurasi khusus untuk WebAuthn dan kunci sandi. ```json [ { "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](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/assetlinks.json). Agar aplikasi Android berfungsi, file assetlinks.json harus disimpan di bawah direktori `/.well-known` milik Relying Party ID `https:///.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. ## 5. Menjalin Kepercayaan antara Aplikasi Native dan Aplikasi Web ### 5.1 iOS 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. ### 5.2 Android 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](https://developer.android.com/training/sign-in/passkeys#add-support-dal). 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://./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. ## 6. Ringkasan Pengaturan Android, iOS & Flutter Berikut ini, kami menyediakan ringkasan terperinci tentang berbagai pengaturan yang diperlukan untuk menyiapkan autentikasi kunci sandi dengan benar pada aplikasi native. | Fitur | iOS | Android | | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Panduan implementasi resmi untuk autentikasi kunci sandi native | Apple Developer | Google Developer | | Memungkinkan berbagi kunci sandi dengan aplikasi web | Ya, melalui file apple-app-site-association | Ya, melalui assetlinks.json | | Lokasi file asosiasi | [https://acme.com/.well-known/apple-app-site-association](https://acme.com/.well-known/apple-app-site-association) | [https://acme.com/.well-known/assetlinks.json](https://acme.com/.well-known/assetlinks.json) | | File di-cache | Ya (sejak iOS 14), sinkronisasi awal bisa memakan waktu hingga 24 jam | Ya (oleh Play Services) | | Pemintasan (By-pass) memungkinkan | Ya, dengan bagian alternate mode | Tidak | | Dapat diuji dengan | apple-app-site-association test | assetlinks.json test | | Pengenal aplikasi dengan sampel | `.`, mis. `T84QZS65DQ.com.facebook.Messenger` | Sidik jari SHA256, mis. `E3:F9:E1:E0:CF:99:D0:E5:6A:05:5B:A6: 5E:24:1B:33:99: 7F:CE:A5:24:32: 6B:0C:DD:6E:C1:32: 7E:D0:FD:C1` | | Di mana menemukan pengenal aplikasi | Awalan Pengenal Aplikasi Tim dapat ditemukan di akun pengembang pada developer.apple.com dan Pengenal Bundel adalah nama yang persis dari dalam proyek XCode | Saat sudah diunggah: Google Play Console > Release management > App signing Lokal: `keytool -list -v -keystore -alias -storepass -keypass ` | | Nama bagian yang menautkan aplikasi ke web | applinks (tidak diperlukan untuk kunci sandi) | `delegate_permission/common.handle_all_urls` (diperlukan untuk kunci sandi) | | Nama bagian yang mengizinkan berbagi kredensial antara aplikasi / web | webcredentials | `delegate_permission/common.get_login_creds` | | Pendaftaran dari semua file asosiasi | Aktifkan dan tambahkan associated domain di lingkungan pengembangan XCode (pengaturan properti untuk menghasilkan file hak) | Saat menggunakan API Credential Manager, pendaftaran assetlinks.json dalam manifest tidak diperlukan untuk kunci sandi (meskipun diperlukan untuk kata sandi). Jika tidak menggunakan API Credential Manager, Anda perlu mencantumkan nama host dengan entri `` dalam AndroidManifest.xml pada aktivitas spesifik (bagian dari Kode sumber Aplikasi Android). Parameter `` perlu memiliki autoVerify=true. | Untuk [Flutter](https://www.corbado.com/blog/flutter-passkeys-package), masing-masing aturan dari Android atau iOS berlaku. Satu-satunya pengaturan khusus [Flutter](https://www.corbado.com/blog/flutter-passkeys-package) adalah pendaftaran file asosiasi, di mana Anda harus menambahkan: - Untuk Android: [flutter_deeplinking_enabled ke AndroidManifest.xml](https://docs.flutter.dev/cookbook/navigation/set-up-app-links) - Untuk iOS: [FlutterDeepLinkingEnabled true ke Info.plist](https://docs.flutter.dev/cookbook/navigation/set-up-universal-links) ## 7. Contoh untuk File Asosiasi & Relying Party ID Valid & Tidak Valid 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. ### 7.1 Contoh 1: Relying Party adalah Root Domain | **Relying Party ID** | corbado.com | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | | **Entitlements (hanya iOS)** | webcredentials:corbado.com | | **Lokasi file apple-app-site-association** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **Lokasi file assetlinks.json** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | n/a | 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.** ### 7.2 Contoh 2: Relying Party adalah Subdomain dan CNAME disetel | Relying Party ID | auth.corbado.com | | ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Entitlements (hanya iOS)** | webcredentials:auth.corbado.com | | **Lokasi file apple-app-site-association** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **Lokasi file assetlinks.json** | [https://pro-123.passkeys.eu/.well-known/assetlinks.json](https://pro-123.passkeys.eu/.well-known/assetlinks.json) | | **CNAME** | auth.corbado.com => pro-123.passkeys.eu | 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.** ### 7.3 Contoh 3: Relying Party adalah Root Domain dan CNAME disetel | Relying Party ID | corbado.com | | ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Entitlements (hanya iOS)** | webcredentials:corbado.com; webcredentials:auth.corbado.com | | **Lokasi file apple-app-site-association** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **Lokasi file assetlinks.json** | [https://pro-123.passkeys.eu/.well-known/assetlinks.json](https://pro-123.passkeys.eu/.well-known/assetlinks.json) | | **CNAME** | auth.corbado.com => pro-123.passkeys.eu | 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.** ### 7.4 Contoh 4: Relying Party adalah Subdomain & Wildcard Entitlement disetel | Relying Party ID | auth.corbado.com | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | | **Entitlements (hanya iOS)** | webcredentials:\*.corbado.com | | **Lokasi file apple-app-site-association** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **Lokasi file assetlinks.json** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | n/a | 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.** ## 8. Kesalahan Umum Relying Party ID & Cara Menghindarinya ### 8.1 Mengubah Relying Party ID dari Subdomain ke Root Domain **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](https://publicsuffix.org/learn/). ### 8.2 Relying Party ID Berbeda untuk Aplikasi Native dan Web **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. ### 8.3 File Asosiasi Tidak Valid dan Tidak Dapat Diakses **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](https://cybernews.com/best-vpn/most-secure-vpns/) atau tembok api yang mencegah akses dengan benar untuk bot perayap Apple dan Google) atas sebuah file asosiasi melalui alat yang disediakan untuk [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) dan Android. ### 8.4 File apple-app-site-association Belum Di-cache oleh CDN Apple **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`). ### 8.5 Inkompatibilitas Emulator Android dan Versi API **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. ## 9. Rekomendasi ### 9.1 Rekomendasi Umum 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). | Kasus | Rekomendasi | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **A) Anda memiliki satu root domain:**

Contoh: acme.com

Semua aplikasi dan autentikasi berjalan pada root domain ini atau di subdomainnya | ✔️ Pilih root domain sebagai Relying Party ID Anda karena ini tidak akan menyebabkan masalah pada aplikasi web maupun native. | | **B) Anda memiliki banyak root domain:**

Contoh: kayak.com, kayak.co.uk, kayak.de

Anda melayani pengguna Anda dari top-level domain internasional yang berbeda. Kayak.com untuk Amerika Serikat dan kayak.co.uk untuk Inggris atau Anda memiliki root domain yang sama sekali berbeda yang seharusnya memungkinkan pengguna yang sama untuk masuk menggunakan kunci sandi yang sama. | ⚠️ Pada aplikasi web Anda, berbagi kunci sandi memerlukan konfigurasi Related Origin Requests melalui `.well-known/webauthn` untuk memungkinkan origin yang ditentukan untuk menggunakan RP ID yang sama (dukungan peramban bervariasi; verifikasi kompatibilitas). Atau secara alternatif, pilih satu root domain autentikasi bersama.

✔️ Anda dapat menyambungkan aplikasi native Anda ke root domain berapa pun asal Anda memiliki kendali terhadap file asosiasi root.

❌ Jika di kemudian hari Anda ingin bermigrasi ke root domain lain sebagai host situs web Anda, Anda tidak akan dapat menggunakan kunci sandi yang sudah Anda buat, karena Anda harus melakukan rebranding dan mengubah domainnya (Relying Party ID). | | **C) Anda BELUM memiliki root domain, Anda berjalan hanya pada sisi backend atau pada subdomain publik. Ada beberapa kasus di mana ini mungkin terjadi:**

1. Anda bekerja pada subdomain yang tersedia secara gratis, di mana root domain tersebut tidak di bawah kendali Anda (root domain terdaftar dalam [https://publicsuffix.org/](https://publicsuffix.org/)) sebagai contoh URL CDN

2. Anda mengerjakan sebuah aplikasi native. | ❌ Pada subdomain publik, Anda tidak dapat mengontrol file asosiasi pada tingkat root di root domain tersebut. Karenanya, kunci sandi tidak akan bekerja secara native.

⚠️ Satu-satunya cara memperbaiki ini untuk sebagian layanan adalah dengan mengubah ke paket berbayar, di mana Anda dapat menentukan CNAME atau mendapatkan root domain kustom untuk Anda sendiri. | ### 9.2 Rekomendasi Ketika Menggunakan Corbado 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. #### A) Pengembangan Untuk lingkungan pengembangan, kami asumsikan bahwa Anda ingin memulai pengembangan dan pengujian secara cepat. Relying Party ID dapat diubah nanti jika Anda ingin meluncurkannya. ##### A1) Native-Saja - 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 ##### A2) Aplikasi Native & Aplikasi Web 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) #### B) Produksi 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`) ##### B1) Subdomain sebagai Relying Party ID ###### B1.1) Native-Saja - 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` ###### B1.2) Aplikasi Native & Aplikasi Web - 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) ##### B2) Root Domain sebagai Relying Party ID ###### B2.1) Native-Saja - Setel Relying Party ID = `acme.com` - Host sendiri file asosiasi Anda di server Anda sendiri pada `acme.com/.well-known/` - Tidak ada ToDo DNS untuk Anda ###### B2.2) Aplikasi Native & Aplikasi Web - Setel Relying Party ID = `acme.com` - Host sendiri file asosiasi Anda di server Anda sendiri pada `acme.com/.well-known/` - 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. ## 10. Kesimpulan 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](https://www.corbado.com/id/blog/praktik-terbaik-pembuatan-passkey) Anda serta alur [login kunci sandi](https://www.corbado.com/id/blog/passkey-login-praktik-terbaik) untuk mendorong adopsi yang sebenarnya. Untuk wawasan mendalam mengenai persiapan kunci sandi untuk aplikasi native, kami menyarankan untuk membaca tentang kunci sandi pada [Flutter](https://www.corbado.com/blog/flutter-passkeys-package). Jika Anda memiliki pertanyaan lebih lanjut atau memerlukan bantuan, jangan ragu untuk [menghubungi kami](https://bit.ly/passkeys-community). ## Pertanyaan yang Sering Diajukan ### Bagaimana Relying Party ID mencegah phishing dalam autentikasi kunci sandi? 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. ### Apa yang terjadi jika saya mengubah Relying Party ID WebAuthn setelah pengguna mendaftarkan kunci sandi? 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. ### Mengapa kunci sandi iOS saya tidak segera berfungsi setelah saya menyebarkan file apple-app-site-association? 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. ### Haruskah saya menggunakan subdomain atau root domain sebagai Relying Party ID untuk kunci sandi? 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.