Passkey cho ứng dụng gốc: So sánh triển khai Native và WebView

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

Get free Whitepaper

Lưu ý: System WebView và Embedded WebView thường được kết hợp, trong đó System WebView xử lý việc đăng nhập (với chia sẻ thông tin xác thực tự động), sau đó Embedded WebView hiển thị phần quản lý passkey trong cài đặt.

Các yếu tố quyết định chính:

• Đăng nhập dựa trên OAuth? → System WebView (ASWebAuthenticationSession, Chrome Custom Tabs)
• Muốn tái sử dụng xác thực web trong một vỏ ứng dụng gốc? → Embedded WebView (WKWebView, WebView trên Android với WebKit 1.12.1+)
• Xây dựng ứng dụng ưu tiên native (native-first)? → Triển khai Native (Apple AuthenticationServices, Google Credential Manager)

Các nền tảng di động hiện đại cung cấp ba phương pháp riêng biệt để tích hợp passkey vào ứng dụng gốc của bạn, mỗi phương pháp có những đánh đổi khác nhau về trải nghiệm người dùng, độ phức tạp kỹ thuật và khả năng tương thích với OAuth:

1. Triển khai Native: Xây dựng các luồng passkey trực tiếp vào ứng dụng của bạn bằng cách sử dụng API của nền tảng (iOS AuthenticationServices, Android Credential Manager). Cung cấp trải nghiệm người dùng tốt nhất với xác thực sinh trắc học liền mạch, nhưng đòi hỏi nỗ lực triển khai kỹ thuật từ trung bình đến cao.

2. System WebView: Sử dụng thành phần trình duyệt của nền tảng (iOS ASWebAuthenticationSession / SFSafariViewController, Android Chrome Custom Tabs) để xử lý xác thực. Rất phù hợp cho các luồng đăng nhập dựa trên OAuth và chia sẻ thông tin xác thực với trình duyệt hệ thống.

3. Embedded WebView: Nhúng một web view có thể tùy chỉnh (iOS WKWebView, Android WebView) vào ứng dụng của bạn để tái sử dụng xác thực web với một bộ khung ứng dụng gốc. Cung cấp giao diện giống native mà không có thanh URL và toàn quyền kiểm soát giao diện người dùng của web view. Yêu cầu thiết lập bổ sung bao gồm quyền và entitlements (iOS), và cấu hình WebView với AndroidX WebKit 1.12.1+ (Android) để kích hoạt chức năng passkey.

Lựa chọn đúng đắn phụ thuộc vào kiến trúc xác thực của ứng dụng, liệu bạn có sử dụng các nhà cung cấp OAuth hay không, mức độ kiểm soát bạn cần đối với giao diện người dùng và liệu bạn đang xây dựng một ứng dụng ưu tiên native hay tái sử dụng các thành phần web.

Một triển khai passkey native mang lại trải nghiệm người dùng tối ưu, với các luồng xác thực được xây dựng trực tiếp vào giao diện người dùng của ứng dụng bằng cách sử dụng các API dành riêng cho nền tảng. Người dùng được hưởng lợi từ các hộp thoại native của nền tảng, xác minh sinh trắc học liền mạch và thời gian đăng nhập nhanh nhất có thể.

Khi nào nên chọn Triển khai Native:

• Xây dựng một ứng dụng gốc mới hoặc tái cấu trúc xác thực sang các màn hình native
• Muốn có trải nghiệm người dùng tốt nhất có thể với xác thực tức thì, âm thầm
• Lời nhắc passkey tự động khi khởi động ứng dụng: Các triển khai native có thể sử dụng preferImmediatelyAvailableCredentials để tự động hiển thị lớp phủ passkey khi có passkey, cung cấp trải nghiệm đăng nhập nhanh nhất mà không cần nhập định danh
• Cần kiểm soát hoàn toàn giao diện người dùng và luồng xác thực
• Sẵn sàng đầu tư vào việc triển khai cho từng nền tảng cụ thể (iOS Swift, Android Kotlin)

Lợi thế chính: preferImmediatelyAvailableCredentials()

Các triển khai native có thể tận dụng preferImmediatelyAvailableCredentials() để tạo ra một lớp phủ passkey tự động xuất hiện ngay khi ứng dụng khởi động khi có passkey. Luồng không cần tên người dùng này cung cấp trải nghiệm đăng nhập nhanh nhất có thể—người dùng thấy passkey của họ ngay lập tức mà không cần nhập định danh trước. Khả năng này chỉ có ở các triển khai native và không có sẵn trong các biến thể WebView.

Mặc dù các triển khai WebView có thể sử dụng Conditional UI (gợi ý passkey trong các trường nhập liệu), lớp phủ tự động của native cung cấp UX vượt trội với tỷ lệ sử dụng passkey cao hơn vì xác thực bắt đầu ngay khi ứng dụng khởi chạy.

Tổng quan về Yêu cầu Kỹ thuật:

Việc tích hợp passkey native đòi hỏi sự tin cậy mật mã giữa ứng dụng và miền web của bạn. Nếu không, hệ điều hành sẽ từ chối tất cả các hoạt động WebAuthn. Các yêu cầu chính:

1. Tệp liên kết App-Domain được lưu trữ tại /.well-known/
2. Relying Party ID chính xác khớp với miền web của bạn
3. Các khả năng dành riêng cho nền tảng (chi tiết trong Phần 4)

Lợi ích lớn nhất: passkey được tạo trên trang web của bạn sẽ hoạt động liền mạch trong ứng dụng của bạn và ngược lại.

Việc triển khai passkey một cách native trên iOS liên quan đến framework AuthenticationServices của Apple, cung cấp một API cho các hoạt động WebAuthn:

Các thành phần chính:

• ASAuthorizationController: Quản lý luồng xác thực
• ASAuthorizationPlatformPublicKeyCredentialProvider: Tạo yêu cầu passkey
• Ba chế độ giao diện người dùng riêng biệt để xử lý đăng nhập bằng passkey:
  • Đăng nhập bằng ô văn bản: Trường tên người dùng truyền thống với việc đăng nhập bằng passkey bắt đầu khi nhấn nút
  • Lớp phủ modal passkey: Hộp thoại của hệ điều hành liệt kê các passkey có sẵn
  • Conditional UI: Gợi ý passkey trong thanh QuickType phía trên bàn phím

Mẹo phát triển

• AASA Caching: Apple lưu bộ nhớ đệm tệp AASA rất chặt chẽ (lên đến 24 giờ), điều này có thể gây khó khăn cho việc kiểm thử. Giải pháp: Bật Chế độ nhà phát triển trên thiết bị thử nghiệm của bạn và thêm ?mode=developer vào URL AASA của bạn để buộc làm mới
• Kiểm thử hiệu năng: Kiểm thử với các tài khoản iCloud chứa hàng trăm thông tin xác thực để quan sát độ trễ trong thế giới thực. Lớp phủ hệ thống có thể hiển thị một chút chậm trễ với nhiều passkey được lưu trữ

Việc triển khai passkey native của Android sử dụng API Credential Manager (hoặc API FIDO2 cũ hơn để tương thích ngược):

Các thành phần chính:

• CredentialManager: API trung tâm cho tất cả các hoạt động về thông tin xác thực
• CreatePublicKeyCredentialRequest: Dành cho việc đăng ký passkey
• GetCredentialRequest: Dành cho việc xác thực bằng passkey
• Hai chế độ giao diện người dùng chính:
  • Đăng nhập bằng ô văn bản: Trường tên người dùng truyền thống với việc đăng nhập bằng passkey bắt đầu khi nhấn nút
  • Lớp phủ modal passkey: Hộp thoại của hệ điều hành liệt kê các passkey có sẵn

Lưu ý: Android hiện thiếu các gợi ý bàn phím Conditional UI của iOS trong các ứng dụng native (mặc dù Conditional UI hoạt động trong các ứng dụng web)

Việc triển khai passkey một cách native có những thách thức và bài học quan trọng: Việc tích hợp ở cấp độ hệ điều hành có thể làm phát sinh các vấn đề trên các thiết bị và phiên bản hệ điều hành khác nhau.

1. Ví dụ, nhóm của chúng tôi đã gặp phải các vấn đề như việc Apple lưu bộ nhớ đệm quá chặt chẽ tệp apple-app-site-association (được sử dụng để liên kết thông tin xác thực ứng dụng/web) và sự khác biệt nhỏ về giao diện người dùng trong một số lời nhắc sinh trắc học của các nhà sản xuất thiết bị Android (OEM).
2. Hơn nữa, hãy xem xét rằng trong một số tình huống doanh nghiệp, các thiết bị được quản lý có thể đã bị tắt tính năng đồng bộ hóa passkey theo chính sách. Trong môi trường doanh nghiệp nơi đồng bộ hóa iCloud Keychain hoặc Google Password Manager bị tắt, passkey sẽ bị ràng buộc với thiết bị và không thể di chuyển - một kịch bản quan trọng cần lên kế hoạch (ví dụ: đảm bảo người dùng vẫn có thể đăng nhập nếu họ có điện thoại mới).
3. Ngoài ra, các ứng dụng quản lý thông tin xác thực của bên thứ ba có thể ảnh hưởng đến luồng. Ví dụ, nếu người dùng có một trình quản lý mật khẩu như 1Password được đặt làm nhà cung cấp thông tin xác thực đang hoạt động, nó thường sẽ chặn việc tạo và lưu trữ passkey, ưu tiên hơn trình quản lý thông tin xác thực native của nền tảng.

Trong khi bạn có thể triển khai passkey bằng cách sử dụng các API thô của nền tảng, các SDK được xây dựng chuyên dụng giúp tăng tốc đáng kể quá trình phát triển bằng cách xử lý sự phức tạp của WebAuthn, các trường hợp đặc biệt và cung cấp τηλεμετρία tích hợp sẵn. Các SDK cũng cung cấp các giao diện có thể mô phỏng (mockable) để kiểm thử đơn vị (rất quan trọng vì bạn không thể kiểm thử sinh trắc học trong trình giả lập).

Khuyến nghị: Đối với các triển khai native, chúng tôi khuyên bạn nên sử dụng SDK của Corbado (SDK Passkey iOS Swift, SDK Passkey Android Kotlin để xử lý vô số trường hợp đặc biệt được phát hiện qua các lần triển khai sản phẩm, cung cấp thêm τηλεμετρία và kiểm thử.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Passkey được hàng triệu người chấp nhận, nhanh chóng. Bắt đầu với Nền tảng chấp nhận của Corbado.

Bắt đầu dùng thử miễn phí

System WebView sử dụng thành phần trình duyệt native của nền tảng để xử lý xác thực trong ứng dụng của bạn. Không giống như các triển khai hoàn toàn native, System WebView hiển thị nội dung web bằng trình duyệt hệ thống thực tế (Safari trên iOS, Chrome trên Android), duy trì cookie được chia sẻ, thông tin xác thực đã lưu và các chỉ báo bảo mật quen thuộc của trình duyệt.

Khi nào nên chọn System WebView:

• Ứng dụng của bạn sử dụng đăng nhập dựa trên OAuth: System WebView là phương pháp được khuyến nghị cho các luồng OAuth2/OIDC, cung cấp xác thực an toàn
• Xác thực dựa trên web hiện có mà bạn muốn tái sử dụng trong các ứng dụng di động
• Cần hỗ trợ nhiều phương thức xác thực (mật khẩu, đăng nhập mạng xã hội, passkey) mà không cần xây dựng lại từ đầu bằng native
• Muốn duy trì một codebase xác thực duy nhất trên web và di động

Lợi thế chính:

• Tương thích OAuth: Được xây dựng chuyên dụng cho các luồng xác thực OAuth/OIDC
• Chỉ báo bảo mật: Người dùng nhìn thấy URL thực tế và chứng chỉ SSL, tạo dựng lòng tin
• Nỗ lực triển khai thấp: Yêu cầu mã native tối thiểu
• UX nhất quán: Giao diện trình duyệt quen thuộc mà người dùng đã tin tưởng

Thành phần nền tảng:

• iOS: ASWebAuthenticationSession (khuyến nghị cho các luồng xác thực) hoặc SFSafariViewController (duyệt web thông thường)
• Android: Chrome Custom Tabs (CCT)

Các công ty lớn như Google và GitHub đã áp dụng cách tiếp cận này để thêm tính năng đăng nhập bằng passkey vào ứng dụng di động của họ thông qua các lớp phủ WebView trên các trang xác thực web hiện có. Điều này hoạt động tốt khi việc xây dựng lại xác thực hoàn toàn bằng native không khả thi ngay lập tức.

iOS cung cấp hai thành phần System WebView chính để xác thực:

ASWebAuthenticationSession (Khuyến nghị để xác thực):

• Được xây dựng chuyên dụng cho các luồng OAuth/OIDC và đăng nhập an toàn
• Tự động nhắc người dùng rằng ứng dụng muốn xác thực
• Chia sẻ cookie và thông tin xác thực với Safari
• Hỗ trợ passkey qua iCloud Keychain

SFSafariViewController (Duyệt web thông thường):

• Trải nghiệm Safari đầy đủ trong ứng dụng
• Hiển thị thanh URL và các chỉ báo bảo mật
• Không chia sẻ cookie của Safari trên iOS 11+; sử dụng ASWebAuthenticationSession khi yêu cầu chia sẻ phiên Safari
• Ít tùy biến hơn nhưng đáng tin cậy hơn với người dùng

Nếu ứng dụng của bạn sử dụng đăng nhập dựa trên OAuth, ASWebAuthenticationSession là lựa chọn được khuyến nghị vì nó được thiết kế đặc biệt cho các kịch bản xác thực và cung cấp sự cân bằng tốt nhất giữa bảo mật và trải nghiệm người dùng.

Chrome Custom Tabs (CCT) cung cấp trải nghiệm xác thực được hỗ trợ bởi Chrome trong ứng dụng của bạn:

Các tính năng chính:

• Chia sẻ cookie và thông tin xác thực với trình duyệt Chrome
• Hiển thị URL và các chỉ báo bảo mật
• Có thể tùy chỉnh màu thanh công cụ và thương hiệu
• Khởi động trước để tải nhanh hơn

Tích hợp OAuth: Chrome Custom Tabs là phiên bản tương đương của ASWebAuthenticationSession trên iOS, cung cấp hỗ trợ OAuth xuất sắc trong khi vẫn duy trì quyền truy cập vào các passkey đã lưu.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

Embedded WebView cung cấp toàn quyền kiểm soát việc hiển thị nội dung web trong ứng dụng của bạn, cho phép thao tác trực tiếp với cookie, phiên và điều hướng mà không có thanh URL. Tuy nhiên, quyền kiểm soát này đi kèm với các yêu cầu kỹ thuật bổ sung để kích hoạt chức năng passkey.

Khi nào nên chọn Embedded WebView:

• Trải nghiệm giống native: Ứng dụng của bạn đã nhúng xác thực trong một web view tùy chỉnh để duy trì giao diện native, và bạn muốn giữ trải nghiệm người dùng nhất quán này
• Cần kiểm soát phiên/cookie: Ứng dụng của bạn yêu cầu thao tác trực tiếp với token xác thực và trạng thái phiên sau khi xác thực OAuth hoàn tất
• Luồng xác thực hiện có trong đó xác thực System WebView trả về mã xác thực nhưng không có phiên trong ngữ cảnh nhúng
• Phải duy trì trạng thái xác thực trên nhiều màn hình web nhúng
• Chỉ xác thực bên thứ nhất: Ứng dụng của bạn xử lý xác thực trực tiếp, đối với các triển khai passkey của bên thứ ba, xem tại đây: https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk
• AndroidX WebKit 1.12.1+ với phát hiện tính năng thời gian chạy
• Chấp nhận giới hạn của Conditional UI cho Đăng nhập (không được hỗ trợ trong Embedded WebView), không liên quan đến cài đặt quản lý

Bối cảnh quan trọng:

Nhiều ứng dụng sử dụng phương pháp kết hợp: System WebView xử lý xác thực OAuth ban đầu (nơi passkey hoạt động liền mạch), sau đó chuyển sang Embedded WebView sau xác thực để quản lý passkey trong phần cài đặt. Thách thức phát sinh khi cố gắng sử dụng passkey trực tiếp trong Embedded WebView.

Yêu cầu kỹ thuật:

Embedded WebView yêu cầu thiết lập bổ sung so với System WebView:

1. iOS: Entitlements Associated Domains, cấu hình tệp AASA
2. Android: AndroidX WebKit 1.12.1+ với cấu hình WebView WebAuthn (yêu cầu phát hiện tính năng)
3. Cả hai: Các tệp liên kết well-known được cấu hình đúng cách và Digital Asset Links

Thành phần nền tảng:

• iOS: WKWebView
• Android: android.webkit.WebView

Đánh đổi:

• Độ phức tạp trung bình: Yêu cầu cấu hình WebView (Android WebKit 1.12.1+) và thiết lập entitlements (iOS)
• Mức độ chấp nhận passkey thấp hơn: Người dùng có thể gặp nhiều rắc rối hơn so với native
• Conditional UI không được hỗ trợ: Tự động điền passkey trong các trường nhập liệu không hoạt động trong Embedded WebView của Android
• Hỗ trợ nền tảng hạn chế: Một số tính năng có thể không hoạt động nhất quán (ví dụ: tự động tạo passkey)

Khi triển khai passkey qua WebView, việc hiểu rõ sự khác biệt giữa System WebView và Embedded WebView là rất quan trọng. Ba phương pháp được nêu ở trên (Triển khai Native, System WebView và Embedded WebView) mỗi phương pháp phục vụ cho các trường hợp sử dụng khác nhau.

Trên iOS, bạn có nhiều tùy chọn để hiển thị nội dung web trong ứng dụng:

• WKWebView là một thành phần WebView có thể tùy chỉnh, là một phần của framework WebKit (được giới thiệu trong iOS 8). Nó cho phép bạn kiểm soát rất nhiều về giao diện và hành vi của nội dung web.
• SFSafariViewController là một view controller do Apple cung cấp, hoạt động như một trình duyệt Safari gọn nhẹ trong ứng dụng của bạn. Nó sử dụng công cụ của Safari. Trên iOS 11+, nó có một kho cookie riêng và không chia sẻ cookie của Safari. Sử dụng ASWebAuthenticationSession khi yêu cầu chia sẻ phiên Safari.
• SFAuthenticationSession / ASWebAuthenticationSession là các phiên xác thực web chuyên dụng (có từ iOS 11/12) dành riêng cho các luồng OAuth/OpenID hoặc các luồng đăng nhập an toàn khác. Chúng cũng tận dụng Safari ngầm, nhưng tập trung vào các luồng xác thực và tự động xử lý những thứ như cookie được chia sẻ và Single Sign-On (SSO).

Trên Android, các lựa chọn chính là:

• Android WebView là widget WebView tiêu chuẩn (android.webkit.WebView), về cơ bản là một trình duyệt mini có thể được nhúng vào các activity của bạn. Nó rất dễ tùy chỉnh nhưng chạy trong tiến trình của ứng dụng bạn.
• Chrome Custom Tabs (CCT) là một tính năng mở một tab được hỗ trợ bởi Chrome trong ngữ cảnh ứng dụng của bạn. Custom Tabs xuất hiện như một phần của ứng dụng nhưng được cung cấp bởi trình duyệt Chrome (nếu được cài đặt) với các tính năng như tải trước, chia sẻ cookie và thanh URL quen thuộc để tạo lòng tin cho người dùng.

Trong các phần sau, chúng ta sẽ tìm hiểu sâu hơn về các loại WebView này cho iOS và Android, và thảo luận xem loại nào có thể phù hợp nhất cho các luồng xác thực bằng passkey.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Nền tảng của Apple cung cấp ba tùy chọn WebView được liệt kê ở trên. Lựa chọn của bạn sẽ ảnh hưởng đến mức độ mượt mà của việc sử dụng passkey trong ứng dụng:

Để kiểm tra hành vi của các WebView khác nhau trên iOS, chúng tôi khuyên dùng ứng dụng WebView - WKWebView and UIWebView rendering.

WKWebView là một thành phần WebView đa năng cho iOS. Các nhà phát triển có thể nhúng một WKWebView để hiển thị nội dung web với mức độ kiểm soát cao về giao diện người dùng và hành vi. WKWebView sử dụng cùng một công cụ hiển thị như Safari, vì vậy nó rất hiệu quả và hỗ trợ các tính năng web hiện đại. Về lý thuyết, WKWebView có thể xử lý WebAuthn (và do đó là passkey) nếu được cấu hình đúng cách, nhưng lưu ý rằng một số tính năng trình duyệt nâng cao có thể bị hạn chế vì lý do bảo mật. Một điều cần chú ý là WKWebView theo mặc định không chia sẻ cookie hoặc dữ liệu keychain với Mobile Safari. Người dùng có thể phải đăng nhập lại vì phiên WebView của họ bị cô lập khỏi phiên của Safari. Ngoài ra, vì nội dung WKWebView có thể được tùy chỉnh hoàn toàn bởi ứng dụng, người dùng không nhìn thấy thanh địa chỉ hoặc giao diện người dùng Safari – điều này rất tốt cho việc xây dựng thương hiệu, nhưng nó có nghĩa là người dùng có ít tín hiệu hơn để xác minh tính hợp pháp của trang (một mối lo ngại về chống lừa đảo (phishing)). Một số ứng dụng thậm chí đã lạm dụng WKWebView để chèn script hoặc thay đổi nội dung (ví dụ: TikTok đã được ghi nhận là chèn JS theo dõi qua trình duyệt trong ứng dụng của họ), vì vậy cần phải cẩn thận khi sử dụng WKWebView một cách an toàn và đáng tin cậy cho người dùng.

SFSafariViewController cung cấp trải nghiệm Safari trong ứng dụng. Khi bạn mở một URL bằng SFSafariViewController, nó gần giống như mở nó trong trình duyệt Safari thực, ngoại trừ việc người dùng vẫn ở trong giao diện người dùng của ứng dụng bạn. Lợi thế cho passkey là rất đáng kể: vì về cơ bản nó là Safari, iCloud Keychain và các passkey đã lưu của người dùng đều có thể truy cập được. Lưu ý rằng cookie không được chia sẻ trên iOS 11+. Điều này có nghĩa là nếu người dùng đã có passkey cho trang web của bạn, Safari có thể tìm thấy nó và thậm chí hiển thị tự động hoàn thành Conditional UI để đăng nhập dễ dàng. SFSafariViewController ít tùy chỉnh hơn (bạn không thể thay đổi nhiều thanh công cụ của nó), nhưng nó tự động xử lý rất nhiều tính năng bảo mật và quyền riêng tư. Thanh URL được hiển thị, hoàn chỉnh với biểu tượng ổ khóa cho HTTPS, điều này mang lại cho người dùng sự tự tin rằng họ đang ở đúng tên miền. Nói chung, SFSafariViewController được coi là an toàn hơn một WKWebView thô và đơn giản hơn để triển khai (Apple cung cấp nó dưới dạng thả vào). Sự đánh đổi chính là bạn hy sinh một số quyền kiểm soát về giao diện và cảm nhận. Đối với một luồng xác thực, điều đó thường có thể chấp nhận được. Ưu tiên ở đây là bảo mật và dễ dàng đăng nhập, điều mà SFSafariViewController thực hiện xuất sắc bằng cách sử dụng ngữ cảnh của Safari.

SFAuthenticationSession / ASWebAuthenticationSession – Các lớp này (lớp sau là tên mới thân thiện với Swift) được xây dựng đặc biệt cho các luồng đăng nhập như OAuth hoặc OpenID Connect. Khi bạn cần xác thực người dùng qua một trang web (có thể là đến một IdP bên ngoài), các phiên này là lựa chọn được khuyến nghị trên iOS. Chúng rất giống với SFSafariViewController ở chỗ chúng sử dụng trình duyệt Safari ngầm và chia sẻ cookie/bộ nhớ với Safari. Sự khác biệt chính là SFAuthenticationSession sẽ luôn nhắc người dùng rằng ứng dụng muốn xác thực bằng một trang web (để người dùng nhận biết) và nó sẽ tự động sử dụng phiên Safari hiện có của người dùng nếu có.

Lợi ích là một trải nghiệm SSO liền mạch – nếu người dùng đã đăng nhập vào nhà cung cấp trong Safari, phiên này có thể sử dụng cookie đó để tránh một lần đăng nhập khác. Đối với passkey, điều này quan trọng vì nó có nghĩa là bất kỳ thông tin xác thực passkey nào được lưu trữ trong Safari/iCloud Keychain cũng có thể được sử dụng ở đây. Hướng dẫn chính thức của Apple là sử dụng ASWebAuthenticationSession cho bất cứ điều gì trông giống như một luồng đăng nhập. Ưu điểm là tăng cường quyền riêng tư (ứng dụng của bạn không bao giờ thấy thông tin xác thực hoặc cookie, Safari sẽ xử lý) và hỗ trợ SSO tích hợp. Nhược điểm là nó chỉ giới hạn trong các luồng xác thực (bạn sẽ không sử dụng nó để chỉ hiển thị nội dung web tùy ý trong ứng dụng của mình). Tóm lại, nếu bạn chọn phương pháp WebView trên iOS, ASWebAuthenticationSession thường là lựa chọn tốt nhất để triển khai passkey vì nó an toàn, chia sẻ trạng thái với Safari và được xây dựng chuyên dụng cho việc xác thực.

Want to find out how many people use passkeys?

View Adoption Data

Trên Android, quyết định về WebView là giữa WebView cổ điển và Chrome Custom Tabs:

Để kiểm tra hành vi của các WebView khác nhau trên Android, chúng tôi khuyên dùng ứng dụng WebView vs Chrome Custom Tabs.

Android WebView (android.webkit.WebView) là một thành phần cho phép bạn nhúng các trang web vào bố cục activity của mình. Nó tương tự như WKWebView ở chỗ nó cho phép bạn toàn quyền kiểm soát: bạn có thể chặn điều hướng, chèn JavaScript, tùy chỉnh giao diện người dùng, v.v. Nó cũng chạy trong tiến trình của ứng dụng bạn. Sử dụng WebView cho passkey có nghĩa là ứng dụng của bạn tải trang đăng nhập web của bạn, và trang đó có thể khởi tạo một nghi thức passkey WebAuthn. Android WebView hiện đại có hỗ trợ WebAuthn (với điều kiện là việc triển khai WebView của thiết bị được cập nhật thông qua Android System WebView hoặc thành phần Chrome). Một cân nhắc lớn: theo mặc định, một Android WebView không chia sẻ cookie hoặc thông tin xác thực đã lưu với trình duyệt Chrome của người dùng. Vì vậy, bất kỳ passkey nào được tạo hoặc sử dụng trong WebView có thể không được Chrome biết đến, và ngược lại. Sự cô lập này có thể tốt cho bảo mật (ứng dụng của bạn không thể đọc cookie trình duyệt), nhưng nó có thể buộc người dùng phải đăng nhập lại nếu họ đã xác thực trong Chrome. Một vấn đề khác là sự tin cậy. Một WebView đơn giản không hiển thị URL hoặc biểu tượng khóa SSL, vì vậy người dùng phải tin tưởng hoàn toàn vào ứng dụng của bạn để không bị lừa đảo. Google thậm chí đã cấm sử dụng WebView cho các lần đăng nhập Google OAuth do rủi ro lừa đảo tiềm ẩn. Về hiệu suất, WebView vẫn ổn, nhưng chúng có thể chậm hơn hoặc tốn nhiều bộ nhớ hơn so với việc sử dụng trình duyệt mặc định của người dùng, đặc biệt là khi tải các trang nặng.

Chrome Custom Tabs (CCT) là một phương pháp kết hợp. Chúng cho phép ứng dụng của bạn mở một trang do Chrome hiển thị trông giống như một phần của ứng dụng bạn. Bạn có thể tùy chỉnh màu thanh công cụ, thêm logo ứng dụng, v.v., nhưng nội dung được hiển thị bởi Chrome trong một tiến trình riêng biệt. Đối với passkey, CCT có một số lợi ích: chúng chia sẻ cookie và thông tin xác thực của người dùng với Chrome, có nghĩa là nếu người dùng có passkey được lưu qua Chrome (Google Password Manager), Custom Tab có thể truy cập nó. Người dùng cũng sẽ thấy URL thực tế và các chỉ báo bảo mật, điều này tạo dựng lòng tin. Hiệu suất thường tốt hơn – Chrome có thể được "làm nóng" trong nền để tải nhanh hơn. Và quan trọng là, bảo mật rất mạnh: vì về cơ bản nó là ứng dụng Chrome, những thứ như Google Safe Browsing bảo vệ phiên, và ứng dụng của bạn không thể chèn các tập lệnh tùy ý vào trang (ngăn chặn một số cuộc tấn công nhất định).

Nhược điểm là nó yêu cầu người dùng phải cài đặt và cập nhật Chrome (hoặc một trình duyệt được hỗ trợ). Hầu hết người dùng Android đều có, nhưng trên một số thiết bị ở một số khu vực nhất định, đây có thể là một vấn đề. Nhìn chung, nếu bạn đi theo hướng web nhúng trên Android, Chrome Custom Tabs được khuyến nghị cho các luồng passkey, vì chúng cung cấp sự cân bằng tốt giữa tích hợp và bảo mật. Thực tế, chúng tương tự như SFSafariViewController/ASWebAuthSession của iOS ở nhiều khía cạnh – tận dụng trình duyệt mặc định để xác thực.

(Ngoài lề: WKWebView so với SFSafariViewController của Apple và WebView so với CCT của Android có nhiều điểm tương đồng. Cả Safari VC và Chrome Tabs đều chia sẻ trạng thái trình duyệt và cung cấp bảo mật tốt hơn, trong khi WKWebView/Android WebView cho phép kiểm soát nhiều hơn nhưng lại cô lập nội dung web. Đối với passkey, việc chia sẻ trạng thái (cookie, kho thông tin xác thực) thường là điều mong muốn để passkey có thể được truy cập và tạo ra một cách liền mạch.)

Bất kể bạn chọn phương pháp triển khai nào, một số yêu cầu kỹ thuật nhất định phải được đáp ứng để kích hoạt chức năng passkey. Phần này cung cấp hướng dẫn toàn diện về cách cấu hình các tệp liên kết well-known, entitlements của iOS và cấu hình Android WebView.

Lưu ý về thiết bị được quản lý: Hành vi của Passkey thay đổi đáng kể trên các thiết bị được quản lý nơi các chính sách Quản lý Thiết bị Di động (MDM) kiểm soát việc lưu trữ thông tin xác thực. Để kiểm thử passkey trên các thiết bị được quản lý, hãy xem Passkey trên thiết bị iOS & Android được quản lý.

Các luồng Native và Embedded WebView yêu cầu các tệp liên kết để thiết lập sự tin cậy mật mã giữa ứng dụng và miền web của bạn. System WebView (ASWebAuthenticationSession) và Chrome Custom Tabs không yêu cầu liên kết từ ứng dụng đến trang web.

Tệp AASA thiết lập kết nối giữa ứng dụng iOS và miền web của bạn, cho phép passkey hoạt động trên cả hai nền tảng.

Vị trí tệp: https://yourdomain.com/.well-known/apple-app-site-association

Yêu cầu cấu hình:

• Lưu trữ tại /.well-known/apple-app-site-association trên miền của bạn
• Phục vụ qua HTTPS với chứng chỉ SSL hợp lệ
• Content-Type: application/json
• Không chuyển hướng trên đường dẫn .well-known
• Bao gồm Team ID và Bundle ID của ứng dụng của bạn

Tệp AASA mẫu:

{
    "webcredentials": {
        "apps": ["TEAMID123.com.example.app"]
    }
}

Bộ nhớ đệm AASA và kiểm thử:

Apple lưu bộ nhớ đệm các tệp AASA rất chặt chẽ (lên đến 24-48 giờ) bằng CDN, điều này có thể gây khó khăn cho việc phát triển và kiểm thử. Để bỏ qua bộ nhớ đệm trong quá trình phát triển:

1. Bật Chế độ nhà phát triển trên thiết bị thử nghiệm của bạn
2. Thêm ?mode=developer vào miền liên kết của bạn trong Xcode
3. Điều này buộc iOS phải lấy tệp AASA mới nhất trực tiếp từ máy chủ của bạn

⚠️ Quan trọng: KHÔNG sử dụng ?mode=developer trong các bản phát hành sản phẩm. Tham số này chỉ dành cho phát triển—sử dụng nó trong sản phẩm sẽ ngăn iOS phát hiện đúng tệp AASA của bạn, làm hỏng chức năng passkey.

Xác thực: Sử dụng Trình xác thực AASA của Apple để xác minh cấu hình của bạn.

Android sử dụng Digital Asset Links để xác minh mối quan hệ giữa ứng dụng và trang web của bạn.

Vị trí tệp: https://yourdomain.com/.well-known/assetlinks.json

Yêu cầu cấu hình:

• Lưu trữ tại /.well-known/assetlinks.json trên miền của bạn
• Phục vụ qua HTTPS với chứng chỉ hợp lệ
• Content-Type: application/json
• Bao gồm vân tay SHA256 của ứng dụng (từ chứng chỉ ký)

Tệp assetlinks.json mẫu:

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.example.app",
            "sha256_cert_fingerprints": [
                "AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99"
            ]
        }
    }
]

Xác thực: Sử dụng Trình tạo Digital Asset Links của Google để tạo và xác minh cấu hình của bạn.

Các ứng dụng iOS yêu cầu các entitlements phù hợp để truy cập chức năng passkey. Các yêu cầu khác nhau một chút dựa trên phương pháp triển khai của bạn.

Tệp entitlements (thường có tên là Runner.entitlements trong các ứng dụng Flutter hoặc YourApp.entitlements trong các dự án iOS native) xác định các quyền và khả năng đặc biệt được cấp bởi hệ thống của Apple. Đối với passkey, tệp này cấu hình Associated Domains.

Vị trí tệp: Thường trong dự án Xcode của bạn tại ios/Runner/Runner.entitlements

Triển khai Native và Embedded WebView yêu cầu khả năng Associated Domains để liên kết ứng dụng của bạn với miền web. System WebView (ASWebAuthenticationSession) không yêu cầu điều này vì nó chạy trong ngữ cảnh Safari.

Thiết lập trong Xcode:

1. Mở dự án của bạn trong Xcode
2. Chọn mục tiêu ứng dụng của bạn
3. Đi đến tab "Signing & Capabilities"
4. Nhấp vào "+ Capability" và thêm "Associated Domains"
5. Thêm miền của bạn với tiền tố webcredentials:

Cấu hình mẫu:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>webcredentials:yourdomain.com</string>
        <string>webcredentials:subdomain.yourdomain.com</string>
    </array>
</dict>
</plist>

Nhiều miền: Nếu ứng dụng của bạn cần hoạt động với nhiều miền, bạn có thể cần Related Origin Requests (ROR).

Android Embedded WebView đã có hỗ trợ WebAuthn native với AndroidX WebKit 1.12, loại bỏ nhu cầu về mã cầu nối JavaScript tùy chỉnh. System WebView (Chrome Custom Tabs) không yêu cầu cấu hình nào - thông tin xác thực hoạt động tự động.

Yêu cầu:

• AndroidX WebKit 1.12.1 trở lên (khuyến nghị 1.14.0+)
• Đã cấu hình Digital Asset Links
• APK WebView có hỗ trợ WebAuthn (kiểm tra qua phát hiện tính năng)
• Lưu ý: Thư viện AndroidX Credentials KHÔNG bắt buộc đối với WebAuthn trong WebView, chỉ dành cho các triển khai hoàn toàn native

Triển khai:

import androidx.webkit.WebSettingsCompat
import androidx.webkit.WebViewFeature
 
// Kiểm tra xem Web Authentication có được hỗ trợ không
if (WebViewFeature.isFeatureSupported(WebViewFeature.WEB_AUTHENTICATION)) {
    // Bật Web Authentication
    WebSettingsCompat.setWebAuthenticationSupport(
        webView.settings,
        WebSettingsCompat.WEB_AUTHENTICATION_SUPPORT_FOR_APP
    )
 
    // Bật JavaScript
    webView.settings.javaScriptEnabled = true
}

Điểm chính:

• Không cần cầu nối JavaScript: WebAuthn hoạt động native trong WebView
• Yêu cầu phát hiện tính năng: Luôn kiểm tra WebViewFeature.WEB_AUTHENTICATION tại thời điểm chạy
• Conditional UI không được hỗ trợ: mediation:"conditional" (tự động điền passkey trong các trường nhập liệu) không hoạt động trong Embedded WebView
• Chiến lược dự phòng: Nếu tính năng không có sẵn, hãy sử dụng Chrome Custom Tabs thay thế

Lưu ý về phiên bản:

• Sử dụng WebKit 1.12.1 trở lên (1.12.0 có vấn đề về tính khả dụng tại thời điểm chạy)
• Hỗ trợ tính năng phụ thuộc vào phiên bản APK WebView của người dùng - các APK cũ hơn trên thiết bị sẽ không hiển thị tính năng này

Trước AndroidX WebKit 1.12.0, không có hỗ trợ WebAuthn native trong Embedded WebView. Các nhóm phải:

1. Sử dụng Chrome Custom Tabs hoặc Auth Tab (khuyến nghị)
2. Xây dựng một cầu nối JavaScript tùy chỉnh

Nếu bạn cần hỗ trợ các phiên bản Android cũ hơn hoặc các thiết bị không có APK WebView được cập nhật, hãy xem hướng dẫn Tích hợp WebView của Credential Manager trên Android để biết phương pháp mã cầu nối. Tuy nhiên, chúng tôi thực sự khuyên bạn nên sử dụng phương pháp WebKit 1.12.1+ native cho các ứng dụng hiện đại.

Khuyến nghị: Sử dụng hỗ trợ WebAuthn native với AndroidX WebKit 1.12.1+. Nếu không có sẵn tại thời điểm chạy, hãy chuyển sang Chrome Custom Tabs, cung cấp hỗ trợ passkey xuất sắc với thông tin xác thực được chia sẻ.

Khi triển khai passkey trong các ứng dụng gốc, bạn cần thiết lập sự tin cậy giữa ứng dụng và (các) miền web của mình. Phần này đề cập đến cách xử lý các miền đơn lẻ, nhiều miền liên quan (ROR) và cách xác minh các tệp liên kết well-known của bạn được cấu hình đúng cách.

Đối với các ứng dụng sử dụng một miền duy nhất (ví dụ: kayak.com), bạn cần:

• Một tệp AASA cho iOS tại https://kayak.com/.well-known/apple-app-site-association
• Một tệp assetlinks.json cho Android tại https://kayak.com/.well-known/assetlinks.json
• Entitlement Associated Domains được cấu hình với webcredentials:kayak.com

Related Origins (ROR) là một tính năng của WebAuthn cho phép một bộ passkey duy nhất hoạt động trên nhiều miền liên quan (ví dụ: kayak.com, kayak.de, kayak.co.uk). ROR sử dụng điểm cuối /.well-known/webauthn trên mỗi trang web để xác định các miền liên quan, KHÔNG phải tệp AASA hay assetlinks.

Điểm chính:

• Cấu hình ROR: Mỗi miền lưu trữ /.well-known/webauthn với danh sách các miền liên quan
• Tệp liên kết ứng dụng (AASA/assetlinks): Chỉ được sử dụng để ánh xạ ứng dụng với các trang web tương ứng của chúng
• Embedded WebView trên iOS 18+: Hỗ trợ ROR khi được cấu hình đúng cách
• Entitlements Associated Domains: Bao gồm tất cả các miền mà ứng dụng của bạn cần xác thực

Ví dụ cấu hình:

Nếu ứng dụng của bạn hoạt động với kayak.com và kayak.de, cả hai miền phải:

• Lưu trữ các tệp AASA tương ứng của chúng với cùng một Team ID và Bundle ID
• Được liệt kê trong entitlements Associated Domains của ứng dụng của bạn
• Có các tệp well-known được cấu hình và có thể truy cập đúng cách

Trước khi đưa vào hoạt động, hãy xác minh các tệp well-known của bạn được cấu hình và có thể truy cập đúng cách. Apple và Google cung cấp các URL kiểm tra dựa trên CDN để kiểm tra tính khả dụng của tệp:

Sử dụng các URL kiểm tra này:

• Nhấp vào các liên kết để xác minh xem Apple/Google có thể truy xuất các tệp well-known của bạn không
• Tham số ?nocache=1 của Apple buộc truy xuất mới, bỏ qua bộ nhớ đệm CDN
• Nếu các tệp không thể truy cập được thông qua các URL này, chức năng passkey sẽ không hoạt động trong ứng dụng của bạn
• Thay thế kayak.com hoặc kayak.de bằng (các) miền của riêng bạn trong các mẫu URL ở trên

Lưu ý khi kiểm thử: Đảm bảo tất cả các miền đều có các tệp well-known được cấu hình đúng cách. Một tệp bị thiếu hoặc cấu hình sai trên bất kỳ miền nào cũng có thể làm hỏng chức năng passkey cho miền đó.

Thông tin thêm: WebAuthn Relying Party ID trong ứng dụng gốc

Việc chọn phương pháp triển khai phù hợp phụ thuộc vào kiến trúc xác thực của ứng dụng, yêu cầu OAuth và nhu cầu kiểm soát phiên. Sử dụng cây quyết định này để xác định con đường tốt nhất.

Bắt đầu với những câu hỏi chính này:

1. Ứng dụng của bạn có sử dụng đăng nhập dựa trên OAuth (OAuth2, OIDC, nhà cung cấp đăng nhập xã hội) không?

   • Có → System WebView (Phần 1.2)
     • iOS: Sử dụng ASWebAuthenticationSession
     • Android: Sử dụng Chrome Custom Tabs
     • Hỗ trợ OAuth xuất sắc với thông tin xác thực được chia sẻ

2. Bạn có muốn tái sử dụng xác thực web trong một vỏ ứng dụng giống native (không có thanh URL, kiểm soát giao diện người dùng đầy đủ) không?

   • Có → Embedded WebView (Phần 1.3) với cấu hình
   • iOS: WKWebView + entitlements Associated Domains
   • Android: WebView + cấu hình AndroidX WebKit 1.12.1+
   • Cung cấp giao diện giống native trong khi tái sử dụng các thành phần web
   • Lưu ý: Conditional UI không được hỗ trợ trong Embedded WebView
   • Không → Cân nhắc System WebView hoặc Native

3. Bạn đang xây dựng một ứng dụng gốc mới hay có các màn hình đăng nhập native?

   • Có → Triển khai Native (Phần 1.1)
     • Trải nghiệm người dùng tốt nhất
     • Xác thực tức thì, âm thầm
     • Yêu cầu phát triển riêng cho từng nền tảng

4. Bạn có xác thực web hiện có mà bạn muốn tái sử dụng không?

   • Có → System WebView để triển khai nhanh
   • Không → Triển khai Native để có UX tối ưu

Đây là cách mỗi phương pháp hoạt động trên các khía cạnh chính:

Giải thích các khía cạnh:

• Tạo Passkey: Mức độ dễ dàng người dùng có thể tạo passkey thông qua phương pháp này
• Sử dụng Passkey: Trải nghiệm xác thực khi sử dụng các passkey hiện có
• Quản lý Passkey: Cách người dùng xem, chỉnh sửa hoặc xóa passkey
• Độ phức tạp kỹ thuật: Nỗ lực phát triển và bảo trì liên tục
• Hỗ trợ OAuth: Mức độ phương pháp xử lý các luồng xác thực OAuth2/OIDC
• Thời gian thiết lập: Lịch trình triển khai điển hình

Khuyến nghị: System WebView

Nếu ứng dụng của bạn xác thực qua OAuth2, OIDC hoặc các nhà cung cấp đăng nhập xã hội (Google, GitHub, Microsoft, v.v.), System WebView là lựa chọn tối ưu:

• iOS: ASWebAuthenticationSession được xây dựng chuyên dụng cho các luồng OAuth
• Android: Chrome Custom Tabs cung cấp tích hợp OAuth liền mạch
• Lợi ích: Mã native tối thiểu, chia sẻ thông tin xác thực tự động
• Triển khai: Thêm WebAuthn vào trang xác thực web của bạn, sau đó tải nó qua System WebView

Ví dụ: Các ứng dụng du lịch như kayak.com và kayak.de sử dụng OAuth để xác thực. System WebView cho phép họ duy trì cơ sở hạ tầng OAuth hiện có trong khi thêm hỗ trợ passkey thông qua các trang xác thực web của họ.

Khuyến nghị: Phương pháp kết hợp

Sử dụng System WebView để xác thực OAuth ban đầu, sau đó Embedded WebView cho các phiên sau xác thực:

1. Xác thực ban đầu: System WebView xử lý đăng nhập OAuth + passkey
2. Quản lý phiên: Chuyển sang Embedded WebView cho nội dung web đã xác thực nơi bạn cần kiểm soát cookie/phiên
3. Thiết lập kỹ thuật: Cấu hình cả yêu cầu System và Embedded WebView—đối với Android, đảm bảo AndroidX WebKit 1.12.1+ được bao gồm (xem Phần 5)

Khi nào sử dụng: Các ứng dụng xác thực qua OAuth nhưng sau đó cần hiển thị nội dung web đã xác thực nơi yêu cầu thao tác phiên trực tiếp.

Khuyến nghị: Triển khai Native

Xây dựng từ đầu hoặc có các màn hình native? Hãy đi theo hướng hoàn toàn native:

• iOS: Sử dụng framework AuthenticationServices
• Android: Sử dụng API Credential Manager
• Lợi ích: UX tốt nhất, xác thực tức thì, kiểm soát hoàn toàn
• Lợi thế độc đáo: Sử dụng preferImmediatelyAvailableCredentials để hiển thị lớp phủ passkey tự động khi khởi động ứng dụng - độc quyền cho các triển khai native và cung cấp tỷ lệ chuyển đổi cao nhất
• Khuyến nghị SDK: Sử dụng SDK của Corbado (iOS, Android) để tăng tốc phát triển với việc xử lý các trường hợp đặc biệt đã được kiểm thử trong sản xuất

Đối với ứng dụng mới: Rất khuyến khích xây dựng đăng nhập native ngay từ ngày đầu. Điều này giúp bạn có được UX tối ưu và tránh các cuộc di chuyển từ WebView sang native trong tương lai.

Khuyến nghị: Di chuyển theo giai đoạn

• Giai đoạn 1: Passkey trên System WebView - Thêm hỗ trợ passkey vào đăng nhập web hiện có, tải qua System WebView (ASWebAuthenticationSession/Chrome Custom Tabs). Một chiến thắng nhanh chóng với mã native tối thiểu.
• Giai đoạn 2: Chặn bằng Native - Thêm kiểm tra passkey native trước khi hiển thị WebView. Ví dụ: kayak.com cố gắng xác thực passkey native trước, chuyển sang WebView nếu cần. Cung cấp đăng nhập sinh trắc học nhanh chóng trong khi vẫn duy trì khả năng tương thích ngược.
• Giai đoạn 3: Hoàn toàn Native - Dần dần di chuyển sang xác thực native cho người dùng passkey, giữ lại WebView cho các phương pháp cũ.

Phương pháp theo giai đoạn này cho phép cải tiến dần dần mà không làm gián đoạn người dùng hiện tại.

Xem Phần 5 để biết hướng dẫn cấu hình chi tiết.

Kiểm thử passkey trong các ứng dụng gốc đòi hỏi một phương pháp có cấu trúc, đa tầng. Tuân theo kim tự tháp kiểm thử: kiểm thử đơn vị (logic biệt lập), kiểm thử tích hợp (nghi thức WebAuthn trên trình giả lập) và kiểm thử hệ thống (đầu cuối trên thiết bị vật lý).

Các hạng mục kiểm thử thiết yếu:

• Luồng chính: Đăng ký, xác thực, luồng chéo thiết bị, xóa passkey
• Phạm vi nền tảng: iOS (native), Android (native), trình duyệt web trên các phiên bản hệ điều hành
• Liên kết miền: Xác minh tệp AASA (iOS) và Digital Asset Links (Android) có thể truy cập được
• Luồng hủy bỏ: Kiểm tra việc người dùng hủy bỏ tại các lời nhắc của hệ điều hành và màn hình sinh trắc học
• Xử lý lỗi: Lỗi backend, hết thời gian mạng, thông tin xác thực không khớp
• Trường hợp đặc biệt: Khóa màn hình bị tắt, iCloud/Google Password Manager bị tắt
• Luồng OAuth: Tích hợp hoàn chỉnh OAuth + passkey từ đầu đến cuối
• Thiết bị được quản lý: Môi trường do MDM kiểm soát (xem kiểm thử thiết bị được quản lý)
• Trình quản lý của bên thứ ba: Tương thích với 1Password, Bitwarden, Dashlane
• Xác thực chéo thiết bị: Luồng mã QR và kiểm thử vận chuyển kết hợp
• Dành riêng cho Embedded WebView: Nếu sử dụng Embedded WebView, xác minh cấu hình WebKit 1.12.1+ trên Android
• Giám sát sản xuất: Bảng điều khiển cho tỷ lệ thành công, thất bại và độ trễ

Để có hướng dẫn kiểm thử toàn diện bao gồm các chiến lược tự động hóa, các lỗi cụ thể của nền tảng và danh sách kiểm tra đầy đủ trước khi triển khai, hãy xem hướng dẫn chuyên dụng của chúng tôi: Kiểm thử luồng Passkey trong ứng dụng gốc iOS & Android.

Cân nhắc nhắc người dùng tạo passkey sau khi đăng nhập truyền thống thành công (mật khẩu, OAuth). Phương pháp chuyển đổi dần dần này:

• Không làm gián đoạn các luồng xác thực hiện có
• Cho phép giảm cấp nhẹ nhàng nếu người dùng từ chối
• Tăng tỷ lệ chấp nhận passkey theo thời gian mà không ép buộc thay đổi
• Hoạt động tốt với cả ba phương pháp triển khai

Ví dụ: Sau khi đăng nhập OAuth qua System WebView, hiển thị một lời nhắc native: "Bật đăng nhập nhanh hơn với Face ID?" Nếu được chấp nhận, tạo passkey thông qua trang web được tải trong System WebView.

Quyết định cách triển khai passkey - qua Triển khai Native, System WebView hay Embedded WebView là một lựa chọn thiết kế quan trọng ảnh hưởng đến bảo mật, trải nghiệm người dùng và độ phức tạp của việc phát triển. Không có câu trả lời nào phù hợp cho tất cả.

Đối với các ứng dụng dựa trên OAuth: System WebView (ASWebAuthenticationSession, Chrome Custom Tabs) là điểm khởi đầu được khuyến nghị. Nó cung cấp hỗ trợ OAuth xuất sắc, nỗ lực triển khai tối thiểu và chia sẻ thông tin xác thực tự động.

Đối với các ứng dụng ưu tiên native: Hãy chuyển sang native càng sớm càng tốt. Đăng nhập bằng passkey native mang lại UX liền mạch nhất với các khả năng độc quyền như preferImmediatelyAvailableCredentials, cho phép hiển thị lớp phủ passkey tự động khi khởi động ứng dụng—điều mà các triển khai WebView không thể cung cấp. Với việc iOS và Android hiện cung cấp hỗ trợ hàng đầu cho passkey, các thành công trong thế giới thực cho thấy tỷ lệ chấp nhận cao. Các công cụ (bao gồm các SDK mã nguồn mở và thư viện nền tảng) đã trưởng thành để giúp việc tích hợp native trở nên khả thi trong các khung thời gian hợp lý. Mặc dù bạn phải lưu ý đến các chính sách quản lý thiết bị, đồng bộ hóa chéo thiết bị và các nhà cung cấp bên thứ ba, những thách thức này có thể được quản lý bằng kỹ thuật và kiểm thử cẩn thận. Kết quả là một đăng nhập ứng dụng làm hài lòng người dùng với sự dễ dàng và tốc độ của nó trong khi cải thiện đáng kể bảo mật.

Đối với các yêu cầu về khung Embedded WebView: Embedded WebView thường được sử dụng trong hai kịch bản thực tế. Đầu tiên, các ứng dụng dựa trên OAuth thường sử dụng System WebView cho luồng đăng nhập ban đầu, sau đó chuyển sang Embedded WebView để hiển thị các tùy chọn quản lý passkey trong màn hình cài đặt nơi cần kiểm soát phiên—mặc dù một số ứng dụng đơn giản hóa điều này bằng cách giữ System WebView cho cả hai luồng. Thứ hai, các ứng dụng đã nhúng luồng xác thực của họ vào khung WebView trước khi áp dụng passkey tiếp tục mô hình này để đảm bảo tính nhất quán. Embedded WebView với hỗ trợ WebAuthn native (AndroidX WebKit 1.12.1+) yêu cầu cấu hình và thiết lập (quyền, entitlements, cài đặt WebView) nhưng không còn cần mã cầu nối JavaScript tùy chỉnh. Lưu ý rằng Conditional UI không được hỗ trợ trong Embedded WebView. Chọn phương pháp này khi duy trì các mẫu xác thực nhúng hiện có hoặc khi bạn cần kiểm soát phiên/cookie cho các màn hình sau xác thực.

Cuối cùng, passkey trong các ứng dụng gốc đại diện cho một bước nhảy vọt lớn về cả sự tiện lợi cho người dùng và bảo mật. Dù được triển khai qua Native, System WebView hay Embedded WebView, chúng đều loại bỏ rủi ro lừa đảo (phishing) và gánh nặng quản lý mật khẩu cho người dùng của bạn. Các triển khai trong thế giới thực như tích hợp passkey trong ứng dụng gốc của VicRoads chứng minh rằng các phương pháp ưu tiên native mang lại tỷ lệ chấp nhận và sự hài lòng của người dùng cao nhất khi được thực hiện đúng cách với các tính năng như lớp phủ passkey tự động. Bằng cách tuân theo các thực tiễn tốt nhất để xác thực thân thiện với người dùng và chọn phương pháp triển khai phù hợp với kiến trúc ứng dụng của bạn—native-first cho ứng dụng mới, System WebView cho các luồng OAuth, hoặc Embedded WebView cho các mẫu nhúng hiện có—bạn có thể cung cấp đăng nhập không mật khẩu, sinh trắc học thực sự hiện thực hóa tầm nhìn của passkey: xác thực đơn giản, an toàn và thú vị cho mọi người.

Nếu passkey không hoạt động trong ứng dụng gốc của bạn, hãy kiểm tra các vấn đề phổ biến này theo phương pháp triển khai:

• Tệp được phục vụ qua HTTPS với chứng chỉ hợp lệ
• Loại MIME chính xác: application/json
• Không có chuyển hướng trên đường dẫn .well-known
• iOS: Team ID và Bundle ID khớp chính xác trong tệp AASA
• Android: Vân tay SHA256 khớp với chứng chỉ ký của bạn trong assetlinks.json
• Relying Party ID khớp với miền của bạn (không có giao thức, không có cổng)
• Không có dấu gạch chéo cuối cùng trong RP ID
• Nguồn gốc WebAuthn: https://your-domain.com (không phải app://)

• iOS: Khả năng Associated Domains được bật trong Xcode với webcredentials:yourdomain.com
• Android: Digital Asset Links được khai báo trong AndroidManifest.xml
• Người dùng đã bật khóa màn hình (sinh trắc học hoặc PIN)
• Kiểm tra bằng Trình xác thực AASA của Apple và công cụ Digital Asset Links của Google
• Xác minh tệp Runner.entitlements chứa các miền liên kết chính xác

• iOS: Sử dụng ASWebAuthenticationSession (khuyến nghị) hoặc SFSafariViewController
• Android: Sử dụng Chrome Custom Tabs (không phải WebView đơn thuần)
• iOS: Xác minh Associated Domains đã được cấu hình nếu cần
• Kiểm tra xem cookie/thông tin xác thực có được chia sẻ với trình duyệt hệ thống không
• Xác minh trang xác thực web có triển khai WebAuthn phù hợp

• iOS: Được cấu hình với các entitlements phù hợp
• iOS: Associated Domains bao gồm tất cả các miền liên quan
• iOS: Tệp AASA có thể truy cập và được định dạng đúng cách
• iOS: Kiểm tra với ?mode=developer trong quá trình phát triển (xóa đối với sản phẩm)
• Android: AndroidX WebKit 1.12.1+ (hoặc mới hơn) được bao gồm trong dự án
• Android: Kiểm tra tính năng thời gian chạy cho WebViewFeature.WEB_AUTHENTICATION
• Android: setWebAuthenticationSupport() được gọi với WEB_AUTHENTICATION_SUPPORT_FOR_APP
• Android: JavaScript được bật trong cài đặt WebView
• Android: Phiên bản APK WebView của người dùng hỗ trợ tính năng WebAuthn (sử dụng phát hiện tính năng, không phải phiên bản hệ điều hành)
• Conditional UI không được sử dụng (không được hỗ trợ trong Embedded WebView)
• Chuyển sang Chrome Custom Tabs nếu tính năng WebAuthn không khả dụng

• Kiểm tra xem người dùng có nhà cung cấp thông tin xác thực không mặc định đang hoạt động không (1Password, Bitwarden, v.v.)
• Xác minh nhà cung cấp có hỗ trợ passkey không (không phải tất cả các trình quản lý mật khẩu đều hỗ trợ)
• Kiểm tra với trình quản lý thông tin xác thực gốc của nền tảng (iCloud Keychain, Google Password Manager)

"NotAllowedError: The request is not allowed by the user agent or the platform in the current context"

• Thường có nghĩa là: Thiếu entitlements (iOS) hoặc tính năng WebView không khả dụng/bật (Android Embedded WebView)
• Kiểm tra: Cấu hình Associated Domains, khả năng truy cập tệp AASA, phiên bản WebKit, phát hiện tính năng, lệnh gọi setWebAuthenticationSupport()

Không có lời nhắc passkey xuất hiện

• Có thể có nghĩa là: AASA/assetlinks.json không tải được, loại WebView sai, tệp AASA được lưu trong bộ nhớ đệm
• Thử: Xác thực các tệp liên kết, sử dụng ?mode=developer trên iOS để kiểm thử, xác minh loại WebView

Để gỡ lỗi chi tiết, hãy xem bài viết của chúng tôi về Relying Party ID trong các ứng dụng gốc.

SDK Native của Corbado:

• iOS SDK (Swift)
• Android SDK (Kotlin)
• Gói Flutter

Tài liệu nền tảng:

• Apple: Hỗ trợ Passkey
• Google: Credential Manager

Công cụ xác thực:

• Trình xác thực AASA của Apple
• Trình tạo Digital Asset Links của Google