Tại sao WebView trong ứng dụng di động lại là một thách thức đối với passkey?

Tại sao WebView trong ứng dụng di động lại là một thách thức đối với passkey?#

WebViews, thường được sử dụng trong các ứng dụng di động để hiển thị nội dung web, đặt ra những thách thức độc đáo khi triển khai passkey. Những thách thức này bắt nguồn từ việc hỗ trợ hạn chế cho các tính năng WebAuthn trong nhiều môi trường WebView.

Những thách thức chính của WebView đối với Passkey#

1. Hỗ trợ WebAuthn hạn chế#

• Nhiều WebViews thiếu hỗ trợ đầy đủ cho các API WebAuthn, gây khó khăn cho việc kích hoạt chức năng passkey.
• Các trình duyệt gốc (native browsers) như Chrome hoặc Safari thường sẵn sàng cho passkey hơn so với WebViews. Thay vào đó, chúng ta có thể triển khai passkey gốc trong ứng dụng iOS hoặc Android.

2. Triển khai không nhất quán#

Khả năng của WebView thay đổi tùy theo nền tảng và phiên bản:

• WKWebView trên iOS hỗ trợ tốt hơn nhưng vẫn có thể thiếu các tính năng WebAuthn quan trọng.
• Việc triển khai WebView trên Android thường kém nhất quán hơn và có thể yêu cầu cấu hình tùy chỉnh.

3. Hạn chế về bảo mật#

• WebViews thường có môi trường hạn chế quyền truy cập vào authenticator (trình xác thực) cục bộ, chẳng hạn như Face ID, Touch ID hoặc các tính năng sinh trắc học tương đương trên Android.
• Điều này có thể ngăn cản việc tạo passkey (passkey creation) hoặc sử dụng chúng một cách mượt mà trong ứng dụng.

4. Vấn đề về trải nghiệm người dùng#

Nếu passkey không hoạt động trong WebViews, người dùng có thể phải chuyển sang trình duyệt hoặc ứng dụng bên ngoài để xác thực, làm gián đoạn luồng đăng nhập. Thông thường, trải nghiệm UX của passkey tốt nhất đạt được khi sử dụng triển khai passkey gốc trong framework phát triển ứng dụng iOS hoặc Android tương ứng (ví dụ: Kotlin, Swift).

Chiến lược giải quyết thách thức của WebView#

1. Kiểm tra khả năng tương thích của WebView:
   • Sử dụng dữ liệu từ State of Passkeys để xác định các hạn chế của WebView.
   • Đánh giá các loại WebView cụ thể (ví dụ: WKWebView so với Android WebView) được sử dụng trong ứng dụng của bạn.

2. Các tùy chọn dự phòng (Fallback):

   • Chuyển hướng người dùng đến trình duyệt gốc để xác thực nếu WebView hỗ trợ không đủ.
   • Duy trì các phương pháp MFA thay thế trong giai đoạn chuyển tiếp.

3. Khuyến khích triển khai Native: Khi có thể, hãy sử dụng các thành phần ứng dụng gốc (native app) cho chức năng passkey thay vì phụ thuộc vào WebViews.

4. Làm việc với các nhà cung cấp: Hợp tác với các nhà cung cấp WebView và nền tảng để thúc đẩy việc hỗ trợ WebAuthn tốt hơn trong các bản cập nhật tương lai.

Kết luận#

WebViews đặt ra những thách thức đáng kể đối với passkey do hỗ trợ WebAuthn hạn chế và các ràng buộc về bảo mật. Bằng cách hiểu rõ những hạn chế này và áp dụng các chiến lược như tùy chọn dự phòng và các thành phần ứng dụng gốc (native app), chúng ta có thể đảm bảo quá trình triển khai passkey diễn ra suôn sẻ hơn.

Đọc toàn bộ bài viết#

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 →