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

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, trả về 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, lời nhắc sinh trắc học, 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 đó 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 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 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 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 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, 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 (Apple, Google Password Manager, iCloud Keychain, Windows Hello, 1Password, Bitwarden, Dashlane, 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 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 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 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, 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 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.

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 →

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 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.