---
url: 'https://www.corbado.com/vi/blog/authentication-process-mining'
title: 'Khai phá Quy trình Xác thực: Kỷ luật CIAM Tiếp theo'
description: 'Khai phá quy trình xác thực biến nhật ký sự kiện passkey thành hành trình đăng nhập được tối ưu hóa. Tìm hiểu kỷ luật khả năng quan sát CIAM đằng sau xác thực step-up và phân tích.'
lang: 'vi'
author: 'Vincent Delitz'
date: '2026-05-19T14:51:02.878Z'
lastModified: '2026-05-20T06:05:40.603Z'
keywords: 'khai phá quy trình xác thực, hành trình xác thực người dùng, khả năng quan sát CIAM, xác thực step-up, tối ưu hóa hành trình xác thực'
category: 'Passkeys Strategy'
---

# Khai phá Quy trình Xác thực: Kỷ luật CIAM Tiếp theo

## Key Facts

- **Khai phá quy trình xác thực** (Authentication process mining) ánh xạ **tái cấu
    trúc nhật ký sự kiện** theo phong cách **Celonis**, được chính thức hóa bởi **IEEE
    Task Force on Process Mining** cho quy trình làm việc **ERP** vào **thập niên 2010**,
    lên các nghi thức đăng nhập bằng passkey. - Nó yêu cầu một **lớp khả năng quan sát
    phía client**. **Nhật ký IDP** ghi lại **nỗ lực**, **thành công** và **thất bại** ở
    phía server và bỏ sót **Conditional UI**, lời nhắc sinh trắc học, việc lựa chọn
    **trình quản lý thông tin xác thực** (credential manager) và sự từ bỏ âm thầm. - Trong
    các triển khai được quan sát, chỉ khoảng **30%** người dùng đủ điều kiện đi theo
    **happy path passkey được thiết kế**, và **tỷ lệ thành công tổng thể 92%** thường che
    giấu **tỷ lệ từ bỏ 40%** trên riêng lộ trình passkey. - **Năm biến thể sai lệch hàng
    đầu** thường chiếm **85%** tổng số sai lệch, do đó các bản sửa lỗi có mục tiêu sẽ thúc
    đẩy việc áp dụng nhiều hơn bất kỳ thử nghiệm A/B nào trên happy path. - Mô hình sự
    kiện cần **3 loại khởi tạo** (`text-field`, `one-tap`, `cui`), **6 lớp kết quả** và
    một **kho thông tin xác thực** được phân đoạn theo **phương thức truyền tải**
    (transport) và authenticator (**Apple**, **Google Password Manager**, **iCloud
    Keychain**, **Windows Hello**, **YubiKey**). - Dữ liệu khai phá quy trình biến **xác
    thực step-up** từ một quy tắc OTP cứng nhắc - gây rào cản trên **95%** lưu lượng truy
    cập hợp lệ để bắt **5%** đáng ngờ - thành một **quyết định được chấm điểm rủi ro**
    liên tục. - Không **IDP** nào tích hợp sẵn tính năng này: **Okta**, **Ping**,
    **ForgeRock** và **Auth0** sở hữu **mặt phẳng điều khiển** (control plane), trong khi
    khai phá quy trình là một **kỷ luật mặt phẳng dữ liệu**, khiến **phân tích biến thể**,
    **phát hiện trôi dạt thuần tập** (cohort drift detection) và **kiểm tra sự tuân thủ**
    trở thành bắt buộc đối với các nhóm phân tích CIAM vào năm **2027**.

## 1. Giới thiệu

Passkey đang thúc đẩy CIAM tiến lên. Các nhóm xuất sắc nhất đang bắt đầu trang bị công cụ
cho hành trình đăng nhập từ đầu đến cuối, phân loại các lỗi mà họ chưa từng ghi nhật ký
trước đây và xem xét đo lường từ xa phía client lần đầu tiên. Phần lớn các nhóm quản lý
danh tính chưa đạt đến mức đó: không có lớp khả năng quan sát xác thực thực sự, không có
biểu đồ sự kiện theo từng phiên, không có dữ liệu nghi thức phía client. Nỗ lực, thành
công và thất bại ở phía server vẫn là toàn bộ bức tranh.

Khai phá quy trình xác thực là bước hợp lý tiếp theo nhưng chỉ khi dữ liệu sự kiện cơ bản
đó tồn tại. Không có lớp khả năng quan sát, không có gì để khai phá. Có nó, một kỷ luật
mới sẽ có sẵn. Nó vay mượn trực tiếp từ khai phá quy trình kinh doanh, biến nhật ký sự
kiện ERP thô thành các quy trình làm việc được tối ưu hóa vào thập niên 2010. Áp dụng vào
danh tính, nó so sánh hành trình đăng nhập được thiết kế với hành trình thực tế, làm nổi
bật các lộ trình sai lệch và sau đó thu hẹp khoảng cách bằng xác thực step-up tinh chỉnh,
quy tắc triệt tiêu hoặc thay đổi UX được đo lường từ đầu đến cuối.

Bài viết này định hình lại những gì các nhóm CIAM nên xây dựng dựa trên lớp khả năng quan
sát xác thực.

### 1.1 Những câu hỏi bài viết này trả lời

Trong bài viết này, chúng ta sẽ giải quyết các câu hỏi sau:

1. Khai phá quy trình đã làm gì cho BPM, và điểm tương đồng trực tiếp đối với xác thực là
   gì?
2. Tại sao việc triển khai passkey lại làm lộ ra khoảng trống này, và tại sao nhật ký xác
   thực lại không bao giờ tự đủ?
3. Mô hình sự kiện khai phá quy trình xác thực thực sự trông như thế nào từ đầu đến cuối?
4. Khai phá quy trình kết nối với xác thực step-up tinh chỉnh và cấp quyền như thế nào?
5. Điều này có ý nghĩa gì đối với cục diện các nhà cung cấp CIAM và đối với các nhóm danh
   tính đã sở hữu IDP?

## 2. Khai phá quy trình đã làm gì cho BPM

### 2.1 Từ Nhật ký sự kiện đến các Quy trình được tối ưu hóa

Khai phá quy trình kinh doanh nổi lên từ nhận thức rằng mọi hệ thống ERP, CRM hoặc bán vé
đều ghi lại nhật ký sự kiện, khi được tái cấu trúc, sẽ tiết lộ quy trình làm việc thực tế,
không phải quy trình trên wiki. Một đơn đặt hàng đáng lẽ phải qua ba người phê duyệt lại
bỏ qua hai người trong số đó ở 40% thời gian. Một luồng yêu cầu bồi thường được ghi nhận
là một đường thẳng lại vòng lại chính nó năm lần đối với 18% yêu cầu. Các công cụ khai phá
quy trình như các công cụ được Celonis phổ biến hóa đã xây dựng lại các biểu đồ đó từ các
sự kiện có dấu thời gian và cho phép người vận hành đặt câu hỏi mới: quy trình thực tế
khác biệt với quy trình được thiết kế ở đâu, và sự khác biệt đó tốn kém như thế nào?

### 2.2 Điểm tương đồng trong Xác thực

Xác thực có cấu trúc tương tự. Mọi lần đăng nhập đều là một chuỗi sự kiện có dấu thời
gian: tải trang, nhập định danh, chọn thử thách, nhắc
[sinh trắc học](https://www.corbado.com/vi/blog/sinh-trac-hoc-nhan-thuc-nguoi-thanh-toan), trả về
[assertion](https://www.corbado.com/glossary/assertion). Cấu trúc song song là hoàn toàn chính xác. Điểm khác
biệt thực tế là, không giống như ERP hoặc CRM, dữ liệu sự kiện này chưa nằm trong nhật ký
IDP của bạn - ít nhất là không ở dạng chi tiết mà khai phá quy trình cần. Các IDP ghi lại
kết quả đăng nhập và phương thức được sử dụng. Chúng không ghi lại nghi thức phía client
bên dưới: lệnh gọi [Conditional UI](https://www.corbado.com/glossary/conditional-ui), lời nhắc
[sinh trắc học](https://www.corbado.com/vi/blog/sinh-trac-hoc-nhan-thuc-nguoi-thanh-toan), lựa chọn trình quản lý
thông tin xác thực, sự từ bỏ âm thầm trước khi yêu cầu tiếp cận server. Lớp tiền
[assertion](https://www.corbado.com/glossary/assertion) đó phải được trang bị ở lớp front-end SDK và lắp ráp lại
thành một biểu đồ theo từng phiên trước khi khai phá quy trình có thể hoạt động trên đó.

Khi dữ liệu đã ở đó, các kỹ thuật tương tự sẽ được áp dụng: hành trình passkey thiết kế so
với hành trình passkey thực tế, luồng khôi phục thiết kế so với luồng khôi phục thực tế,
step-up thiết kế so với step-up thực tế. Chuyên ngành học thuật xoay quanh công việc này
đang trưởng thành. Một điểm khởi đầu hữu ích là
[Process Mining Manifesto](https://www.tf-pm.org/resources/manifesto) từ IEEE Task Force
on Process Mining, trong đó đưa ra ba kỹ thuật cốt lõi là kiểm tra sự tuân thủ, phân tích
biến thể và tăng cường. Mỗi cái ánh xạ tương ứng một-một lên xác thực.

## 3. Tại sao Triển khai Passkey làm lộ ra Khoảng trống

### 3.1 Passkey buộc các Nhóm phải suy nghĩ lại về Nhật ký Frontend

Xác thực mật khẩu cổ điển ghi lại ba điều phía server: nỗ lực, thành công, thất bại. Điều
đó đủ để chạy một hệ thống mật khẩu, vì chế độ thất bại rất đơn giản: người dùng gõ sai
một chuỗi, và nỗ lực tiếp theo hoặc thành công hoặc không. Với passkey, các khoảnh khắc
quan trọng chuyển sang frontend: [Conditional UI](https://www.corbado.com/glossary/conditional-ui) kích hoạt,
trình duyệt quyết định có hiển thị lời nhắc hay không, trình quản lý thông tin xác thực
đưa ra lựa chọn, thử thách
[sinh trắc học](https://www.corbado.com/vi/blog/sinh-trac-hoc-nhan-thuc-nguoi-thanh-toan) thành công hoặc bị loại
bỏ. Tất cả những điều này xảy ra trên thiết bị của người tiêu dùng, trước khi
[assertion](https://www.corbado.com/glossary/assertion) tiếp cận backend.

Sự thay đổi đó là lý do khiến nhiều nhóm hiện đang suy nghĩ lại về cách họ ghi nhật ký
hành vi phía client. Không có công cụ frontend, họ không thể thấy lý do người dùng từ bỏ,
các bước người dùng thực hiện trước khi đăng nhập, hoặc những gì thực sự xảy ra khi nỗ lực
đăng nhập không hoàn tất. Nhật ký server chỉ hiển thị sự vắng mặt, không phải nguyên nhân.
Xem bài viết chuyên sâu của chúng tôi về khả năng quan sát xác thực để biết phân loại sự
kiện đầy đủ.

### 3.2 Khoảng trống giữa Hành trình Thiết kế và Hành trình Thực tế

Khi các nhóm có sự kiện phía client, họ có thể thấy điều gì đó mới mẻ: hành trình passkey
được thiết kế (vào trang đăng nhập, thấy
[nút passkey](https://www.corbado.com/vi/blog/thuc-hanh-tot-nhat-dang-nhap-passkey), chạm, xác thực, xong) được
sử dụng bởi có lẽ 30% người dùng đủ điều kiện. 70% còn lại trôi dạt sang các trường mật
khẩu, đăng nhập mạng xã hội, magic link hoặc từ bỏ hoàn toàn. Đó là vấn đề khai phá quy
trình, không phải vấn đề ghi nhật ký. Không một lượng mã lỗi WebAuthn bổ sung nào có thể
tự thu hẹp khoảng cách.

### 3.3 Tại sao Nhật ký Xác thực không bao giờ là Đủ

Nhật ký xác thực tự thân cho bạn biết kết quả. Chúng không cho bạn biết lộ trình. Tỷ lệ
đăng nhập thành công 92% trên tất cả các phương thức có thể che giấu tỷ lệ từ bỏ 40% trên
lộ trình passkey và tỷ lệ từ bỏ 15% trên lộ trình mật khẩu, cuối cùng được coi là "ổn".
Khai phá quy trình từ chối cách tính trung bình đó. Nó khăng khăng xem xét riêng từng biến
thể rồi xếp hạng các biến thể theo tần suất, chi phí và tỷ lệ thất bại.

## 4. Khai phá Quy trình Xác thực thực sự trông như thế nào

### 4.1 Mô hình Sự kiện: Quy trình, Sự kiện và Phân loại Kết quả

Đơn vị phân tích không phải là một sự kiện đơn lẻ, nó là một **quy trình**: một nỗ lực
đăng nhập hoặc thêm thông tin xác thực đầy đủ trên thiết bị của người tiêu dùng, từ lúc
giao diện xác thực tải cho đến lúc phiên hoàn tất hoặc bị hủy bỏ. Mỗi quy trình chứa một
luồng sự kiện chi tiết, mang siêu dữ liệu nhận dạng và kết thúc bằng phân loại kết quả
phong phú hơn so với nhị phân "thành công hay thất bại".

**Siêu dữ liệu quy trình.** Mọi quy trình đều có ID quy trình và dấu thời gian. Nó gắn
liền với một ứng dụng, một hệ điều hành, một trình duyệt và một thương hiệu thiết bị. Nó
được gắn thẻ bằng danh mục khách truy cập (người dùng thực, người kiểm tra thủ công, người
kiểm tra tự động, chưa được phân loại) để lưu lượng tự động hóa và bot có thể được phân
đoạn ra trước khi tính toán bất kỳ số liệu nào. Nó cũng mang điểm quy trình và số lượng sự
kiện, đây là hai tín hiệu đơn giản nhất cho "phiên cụ thể này phức tạp như thế nào".

**Khởi tạo đăng nhập.** Mọi quy trình đều ghi lại cách luồng được bắt đầu. Các loại khởi
tạo chính là `text-field` (người dùng đã gõ định danh của họ), `one-tap` (định danh đã lưu
được sử dụng lại) và `cui` (Conditional UI hiển thị thông tin xác thực mà không cần nhấp
nút rõ ràng). Khởi tạo là một chiều dữ liệu, không phải là một chỉ số: cùng một quá trình
triển khai có thể trông rất khác trên thuần tập `cui` so với thuần tập `text-field`, và
việc lấy trung bình trên chúng che giấu chính xác hành vi mà khai phá quy trình nhằm mục
đích tiết lộ.

**Phân loại kết quả.** Thay vì "thành công" hoặc "thất bại", kết quả là một trong số các
lớp ánh xạ tới một hành vi riêng biệt. Một ví dụ cho passkey là như sau:

- `completed` - nghi thức đã kết thúc và người dùng đã được xác thực.
- `filtered-explicit-abort` - người dùng thấy lời nhắc và hủy rõ ràng.
- `filtered-implicit-abort` - người dùng rời đi hoặc hết thời gian chờ mà không quyết
  định.
- `filtered-passkey-intel` - lớp thông minh phía client cố tình triệt tiêu lộ trình
  passkey, điển hình vì tổ hợp thiết bị/hệ điều hành được biết là bị hỏng.
- `filtered-no-start` - luồng không bao giờ vượt qua bước nhập liệu ban đầu.
- `not-loaded` - giao diện xác thực không bao giờ tải xong.

Nghi thức thêm (tạo thông tin xác thực) có phân loại tương tự, bao gồm trường hợp
`completed-exclude-credentials` khi người dùng đã có thông tin xác thực.

**Các lớp Phễu và Kho lưu trữ.** Nằm trên các quy trình, hai lớp tổng hợp có vai trò quan
trọng. Một **lớp phễu** (funnel layer) nhóm các quy trình theo thời gian dựa trên kết quả,
khởi tạo, trạng thái hoàn thành, hệ điều hành và ứng dụng, cho cả đăng nhập và thêm. Một
**lớp kho thông tin xác thực** (credential inventory layer) nhóm các passkey hiện có theo
trạng thái đồng bộ hóa (đã đồng bộ vs. chưa đồng bộ), phương thức truyền tải (`internal`,
`hybrid`, `usb`, `nfc`, `ble`, `smart-card`), [authenticator](https://www.corbado.com/glossary/authenticator)
(Apple, [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager),
[iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain), [Windows Hello](https://www.corbado.com/glossary/windows-hello),
[1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis),
[Bitwarden](https://www.corbado.com/blog/passkey-analysis-bitwarden-developer-survey-2024),
[Dashlane](https://www.corbado.com/blog/dashlane-passkeys), [YubiKey](https://www.corbado.com/glossary/yubikey)), hệ điều hành và trình
duyệt. Không có lớp kho lưu trữ, không thể hỏi liệu một biến thể sai lệch cụ thể có tập
trung vào một trình quản lý thông tin xác thực hoặc trạng thái đồng bộ hóa cụ thể hay
không.

Đây là hình dạng tối thiểu giúp khai phá quy trình có thể xử lý được. Mỗi sự kiện mang đủ
siêu dữ liệu để được nhóm, lọc và xếp hạng. Mỗi quy trình có thể được theo dõi riêng lẻ,
đây là điều cho phép các ví dụ ở dưới.

### 4.2 Happy Path so với Phân tích Sai lệch

Khi các sự kiện được lưu trữ dưới dạng biểu đồ có hướng trên mỗi phiên, chúng ta có thể
hỏi câu hỏi khai phá quy trình: bao nhiêu phần trăm số phiên đi theo happy path, và đối
với những phiên không làm như vậy, năm biến thể sai lệch hàng đầu được xếp hạng theo tần
suất là gì? Trong dữ liệu phân tích của chúng tôi, năm biến thể hàng đầu thường chiếm 85%
tổng số sai lệch. Việc sửa hai trong số chúng thường thay đổi các con số nhiều hơn bất kỳ
thử nghiệm A/B nào trên happy path.

### 4.3 Phát hiện Trôi dạt Thuần tập

Các biến thể có thể trôi dạt. Một bản cập nhật trình duyệt, một lần tung ra hệ điều hành,
một thay đổi của trình quản lý thông tin xác thực có thể làm một biến thể nhỏ trước đây
đột nhiên trở nên thống trị. Phát hiện trôi dạt thuần tập là kỷ luật theo dõi phân phối
biến thể theo thuần tập thiết bị/hệ điều hành/trình duyệt theo thời gian, thay vì chỉ xem
tỷ lệ thành công tổng thể. Đây là cách các nhóm nắm bắt các hồi quy âm thầm trong vài giờ
thay vì vài quý.

## 5. Từ Khai phá Quy trình đến Step-up Tinh chỉnh

### 5.1 Tại sao Step-up chưa được sử dụng đúng mức

Xác thực step-up đã tồn tại hơn một thập kỷ. Nó chưa được sử dụng đúng mức vì hầu hết các
nhóm thực hiện step-up theo cùng một cách bất kể rủi ro: bắt buộc có OTP trên mọi giao
dịch vượt quá một ngưỡng. Đó là một quy tắc cứng nhắc, không phải là một quyết định dựa
trên chấm điểm rủi ro. Nó tạo ra rào cản trên 95% giao dịch hợp lệ có giá trị cao để chặn
5% đáng ngờ.

### 5.2 Hành trình Chấm điểm rủi ro

Với dữ liệu khai phá quy trình, chúng ta có thể chấm điểm một phiên liên tục. Danh tiếng
của thiết bị, tỷ lệ thành công của đường cơ sở thuần tập, bất thường về thời gian trong
ngày, sự sai lệch khỏi lộ trình lịch sử của chính người dùng, danh tính trình quản lý
thông tin xác thực, danh tiếng IP. Điểm rủi ro sau đó thúc đẩy quyết định step-up tinh
chỉnh: chỉ yêu cầu nhân tố thứ hai khi điểm rủi ro của phiên vượt qua ngưỡng giá trị giao
dịch. Các phiên rủi ro thấp cho giao dịch giá trị cao sẽ vượt qua. Các phiên rủi ro cao
cho giao dịch giá trị thấp sẽ bị step-up.

## 6. Điều này có ý nghĩa gì đối với Cục diện Nhà cung cấp CIAM

### 6.1 Thiết kế Hành trình như một Kỷ luật Chuyên môn

Ngành công nghiệp danh tính trước đây đã bó gọn thiết kế hành trình bên trong IDP. Các
công cụ điều phối (orchestration engines) bên trong Okta, Ping, ForgeRock,
[Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis) và những nền tảng khác cho phép thiết lập cấu hình
luồng. Tuy nhiên, những gì chúng không làm tốt là quan sát chúng. Sự không khớp đó mở ra
không gian cho một lớp phân tích chuyên biệt.

### 6.2 Tại sao không có IDP nào tích hợp sẵn Tính năng này

Các nhà cung cấp IDP tối ưu hóa cho mặt phẳng điều khiển: ai có thể đăng nhập, bằng thông
tin xác thực nào, theo chính sách nào. Khai phá quy trình là một kỷ luật của mặt phẳng dữ
liệu: mọi sự kiện, ở quy mô lớn, được chuẩn hóa trên các tổ hợp hệ điều hành/trình
duyệt/trình quản lý thông tin xác thực. Khối lượng sự kiện, tính chất lớn và các đường cơ
sở xuyên khách hàng đều chống lại một quá trình xây dựng IDP nội bộ. Xem các ghi chú thực
tế trong [hướng dẫn](https://www.corbado.com/vi/blog/ung-dung-crud-react-express-mysql) mua hay xây dựng đối với
passkey cho cùng một mô hình được áp dụng cho lớp SDK.

### 6.3 Lớp Phân tích như một Hạng mục mới

Những gì nổi lên là một lớp phân tích và áp dụng mỏng nằm phía trên IDP, tiếp nhận các sự
kiện từ front-end, chuẩn hóa chúng theo các đường cơ sở triển khai chéo và phản hồi lại
vào các quyết định điều phối. Nó không thay thế IDP. Nó làm cho IDP có thể đo lường được.

## 7. Corbado giúp Khai phá Quy trình Xác thực như thế nào

[Corbado](https://www.corbado.com/) cung cấp lớp đo lường và áp dụng nằm phía trên các IDP
hiện có. Nó tích hợp với Okta, [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis), Ory, ForgeRock và
các ngăn xếp tùy chỉnh mà không thay thế chúng. Những gì nó thêm vào đặc biệt là khả năng
khai phá quy trình:

- **Phân loại Sự kiện End-to-end.** Client-side SDK thu thập toàn bộ nghi thức từ lúc tải
  trang đến assertion, bao gồm các sự kiện tiền định danh, lệnh gọi
  [Conditional UI](https://www.corbado.com/glossary/conditional-ui) và chọn trình quản lý thông tin xác thực.
- **Phân tích Biến thể sẵn có.** Nền tảng xây dựng lại biểu đồ hành trình theo từng thuần
  tập và xếp hạng các biến thể sai lệch theo tần suất, cơ hội khôi phục và chi phí.
- **Cảnh báo Trôi dạt Thuần tập.** Khi phân phối biến thể dịch chuyển đối với một hệ điều
  hành, trình duyệt hoặc trình quản lý thông tin xác thực cụ thể, nền tảng sẽ gắn cờ nó
  trước khi nó trở thành một vấn đề day-2.
- **Đường cơ sở Triển khai Chéo.** Vì Corbado tổng hợp dữ liệu ẩn danh qua các môi trường
  của khách hàng, các lỗi mới hoặc sự hồi quy nổi lên trong một triển khai được phân loại
  và lập tài liệu trước khi chúng ảnh hưởng đến bạn. Xem lý do chọn Corbado để biết phương
  pháp tiếp cận đầy đủ.
- **Phản hồi về Điều phối.** Quyết định step-up chấm điểm rủi ro và các quy tắc triệt tiêu
  có thể được đẩy trở lại IDP hoặc xử lý tại lớp áp dụng, bao gồm công tắc tiêu diệt động
  và cảnh báo cụ thể cho từng thuần tập.

## 8. Kết luận

Passkey không phải là đích đến. Chúng là công cụ tạo tiền đề buộc làn sóng đầu tiên của
các nhóm CIAM phải ghi nhật ký các sự kiện phía client. Khi lớp khả năng quan sát đó tồn
tại, một kỷ luật mới nằm phía trên nó: khai phá quy trình xác thực. Đó là cách các nhóm
danh tính chuyển từ "việc đăng nhập có thành công không" sang "người dùng này đã đi theo
biến thể nào của hành trình, nó tốn kém như thế nào và phiên tiếp theo nên được định tuyến
khác đi ra sao". Các nhóm xây dựng lớp khả năng quan sát trước, và lớp khai phá quy trình
ngay sau đó, sẽ thiết lập chuẩn mực cho hạng mục này. Các nhóm tiếp tục bám vào các tỷ lệ
thành công tổng thể sẽ tiếp tục bỏ lỡ các biến thể có hệ thống bên dưới.

## FAQ

### Khai phá Quy trình Xác thực là gì?

Khai phá quy trình xác thực là việc áp dụng các kỹ thuật khai phá quy trình kinh doanh vào
nhật ký sự kiện đăng nhập. Nó tái cấu trúc biểu đồ có hướng của các sự kiện theo từng
phiên, so sánh hành trình xác thực thực tế với hành trình được thiết kế và xếp hạng các
biến thể sai lệch theo tần suất và chi phí. Nó nằm phía trên khả năng quan sát xác thực và
bên dưới điều phối.

### Nó khác với Phân tích Xác thực như thế nào?

Phân tích xác thực báo cáo các chỉ số như tỷ lệ đăng nhập thành công, tỷ lệ bỏ cuộc và tỷ
lệ sử dụng passkey. Khai phá quy trình tiến xa hơn bằng cách tái cấu trúc toàn bộ chuỗi sự
kiện theo phiên và đặt câu hỏi những biến thể nào của hành trình tồn tại, tần suất xảy ra
của mỗi biến thể và nơi mỗi biến thể phân kỳ khỏi happy path được thiết kế. Phân tích báo
cáo kết quả. Khai phá quy trình giải thích lộ trình.

### Tại sao việc Áp dụng Passkey lại làm Kỷ luật này trở nên cần thiết?

Việc triển khai passkey là lý do đầu tiên khiến các nhóm CIAM trang bị công cụ đo lường
cho các sự kiện phía client. Một khi những sự kiện đó tồn tại, các chỉ số tổng hợp che che
giấu quá nhiều: tỷ lệ thành công 92% có thể che đậy tỷ lệ từ bỏ 40% trên lộ trình passkey.
Khai phá quy trình từ chối sự lấy trung bình đó và buộc các nhóm phải xem xét các biến thể
một cách riêng biệt.

### Khai phá Quy trình kết nối với Xác thực Step-up như thế nào?

Xác thực step-up hoạt động tốt nhất khi nó được chấm điểm rủi ro thay vì dựa trên quy tắc.
Khai phá quy trình cung cấp bằng chứng ở cấp độ phiên (đường cơ sở thuần tập, độ lệch so
với lộ trình lịch sử của người dùng, danh tiếng thiết bị) cho phép công cụ step-up đưa ra
quyết định tinh chỉnh thay vì quyết định ngưỡng cứng nhắc.

### IDP của tôi có tích hợp sẵn tính năng này không?

Gần như không thể trong tương lai gần. Các IDP tối ưu hóa cho mặt phẳng điều khiển. Khai
phá quy trình là một kỷ luật của mặt phẳng dữ liệu với khối lượng sự kiện cao và số lượng
lớn trên các tổ hợp hệ điều hành, trình duyệt và trình quản lý thông tin xác thực. Mô hình
này khớp với những gì chúng ta thấy trong lớp SDK ngày nay, được đề cập trong
[hướng dẫn](https://www.corbado.com/vi/blog/ung-dung-crud-react-express-mysql) mua hay xây dựng của chúng tôi.

### Điều đầu tiên một Nhóm CIAM nên đo lường là gì?

Bắt đầu với tần suất biến thể trên lộ trình passkey: bao nhiêu phần trăm phiên đi theo
happy path và năm biến thể sai lệch hàng đầu được xếp hạng theo tần suất là gì? Biểu đồ
duy nhất đó thường đủ để tiết lộ hai hoặc ba bản sửa lỗi giúp thúc đẩy việc áp dụng
passkey tổng thể nhiều nhất.