--- url: 'https://www.corbado.com/vi/blog/webauthn-relying-party-id-rpid-passkeys' title: 'WebAuthn Relying Party ID (rpID) & Passkeys: Tên miền & Ứng dụng gốc' description: 'Bài đăng trên blog này giải thích về WebAuthn Relying Party ID cho xác thực passkey. Nó phác thảo cấu hình chuẩn xác, khớp tên miền và cấu hình ứng dụng gốc.' lang: 'vi' author: 'Vincent Delitz' date: '2026-06-15T13:56:36.941Z' lastModified: '2026-06-16T06:08:57.568Z' keywords: 'relying party id, passkey, xác thực passkey, ứng dụng gốc, tên miền' category: 'WebAuthn Know-How' --- # WebAuthn Relying Party ID (rpID) & Passkeys: Tên miền & Ứng dụng gốc ## Key Facts - **Relying Party ID** là một tên miền được nhúng trong mọi passkey. Quá trình xác thực sẽ thất bại nếu nguồn gốc (origin) của trình duyệt không khớp, giúp passkey có khả năng chống lừa đảo mạnh mẽ. - **RP ID** không được nằm trong **Public Suffix List** (Danh sách Hậu tố Công cộng) và việc thay đổi nó sẽ làm mất hiệu lực tất cả các passkey hiện có. Hãy sử dụng tên miền gốc theo mặc định để đảm bảo khả năng tương thích trong tương lai. - Ứng dụng iOS yêu cầu tệp **apple-app-site-association** tại đường dẫn `/.well-known/` dưới RP ID. Android yêu cầu tệp **assetlinks.json** ở cùng đường dẫn. Các tệp mới có thể mất tới 24 giờ để lưu vào bộ nhớ cache. - Nhiều tên miền gốc cần **Related Origin Requests** (Yêu cầu Nguồn gốc Liên quan) thông qua `.well-known/webauthn` để chia sẻ passkey. Sử dụng một máy chủ WebAuthn duy nhất với một RP ID cho tất cả các ứng dụng, web và ứng dụng gốc. ## 1. Giới thiệu [Xác thực](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android) bằng passkey đang nhanh chóng trở thành tiêu chuẩn khi các gã khổng lồ công nghệ như [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) và Amazon đã hoặc đang triển khai chúng. Rõ ràng là thế giới công nghệ đang nhận ra tầm quan trọng của việc [xác thực](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android) đơn giản và an toàn. Bên cạnh trải nghiệm người dùng liền mạch khi [xác thực](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android) bằng [Face ID](https://www.corbado.com/faq/is-face-id-passkey), Touch ID hoặc [Windows Hello](https://www.corbado.com/glossary/windows-hello), passkey mang lại khả năng [bảo mật](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android) vô song so với các phương pháp xác thực truyền thống như mật khẩu. Một trong những tính năng nổi bật là khả năng chống lừa đảo mạnh mẽ của chúng. Tấn công lừa đảo (phishing attack) là một cuộc tấn công trong đó nạn nhân bị lừa cung cấp thông tin đăng nhập cho một trang web giả mạo bắt chước trang web gốc. Ví dụ: hãy tưởng tượng bạn nhận được một email có vẻ như từ ngân hàng của bạn, yêu cầu bạn đăng nhập. Bạn nhấp vào liên kết, và trang web trông hợp pháp, vì vậy bạn nhập thông tin đăng nhập của mình và kẻ tấn công có thể sử dụng chúng để đăng nhập vào trang web gốc. Đây đang trở thành một vấn đề ngày càng gia tăng trong kỷ nguyên kỹ thuật số và ngay cả các công ty lớn như [Okta ](https://www.darkreading.com/application-security/okta-flaw-involved-mgm-resorts-breach-attackers-claim)(một nhà cung cấp xác thực!) hoặc [Retool ](https://retool.com/blog/mfa-isnt-mfa/)cũng từng là nạn nhân của các cuộc tấn công spear-[phishing](https://www.corbado.com/glossary/phishing) (một dạng lừa đảo đặc biệt trong đó những nạn nhân đơn lẻ là mục tiêu cụ thể bằng các thủ đoạn lừa đảo rất cá nhân), nhấn mạnh sự cần thiết của các biện pháp [bảo mật](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android) mạnh mẽ. Ngược lại, nếu bạn sử dụng passkey và trang web đó là giả mạo, quá trình xác thực của bạn sẽ thất bại. Điều này là do passkey được liên kết chặt chẽ với các tên miền mà chúng được tạo ra thông qua **Relying Party ID**. > Bạn không thể đăng nhập bằng passkey trên bất kỳ trang web nào khác, làm cho passkey có > khả năng chống lừa đảo mạnh mẽ (mặc dù không có hệ thống nào hoàn toàn miễn > [nhi](https://www.corbado.com/blog/agentic-non-human-identity-eic-2026)ễm với tất cả các vectơ tấn công). Cơ chế này được tích hợp vào WebAuthn, tiêu chuẩn web nền tảng của passkey cho [xác thực không mật khẩu](https://www.corbado.com/vi/glossary/ctap). WebAuthn được xây dựng trên hai nghi thức cốt lõi: nghi thức đăng ký và xác thực. Trong nghi thức đăng ký (đăng ký tài khoản), một passkey mới được tạo cho một dịch vụ trực tuyến (Relying Party) thông qua một ứng dụng web hoặc ứng dụng gốc. Trong quá trình này, tên miền (Relying Party ID) mà [passkey được tạo](https://www.corbado.com/vi/faq/passkey-duoc-tao-ra-nhu-the-nao) ra cho nó sẽ được lưu trữ trong passkey. Điều này cho phép nghi thức xác thực (đăng nhập) kiểm tra xem dịch vụ trực tuyến (Relying Party), mà ứng dụng web hoặc ứng dụng gốc thuộc về, có khớp với [Relying Party](https://www.corbado.com/glossary/relying-party) ID được lưu trữ trong passkey hay không. Trong phần sau, chúng ta sẽ xem chi tiết cách quá trình [khớp tên miền](#what-relying-party-id) này hoạt động và cụ thể là cách các ứng dụng gốc được [bảo mật](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android). ## 2. Relying Party ID là gì? [**Relying Party ID**](https://www.w3.org/TR/webauthn-2/#relying-party-identifier) về cơ bản là một tên miền được lưu trữ trong passkey, đảm bảo passkey chỉ hoạt động nếu URL trình duyệt hiện tại (nguồn gốc của người dùng được tự động gửi trong mỗi yêu cầu) khớp với nó (xem cách tiếp cận ứng dụng gốc [bên dưới](#integration-options-native-apps)). Đây là một thành phần quan trọng của thông số kỹ thuật WebAuthn, mà bạn có thể tìm hiểu sâu hơn [tại đây](https://www.w3.org/TR/webauthn-2/). [Relying Party](https://www.corbado.com/glossary/relying-party) ID có thể là tên miền gốc (ví dụ: `corbado.com`) hoặc một miền phụ (`auth.corbado.com`). Bạn không thể lưu trữ tên miền gốc làm [Relying Party](https://www.corbado.com/glossary/relying-party) ID nếu nó nằm trong danh sách hậu tố công cộng (tìm danh sách và thư viện phát hiện hậu tố công cộng [tại đây](https://publicsuffix.org/learn/)). Việc thay đổi Relying Party ID cho một dịch vụ trực tuyến sẽ làm hỏng các passkey hiện có (ngoại lệ: Relying Party ID mới là một miền phụ của Relying Party ID cũ, hoặc Related Origin Requests được cấu hình thông qua `.well-known/webauthn` để cho phép tái sử dụng passkey trên các miền liên quan). Trong quá trình xác thực, Relying Party ID được kiểm tra chéo với URL trình duyệt (nguồn gốc của người dùng) để đảm bảo chúng khớp nhau. Khớp trong ngữ cảnh này có nghĩa là một trong hai trường hợp: - URL trình duyệt (nguồn gốc của người dùng) khớp chính xác với Relying Party ID HOẶC - URL trình duyệt (nguồn gốc của người dùng) là một miền phụ khớp với Relying Party ID và miền cha có thể đăng ký được (ví dụ: `com` hoặc bất kỳ miền nào trên Public Suffix List đều không hoạt động) Dưới đây là phác thảo chi tiết về những _originalHost_ nào (cột thứ hai) được phép truy cập vào tên miền cha của nó: ![bảng relying party id](https://www.corbado.com/website-assets/relying_party_id_table_4c98cc04f4.jpg) Trong phần sau, bạn sẽ thấy [**PublicKeyCredentialCreationOptions**](https://www.w3.org/TR/webauthn-2/#iface-pkcredential) đã được phân tích cú pháp: ```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": "Corbado user", "id": "bz9ZDfHzOBLycqISTAdWwWIZt8VO-6mT3hBNXS5jwmY=" } } } ``` `rp` là viết tắt của Relying Party. Một trong những lợi ích lớn nhất của Relying Party ID là phòng ngừa các cuộc tấn công lừa đảo. Hãy tưởng tượng kịch bản sau: 1. Kẻ tấn công phát triển một bản sao của [PayPal](https://www.corbado.com/blog/paypal-passkeys), là một trang web giả mạo cố gắng đánh cắp thông tin đăng nhập [PayPal](https://www.corbado.com/blog/paypal-passkeys) của bạn để đăng nhập dưới danh nghĩa của bạn và gửi tiền vào tài khoản của kẻ tấn công. Trang web [PayPal](https://www.corbado.com/blog/paypal-passkeys) giả mạo này được lưu trữ trên miền paybal.com (vì vậy thoạt nhìn thường không thể nhận ra đó là một tên miền khác). 2. Bạn đã [tạo một passkey](https://www.corbado.com/vi/blog/thuc-hanh-tot-nhat-tao-passkey) trong quá khứ cho trang web PayPal hợp pháp. Passkey này đã lưu trữ Relying Party ID paypal.com. 3. Bạn truy cập trang web PayPal giả mạo tại paybal.com (khi bạn truy cập trang web này, nguồn gốc yêu cầu của bạn là paybal.com\*) và trang web gửi cho thiết bị của bạn (bộ xác thực) một thử thách cho Relying Party ID `paypal.com` (ở đây nó cố lừa bạn) và yêu cầu bạn ký nó bằng passkey của bạn cho Relying Party ID paypal.com. 4. Thiết bị của bạn (bộ xác thực) kiểm tra xem nguồn gốc của yêu cầu (`paypal.com`) và Relying Party ID mà nó lưu trữ trong passkey (`paypal.com`) có khớp nhau hay không. 5. Vì chúng rõ ràng không khớp nhau, quá trình xác thực sẽ thất bại và nó cứu bạn khỏi việc cấp quyền truy cập vào tài khoản PayPal của bạn cho kẻ tấn công nào đó. Sơ đồ sau minh họa cơ chế phòng ngừa lừa đảo này. _Trong trường hợp của một ứng dụng gốc, việc xử lý nguồn gốc khác nhau tùy theo nền tảng: Trên Android, nguồn gốc được định dạng là `android:apk-key-hash:`. Trên iOS, nguồn gốc WebAuthn là web-origin của RP (ví dụ: `https://paypal.com`). Trong cả hai trường hợp, sự tin cậy giữa ứng dụng gốc của bạn và máy chủ được xác minh thông qua tệp liên kết (association file) tương ứng (xem [bên dưới](#configuring-relying-party-native-apps)). Để biết thông tin chi tiết về cách hoạt động xác minh nguồn gốc cho ứng dụng gốc, hãy xem hướng dẫn chuyên dụng của chúng tôi về xác minh nguồn gốc WebAuthn cho ứng dụng gốc._ ## 3. Hai Tùy chọn Tích hợp Khác nhau cho Ứng dụng Gốc Để triển khai passkey trong một ứng dụng gốc, nhà phát triển có thể quyết định giữa việc thêm chúng qua [WebView](https://www.corbado.com/blog/native-app-passkeys) hoặc theo cách gốc (native). Hãy cùng xem xét những lợi ích và hạn chế của cả hai cách tiếp cận sau đây. ### 3.1 Tích hợp Passkey qua WebView ![Tích hợp Passkey qua WebView (GitHub)](https://www.corbado.com/website-assets/650c601b1eb462e25702a870_android_webview_passkey_github_8bc81d9852.jpg) Sử dụng **WebView**\* để tích hợp passkey có nghĩa là nhúng một trình duyệt web vào trong ứng dụng gốc để xử lý quy trình xác thực. Cách tiếp cận này về cơ bản là hiển thị một trang web bên trong ứng dụng, giúp việc tái sử dụng các quy trình xác thực dựa trên web dễ dàng hơn mà không cần phải viết lại chúng cho nền tảng gốc. Tuy [nhi](https://www.corbado.com/blog/agentic-non-human-identity-eic-2026)ên, có một số nhược điểm. [WebView](https://www.corbado.com/blog/native-app-passkeys) có thể không hỗ trợ tất cả các tính năng của passkey, và có nguy cơ tiềm ẩn về các cuộc tấn công "man-in-the-middle" nếu không được triển khai an toàn. Ngoài ra, trải nghiệm người dùng có thể không mượt mà như tích hợp gốc và có thể có những thách thức trong việc duy trì hành vi nhất quán trên các thiết bị và phiên bản HĐH khác nhau. _\*Có nhiều loại WebView: Trên iOS (WKWebView, SFSafariViewController hoặc SFAuthenticationSession / ASWebAuthenticationSession cho các quy trình xác thực dựa trên OAuth/OpenID Connect) và Android (WebView, CCT-Chrome Custom Tabs). Xem bài đăng trên blog này để biết thêm chi tiết. Chúng tôi khuyên bạn nên sử dụng SFSafariViewController/ ASWebAuthenticationSession và Chrome Custom Tabs trong ngữ cảnh của passkey nếu bạn không muốn tích hợp gốc._ ### 3.2 Tích hợp Passkey Gốc ![Tích hợp Passkey Gốc (Kayak)](https://www.corbado.com/website-assets/650c625cac723f594137a029_android_native_passkey_kayak_0f689e761e.jpg) **Tích hợp gốc** liên quan đến việc xây dựng chức năng passkey trực tiếp vào ứng dụng [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) hoặc [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) sử dụng các API và thư viện dành riêng cho nền tảng. Phương pháp này mang lại trải nghiệm người dùng liền mạch hơn, vì không cần chuyển đổi giữa ứng dụng gốc và [WebView](https://www.corbado.com/blog/native-app-passkeys). Nó cũng cho phép hiệu suất tốt hơn và giao diện nhất quán hơn. Từ góc độ bảo mật, tích hợp gốc có thể cung cấp khả năng bảo vệ tăng cường chống lại một số loại hình tấn công nhất định, đặc biệt là khi kết hợp với các tính năng bảo mật của từng nền tảng. Tuy [nhi](https://www.corbado.com/blog/agentic-non-human-identity-eic-2026)ên, công sức triển khai có thể cao hơn, vì các nhà phát triển cần viết và bảo trì mã riêng cho mỗi nền tảng (Android và [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)). Hơn nữa, việc cập nhật các thông số kỹ thuật passkey / WebAuthn mới nhất có thể yêu cầu các bản cập nhật ứng dụng thường xuyên hơn. Trong phần sau, chúng tôi sẽ tập trung vào tích hợp passkey gốc. ## 4. Cấu hình Relying Party cho Ứng dụng Gốc Các ứng dụng gốc (ví dụ: ứng dụng [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) hoặc [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) đặt ra một thách thức so với các ứng dụng web. Không giống như các ứng dụng web, không có URL trình duyệt nào để khớp với Relying Party ID. Tuy nhiên, để đảm bảo cùng một mức độ bảo mật, các tên miền được kết nối với các ứng dụng gốc thông qua **các tệp liên kết (association files)**, để thiết lập sự tin cậy giữa một tên miền và một ứng dụng gốc. Điều này đặc biệt quan trọng nếu một [passkey được tạo](https://www.corbado.com/vi/faq/passkey-duoc-tao-ra-nhu-the-nao) trên một ứng dụng web và nên được sử dụng cho cùng một Relying Party ID trên một ứng dụng gốc (và ngược lại). ### 4.1 Các tệp liên kết trên iOS: apple-app-site-association iOS sử dụng tệp apple-app-site-association. Tệp này chứa nhiều quyền (entitlements) khác nhau, nhưng đối với WebAuthn và passkey, quyền webcredentials rất quan trọng. ```json { "webcredentials": { "apps": ["9RF9KY88B2.com.corbado.passkeys"] } } ``` Trong webcredentials.apps, bạn cần lưu trữ Tiền tố Định danh Ứng dụng (ví dụ: `9RF9KY77B2`) và Định danh Gói (Bundle Identifier) của bạn (ví dụ: `com.corbado.passkeys`). Để các ứng dụng gốc iOS hoạt động, tệp apple-app-site-association phải được lưu trữ trong thư mục `/.well-known` của Relying Party ID (`https:///.well-known/apple-app-site-association`). Xem ví dụ trực tiếp [tại đây](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/apple-app-site-association). ### 4.2 Các tệp liên kết trên Android: assetlinks.json [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) sử dụng tệp `assetlinks.json`, giống như đối tác iOS của nó, yêu cầu các cấu hình đặc biệt cho WebAuthn và passkey. ```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" ] } } ] ``` Bạn cần thiết lập các giá trị relation là `delegate_permission/common.handle_all_urls` và `delegate_permission/common.get_login_creds`. Bên cạnh đó, bạn cần thêm tên gói của mình và dấu vân tay SHA-256 của chứng chỉ ký của bạn. Để cho phép chia sẻ passkey giữa ứng dụng gốc và ứng dụng web, bạn cần thêm hai mục. Một cho namespace web và một cho namespace android_app. Xem ví dụ trực tiếp [tại đây](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/assetlinks.json). Để các ứng dụng Android hoạt động, tệp assetlinks.json phải được lưu trữ trong thư mục `/.well-known` của Relying Party ID `https:///.well- known/assetlinks.json` - gần giống như trên iOS). Hãy xem bài đăng blog này để thấy một triển khai mẫu chia sẻ passkey giữa một ứng dụng Android / iOS gốc và một ứng dụng web. ## 5. Thiết lập Sự Tin cậy giữa một Ứng dụng Gốc và Ứng dụng Web ### 5.1 iOS Quá trình thiết lập sự tin cậy giữa ứng dụng iOS và ứng dụng web diễn ra như sau: 1. Nhà phát triển ứng dụng iOS phải chỉ định danh sách các tên miền mà họ muốn liên kết với ứng dụng gốc. Các tên miền này được mã hóa cứng trong các quyền (entitlements) của ứng dụng iOS, ví dụ: - webcredentials:auth.Corbado.com - webcredentials:\*.Corbado.com 2. Mỗi khi ứng dụng iOS được cài đặt hoặc cập nhật, iOS sẽ tải xuống tệp apple-app-site-association cho từng mục trong danh sách quyền của ứng dụng iOS. 3. Khi thông tin xác thực (ví dụ: passkey) được tạo bên trong một ứng dụng iOS, ứng dụng iOS xác minh xem tên miền của máy chủ relying party có được liên kết với ứng dụng iOS hay không bằng cách kiểm tra hai khía cạnh sau: - Có tệp `apple-app-site-association` cho tên miền máy chủ relying party này tồn tại trên thiết bị không? - Ứng dụng iOS có được liệt kê trong tệp `apple-app-site-association` đó không? Nếu và chỉ nếu, cả hai câu hỏi đều có thể được trả lời là có, thì passkey có thể được tạo trong ứng dụng iOS. ### 5.2 Android Quá trình thiết lập sự tin cậy giữa ứng dụng Android và ứng dụng web diễn ra như sau: 1. Nhà phát triển ứng dụng Android phải chỉ định danh sách các tên miền mà họ muốn liên kết với ứng dụng Android. Các tên miền này được lưu trữ dưới dạng các mục tiêu (targets) với namespace web trong tệp assetlinks.json. Để khai báo rằng các ứng dụng Android và ứng dụng web chia sẻ thông tin xác thực, cần phải chỉ định `delegate_permission/common.get_login_creds`. Tìm chi tiết [tại đây](https://developer.android.com/training/sign-in/passkeys#add-support-dal). 2. Nếu [passkey được tạo](https://www.corbado.com/vi/faq/passkey-duoc-tao-ra-nhu-the-nao) bên trong ứng dụng Android, ứng dụng Android xác minh xem Relying Party ID có được liên kết với ứng dụng Android hay không bằng cách kiểm tra `assetlinks.json`: - Có tệp `assetlinks.json` nào cho Relying Party ID này tại `https://./well-known/assetlinks.json` không? - Ứng dụng Android có được xác định chính xác như một target không. 3. Nếu và chỉ nếu, cả hai câu hỏi đều có thể được trả lời là có, thì passkey có thể được tạo trong ứng dụng Android. Sơ đồ dưới đây so sánh song song các quy trình thiết lập sự tin cậy này. ## 6. Tổng quan về Cài đặt cho Android, iOS & Flutter Trong phần sau, chúng tôi cung cấp cái nhìn tổng quan chi tiết về các cài đặt khác nhau cần thiết để thiết lập đúng quy trình [xác thực passkey](https://www.corbado.com/vi/blog/nha-cung-cap-xac-thuc-passkey-giup-tiet-kiem-100000-usd) cho các ứng dụng gốc. | Tính năng | iOS | Android | | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Hướng dẫn triển khai chính thức cho xác thực passkey gốc | Apple Developer | Google Developer | | Cho phép chia sẻ passkey với các ứng dụng web | Có, thông qua tệp apple-app-site-association | Có, thông qua assetlinks.json | | Vị trí của tệp liên kết | [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) | | Tệp được lưu vào bộ nhớ cache (cached) | Có (kể từ iOS 14), quá trình đồng bộ hóa ban đầu có thể mất tới 24 giờ | Có (bởi Play Services) | | Có thể vượt qua (By-pass) | Có, với phần alternate mode | Không | | Có thể kiểm tra bằng | kiểm tra apple-app-site-association | kiểm tra assetlinks.json | | Định danh ứng dụng với mẫu | `.`, ví dụ: `T84QZS65DQ.com.facebook.Messenger` | Dấu vân tay SHA256, ví dụ: `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` | | Nơi tìm định danh ứng dụng | Team Application Identifier Prefix có thể được tìm thấy trong tài khoản nhà phát triển trên developer.apple.com và Bundle Identifier là tên chính xác từ bên trong dự án XCode | Khi đã tải lên: Google Play Console > Quản lý phát hành (Release management) > Chữ ký ứng dụng (App signing) Cục bộ: `keytool -list -v -keystore -alias -storepass -keypass ` | | Tên phần liên kết ứng dụng với web | applinks (không bắt buộc đối với passkey) | `delegate_permission/common.handle_all_urls` (bắt buộc đối với passkey) | | Tên phần cho phép chia sẻ thông tin xác thực giữa ứng dụng / web | webcredentials | `delegate_permission/common.get_login_creds` | | Đăng ký tất cả các tệp liên kết | Bật và thêm miền được liên kết trong môi trường phát triển XCode (cài đặt thuộc tính để tạo tệp entitlements) | Khi sử dụng Credential Manager API, việc đăng ký assetlinks.json trong manifest không bắt buộc đối với passkey (tuy nhiên lại bắt buộc đối với mật khẩu). Khi không sử dụng Credential Manager API, bạn cần liệt kê các tên máy chủ bằng mục `` trong AndroidManifest.xml ở hoạt động cụ thể (một phần của Mã nguồn Ứng dụng Android). Phần `` cần phải là autoVerify=true. | Đối với [Flutter](https://www.corbado.com/blog/flutter-passkeys-package), quy tắc tương ứng của Android hoặc iOS sẽ được áp dụng. Cài đặt dành riêng cho [Flutter](https://www.corbado.com/blog/flutter-passkeys-package) duy nhất là đăng ký các tệp liên kết, nơi bạn nên thêm: - Đối với Android:[ flutter_deeplinking_enabled vào AndroidManifest.xml](https://docs.flutter.dev/cookbook/navigation/set-up-app-links) - Đối với iOS: [FlutterDeepLinkingEnabled true vào Info.plist](https://docs.flutter.dev/cookbook/navigation/set-up-universal-links) ## 7. Các Ví dụ về Relying Party ID & Tệp Liên kết Hợp lệ & Không Hợp lệ Vì bản thân chúng tôi đã trải nghiệm, việc làm việc với Relying Party IDs, các cấp độ khác nhau của (sub-)domains và CNAMEs có thể là một nhiệm vụ khá thách thức, chúng tôi trình bày bốn ví dụ riêng biệt và giải thích lý do cũng như cách chúng hoạt động. Lưu ý rằng, hàng bảng CNAME không bắt buộc đối với [xác thực passkey](https://www.corbado.com/vi/blog/nha-cung-cap-xac-thuc-passkey-giup-tiet-kiem-100000-usd) và chỉ là kết quả nghiên cứu mà chúng tôi muốn thêm vào. ### 7.1 Ví dụ 1: Relying Party là Tên miền Gốc | **Relying Party ID** | corbado.com | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Quyền - Entitlements (chỉ trên iOS)** | webcredentials:corbado.com | | **Vị trí tệp apple-app-site-association** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **Vị trí tệp assetlinks.json** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | không có | Trong ví dụ này, tệp `apple-app-site-association` / `assetlinks.json` cho Corbado.com có thể được tải xuống mà không gặp bất kỳ vấn đề gì khi ứng dụng gốc được cài đặt / cập nhật, vì tệp nằm ở cùng vị trí với Relying Party ID. **Một passkey cho Relying Party ID có thể được tạo.** ### 7.2 Ví dụ 2: Relying Party là Miền phụ và CNAME được đặt | Relying Party ID | auth.corbado.com | | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Quyền - Entitlements (chỉ trên iOS)** | webcredentials:auth.corbado.com | | **Vị trí tệp 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) | | **Vị trí tệp 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 | Trong ví dụ này, tệp `apple-app-site-association` / `assetlinks.json` cho auth.corbado.com có thể được tải xuống mà không gặp bất kỳ sự cố nào khi ứng dụng gốc được cài đặt / cập nhật, vì tệp nằm trên vị trí tương ứng với Relying Party ID, do CNAME trỏ từ Relying Party ID đến vị trí được lưu trữ. **Một passkey cho Relying Party ID có thể được tạo.** ### 7.3 Ví dụ 3: Relying Party là Tên miền Gốc và CNAME được đặt | Relying Party ID | corbado.com | | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Quyền - Entitlements (chỉ trên iOS)** | webcredentials:corbado.com; webcredentials:auth.corbado.com | | **Vị trí tệp 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) | | **Vị trí tệp 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 | Trong ví dụ này, tệp `apple-app-site-association` / `assetlinks.json` cho auth.corbado.com có thể được tải xuống mà không gặp sự cố khi ứng dụng gốc được cài đặt / cập nhật, vì tệp ở đó, do CNAME, tại vị trí nơi mà `auth.corbado.com` mong đợi nó. NHƯNG: Tệp `apple-site-association-file` / `assetlinks.json` cho corbado.com không thể được tải xuống, khi ứng dụng gốc được cài đặt / cập nhật, vì tệp không nằm ở `https://corbado.com/.well-known/apple-app-site-association` / `https://corbado.com/.well-known/assetlinks.json`, nơi nó được mong đợi và không có CNAME nào trỏ đến đó. **Một passkey cho Relying Party ID KHÔNG thể được tạo.** ### 7.4 Ví dụ 4: Relying Party là một Miền phụ & Quyền dạng Wildcard được đặt | Relying Party ID | auth.corbado.com | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Quyền - Entitlements (chỉ trên iOS)** | webcredentials:\*.corbado.com | | **Vị trí tệp apple-app-site-association** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **Vị trí tệp assetlinks.json** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | không có | Trong ví dụ này, tệp `apple-app-site-association` cho corbado.com có thể được tải xuống mà không gặp vấn đề gì khi ứng dụng gốc được cài đặt / cập nhật, vì tệp nằm ở nơi mà nó được mong đợi và quyền webcredentials (`*.corbado.com`) khớp với Relying Party ID (`auth.corbado.com`). Lưu ý rằng ví dụ này không hoạt động đối với Android, vì Android không hoạt động với những thứ như quyền wildcard. Nói chung, cách định nghĩa Relying Party IDs này không được khuyến khích. **Một passkey cho Relying Party ID có thể được tạo.** ## 8. Những Lỗi Thường gặp về Relying Party ID & Cách Phòng tránh Chúng ### 8.1 Thay đổi Relying Party ID từ Miền phụ sang Tên miền Gốc **Lỗi:** Bạn bắt đầu phát triển và định nghĩa một miền phụ (ví dụ: `login.acme.com`) là Relying Party ID của bạn. Những người dùng đầu tiên đã [tạo một passkey](https://www.corbado.com/vi/blog/thuc-hanh-tot-nhat-tao-passkey) cho Relying Party ID này. Sau đó, bạn nhận thấy rằng bạn cũng cần các passkey này để xác thực trên một miền phụ khác (ví dụ: `app.acme.com`). Vì nguồn gốc của người dùng và Relying Party ID cho miền phụ mới không khớp nhau, người dùng không thể đăng nhập bằng passkey. Việc thay đổi Relying Party ID trong cài đặt WebAuthn của bạn thành `acme.com` sẽ làm mất hiệu lực tất cả các passkey hiện có, vì nguồn gốc mới và Relying Party ID được lưu trữ trong các passkey hiện tại không khớp nhau. **Giải pháp:** Hãy kiểm tra kỹ lưỡng ngay từ ban đầu khi định nghĩa Relying Party ID của bạn vì điều này phần nhiều là quyết định cuối cùng. Nếu bạn không chắc chắn và muốn sẵn sàng cho tương lai, nghĩa là các miền phụ khác trong tương lai có thể cần passkey để xác thực, chúng tôi khuyên bạn nên sử dụng tên miền gốc (ví dụ: acme.com) làm Relying Party ID trừ khi nó nằm trên [Public Suffix List](https://publicsuffix.org/learn/). ### 8.2 Relying Party ID Khác nhau cho Ứng dụng Gốc và Ứng dụng Web **Lỗi:** Bạn đang phát triển đồng thời một ứng dụng gốc và một ứng dụng web. Để đẩy nhanh tiến độ, bạn sử dụng hai máy chủ WebAuthn khác nhau (với Relying Party ID khác nhau cho ứng dụng gốc và web). Khi người dùng của bạn tạo những passkey đầu tiên, Relying Party ID tương ứng sẽ được lưu trữ trong passkey. Việc cho phép đăng nhập chéo thiết bị / chéo nền tảng bằng cùng một passkey, ví dụ như với một passkey được tạo trong ứng dụng web và cố gắng đăng nhập trong ứng dụng gốc, sẽ không còn khả thi nữa. Việc hợp nhất hai máy chủ WebAuthn sẽ hủy bỏ các passkey đã được đăng ký với máy chủ WebAuthn cũ (Relying Party ID cũ) và người dùng của bạn không thể đăng nhập bằng các passkey này. **Giải pháp:** Nếu bạn có nhiều ứng dụng (ví dụ: một ứng dụng web và một ứng dụng gốc), hãy luôn chỉ có một máy chủ WebAuthn duy nhất và chỉ định nghĩa một Relying Party ID cho tất cả các ứng dụng của bạn. Việc liên kết giữa các ứng dụng này có thể được thực hiện thông qua các bước được mô tả ở trên. ### 8.3 Các Tệp Liên kết Không Hợp lệ và Không thể Truy cập **Lỗi:** Bạn bắt đầu phát triển ứng dụng của mình, đã định cấu hình các tệp liên kết và triển khai chúng lên máy chủ của bạn. Vì một lý do nào đó, bạn vẫn nhận được thông báo lỗi và không tìm ra nguyên nhân gốc rễ. **Giải pháp:** Một nguyên nhân tiềm ẩn gây ra thông báo lỗi có thể là một tệp liên kết bị sai định dạng hoặc không thể truy cập được. Trước khi triển khai bất kỳ tệp liên kết nào lên máy chủ, chúng tôi thực sự khuyên bạn nên kiểm tra tính hợp lệ và khả năng truy cập (thường các tệp này có thể nằm sau [một VPN mạnh mẽ](https://cybernews.com/best-vpn/most-secure-vpns/) hoặc tường lửa ngăn chặn quyền truy cập thích hợp cho các crawler của Apple và Google) của một tệp liên kết thông qua các công cụ được cung cấp cho [iOS ](https://branch.io/resources/aasa-validator/)và Android. ### 8.4 Tệp apple-app-site-association Chưa Được Cache Bởi Apple CDN **Lỗi:** Bạn đã triển khai tệp apple-app-site-association của mình lên máy chủ và muốn bắt đầu ngay việc [tạo passkey](https://www.corbado.com/vi/blog/thuc-hanh-tot-nhat-tao-passkey) trên thiết bị thử nghiệm của mình. Tuy nhiên, vì một lý do nào đó, bạn không thể [tạo passkey](https://www.corbado.com/vi/blog/thuc-hanh-tot-nhat-tao-passkey) và nhận được thông báo lỗi. **Giải pháp:** Lý do đằng sau các thông báo lỗi này là do các thiết bị iOS tải xuống tệp `apple- app-site-association` để xác thực Relying Party. Để làm điều này, các thiết bị iOS không gửi yêu cầu trực tiếp đến máy chủ của bạn mà sử dụng CDN thay thế. Cả thiết bị và CDN đều lưu trữ tệp `apple-app-site- association` vào bộ nhớ đệm (cache) sau khi nó được truy xuất thành công. Do chức năng bộ nhớ đệm này, các thay đổi mới trong tệp `apple-app-site-association` của bạn không được phản ánh trực tiếp trong ứng dụng của bạn. Có thể mất tới 24 giờ cho đến khi CDN lưu tệp `apple-app-site-association` vào bộ nhớ đệm. Để vượt qua hạn chế này trong quá trình phát triển, bạn có thể nối thêm `?mode=developer` vào Relying Party ID và vô hiệu hóa bộ nhớ đệm hoàn toàn (ví dụ: Relying Party ID sẽ là `acme.com?mode=developer`). ### 8.5 Trình giả lập Android và Tính không Tương thích của Phiên bản API **Lỗi:** Bạn bắt đầu phát triển một ứng dụng Android và muốn kiểm tra nó trên một trình giả lập Android. Vì một lý do nào đó, bạn nhận được các thông báo lỗi, mặc dù bạn đã thiết lập đúng trình giả lập Android và các ứng dụng khác dường như hoạt động trơn tru trên đó. **Giải pháp:** Các phiên bản Android, sự hỗ trợ của Play Store và các phiên bản API đóng vai trò chính khi thử nghiệm một ứng dụng passkey. Bên cạnh đó, bạn cần phải đăng nhập vào một tài khoản Google. Vui lòng tham khảo phần khắc phục sự cố của chúng tôi để biết chi tiết. ## 9. Khuyến nghị ### 9.1 Khuyến nghị Chung Khuyến nghị tổng thể của chúng tôi là chọn Relying Party ID một cách cẩn thận dựa trên bối cảnh ứng dụng và yêu cầu của bạn. Dưới đây, chúng tôi đã tổng hợp các trường hợp sử dụng phổ biến nhất, nhưng khuyến nghị chung của chúng tôi là bạn nên **hướng tới việc chọn tên miền gốc của mình làm Relying Party ID** và định cấu hình quá trình xác thực của bạn theo cách này. Với Corbado, chúng tôi cũng đã cấu hình sẵn theo cách này cho bạn (vì đây là một phần trong phương pháp của chúng tôi nhằm cung cấp tính năng [xác thực passkey](https://www.corbado.com/vi/blog/nha-cung-cap-xac-thuc-passkey-giup-tiet-kiem-100000-usd) liền mạch cho tất cả các thiết lập kỹ thuật. Các thành phần UI và SDK của chúng tôi được chuẩn bị để sử dụng cùng với tên miền gốc của bạn làm Relying Party ID). | Trường hợp | Khuyến nghị | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **A) Bạn có một tên miền gốc:**

Ví dụ: acme.com

Tất cả các ứng dụng và quy trình xác thực đều chạy trên tên miền gốc này hoặc các miền phụ của nó. | ✔️ Chọn tên miền gốc làm Relying Party ID của bạn vì điều này sẽ không gây ra bất kỳ vấn đề nào cho ứng dụng web hoặc ứng dụng gốc. | | **B) Bạn có nhiều tên miền gốc:**

Ví dụ: kayak.com, kayak.co.uk, kayak.de

Bạn phục vụ người dùng của mình từ các tên miền cấp cao nhất quốc tế khác nhau. Kayak.com cho Hoa Kỳ và kayak.co.uk cho Vương quốc Anh hoặc bạn có các tên miền gốc hoàn toàn khác nhau nhưng vẫn muốn cho phép cùng những người dùng đó đăng nhập bằng cùng các passkey. | ⚠️ Trên ứng dụng web của bạn, việc chia sẻ passkey yêu cầu cấu hình Related Origin Requests thông qua `.well-known/webauthn` để cho phép các nguồn gốc được chỉ định sử dụng một RP ID chung (sự hỗ trợ của trình duyệt thay đổi; hãy xác minh tính tương thích). Hoặc chọn một tên miền gốc chung cho xác thực.

✔️ Bạn có thể kết nối các ứng dụng gốc của mình với bất kỳ số lượng tên miền gốc nào miễn là bạn có quyền kiểm soát đối với các tệp liên kết ở mức độ gốc.

❌ Trong trường hợp sau này bạn muốn chuyển sang một tên miền gốc khác để lưu trữ trang web của mình, bạn sẽ không thể sử dụng các passkey đã được tạo của mình, vì bạn sẽ phải đổi thương hiệu và thay đổi tên miền (Relying Party ID). | | **C) Bạn CHƯA có tên miền gốc, bạn chỉ đang chạy trên backend hoặc trên một miền phụ công cộng. Có một số trường hợp mà điều này có thể xảy ra:**

1. Bạn làm việc trên một miền phụ có sẵn miễn phí, nơi tên miền gốc không nằm dưới sự kiểm soát của bạn (tên miền gốc được liệt kê trong [https://publicsuffix.org/](https://publicsuffix.org/)) ví dụ như các URL CDN.

2. Bạn làm việc trên một ứng dụng gốc. | ❌ Trên các miền phụ công cộng, bạn không thể kiểm soát các tệp liên kết ở cấp độ gốc của tên miền gốc. Do đó, passkey sẽ không hoạt động một cách native (bản địa).

⚠️ Cách duy nhất để sửa lỗi này đối với một số dịch vụ là chuyển sang gói trả phí, nơi bạn có thể định nghĩa một CNAME hoặc tự lấy một tên miền gốc tùy chỉnh. | ### 9.2 Khuyến nghị Khi Sử dụng Corbado Trong phần sau, chúng tôi cung cấp một cây quyết định rất cụ thể giúp bạn xác định đúng Relying Party ID và cách bạn nên xử lý / lưu trữ các tệp liên kết khi sử dụng Corbado làm giải pháp passkey cho mình. Quyết định đầu tiên là liệu bạn đang ở trong môi trường phát triển hay sản xuất. Mức độ quyết định tiếp theo mà bạn phải đưa ra dựa trên bối cảnh ứng dụng của bạn: bạn chỉ có ứng dụng gốc hay có cả ứng dụng gốc và ứng dụng web. #### A) Phát triển Đối với môi trường phát triển, chúng tôi cho rằng bạn muốn bắt đầu phát triển và thử nghiệm nhanh chóng. Relying Party ID có thể được thay đổi sau nếu bạn muốn đưa vào hoạt động chính thức (go live). ##### A1) Chỉ Ứng dụng Gốc (Native-Only) - Đặt Relying Party ID = `pro-XXX.frontendapi.cloud.corbado.io` (giá trị mặc định) - Corbado lưu trữ tệp liên kết giúp bạn - Không có tác vụ DNS nào dành cho bạn ##### A2) Ứng dụng Gốc & Ứng dụng Web Thường thì không dễ dàng để kiểm tra cả ứng dụng web và ứng dụng gốc cùng một lúc. **Tùy chọn 1:** Bạn đặt Relying Party ID = `pro-XXX.frontendapi.cloud.corbado.io` (ứng dụng gốc hoạt động) HOẶC đặt Relying Party ID = `localhost` (ứng dụng web hoạt động). **Tùy chọn 2:** Giải pháp duy nhất để ứng dụng gốc và web hoạt động cùng lúc là sử dụng một proxy ngược cục bộ (đây là một giải pháp khá thủ thuật): - Đặt Relying Party ID = `acme-dev.com` - Đặt CNAME từ `acme-dev.com` => `pro-XXX.frontendapi.cloud.corbado.io` - Thêm mục cấu hình `/etc/hosts` cục bộ: `localhost acme-dev.com` - Thêm reverse proxy (nginx) với quy tắc cho `acme-dev.com` => `localhost:3000` (như một ví dụ) #### B) Sản xuất Trong môi trường sản xuất, bạn phải quyết định xem liệu bạn hài lòng với một miền phụ làm Relying Party ID (ví dụ: `auth.acme.com`) hay bạn muốn một tên miền gốc làm Relying Party ID (ví dụ: `acme.com`). ##### B1) Miền phụ làm Relying Party ID ###### B1.1) Chỉ Ứng dụng Gốc (Native-Only) - Đặt Relying Party ID = `auth.acme.com` - Corbado lưu trữ tệp liên kết giúp bạn - Đặt CNAME từ `auth.acme.com` => `pro-XXX.frontendapi.cloud.corbado.io` ###### B1.2) Ứng dụng Gốc & Ứng dụng Web - Đặt Relying Party ID = `auth.acme.com` - Corbado lưu trữ tệp liên kết giúp bạn - Đặt CNAME từ `auth.acme.com` => `pro-XXX.frontendapi.cloud.corbado.io` (cũng cần thiết để cookie hoạt động nếu bạn sử dụng tính năng quản lý phiên của Corbado) ##### B2) Tên miền Gốc làm Relying Party ID ###### B2.1) Chỉ Ứng dụng Gốc (Native-Only) - Đặt Relying Party ID = `acme.com` - Tự lưu trữ tệp liên kết trên máy chủ riêng của bạn tại `acme.com/.well-known/` - Không có tác vụ DNS nào dành cho bạn ###### B2.2) Ứng dụng Gốc & Ứng dụng Web - Đặt Relying Party ID = `acme.com` - Tự lưu trữ tệp liên kết trên máy chủ riêng của bạn tại `acme.com/.well-known/` - Nếu bạn sử dụng tính năng quản lý phiên của Corbado, bạn cần đặt CNAME từ `auth.acme.com` => `pro-XXX.frontendapi.cloud.corbado.io` để làm cho cookie hoạt động (CNAME này không cần thiết cho Relying Party ID mà chỉ dành cho việc quản lý phiên) Cây quyết định sau đây tóm tắt tất cả các đường dẫn cấu hình. ## 10. Kết luận Relying Party ID là nền tảng của WebAuthn và xác thực dựa trên passkey, đồng thời cung cấp khả năng chống lừa đảo mạnh mẽ. Việc định cấu hình đúng đắn, hiểu được những sự phức tạp trong việc khớp tên miền, và đảm bảo triển khai chính xác cho các ứng dụng gốc là rất quan trọng. Bài đăng blog này đã cho bạn thấy cách thiết lập chúng đúng cách và cách xử lý các lỗi khác nhau. Một khi cấu hình rpID của bạn đã vững chắc, hãy tập trung vào việc tối ưu hóa các quy trình [tạo passkey](https://www.corbado.com/vi/blog/thuc-hanh-tot-nhat-tao-passkey) và quy trình đăng [nhập passkey](https://www.corbado.com/vi/blog/giao-thuc-trao-doi-thong-tin-xac-thuc-cxp-dinh-dang-cxf) để thúc đẩy sự đón nhận thực tế. Để hiểu rõ hơn về cách thiết lập passkey cho ứng dụng gốc, chúng tôi khuyên bạn nên đọc về passkey trong [Flutter](https://www.corbado.com/blog/flutter-passkeys-package). Nếu bạn có thêm câu hỏi hoặc cần hỗ trợ, đừng ngần ngại [liên hệ](https://bit.ly/passkeys-community). ## Câu hỏi Thường gặp (FAQ) ### Relying Party ID ngăn chặn lừa đảo trong xác thực passkey như thế nào? Bộ xác thực so sánh nguồn gốc thực tế của trình duyệt với Relying Party ID được lưu trữ trong passkey. Nếu kẻ tấn công lưu trữ một trang web giả mạo tại một tên miền khác, sự không khớp nguồn gốc sẽ tự động khiến quá trình xác thực thất bại, ngay cả khi thử thách bị làm giả tuyên bố đó là RP ID hợp pháp. Sự liên kết này có nghĩa là một passkey được đăng ký tại paypal.com không thể được sử dụng trên một tên miền có bề ngoài giống hệt như paybal.com. ### Điều gì xảy ra nếu tôi thay đổi WebAuthn Relying Party ID sau khi người dùng đã đăng ký passkey? Thay đổi RP ID làm vô hiệu hóa tất cả các passkey hiện có vì RP ID được lưu trữ trong mỗi thông tin xác thực sẽ không còn khớp với giá trị mới. Các ngoại lệ duy nhất là khi RP ID mới là một miền phụ của RP ID cũ hoặc khi Related Origin Requests được định cấu hình qua `.well-known/webauthn`. Hãy chọn tên miền gốc làm RP ID ngay từ đầu để tránh vấn đề không thể đảo ngược này. ### Tại sao passkey iOS của tôi không hoạt động ngay sau khi tôi triển khai tệp apple-app-site-association? iOS không tải tệp apple-app-site-association trực tiếp từ máy chủ của bạn. Hệ điều hành này sử dụng CDN của Apple, CDN này có thể mất tới 24 giờ để đưa một tệp mới triển khai hoặc vừa cập nhật vào bộ nhớ đệm. Trong quá trình phát triển, hãy thêm `?mode=developer` vào Relying Party ID để hoàn toàn bỏ qua quá trình lưu vào bộ nhớ đệm. ### Tôi nên sử dụng miền phụ hay tên miền gốc làm Relying Party ID của mình cho các passkey? Bạn nên sử dụng tên miền gốc (ví dụ: acme.com) vì passkey được tạo trên bất kỳ miền phụ nào cũng có thể xác thực trên tất cả các miền phụ của tên miền gốc đó. Một RP ID thuộc miền phụ sẽ hạn chế việc sử dụng passkey trong miền phụ đó và các miền phụ con của nó, điều này sau này có thể làm hỏng các quy trình xác thực chéo miền phụ. Nếu bạn có nhiều tên miền gốc, ví dụ như acme.com và acme.co.uk, hãy cấu hình Related Origin Requests qua `.well-known/webauthn` để cho phép tái sử dụng passkey trên chúng.