---
url: 'https://www.corbado.com/vi/blog/passkey-fallback-recovery'
title: 'Dự phòng & Khôi phục Passkey: Phương pháp Ưu tiên Định danh'
description: 'Đọc hướng dẫn dành cho người quản lý sản phẩm / nhà phát triển của chúng tôi về các chiến lược dự phòng và khôi phục cho xác thực dựa trên passkey, đảm bảo quyền truy cập an toàn và liền mạch cho người dùng.'
lang: 'vi'
author: 'Vincent Delitz'
date: '2026-05-24T16:10:54.456Z'
lastModified: '2026-05-24T16:16:25.702Z'
keywords: 'khôi phục passkey, dự phòng passkey'
category: 'Passkeys Strategy'
---

# Dự phòng & Khôi phục Passkey: Phương pháp Ưu tiên Định danh

## Key Facts

- Gần 95% thiết bị đã sẵn sàng cho passkey, tuy nhiên các **chiến lược dự phòng và khôi phục** hiệu quả vẫn rất cần thiết cho các tình huống mà passkey không thể truy cập hoặc bị mất.
- **Phương pháp Ưu tiên Định danh** tự động xác định tính khả dụng của passkey sau khi người dùng nhập định danh của họ, loại bỏ việc người dùng phải tự đưa ra quyết định và tránh các trạng thái lỗi ngõ cụt gây nhầm lẫn.
- **Passkey được đồng bộ hóa** ít bị mất hơn so với số điện thoại di động, làm cho chi phí khôi phục passkey được đồng bộ hóa trên đám mây thấp hơn so với việc khôi phục MFA dựa trên SMS OTP truyền thống trong khoảng thời gian 36 tháng.
- **Xác thực bằng ảnh tự sướng với kiểm tra thực thể sống** cho phép khôi phục MFA thông minh đối với các ngành bị quản lý, xác minh sự hiện diện vật lý và khớp người dùng với ID được chụp ảnh để ngăn chặn gian lận.

## 1. Giới thiệu

Passkey đã phát triển thành một sự thay thế thực sự cho các phương pháp xác thực truyền thống, với [gần 95% thiết bị sẵn sàng cho passkey](https://state-of-passkeys.io/). Tuy nhiên, ngay cả những hệ thống tiên tiến nhất cũng yêu cầu các chiến lược dự phòng (Fallback) và khôi phục (Recovery) hiệu quả để giải quyết các tình huống mà passkey không thể truy cập được hoặc thậm chí bị mất. Hướng dẫn này nhằm khám phá các tình huống khác nhau nơi việc dự phòng và khôi phục là cần thiết và thảo luận về các giải pháp khả thi trông như thế nào.

Khi nghĩ về các phương pháp dự phòng & khôi phục, điều quan trọng là sức mạnh của chúng phải tương đương với phương pháp xác thực chính. Hướng dẫn này sẽ phân biệt giữa các cách sử dụng passkey khác nhau, đặc biệt tập trung vào các bối cảnh nơi passkey được sử dụng như một MFA độc lập, để điều chỉnh các phương pháp dự phòng và khôi phục một cách thích hợp.

**Những Câu Hỏi Chính:**

- **Có Những Tình Huống Dự Phòng Nào?** Những tình huống dự phòng tiềm ẩn nào có thể xảy ra với hệ thống passkey, và chúng nên được xử lý như thế nào để duy trì bảo mật?
- **Khôi Phục Nên Được Xử Lý Như Thế Nào?** Tùy thuộc vào các kiểu sử dụng passkey, đặc biệt là trong các môi trường sử dụng MFA, quá trình khôi phục nên được thiết kế như thế nào để đảm bảo chúng an toàn?

Thông qua việc khám phá những câu hỏi này, hướng dẫn này sẽ cung cấp cho các nhà quản lý sản phẩm và nhà phát triển những hiểu biết cần thiết để thiết kế, triển khai và quản lý các hệ thống passkey một cách hiệu quả, đảm bảo rằng bảo mật không làm ảnh hưởng đến trải nghiệm người dùng.

## 2. Định nghĩa: Định danh, Mức độ Bảo mật & Dự phòng & Khôi phục

Trước khi đi sâu vào các chiến lược dự phòng và khôi phục, điều quan trọng là phải thiết lập một sự hiểu biết rõ ràng về một số thuật ngữ nền tảng mà chúng ta sẽ sử dụng.

### 2.1 Định danh: Email, Số điện thoại và Tên người dùng

Trong hầu hết các hệ thống doanh nghiệp và người tiêu dùng, việc xác thực dựa trên ba định danh chính: **email**, **số điện thoại**, và **tên người dùng**.

Phần lớn các hệ thống sử dụng **email** làm định danh chính, đặc biệt là trong các ứng dụng web. Tuy nhiên, các nền tảng ưu tiên thiết bị di động hoặc ưu tiên ứng dụng thường thích sử dụng **số điện thoại** làm định danh do sự dễ dàng trong việc điền trước một OTP (Mã Số Dùng Một Lần) dựa trên SMS, có thể được chèn tự động. Trong một số trường hợp, người dùng cũng có thể được yêu cầu thiết lập **tên người dùng** bên cạnh các định danh này, chủ yếu đối với các nền tảng yêu cầu một tên hiển thị duy nhất. Cũng có một xu hướng ngày càng tăng, đặc biệt trên các nền tảng lớn hơn, cho phép sử dụng cả **email** và **số điện thoại** để tăng thêm tính linh hoạt.

Trong quá trình đăng ký ban đầu, các định danh này thường được xác minh thông qua một liên kết xác nhận / OTP (đối với **email**) hoặc một OTP (đối với **số điện thoại**), đảm bảo rằng định danh thuộc về đúng người. Trong trường hợp bị mất quyền truy cập, việc chứng minh quyền kiểm soát đối với **email** hoặc **số điện thoại** đã được xác minh trước đó thường là đủ để khôi phục quyền truy cập tài khoản. Vì các định danh này là những hình thức giao tiếp đáng tin cậy nhất với người dùng, **số điện thoại** thường được thu thập cho các mục đích MFA (Xác thực Đa Yếu tố), với SMS là yếu tố thứ hai được sử dụng phổ biến.

**Tên người dùng** thường được sử dụng để cung cấp một lớp nhận dạng người dùng bổ sung trong các hệ thống yêu cầu các định danh công khai, chẳng hạn như mạng xã hội, diễn đàn hoặc một số nền tảng chuyên nghiệp. Mặc dù chúng không đóng vai trò chức năng trong xác thực giống như **email** hoặc **số điện thoại**, tên người dùng cung cấp cho người dùng một danh tính dễ nhận biết trong các bối cảnh công khai hoặc ngang hàng. Tuy nhiên, chúng đưa ra thêm một sự phức tạp vì người dùng thường có thể quên chúng, và trong hầu hết các trường hợp, một định danh khác được yêu cầu cùng với tên người dùng. Do đó, trong bài viết này, chúng tôi sẽ không tập trung vào tên người dùng.

Các tùy chọn 2FA khác, chẳng hạn như ứng dụng xác thực (tạo mã TOTP), không dựa trên định danh nhưng thường phức tạp hơn để thiết lập đối với người dùng trung bình. **Passkey** cũng đã giới thiệu khả năng làm việc mà không cần định danh (xác thực không cần tên người dùng), một tính năng ngày càng trở nên phổ biến trong không gian tiền điện tử. Tuy nhiên, đối với cả giải pháp dành cho người tiêu dùng và doanh nghiệp, nhu cầu giao tiếp với người dùng (thường qua **email**) cho các mục đích dự phòng hoặc khôi phục khiến các hệ thống không cần tên người dùng trở nên kém thực tế hơn.

### 2.2 Mức độ Bảo mật: Xác thực Đơn Yếu tố (SFA) & Xác thực Đa Yếu tố (MFA)

Hệ thống **Xác thực Đơn Yếu tố (SFA)** là những hệ thống dựa trên một hình thức xác thực duy nhất để xác minh danh tính của người dùng. Thông thường, yếu tố duy nhất này là mật khẩu, nhưng nó cũng có thể là đăng nhập qua mạng xã hội, OTP qua email hoặc bất kỳ phương pháp nào chỉ yêu cầu một loại bằng chứng. Hầu hết các hệ thống trên web ngày nay là hệ thống SFA. Tuy nhiên, có một sự đánh đổi nổi tiếng với bảo mật. Khi tích hợp passkey, chúng thường đóng vai trò như một phần bổ sung hoặc thay thế cho mật khẩu truyền thống, nâng cao sự tiện lợi của hệ thống. Thông thường đối với các hệ thống như vậy, việc vẫn cho phép các tùy chọn dự phòng như OTP qua email hoặc đăng nhập mạng xã hội sẽ cải thiện trải nghiệm người dùng bằng cách giảm thiểu mật khẩu nhưng không nâng cao mức độ bảo mật của hệ thống vượt qua SFA.

**Xác thực Đa Yếu tố (MFA)** bao gồm hai hoặc nhiều yếu tố độc lập để xác minh danh tính của người dùng; đây là điều làm cho nó an toàn hơn so với SFA. Các yếu tố này có thể bao gồm những gì người dùng biết (mật khẩu hoặc mã PIN), những gì người dùng có (một khóa bảo mật hoặc một ứng dụng trên điện thoại di động) và những gì người dùng là (xác minh sinh trắc học như dấu vân tay hoặc nhận dạng khuôn mặt). Các hệ thống MFA được thiết kế để bảo vệ chống lại các lỗ hổng cụ thể mà hệ thống SFA không thể phòng thủ, chẳng hạn như các cuộc tấn công lừa đảo hoặc vi phạm mật khẩu. Khi sử dụng passkey trong hệ thống MFA, chúng thường được tận dụng như một tùy chọn MFA độc lập. Trong những trường hợp này, điều quan trọng là bất kỳ phương pháp dự phòng hoặc khôi phục nào cũng phải duy trì cùng mức độ bảo mật như passkey.

### 2.3 Dự phòng & Khôi phục

**Dự phòng** (Fallback) được sử dụng trong tất cả các hệ thống nơi nhiều phương pháp xác thực cùng tồn tại. Chúng được sử dụng khi các phương pháp chính không khả dụng – thường thì người dùng có sự lựa chọn ngay từ đầu về cách đăng ký (ví dụ: đăng nhập mạng xã hội so với mật khẩu). Một phương án dự phòng có thể bao gồm các chiến lược xác thực thay thế như OTP qua email, mật khẩu, đăng nhập mạng xã hội với email phù hợp, thông báo đẩy ứng dụng gốc, mã QR, hoặc khóa bảo mật. Mỗi phương pháp dự phòng này đều khác nhau về chất lượng bảo mật, và việc lựa chọn phương án dự phòng thích hợp là rất quan trọng trong việc cân bằng sự tiện lợi của người dùng với các yêu cầu bảo mật.

Trong các môi trường sử dụng passkey như một phần của hệ thống Xác thực Đa Yếu tố (MFA), các phương pháp dự phòng này phải được xem xét cẩn thận để đảm bảo chúng cung cấp bảo mật đa yếu tố tương đương với passkey. Quá trình **Khôi phục** (Recovery) trở nên quan trọng khi người dùng mất quyền truy cập vào **tất cả các biện pháp xác thực đã thiết lập** đáp ứng các tiêu chuẩn bảo mật được yêu cầu (SFA hoặc MFA). Điều này ít nghiêm trọng hơn trong các hệ thống đơn yếu tố, nơi có thể có nhiều tùy chọn khôi phục, chẳng hạn như đặt lại mật khẩu thông qua OTP email, điều này xác nhận hiệu quả quyền kiểm soát của người dùng đối với một định danh liên kết. Tuy nhiên, việc khôi phục đặc biệt khó khăn trong các hệ thống 2FA/MFA vì các hệ thống này vốn dựa trên nhiều yếu tố để xác minh. Trong những tình huống người dùng chuyển đổi hệ điều hành di động – ví dụ: iPhone sang điện thoại Android - và mất các passkey được liên kết cùng số điện thoại - các yếu tố còn lại (ví dụ: chỉ có mật khẩu) không thể đáp ứng các yêu cầu 2FA. Việc khôi phục trong những trường hợp này có thể cần phải tạo ra các bằng chứng danh tính mới, điều này có thể liên quan đến các yêu cầu hỗ trợ thủ công hoặc các giải pháp sáng tạo hơn mà chúng tôi sẽ đề cập sau.

## 3. Dự phòng Đăng nhập Passkey: Đăng nhập Passkey Thủ công so với Đăng nhập Passkey Tự động

**Khi triển khai một giải pháp passkey, một trong những quyết định đầu tiên cần thực hiện là phương pháp đăng nhập passkey**. Tùy thuộc vào trường hợp sử dụng, đăng nhập thủ công có thể đủ cho các nền tảng nhỏ hơn, nhưng đối với các công ty lớn hơn định hướng UX, một Phương pháp Ưu tiên Định danh được khuyến nghị, cung cấp đăng nhập passkey sau khi định danh chính (rất có thể là email) đã được nhập.

### 3.1 Đăng nhập Passkey Thủ công: Phương pháp Do người dùng Khởi xướng

![Đăng nhập passkey thủ công](https://www.corbado.com/website-assets/manual_passkey_login_ca7554d1ba.jpg)

#### 3.1.1 Phương pháp Do người dùng Khởi xướng là gì?

Trên các nền tảng nhỏ hơn hoặc các nền tảng không tập trung vào tỷ lệ đăng nhập passkey cao, phương pháp do người dùng khởi xướng bao gồm một nút "Đăng nhập bằng passkey" riêng biệt. Trong phương pháp này, **trách nhiệm** sử dụng passkey được đặt hoàn toàn vào người dùng. Sau khi thêm một passkey vào tài khoản của họ, người dùng phải nhớ nhấp vào "Đăng nhập bằng passkey" để đăng nhập bằng nó.

![Passkey trên mygov thủ công](https://www.corbado.com/website-assets/mygov_passkeys_manual_f5311f61e4.png)

Ảnh chụp màn hình hiển thị việc triển khai passkey của [https://my.gov.au](https://my.gov.au), sử dụng phương pháp đăng nhập passkey thủ công. Mặc dù phương pháp này dễ triển khai hơn vì hệ thống phụ trợ không cần xác định xem việc đăng nhập bằng passkey có khả thi hay không, nhưng nó thường dẫn đến tỷ lệ đăng nhập bằng passkey thấp hơn nhiều. Điều này là do nó phụ thuộc nhiều vào sự chủ động của người dùng, và người tiêu dùng có thể không nhớ hoặc không chắc chắn về nền tảng hoặc bộ nhớ đám mây nào lưu trữ passkey của họ. Phương pháp này bắt người dùng phải suy nghĩ. Hãy cùng xem xét những cơ hội dự phòng khả thi nào tồn tại với phương pháp này trong phần tiếp theo.

#### 3.1.2 Dự phòng

Dự phòng là điều cần thiết trong bất kỳ hệ thống nào mà ở đó có khả năng việc truy cập passkey bị thất bại. Trong phương pháp đăng nhập passkey thủ công, các hộp thoại và dự phòng không thể được quản lý riêng lẻ vì tất cả các tùy chọn đăng nhập được hiển thị cùng một lúc và passkey được chọn theo ý muốn của người dùng. Điều này dẫn đến một số thách thức:

- **Lỗi không trực quan:** Các thông báo lỗi mà người dùng gặp phải khi passkey không khả dụng hoặc được thiết lập không chính xác thường không rõ ràng và có thể gây nhầm lẫn. Người dùng có thể không hiểu tại sao họ không thể sử dụng passkey hoặc điều gì đã xảy ra sai sót, dẫn đến sự thất vọng.
- **Ngõ cụt:** Người dùng có thể thấy mình ở trong ngõ cụt nơi họ không thể tiến lên. Nếu passkey bị thiếu hoặc không thể truy cập, người dùng có thể không được hướng dẫn rõ ràng về cách tiếp tục hoặc khôi phục quyền truy cập, khiến họ từ bỏ quá trình đăng nhập.
- **Không hướng dẫn:** Trong những tình huống này, hệ thống không thể cung cấp các hướng dẫn hữu ích để dẫn dắt người dùng đến một phương pháp xác thực thay thế. Người dùng bị bỏ lại để tự tìm cách giải quyết vấn đề, điều này làm giảm trải nghiệm người dùng.

![Lỗi passkey trên mygov](https://www.corbado.com/website-assets/mygov_passkey_errors_a31da4283e.png)

Ví dụ trên cho thấy, các thông báo lỗi trên Windows 11 gây nhầm lẫn như thế nào khi passkey không được tìm thấy trên nền tảng xác thực. Hệ thống có thể cho rằng passkey nằm trên một khóa bảo mật hoặc thiết bị khác. Quá trình này có thể gây nhầm lẫn cho những người dùng không quen thuộc với các luồng xác thực như vậy, đặc biệt nếu họ chưa từng sử dụng khóa bảo mật trước đây hoặc chưa bao giờ tạo passkey.

![Passkey trên mygov không tồn tại](https://www.corbado.com/website-assets/mygov_passkey_not_exists_be8a954d92.png)

**Nếu không tìm thấy passkey nào trên bộ xác thực nền tảng, hệ điều hành & trình duyệt giả định rằng chúng phải tồn tại ở nơi khác, dẫn đến sự nhầm lẫn hơn nữa nếu người dùng chưa tạo passkey.** Conditional UI có thể giúp ích bằng cách hiển thị các passkey hiện có, nhưng điều này chỉ hữu ích nếu passkey thực sự tồn tại. Để có trải nghiệm passkey tốt nhất, hệ thống phụ trợ nên quyết định xem có nên kích hoạt quá trình đăng nhập passkey hay không sau khi người dùng đã cung cấp định danh chính của họ.

### 3.2 Đăng nhập Passkey Tự động: Phương pháp Ưu tiên Định danh

![Đăng nhập passkey tự động](https://www.corbado.com/website-assets/automatic_passkey_login_4786c4413f.jpg)

#### 3.2.1 Phương pháp Ưu tiên Định danh là gì?

Trong phương pháp ưu tiên định danh, người dùng được nhắc cung cấp định danh chính của họ, chẳng hạn như email hoặc số điện thoại, trước khi hệ thống xác định xem việc đăng nhập bằng passkey có khả thi hay không. **Sau khi định danh được xác minh, hệ thống tự động đề xuất phương pháp đăng nhập phù hợp nhất, bao gồm cả passkey nếu chúng khả dụng & có thể truy cập được**. Phương pháp này thân thiện với người dùng hơn vì nó loại bỏ việc người dùng phải nhớ chọn tùy chọn "Đăng nhập bằng passkey" và nâng cao tỷ lệ chấp nhận bằng cách hợp lý hóa quy trình.

![Google đăng nhập ưu tiên định danh](https://www.corbado.com/website-assets/google_identifier_first_sign_in_4d53b85a52.png)_Đăng nhập Ưu tiên Định danh của Google_

![Google đăng nhập bằng passkey](https://www.corbado.com/website-assets/google_passkey_sign_in_df2e4978c5.png)_Đăng nhập Passkey của Google_

**Các ảnh chụp màn hình ở trên hiển thị hành vi đăng nhập của một đăng nhập Google cho một tài khoản có passkey được liên kết trên một thiết bị macOS.** Google cũng tuân theo phương pháp Ưu tiên Định danh và xác định rằng việc đăng nhập bằng passkey rất có thể sẽ khả thi:

1. **Hỗ trợ nền tảng Passkey:** Nền tảng cơ sở hỗ trợ bộ xác thực nền tảng do đó có thể thực hiện đăng nhập.
2. **Passkey có thể truy cập:** Passkey sẽ rất có khả năng có thể truy cập được trên máy khách này (macOS) vì nó đã được tạo trên một hệ thống macOS.

Do đó, quá trình đăng nhập passkey được tự động bắt đầu, hướng dẫn người dùng trải nghiệm tốt nhất có thể. Điều này tuân theo chiến lược "đừng bắt tôi phải suy nghĩ".

> Một thiết kế passkey và xác thực tốt không chuyển trách nhiệm sang cho người dùng mà đề xuất chiến lược xác thực tối ưu cho tài khoản cụ thể tùy thuộc vào môi trường của khách hàng.

#### 3.2.2 Thiếu Hỗ trợ Nền tảng Passkey hoặc Khả năng Truy cập Passkey

Hệ thống xác định xem việc đăng nhập passkey có khả thi hay không. Trong trường hợp:

- **Không có passkey nào tồn tại:** Người dùng chưa tạo một passkey nào cho tài khoản của họ
- **Passkey không thể truy cập:** Những passkey mà người dùng đã tạo ra rất có khả năng không có sẵn trên Client này (ví dụ: người dùng chỉ có một Passkey MacOS và bây giờ đang đăng nhập từ Windows).
- **Xác thực passkey không được hỗ trợ:** Client hiện tại không hỗ trợ bộ xác thực nền tảng và cũng rất không có khả năng hỗ trợ Xác thực Đa thiết bị qua mã QR

![Google đăng nhập không có conditional ui](https://www.corbado.com/website-assets/google_no_conditional_ui_sign_in_7e1fa02c4d.png)

quyết định sẽ là một lần đăng nhập passkey thành công là khó xảy ra và **do đó các tùy chọn dự phòng sẽ được cung cấp tự động mà không kích hoạt đăng nhập passkey**. Cách tiếp cận này thân thiện với người dùng hơn nhiều vì nó loại bỏ việc người dùng phải nhớ chọn tùy chọn "Đăng nhập bằng passkey", nâng cao tỷ lệ áp dụng bằng cách hợp lý hóa quy trình và tránh tình huống xấu nhất khi người dùng thấy ngõ cụt khó hiểu.

Trong ví dụ trên, quá trình đăng nhập dự phòng về mật khẩu và sau đó sẽ tiếp tục yêu cầu các yếu tố xác thực tiếp theo dựa trên trạng thái và bảo mật của tài khoản, bởi vì máy khách là thiết bị Windows 11, vốn không có khả năng truy cập vào passkey macOS. Tùy thuộc vào các yêu cầu bảo mật của hệ thống xác thực của bạn, bạn có toàn quyền kiểm soát phương pháp xác thực nào sẽ kích hoạt trong trường hợp như vậy (ví dụ: tùy chọn xác thực phi passkey thành công cuối cùng).

#### 3.2.3 Hủy bỏ Lễ Xác thực Passkey

Khi một người dùng gặp một màn hình xác thực trong quá trình đăng nhập web, họ có thể bị bất ngờ hoặc choáng ngợp, đặc biệt nếu đó là một trong những lần đầu tiên họ sử dụng xác thực dựa trên passkey. Điều này có thể dẫn đến việc người dùng hủy bỏ quy trình xác thực, không phải do lỗi, mà đơn giản vì họ không chắc chắn về những gì đang xảy ra. Việc lên kế hoạch cho hành vi này là rất quan trọng và coi lần hủy bỏ đầu tiên là một sự kiện bình thường chứ không phải là lỗi:

![Google hủy bỏ passkey lần đầu](https://www.corbado.com/website-assets/google_passkey_first_abort_9024d11904.png)

Màn hình hủy bỏ đầu tiên nên giải thích rõ ràng điều gì đang xảy ra một cách bình tĩnh và trấn an, khuyên người dùng nên thử lại quy trình (xem ví dụ của Google ở trên). Màn hình này nên được thiết kế để giảm thiểu sự lo lắng, coi việc hủy bỏ là một phần thông thường, được mong đợi trong trải nghiệm người dùng. Nhiều người dùng có thể hủy bỏ đơn giản vì họ không nhận ra màn hình xác thực hoặc không quen thuộc với quy trình. Do đó, việc thử lại nên là đề xuất mặc định.

Tuy nhiên, nếu **lần hủy bỏ thứ hai** xảy ra, tình huống nên được xử lý khác đi. Lần hủy bỏ thứ hai có thể chỉ ra rằng thực sự đã có lỗi xảy ra - cho dù đó là sự cố với bộ xác thực nền tảng, người dùng không thể tìm thấy passkey phù hợp, hoặc lỗi kỹ thuật trong lễ WebAuthn. Tại thời điểm này, hệ thống sẽ trình bày một màn hình khác giải thích rằng một sự cố đã xảy ra và gợi ý các tùy chọn dự phòng một cách rõ ràng hơn:

![Google hủy bỏ passkey lần hai](https://www.corbado.com/website-assets/google_passkey_second_abort_b0487ba1bc.png)

**Màn hình hủy bỏ thứ hai nên khuyến khích người dùng chuyển sang một phương pháp xác thực thay thế**. Nó sẽ đảm bảo người dùng vẫn có thể đăng nhập thành công mà không gây thêm sự thất vọng. Như chúng ta có thể thấy trên màn hình ở trên, Google vẫn gợi ý "Thử lại" nhưng đồng thời cho người dùng thấy rằng có lẽ đã có lỗi xảy ra.

### 3.3 So sánh Các Phương pháp Triển khai Passkey

Bảng sau đây giúp so sánh các phương pháp khác nhau bằng cách tóm tắt các đặc điểm quan trọng nhất:

![Bảng so sánh phương pháp triển khai passkey](https://www.corbado.com/website-assets/passkey_falback_comparison_table_1f62928641.jpg)

Các phương pháp tự làm thường tuân theo **Phương pháp Đăng nhập Passkey Thủ công** và dựa vào Conditional UI và việc người dùng chọn tham gia passkey, điều này dẫn đến tỷ lệ đăng nhập bằng passkey rất thấp và làm thất vọng người dùng. **Phương pháp Ưu tiên Định danh** yêu cầu thiết lập logic thiết bị được cân nhắc kỹ lưỡng dựa trên Conditional UI, đó là lúc Corbado có thể giúp bạn. Việc tự xây dựng logic thiết bị và [thông minh passkey](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) của riêng bạn không được khuyến nghị, vì bộ quy tắc này yêu cầu liên tục tinh chỉnh và điều chỉnh với các thiết bị mới, các chức năng WebAuthn & đồng bộ hóa đám mây mới (ví dụ: passkey GPM).

## 4. Khôi phục Passkey

**Khôi phục passkey là một khía cạnh quan trọng của việc duy trì bảo mật và trải nghiệm người dùng khi người dùng mất quyền truy cập vào passkey của họ.** Điều này đặc biệt quan trọng trong các hệ thống phụ thuộc vào MFA. Trong các trường hợp MFA, các quy trình khôi phục phải đảm bảo rằng bảo mật được duy trì trong khi cho phép người dùng giành lại quyền truy cập vào tài khoản của họ. Cách tiếp cận khôi phục phải được điều chỉnh dựa trên mức độ xác thực được sử dụng trong hệ thống.

### 4.1 Khôi phục Đơn Yếu tố và Khôi phục Đa Yếu tố

Để duy trì bảo mật trong các hệ thống SFA, việc khôi phục thường liên quan đến việc chứng minh quyền kiểm soát đối với một định danh như địa chỉ email hoặc số điện thoại di động.

- **OTP qua Email:** Một OTP được gửi đến địa chỉ email đã đăng ký của người dùng. Sau khi được xác minh, điều này cho phép người dùng giành lại quyền truy cập và tạo một passkey mới.
- **OTP qua SMS:** Tương tự như khôi phục qua email, một OTP được gửi đến số điện thoại di động đã đăng ký. Người dùng có thể sử dụng OTP này để giành lại quyền truy cập vào tài khoản của họ.

Mặc dù các phương pháp này đơn giản, nhưng chúng dựa vào việc giữ cho thông tin liên hệ của người dùng luôn được cập nhật. Do đó, điều cần thiết là thường xuyên nhắc nhở người dùng xác minh email và số điện thoại của họ trong các lần đăng nhập thường xuyên.

Trong các hệ thống **Xác thực Đa Yếu tố**, quá trình khôi phục trở nên phức tạp hơn. Vì MFA dựa trên nhiều yếu tố độc lập (ví dụ: passkey, đăng nhập mạng xã hội và OTP), người dùng không nên mất quyền truy cập chỉ vì một yếu tố (như passkey) không khả dụng.

- **Sử dụng các yếu tố thay thế:** Nếu passkey bị mất, người dùng có thể xác thực bằng hai yếu tố khác, chẳng hạn như mật khẩu + OTP SMS hoặc ứng dụng xác thực. Sau khi được xác thực, họ có thể tạo một passkey mới.
- **Sử dụng các passkey khác:** Trong trường hợp người dùng có các thiết bị khác chứa passkey, họ có thể sử dụng chúng để lấy lại quyền truy cập với các gợi ý thích hợp (ví dụ: yêu cầu sử dụng passkey từ iPhone).
- **Tạo passkey mới:** Sau khi xác thực bằng phương pháp khôi phục, người dùng nên được hướng dẫn tạo passkey mới để đảm bảo thiết lập MFA vẫn nguyên vẹn.

Đối với cả hệ thống SFA và MFA, điều cốt lõi là đảm bảo rằng các quá trình khôi phục diễn ra mạnh mẽ và an toàn trong khi giảm thiểu ma sát cho người dùng.

### 4.2 Khôi phục MFA Thông minh: Số hóa Chi phí Khôi phục MFA

Trong các hệ thống xử lý dữ liệu cá nhân nhạy cảm, các ngành công nghiệp bị quản lý hoặc [các dịch vụ của chính phủ](https://www.corbado.com/passkeys-for-public-sector), OTP email và OTP số điện thoại tiêu chuẩn có thể không phải lúc nào cũng đủ hoặc khả dụng để khôi phục. Trong những trường hợp như vậy, các cơ chế **khôi phục MFA thông minh** cung cấp các phương pháp nâng cao để khôi phục tài khoản nhằm duy trì các tiêu chuẩn bảo mật cao trong khi cung cấp cho người dùng một trải nghiệm liền mạch.

Một trong những phương pháp hiệu quả nhất là **xác thực bằng ảnh tự sướng với kiểm tra thực thể sống**. Quá trình này liên quan đến việc người dùng chụp ảnh giấy tờ tùy thân của họ. Ngoài ra, việc kiểm tra thực thể sống qua ảnh tự sướng đảm bảo rằng ảnh tự sướng đang được chụp trong thời gian thực, xác nhận rằng người dùng hiện diện vật lý & khớp với ID được chụp ảnh do đó ngăn chặn gian lận sử dụng hình ảnh tĩnh hoặc ID bị đánh cắp. Tùy thuộc vào công nghệ được sử dụng, kiểm tra thực thể sống được thực hiện bằng cách ghi lại một đoạn video ngắn trong đó khoảng cách đến camera được thay đổi hoặc đầu quay 180 độ (ví dụ: Apple Face ID).

Phương pháp này có thể đặc biệt hữu ích khi các phương pháp khôi phục truyền thống như email hoặc SMS OTP không có sẵn hoặc đã lỗi thời. Ví dụ, đây là một ví dụ về việc chụp ảnh tự sướng sau đó được tiếp nối bằng quy trình kiểm tra thực thể sống từ onfido:

![Kiểm tra thực thể sống onfido](https://www.corbado.com/website-assets/liveness_check_onfido_7109eb3d96.png)_Ví dụ: Xác thực Selfie với kiểm tra thực thể sống từ onfido_

- **Hệ thống chính phủ, các ngành công nghiệp được quản lý hoặc các dịch vụ thương mại lớn** có sẵn dữ liệu cá nhân có thể được sử dụng để xác minh thông tin có trên ID. Trong trường hợp ví dụ: ngày sinh không có sẵn, thông tin thu thập qua ID có thể được sử dụng làm yếu tố trong quá trình khôi phục thủ công.

Hơn nữa, các phương pháp **khôi phục thông minh** khác có thể bao gồm:

- **Khôi phục đa thiết bị:** Nếu người dùng có thiết bị thứ hai đáng tin cậy, họ có thể khôi phục tài khoản của mình bằng cách quét mã QR.
- **Môi trường đã biết:** Những người dùng vẫn còn quyền truy cập vào cùng một thiết bị mà họ đã sử dụng thành công trong quá khứ, có thể sử dụng việc cung cấp các yếu tố đảm bảo bổ sung bằng cách dùng thiết bị này và do đó đưa ra bằng chứng rằng họ đang hoạt động từ cùng một thiết bị, nhà cung cấp và vị trí để giúp cho quy trình khôi phục thủ công. Một cách tiếp cận mà Google sử dụng cho [Khôi phục Tài khoản Gmail](https://gmailaccountrecovery.blogspot.com/).
- **Digital Credentials API:** Với sự áp dụng ngày càng tăng của ví ID, xác minh trực tiếp thông qua API này được kỳ vọng sẽ đóng một vai trò ngày càng lớn trong việc khôi phục tài khoản an toàn và thân thiện với người dùng.

Các phương pháp khôi phục MFA thông minh hướng tới việc cung cấp cho người dùng những cách an toàn, trực quan để lấy lại quyền truy cập vào tài khoản của họ, đặc biệt khi xử lý các thông tin nhạy cảm cao hoặc bị quản lý. Những cách tiếp cận này đảm bảo rằng ngay cả trong những trường hợp các phương pháp truyền thống như khôi phục qua email hoặc điện thoại không có sẵn, người dùng vẫn có thể khôi phục quyền truy cập của họ một cách an toàn và hiệu quả. Khôi phục thông minh giúp giảm chi phí khôi phục MFA.

### 4.3 Tần suất Khôi phục MFA: Số điện thoại so với Passkey

Điều quan trọng cần ghi nhớ là vì các passkey được đồng bộ hóa trên đám mây, chi phí khôi phục MFA thấp hơn nhiều trong khoảng thời gian 36 tháng, vì việc thay đổi số điện thoại di động diễn ra thường xuyên hơn nhiều so với việc chuyển từ Apple sang Android hoặc ngược lại. Trong trường hợp đổi điện thoại hoặc đổi hợp đồng điện thoại, các passkey sẽ được khôi phục.

**Do đó, việc mất quyền truy cập vào các passkey được đồng bộ sẽ xảy ra ít thường xuyên hơn việc mất quyền truy cập vào số di động, vốn là nguyên nhân gây ra hầu hết những khó khăn trong khôi phục đối với các hệ thống MFA hướng tới người tiêu dùng truyền thống.**

Tuy nhiên, với lượng người dùng ngày càng tăng, những trường hợp như vậy vẫn gây ra chi phí hỗ trợ thủ công đáng kể và nên được xử lý bằng một giải pháp kỹ thuật số, điều mà chúng ta sẽ xem xét trong phần tiếp theo.

## 5. Khuyến nghị cho Người Quản lý Sản phẩm và Nhà Phát triển

Khi tích hợp passkey vào hệ thống xác thực của bạn, việc lập kế hoạch cẩn thận cho cả các tùy chọn dự phòng và chiến lược khôi phục là rất quan trọng để duy trì mức độ bảo mật cao trong khi vẫn đảm bảo trải nghiệm người dùng liền mạch. Để tối đa hóa tỷ lệ đăng nhập của xác thực bằng passkey, hãy cân nhắc các khuyến nghị sau:

- **Lựa chọn Phương pháp Ưu tiên Định danh:** Cách tiếp cận này thân thiện với người dùng hơn và giảm thiểu ma sát trong quá trình đăng nhập. Bằng cách yêu cầu người dùng nhập định danh chính của họ trước (ví dụ: email hoặc số điện thoại), hệ thống có thể tự động xác định xem việc đăng nhập bằng passkey có khả thi hay không. Điều này đảm bảo trải nghiệm đăng nhập suôn sẻ, trực quan mà không phụ thuộc vào người dùng trong việc chọn tùy chọn passkey một cách thủ công.
- **Sử dụng các Màn hình Hủy bỏ giải thích để có Trải nghiệm Người dùng tốt hơn:** Trong khi bảo mật phải là ưu tiên hàng đầu, thì việc thiết kế một quy trình giúp người dùng chấp nhận passkey là rất cần thiết. Đảm bảo rằng các lần hủy bỏ lễ xác thực đầu tiên được coi là bình thường và đưa ra hướng dẫn rõ ràng để thử lại.
- **Giữ cho các Tùy chọn Dự phòng và Khôi phục An toàn:** Đảm bảo rằng các phương pháp dự phòng (chẳng hạn như OTP qua email và/hoặc OTP SMS) phù hợp với mức độ bảo mật của phương pháp xác thực chính. Ví dụ: trong một hệ thống MFA sử dụng passkey, phương án dự phòng cũng nên yêu cầu nhiều yếu tố để duy trì cùng một tiêu chuẩn bảo mật.
- **Tự động hóa các Lời nhắc Khôi phục Thường xuyên:** Thường xuyên nhắc người dùng xác minh thông tin liên hệ của họ (địa chỉ email hoặc số điện thoại) trong quá trình đăng nhập để đảm bảo rằng các tùy chọn khôi phục vẫn luôn cập nhật khi họ sử dụng passkey. Điều này giảm thiểu cơ hội người dùng bị khóa khỏi tài khoản của họ do các phương pháp khôi phục lỗi thời.
- **Cân nhắc Các Phương pháp Khôi phục Thông minh để Nâng cao Bảo mật và Giảm Chi phí Hỗ trợ Khôi phục:** Đối với các ngành công nghiệp hoặc hệ thống được quản lý có quyền truy cập vào dữ liệu cá nhân để kiểm tra chéo với nhận dạng trực tuyến, hãy xem xét các phương pháp khôi phục nâng cao như nhận dạng ảnh tự sướng với kiểm tra thực thể sống. Phương pháp này có thể cung cấp thêm các lớp bảo mật trong khi vẫn giữ cho quy trình khôi phục trực quan và thân thiện với người dùng tùy thuộc vào yêu cầu bảo mật của bạn.

Việc tối đa hóa tỷ lệ đăng nhập passkey phụ thuộc vào việc bạn thực hiện tốt các yếu tố này như thế nào. Đảm bảo các tùy chọn dự phòng và khôi phục mượt mà sẽ mang lại cho người dùng sự tự tin trong việc sử dụng passkey làm phương pháp xác thực chính của họ.

## 6. Corbado Có Thể Làm Gì Cho Bạn: Các Component UI & Thông minh Passkey

Corbado cung cấp mọi thứ cần thiết để triển khai phương pháp ưu tiên định danh cho các dự án mới cần một hệ thống xác thực hoàn toàn mới và cho các dự án hiện tại cần thêm passkey vào một hệ thống xác thực đang tồn tại.

### 6.1 Các Component UI Cho Các Trường hợp Sử dụng Khác nhau

Cả hai sản phẩm đều cung cấp các component UI có thể được điều chỉnh theo nhu cầu của bạn:

1. **Corbado Complete: Khởi động dự án của bạn với xác thực ưu tiên passkey**\
   Đây là hệ thống xác thực toàn diện của chúng tôi, bao gồm một phương pháp ưu tiên định danh liền mạch để hợp lý hóa quá trình đăng nhập. Corbado Complete cho phép một trải nghiệm an toàn và thân thiện với người dùng bằng cách tự động xác định xem đăng nhập bằng passkey có khả thi hay không sau khi người dùng cung cấp định danh của họ. Điều này giảm ma sát và đảm bảo trải nghiệm đăng nhập suôn sẻ, điều cốt yếu để tối đa hóa sự chấp nhận passkey.
2. **Corbado Connect: Thêm passkey mà không cần di chuyển sang bất kỳ ứng dụng nào**\
   Đối với các doanh nghiệp đã có quy trình xác thực được thiết lập và muốn thêm passkey như một sự tăng cường, Corbado Connect cung cấp giải pháp bổ sung cho Chiến lược Đơn Yếu tố và Đa Yếu tố. Phương pháp này bổ sung cho cơ sở hạ tầng hiện có của bạn bằng cách tích hợp liền mạch passkey như một lựa chọn an toàn và thuận tiện, cho phép người dùng xác thực qua passkey mà không cần đại tu hệ thống hiện tại của bạn. Ví dụ: Corbado Connect có thể được nhúng liền mạch vào Amazon Cognito.

Chúng tôi nghiêm ngặt căn chỉnh các phương pháp của mình với các nhà lãnh đạo trong ngành như Google và các công ty nổi bật khác trong không gian công nghệ lớn, đặc biệt được điều chỉnh cho các công ty hướng tới người tiêu dùng.

### 6.2 Passkey Intelligence kích hoạt Phương pháp Ưu tiên Định danh

Mục tiêu của chúng tôi không chỉ là tối đa hóa sự chấp nhận passkey (tức là việc tạo passkey) mà còn đảm bảo các passkey này được sử dụng tích cực để thúc đẩy tỷ lệ đăng nhập cao (và do đó tăng bảo mật và giảm chi phí SMS OTP). Các component UI của chúng tôi được xây dựng với lưu ý về phương pháp Ưu tiên Định danh và được kết nối trực tiếp đến [Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) của chúng tôi, quyết định về tính sẵn sàng & khả năng truy cập của passkey dựa trên môi trường máy khách và các passkey hiện có. Chúng hỗ trợ tất cả các chức năng dự phòng và khôi phục đã thảo luận. Các màn hình sau đây hiển thị logic hủy bỏ & thử lại của chúng tôi:

![Hủy bỏ passkey lần đầu corbado](https://www.corbado.com/website-assets/corbado_passkey_first_abort_537bf2c410.png)_Hủy bỏ Passkey Lần Đầu_

![Hủy bỏ passkey lần hai corbado](https://www.corbado.com/website-assets/corbado_passkey_second_abort_a167225e5e.png)_Hủy bỏ Passkey Lần Thứ Hai_

Bằng cách tập trung vào cả việc chấp nhận passkey và mức độ sử dụng passkey, chúng tôi giúp bạn đạt được sự cân bằng giữa bảo mật và trải nghiệm người dùng, đảm bảo rằng người dùng tiếp tục tương tác với passkey một cách không ma sát.

## 7. Kết luận

Trong hướng dẫn này, chúng tôi đã khám phá các chiến lược dự phòng và khôi phục khác nhau sau khi tích hợp passkey vào một hệ thống xác thực. Các câu hỏi chính đặt ra trong phần giới thiệu đã được giải quyết xuyên suốt:

- **Có những tình huống dự phòng nào?** Một số tình huống dự phòng có thể xảy ra, chẳng hạn như thiếu hỗ trợ passkey hoặc passkey không thể truy cập trên một thiết bị cụ thể. Để duy trì bảo mật và cung cấp UX mượt mà, các tùy chọn dự phòng như OTP qua email hoặc SMS nên có sẵn khi việc đăng nhập passkey không thể thực hiện được.
- **Khôi phục nên được xử lý như thế nào?** Quá trình khôi phục nên được thiết kế để phù hợp với mức độ bảo mật của hệ thống xác thực. Trong các hệ thống SFA, OTP qua email hoặc SMS có thể là đủ, trong khi ở các hệ thống MFA, các yếu tố thay thế phải được sử dụng để lấy lại quyền truy cập và tạo passkey mới. Trong các môi trường nhạy cảm hoặc bị quản lý chặt chẽ, các phương pháp khôi phục thông minh như nhận dạng ảnh tự sướng với kiểm tra thực thể sống cung cấp thêm tính bảo mật.

Bằng cách làm theo các thực tiễn tốt nhất được nêu trong hướng dẫn này, các nhà quản lý sản phẩm và nhà phát triển có thể thiết kế các hệ thống xác thực dựa trên passkey mạnh mẽ, cung cấp cho người dùng trải nghiệm đăng nhập an toàn nhưng liền mạch. Bảo mật không nhất thiết phải trả giá bằng trải nghiệm người dùng - cả hai đều có thể đạt được với sự thiết kế và lập kế hoạch chu đáo.

## Câu hỏi thường gặp

### Phương pháp Ưu tiên Định danh xử lý việc đăng nhập passkey như thế nào khi passkey không thể truy cập được trên thiết bị hiện tại?

Khi một passkey có khả năng không thể truy cập được (ví dụ: passkey macOS được truy cập từ thiết bị Windows), hệ thống tự động bỏ qua lời nhắc passkey và trình bày các tùy chọn dự phòng như mật khẩu hoặc OTP. Điều này tránh các ngõ cụt gây nhầm lẫn bằng cách chỉ kích hoạt đăng nhập passkey khi khả năng thành công cao, tuân theo chiến lược 'đừng bắt tôi phải suy nghĩ'.

### Điều gì sẽ xảy ra khi người dùng hủy bỏ lễ xác thực passkey giữa chừng?

Lần hủy bỏ đầu tiên nên được coi là một sự kiện bình thường, với một màn hình bình tĩnh khuyến khích người dùng thử lại, vì nhiều người dùng hủy bỏ đơn giản do họ không quen thuộc với màn hình xác thực. Nếu lần hủy bỏ thứ hai xảy ra, hệ thống nên đưa ra các tùy chọn xác thực dự phòng, vì điều này có thể chỉ ra một vấn đề thực sự đối với bộ xác thực nền tảng hoặc tính khả dụng của passkey.

### Các tùy chọn khôi phục nào tồn tại cho hệ thống MFA khi người dùng mất quyền truy cập vào passkey của họ?

Trong các hệ thống MFA, người dùng có thể khôi phục bằng cách xác thực với hai yếu tố thay thế, chẳng hạn như mật khẩu kết hợp với SMS OTP hoặc bằng cách sử dụng passkey từ một thiết bị đáng tin cậy khác, sau đó tạo một passkey mới. Đối với các ngành được quản lý nơi các phương pháp khôi phục truyền thống không có sẵn, các phương pháp thông minh như nhận diện ảnh tự sướng với kiểm tra thực thể sống cung cấp một đường dẫn khôi phục an toàn bổ sung.

### Tại sao phương pháp sử dụng nút 'Đăng nhập bằng passkey' thủ công dẫn đến tỷ lệ chấp nhận thấp hơn so với Phương pháp Ưu tiên Định danh?

Phương pháp thủ công đặt hoàn toàn trách nhiệm vào người dùng để ghi nhớ và tự chọn tùy chọn passkey, thường dẫn đến tỷ lệ đăng nhập passkey thấp hơn nhiều. Người dùng cũng có thể gặp phải các thông báo lỗi không rõ ràng khi passkey không được tìm thấy trên bộ xác thực nền tảng, dẫn đến sự bực bội và các nỗ lực đăng nhập bị từ bỏ.