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

Bài viết này giải thích cách triển khai passkey trong các ứng dụng gốc (iOS + Android). Bạn sẽ tìm hiểu loại WebView nào được khuyến nghị cho việc xác thực bằng passkey.

Our mission is to make the Internet a safer place, and the new login standard passkeys provides a superior solution to achieve that. That's why we want to help you understand passkeys and its characteristics better.

1. Các lựa chọn triển khai Passkey trong ứng dụng gốc#

Xác thực là yếu tố cốt lõi, bảo vệ dữ liệu người dùng và đảm bảo các tương tác an toàn trong các ứng dụng gốc. Sự ra đời của passkey đã cách mạng hóa lĩnh vực này, cung cấp một cơ chế xác thực mạnh mẽ và thân thiện với người dùng. Có hai cách chính để tích hợp passkey vào ứng dụng gốc, thông qua triển khai native hoặc qua WebView. Trước tiên, hãy cùng xem xét và so sánh hai cách này.

1.1 Triển khai Native: Trải nghiệm người dùng tuyệt vời#

Triển khai native thường được xem là mang lại trải nghiệm người dùng tốt nhất trong một ứng dụng. Nó được đặc trưng bởi các tương tác người dùng mượt mà, tích hợp và liền mạch, được thiết kế chính xác cho môi trường của hệ điều hành, dù là iOS hay Android. Yêu cầu để có một triển khai 100% native là loại bỏ 100% mật khẩu và thực sự chỉ dùng passkey. Cách tiếp cận này giúp bạn thoát khỏi những phiền toái tiềm ẩn khi chuyển đổi giữa ứng dụng gốc và nội dung web (hiển thị qua WebView).

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

1.2 Triển khai WebView: Trải nghiệm giống trình duyệt#

Khi phát triển một ứng dụng gốc, con đường để đi hoàn toàn native không phải lúc nào cũng khả thi. Trong các trường hợp bạn vẫn cần hỗ trợ xác thực dựa trên mật khẩu sử dụng OAuth2, việc tích hợp hoàn toàn native có thể không thực hiện được, khiến việc triển khai WebView trở thành giải pháp thay thế duy nhất. WebView hoạt động như một cầu nối, nhúng nội dung web trực tiếp vào ứng dụng của bạn, cung cấp trải nghiệm người dùng giống như trình duyệt khi điều hướng qua các trang web. Điều này đặc biệt phù hợp nếu bạn là nhà cung cấp OAuth2, giải pháp xác thực cơ bản của bạn dựa trên OAuth2 hoặc nếu giải pháp đăng nhập của bạn sử dụng các phương thức đăng nhập mạng xã hội qua bên thứ ba, chẳng hạn như Google hoặc GitHub. Trong những trường hợp này, việc sử dụng WebView trở nên không thể tránh khỏi do nhu cầu tương tác với nội dung web và quản lý các luồng xác thực người dùng khác nhau, đặc biệt khi cần có các liên kết ứng dụng gốc.

Về cơ bản, trong khi triển khai native mang lại trải nghiệm người dùng mượt mà không gì sánh bằng, chúng không phải lúc nào cũng là một lựa chọn khả thi, đặc biệt khi kết hợp với các giải pháp xác thực dựa trên mật khẩu hoặc OAuth2. Mặt khác, việc triển khai WebView cung cấp một con đường linh hoạt, mặc dù kém liền mạch hơn một chút, để tích hợp nội dung web và quản lý xác thực người dùng trong ứng dụng của bạn, đảm bảo bạn có thể điều hướng sự phức tạp của các luồng xác thực khác nhau và đăng nhập của bên thứ ba.

Các phần tiếp theo của bài viết này tập trung vào việc triển khai qua WebView. Để tìm hiểu thêm về tích hợp passkey native, vui lòng xem tại đây.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

Hơn 10.000 nhà phát triển tin tưởng Corbado và làm cho Internet an toàn hơn với passkey. Có câu hỏi? Chúng tôi đã viết hơn 150 bài blog về passkey.

Tham gia Cộng đồng Passkeys

2. Tổng quan các tùy chọn WebView#

Khi điều hướng qua mê cung xác thực trong các ứng dụng gốc, các nhà phát triển và quản lý sản phẩm phải đối mặt với một quyết định quan trọng: triển khai xác thực passkey theo cách native hay qua WebView. Nếu quyết định chọn cách thứ hai, cả hai nền tảng iOS và Android đều cung cấp hai loại WebView riêng biệt, mỗi loại có các thuộc tính và trường hợp sử dụng tiềm năng riêng.

2.1 WebView trên iOS#

WKWebView
SFSafariViewController
SFAuthenticationSession / ASWebAuthenticationSession (được thiết kế đặc biệt cho các luồng xác thực dựa trên OAuth / OpenID Connect)

2.1 WebView trên Android#

WebView
Chrome Custom Tabs (CCT)

Trong các phần sau, chúng ta sẽ đi sâu hơn vào các loại WebView này và cuối cùng hướng dẫn bạn đưa ra quyết định sáng suốt về việc nên sử dụng WebView nào để xác thực bằng passkey trong các ứng dụng gốc của mình (nếu việc triển khai hoàn toàn native không phải là một giải pháp thay thế).

Subscribe to our Passkeys Substack for the latest news.

3. WebView trên iOS#

WebView trên iOS có thể là WKWebView hoặc SFSafariViewController (nếu làm việc với OAuth / OIDC, đó là SFAuthenticationSession / ASWebAuthenticationSession).

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

3.1 WKWebView#

WKWebView là một tùy chọn WebView mạnh mẽ và linh hoạt dành cho các nhà phát triển iOS. Được giới thiệu cùng với iOS 8, nó cho phép các nhà phát triển nhúng nội dung web trực tiếp vào ứng dụng, cung cấp một loạt các tùy chọn tùy chỉnh và cấu hình. WKWebView nổi tiếng về hiệu suất, sử dụng cùng một công cụ kết xuất web như Safari, và cung cấp một bộ API phong phú để tương tác với nội dung web, quản lý điều hướng, tương tác người dùng, và nhiều hơn nữa.

3.2 SFSafariViewController#

SFSafariViewController là một WebView cho phép các nhà phát triển tận dụng các khả năng của Safari trực tiếp trong ứng dụng của họ. Nó cung cấp một trải nghiệm người dùng liền mạch bằng cách sử dụng các cài đặt Safari của người dùng, chẳng hạn như mật khẩu đã lưu, passkey, cookie, và nhiều hơn nữa, đảm bảo việc duyệt web nhất quán, bởi vì nó thực sự chạy như một ứng dụng Safari. SFSafariViewController không tùy biến được như WKWebView nhưng cung cấp các tính năng bảo mật nâng cao và dễ sử dụng, làm cho nó trở thành một lựa chọn ưu tiên để hiển thị nội dung web đơn giản trong các ứng dụng.

	WKWebView	SFSafariViewController
Trải nghiệm người dùng	- Cảm giác gốc: Người dùng có thể cảm thấy nội dung web là một phần gốc của ứng dụng vì các nhà phát triển có thể tùy chỉnh giao diện để phù hợp với thiết kế của ứng dụng. - Tự động điền: Có thể tự động điền dữ liệu từ Safari	- Liền mạch: Trải nghiệm người dùng liền mạch sử dụng cài đặt Safari của người dùng, đảm bảo việc duyệt web nhất quán giữa ứng dụng gốc và trình duyệt.
Trải nghiệm nhà phát triển	- Tùy biến cao: Có sẵn nhiều tùy chỉnh và cấu hình - Linh hoạt: Nhiều API để tương tác với nội dung web	- Tùy biến trung bình: Các tùy chọn tùy chỉnh hạn chế, đặc biệt so với WKWebView, - Đơn giản: Dễ triển khai hơn so với WKWebView
Hiệu suất	- Khá chậm: Tùy thuộc vào việc triển khai và nội dung web, tốc độ tải có thể được tối ưu hóa, nhưng vẫn có thể chậm hơn so với SFSafariViewController do phải xử lý thêm các tính năng và tương tác tùy chỉnh.	- Khá nhanh: Thường cung cấp hiệu suất tốt hơn vì nó tận dụng công cụ Safari, được tối ưu hóa cho tốc độ và hiệu quả, cung cấp thời gian tải trang web nhanh.
Độ tin cậy và nhận diện	- Không yêu cầu hiển thị URL: WKWebView thường không hiển thị URL, khiến người dùng khó xác minh trang web hơn. Các ứng dụng độc hại có thể bắt chước hành vi này để lừa đảo thông tin đăng nhập.	- Trải nghiệm giống trình duyệt: Kết xuất các trang web bằng Safari, cung cấp trải nghiệm "giống như trình duyệt". Người dùng có thể thấy URL và truy cập các tính năng tự động điền của Safari, có khả năng tạo ra nhiều sự tin tưởng hơn do giao diện quen thuộc.
Sự cô lập	- Tách biệt: Cookie và session được tách biệt khỏi Safari; người dùng sẽ không tự động đăng nhập vào một WKWebView.	- Tách biệt: Cookie và session cũng được tách biệt khỏi Safari; người dùng cũng sẽ không tự động đăng nhập vào SFSafariViewController.
Lỗ hổng bảo mật	- An toàn: Vốn dĩ an toàn do cơ chế sandboxing ứng dụng của Apple, nhưng hành vi và bảo mật phụ thuộc vào việc triển khai của ứng dụng. Có thể có lỗ hổng nếu không được triển khai đúng cách.	- An toàn hơn: Hưởng lợi từ các tính năng bảo mật tích hợp của Safari, bao gồm cảnh báo chống lừa đảo và trang web độc hại. Thường được coi là an toàn hơn để hiển thị nội dung web so với WKWebView do các tính năng này và sự quen thuộc của người dùng với Safari.
Khác	- Tính năng không khả dụng: Một số tính năng của trình duyệt (ví dụ: WebAuthn) có thể không truy cập được đầy đủ do các lo ngại về bảo mật và việc WKWebView chạy trong ngữ cảnh của ứng dụng. - Chèn JavaScript: Một số ứng dụng, ví dụ như TikTok, chèn JavaScript theo dõi vào WKWebView trong ứng dụng của họ, hoặc hạn chế quyền kiểm soát của người dùng (ví dụ: Facebook) - Vấn đề riêng tư: Có nhiều phản hồi từ cộng đồng về quyền riêng tư	- Không chèn JavaScript: Không cho phép thực thi JavaScript từ ứng dụng, tăng cường bảo mật và quyền riêng tư. Nó cũng không hỗ trợ các cảnh báo hoặc xác nhận JavaScript, có khả năng ảnh hưởng đến trải nghiệm người dùng trên một số trang web. - Chế độ đọc: Cung cấp chế độ đọc cho phiên bản sạch, dễ đọc của các bài báo.

3.3 SFAuthenticationSession / ASWebAuthenticationSession#

SFAuthenticationSession và ASWebAuthenticationSession là các WebView được thiết kế đặc biệt cho các luồng xác thực dựa trên OAuth / OpenID Connect. Chúng cung cấp một không gian an toàn và cô lập để xác thực người dùng, bảo vệ thông tin đăng nhập của người dùng và đảm bảo rằng thông tin cá nhân không vô tình bị chia sẻ với ứng dụng. Các session này chia sẻ cookie và dữ liệu trang web với Safari, mang lại trải nghiệm người dùng nhất quán và liền mạch, đặc biệt là trong các quy trình xác thực.

Ưu điểm:

Xác thực chuyên dụng: Được thiết kế đặc biệt cho các luồng xác thực dựa trên OAuth / OpenID Connect, đảm bảo một quy trình xác thực được sắp xếp hợp lý.
Bảo vệ quyền riêng tư: Đảm bảo quyền riêng tư dữ liệu người dùng bằng cách không chia sẻ cookie hoặc dữ liệu trang web với ứng dụng.
Hỗ trợ SSO: Hỗ trợ Đăng nhập một lần (Single Sign-On), mang lại trải nghiệm người dùng tiện lợi.

Nhược điểm:

Trường hợp sử dụng hạn chế: Chủ yếu tập trung vào xác thực OAuth / OpenID Connect, có thể không phù hợp với tất cả các trường hợp sử dụng.

Khi nhiệm vụ chính là xác thực người dùng, đặc biệt là khi triển khai SSO hoặc tương tác với các nhà cung cấp OAuth, bạn nên sử dụng SFAuthenticationSession / ASWebAuthenticationSession thay vì SFSafariViewController.

Want to find out how many people use passkeys?

View Adoption Data

4. WebView trên Android#

WebView trên Android có thể là WebView hoặc Chrome Custom Tabs (CCT). Để kiểm tra các hành vi WebView khác nhau trên Android, chúng tôi đề xuất ứng dụng WebView vs Chrome Custom Tabs.

4.1 Android WebView#

WebView trên Android là một thành phần toàn diện cho phép các nhà phát triển hiển thị nội dung web như một phần của giao diện người dùng ứng dụng. Nó rất linh hoạt, cung cấp một loạt các tùy chọn tùy chỉnh và mang lại cho các nhà phát triển sự linh hoạt để cấu hình WebView cho phù hợp với các nhu cầu khác nhau. WebView cung cấp một bộ API phong phú để tương tác với nội dung web, quản lý tương tác người dùng, và thậm chí xử lý các hộp thoại JavaScript, chứng chỉ máy khách và yêu cầu quyền.

4.2 Chrome Custom Tabs (CCT)#

Chrome Custom Tabs (CCT) cung cấp một cách liền mạch, an toàn và hiệu quả để tích hợp nội dung web trực tiếp vào ứng dụng của bạn. Bằng cách tận dụng các khả năng và tính năng bảo mật của Chrome, CCT mang lại trải nghiệm người dùng vừa nhất quán vừa có hiệu suất cao.

CCT là một thành phần của trình duyệt Chrome, được thiết kế để tích hợp với framework Android, cho phép các ứng dụng mở nội dung web trong một tiến trình nhẹ, chuyên dụng. Đáng chú ý, nó mở nhanh hơn một trình duyệt thông thường và khi được tải trước thông qua lệnh gọi warm-up, nó có khả năng vượt trội hơn một WebView. Mặc dù nó thực thi JavaScript, nó hoạt động trong tiến trình riêng của mình, bảo vệ các ứng dụng khỏi việc chạy mã độc. Hơn nữa, giao diện người dùng của CCT cung cấp một thanh hành động, hiển thị URL và một biểu tượng khóa xác minh SSL cho các trang an toàn, qua đó trấn an người dùng về tính xác thực và bảo mật của trang đang được tải.

Nói chung, có thể nói rằng iOS WKWebView và Android WebView, cũng như SFSafariViewController và Chrome Custom Tabs (CCT) là tương tự nhau.

Tính năng	WebView	Chrome Custom Tab
Trải nghiệm người dùng	- Linh hoạt: Cung cấp một bộ API phong phú để tương tác với nội dung web và quản lý tương tác người dùng, bao gồm xử lý các hộp thoại JavaScript và yêu cầu quyền. - Tính nhất quán: Việc quản lý một trải nghiệm người dùng nhất quán, đặc biệt với nội dung web đa dạng, có thể là một thách thức.	- Tính năng trình duyệt: Chia sẻ các tính năng như Trình tiết kiệm dữ liệu và Tự động hoàn thành được đồng bộ hóa trên các thiết bị. - Nút Quay lại: Cho phép người dùng dễ dàng quay lại ứng dụng với một nút quay lại tích hợp. - Phụ thuộc: Dựa vào ứng dụng Chrome, có thể không có sẵn hoặc không được cập nhật trên tất cả các thiết bị của người dùng - Chuyển hướng đến Trình duyệt: Một số chức năng nhất định có thể chuyển hướng người dùng đến ứng dụng Chrome, có khả năng làm gián đoạn trải nghiệm người dùng. - Partial Custom Tabs: Chỉ một phần của màn hình có thể được sử dụng cho Chrome Custom Tab trong khi phần còn lại hiển thị ứng dụng gốc - Side-sheet: Ở chế độ ngang và trên các thiết bị màn hình lớn, Chrome Custom Tab chỉ được hiển thị ở một bên của màn hình, trong khi phần còn lại của màn hình hiển thị ứng dụng gốc
Trải nghiệm nhà phát triển	- Tùy biến cao: Cung cấp các tùy chọn/nhu cầu tùy chỉnh rộng rãi. - Tương tác: Cung cấp nhiều API để tương tác với nội dung web và quản lý tương tác người dùng.	- Tùy biến được: Cho phép tùy chỉnh màu thanh công cụ, nút hành động, thanh công cụ dưới cùng, các mục menu tùy chỉnh và hoạt ảnh vào/ra. - Callback: Gửi một callback đến ứng dụng khi có một điều hướng bên ngoài. - Tính năng bảo mật: Cung cấp các tính năng sẵn có, loại bỏ nhu cầu quản lý yêu cầu, cấp quyền hoặc kho cookie.
Hiệu suất	- Hiệu suất trung bình: Có thể không cung cấp cùng mức hiệu suất như Chrome Custom Tabs (CCT)	- Làm nóng trước (Pre-Warming): Bao gồm việc làm nóng trước Trình duyệt trong nền và tải các URL một cách suy đoán để tăng tốc thời gian tải trang. - Ưu tiên: Ngăn chặn các ứng dụng khởi chạy Custom Tab bị loại bỏ trong quá trình sử dụng bằng cách nâng tầm quan trọng của nó lên mức "tiền cảnh".
Độ tin cậy và nhận diện	- URL & SSL không hiển thị: Thông tin URL và SSL không hiển thị mặc định trong WebView. Trừ khi nhà phát triển ứng dụng triển khai các tính năng này, người dùng sẽ không biết liệu họ đang ở trên trang web chính xác hay một trang web lừa đảo.	- URL & SSL hiển thị: Sử dụng trình duyệt Chrome thực tế để kết xuất các trang. Người dùng có thể thấy URL và chứng chỉ SSL (cho biết kết nối có an toàn hay không). Điều này có thể mang lại cho người dùng sự tự tin rằng họ không ở trên một trang web lừa đảo.
Sự cô lập	- Chạy trong tiến trình của ứng dụng: Nếu một ứng dụng có lỗ hổng cho phép thực thi mã độc, có nguy cơ WebView có thể bị xâm phạm. Tuy nhiên, WebView cũng nhận được các bản cập nhật, nhưng hành vi và bảo mật của nó có thể phụ thuộc nhiều hơn vào ứng dụng sử dụng nó. - Không chia sẻ Cookie / Session: Không chia sẻ cookie hoặc session với trình duyệt chính của thiết bị, cung cấp sự cô lập nhưng có thể yêu cầu người dùng đăng nhập lại.	- Chạy trong tiến trình của Chrome: Là một phần của Chrome, Custom Tabs chạy trong cùng một tiến trình và có cùng các bản cập nhật bảo mật và tính năng như Chrome. - Chia sẻ Cookie Jar và mô hình quyền: Đảm bảo người dùng không phải đăng nhập lại vào các trang web hoặc cấp lại quyền. - Cài đặt & Tùy chọn của Chrome: Sử dụng các cài đặt và tùy chọn của Chrome.
Lỗ hổng bảo mật	- Callback để đánh cắp thông tin đăng nhập: Các lỗ hổng tiềm ẩn bao gồm việc đôi khi cần có JavaScript, điều này mở ra cánh cửa cho các ứng dụng khác chạy mã độc, chẳng hạn như đăng ký các callback cố gắng chặn tên người dùng và mật khẩu. - Lừa đảo (Phishing): Ngoài ra, một ứng dụng độc hại có thể mở một trang web khác bắt chước luồng Link trong một nỗ lực lừa đảo.	- Google Safe Browsing: Sử dụng tính năng Duyệt web an toàn của Google để bảo vệ cả người dùng và thiết bị khỏi các trang web nguy hiểm. - Trang trí trình duyệt an toàn: Đảm bảo người dùng luôn thấy chính xác URL mà họ đang tương tác và có thể xem thông tin chứng chỉ của trang web, giảm nguy cơ lừa đảo. Hơn nữa, các tab tùy chỉnh không cho phép chèn JavaScript.
Khác	- Google đã cấm WebView để đăng nhập người dùng vào tài khoản Google

5. Khuyến nghị triển khai Passkey trong ứng dụng gốc#

Khách hàng của chúng tôi liên tục hỏi về cách triển khai passkey trong các ứng dụng gốc. Phần lớn những khách hàng này có thể được chia thành các nhóm khác nhau:

Nhóm A:

Khách hàng bắt đầu xây dựng ứng dụng gốc của họ từ đầu và có thể sử dụng trực tiếp xác thực không mật khẩu của chúng tôi (không tồn tại mật khẩu cũ).

Nhóm B:

Khách hàng có người dùng hiện tại và một giải pháp xác thực hiện có. Thường thì họ cũng đã có một ứng dụng web hiện có cũng cần thêm passkey vào quy trình xác thực của nó. Ở đây, nhiều công ty quyết định thực hiện một quy trình hai bước:

Thêm passkey vào luồng xác thực WebView hiện có của bạn (đó là cách Google và GitHub đã triển khai nó trong các ứng dụng gốc của họ)
Thêm passkey thông qua triển khai native lên trên. Việc triển khai passkey native này sẽ kiểm tra trước WebView cũ (ví dụ: cho đăng nhập mạng xã hội và mật khẩu) xem người dùng có thể đăng nhập bằng passkey hay không (đó là cách KAYAK đã triển khai nó trong ứng dụng gốc của họ).

Xác định nhóm của bạn

Để cung cấp cho người dùng của bạn việc triển khai passkey tốt nhất trong một ứng dụng gốc, bạn cần quyết định mình thuộc nhóm nào, dựa trên thiết lập kỹ thuật hiện tại của bạn và cách bạn muốn thúc đẩy passkey (câu hỏi này có liên quan đến các công ty trong nhóm B).

Khuyến nghị cho Nhóm A: Triển khai Native

Nếu bạn đang xây dựng một ứng dụng hoàn toàn mới (nhóm A), chúng tôi khuyên bạn nên đi theo hướng triển khai passkey native và hoàn toàn không dùng mật khẩu ngay từ đầu (do đó không sử dụng bất kỳ loại WebView nào). Vui lòng sử dụng các SDK & API gốc cho iOS và Android (ví dụ: thông qua gói passkeys Flutter). Vui lòng đọc thêm bài viết này về ID Bên Tin cậy (Relying Party ID).

Khuyến nghị cho Nhóm B: Đầu tiên là WebView, sau đó là Triển khai Native

Nếu bạn không thể triển khai passkey native ngay hôm nay vì bất kỳ lý do gì (nhóm B), bạn có thể bắt đầu với việc triển khai WebView và sau đó trong tương lai chuyển sang triển khai passkey native (điều này hoạt động thông qua việc tạo các tệp liên kết, như apple-app-site-association cho ứng dụng iOS và assetlinks.json cho ứng dụng Android). Lý do để đi theo hướng triển khai WebView có thể bao gồm:

Bạn đã cung cấp xác thực dựa trên OAuth2 và muốn tiếp tục cung cấp nó cho người dùng của mình (OAuth2 không hoạt động native, xem tiêu chuẩn tại đây)
Bạn muốn cung cấp xác thực passkey trong cùng một cửa sổ / màn hình, nơi bạn cung cấp các phương thức xác thực khác của mình (ví dụ: mật khẩu, đăng nhập mạng xã hội, OAuth2)

Đây là cách mà Google hoặc GitHub hiện đang triển khai xác thực passkey trong các ứng dụng gốc của họ. Vui lòng xem khuyến nghị dưới đây để thiết lập WebView một cách chính xác cho việc xác thực bằng passkey. Tuy nhiên, chúng tôi khuyên bạn nên xem xét việc triển khai passkey native như KAYAK đã làm và bắt đầu trực tiếp với bước 2.

Nếu bạn thuộc nhóm B và không thể triển khai passkey native, khuyến nghị của chúng tôi nghiêng về việc sử dụng SFAuthenticationSession / ASWebAuthenticationSession cho iOS và Chrome Custom Tabs cho Android (nếu không thì passkey cũng sẽ không hoạt động).

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Sau đây, chúng tôi nêu lý do cho khuyến nghị này:

SFAuthenticationSession / ASWebAuthenticationSession chia sẻ cookie và dữ liệu trang web với Safari, mang lại trải nghiệm người dùng liền mạch trong các quy trình xác thực. Điều tương tự cũng áp dụng cho Chrome Custom Tabs trên Android.

Người dùng được hưởng lợi từ mật khẩu đã lưu, dữ liệu tự động điền và các thông tin được lưu trữ khác trong trình duyệt, giúp quá trình xác thực mượt mà và nhanh chóng hơn.

5.2 Bảo mật nâng cao#

SFAuthenticationSession / ASWebAuthenticationSession trên iOS và Chrome Custom Tabs trên Android cung cấp một không gian an toàn và cô lập để xác thực người dùng, đảm bảo rằng thông tin đăng nhập nhạy cảm của người dùng được bảo vệ và không vô tình bị chia sẻ với ứng dụng hoặc các trang web khác.

Chúng tuân thủ các giao thức bảo mật nghiêm ngặt của Apple và Google, đảm bảo rằng dữ liệu người dùng được xử lý an toàn và quyền riêng tư được duy trì.

Hơn nữa, lựa chọn thiết kế này được hưởng lợi từ các bản cập nhật và cải tiến bảo mật liên tục của Safari và Chrome, đảm bảo rằng nó tuân thủ các tiêu chuẩn và giao thức bảo mật mới nhất.

5.3 Trải nghiệm người dùng#

SFAuthenticationSession / ASWebAuthenticationSession trên iOS và Chrome Custom Tabs trên Android cung cấp một giao diện người dùng nhất quán và quen thuộc, vì người dùng đã quen với trải nghiệm người dùng của trình duyệt. Bên cạnh đó, các cài đặt và tùy chọn người dùng của Safari và Chrome cũng được áp dụng.

Nó cung cấp một sự chuyển đổi mượt mà giữa nội dung ứng dụng và nội dung web, đảm bảo rằng người dùng không bị gián đoạn bởi sự thay đổi giữa các giao diện.

5.4 Hiệu suất#

Chrome Custom Tabs tận dụng hiệu suất của Chrome, đảm bảo trải nghiệm người dùng mượt mà và phản hồi nhanh, điều này đặc biệt quan trọng trong các quy trình xác thực để ngăn chặn sự thất vọng hoặc từ bỏ của người dùng.

Hiệu suất của CCT thường vượt trội so với các tùy chọn Android WebView (tương tự với SFAuthenticationSession / ASWebAuthenticationSession trên iOS), đảm bảo rằng nội dung web và các luồng xác thực được xử lý nhanh chóng và mượt mà.

Hãy xem thêm so sánh này của Google để cảm nhận sự khác biệt về hiệu suất giữa Chrome Custom Tabs, Android WebView và trình duyệt Chrome tiêu chuẩn.

5.5 Dành riêng cho luồng xác thực#

SFAuthenticationSession / ASWebAuthenticationSession được thiết kế đặc biệt để xử lý các luồng xác thực dựa trên OAuth / OpenID Connect, đảm bảo một quy trình được sắp xếp hợp lý và an toàn cho các giao thức xác thực được sử dụng rộng rãi này. Đây cũng là cách được khuyến nghị cho xác thực WebAuthn / passkey.

Trên Android, không có lớp chuyên dụng cho các luồng xác thực nhưng hành vi tương tự có thể được triển khai với Chrome Custom Tabs và Android App Links.

Hơn nữa, chúng tôi kỳ vọng sẽ có nhiều ứng dụng giới thiệu passkey như TikTok bằng cách chỉ thu thập chúng khi người dùng đã được xác thực. Điều này có thể được thực hiện native (triển khai của TikTok) hoặc thông qua triển khai WebView. Một cách tiếp cận phù hợp là kích hoạt Giao diện người dùng có điều kiện (Conditional UI) một cách native. Nếu không hoạt động, bạn sẽ hiển thị triển khai WebView.

6. Kết luận#

Trong bối cảnh xác thực kỹ thuật số hiện đại, việc triển khai passkey qua WebView trong các ứng dụng gốc nổi lên như một ngọn hải đăng của thực tiễn an toàn và thân thiện với người dùng. Mặc dù hành trình lựa chọn WebView tối ưu có thể phức tạp, nhưng điều cốt yếu là phải điều chỉnh các lựa chọn công nghệ phù hợp với trải nghiệm người dùng và bảo mật.