WebAuthn Relying Party ID (rpID) & Passkeys: Tên miền & Ứng dụng gốc

Xác thực 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, GitHub, WhatsApp, X (Twitter), LinkedIn 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 đơ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 bằng Face ID, Touch ID hoặc Windows Hello, passkey mang lại khả năng bảo mật 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.

Cheatsheet Passkeys. Hướng dẫn thực tế, mẫu triển khai và KPI cho chương trình passkeys.

Nhận cheat sheet

Thử passkeys trong demo trực tiếp.

Thử passkeys

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 (một nhà cung cấp xác thực!) hoặc Retool cũng từng là nạn nhân của các cuộc tấn công spear-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 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.

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. 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 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 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 này hoạt động và cụ thể là cách các ứng dụng gốc được bảo mật.

Relying Party ID 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). Đâ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. 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 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). 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ó:

Trong phần sau, bạn sẽ thấy PublicKeyCredentialCreationOptions đã được phân tích cú pháp:

{
    "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, là một trang web giả mạo cố gắng đánh cắp thông tin đăng nhập PayPal 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 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 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:<SHA256_fingerprint>. 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). Để 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.

Tham gia Passkeys Community để nhận cập nhật và hỗ trợ.

Tham gia

Để 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 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.

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ên, có một số nhược điểm. WebView 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.

Xem có bao nhiêu người thực sự dùng passkeys.

Xem dữ liệu adoption

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 hoặc 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. 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ê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). 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.

Xem có bao nhiêu người thực sự dùng passkeys.

Xem dữ liệu adoption

Các ứng dụng gốc (ví dụ: ứng dụng iOS hoặc 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 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).

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.

{
    "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://<Relying Party ID>/.well-known/apple-app-site-association).

Xem ví dụ trực tiếp tại đây.

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.

[
    {
        "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.

Để 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://<Relying Party ID>/.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.

Thử nghiệm các luồng passkey trong Passkeys Debugger.

Thử miễn phí

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.

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

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.

2. Nếu passkey được tạo 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://<Relying Party ID>./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.

Đăng ký Passkeys Substack để nhận tin mới nhất.

Đăng ký

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 cho các ứng dụng gốc.

Đối với Flutter, 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 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
• Đối với iOS: FlutterDeepLinkingEnabled true vào Info.plist

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 và chỉ là kết quả nghiên cứu mà chúng tôi muốn thêm vào.

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.

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.

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.

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.

Tham gia Passkeys Community để nhận cập nhật và hỗ trợ.

Tham gia

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 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.

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.

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ẽ 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 và Android.

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 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 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).

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.

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 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).

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.

Đố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).

• Đặ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

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ụ)

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).

• Đặ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

• Đặ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)

• Đặ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/<association file>
• Không có tác vụ DNS nào dành cho bạn

• Đặ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/<association file>
• 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.

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 và quy trình đăng nhập passkey để 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.

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ệ.

Về Corbado

Corbado là Passkey Intelligence Platform dành cho các đội CIAM vận hành xác thực consumer ở quy mô lớn. Chúng tôi giúp bạn nhìn thấy điều mà log IDP và các công cụ analytics thông thường không thấy: những thiết bị, phiên bản OS, trình duyệt và trình quản lý credential nào hỗ trợ passkey, tại sao quá trình đăng ký không chuyển thành đăng nhập, luồng WebAuthn fail ở đâu, và khi nào một bản cập nhật OS hay trình duyệt làm hỏng đăng nhập một cách âm thầm — tất cả mà không cần thay thế Okta, Auth0, Ping, Cognito hay IDP nội bộ của bạn. Hai sản phẩm: Corbado Observe bổ sung observability cho passkey và mọi phương thức đăng nhập khác. Corbado Connect mang đến managed passkey với analytics tích hợp (song hành cùng IDP của bạn). VicRoads vận hành passkey cho hơn 5M người dùng với Corbado (kích hoạt passkey +80%). Trao đổi với chuyên gia Passkey →

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.

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.

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.

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.