---
url: 'https://www.corbado.com/zh/blog/authentication-process-mining'
title: '身份验证流程挖掘：下一代 CIAM 学科'
description: '身份验证流程挖掘将通行密钥事件日志转化为优化的登录旅程。了解逐步身份验证和分析背后的 CIAM 可观测性学科。'
lang: 'zh'
author: 'Vincent Delitz'
date: '2026-05-19T14:51:03.270Z'
lastModified: '2026-05-20T06:03:11.320Z'
keywords: '身份验证流程挖掘, 身份验证旅程, CIAM 可观测性, 逐步身份验证, 身份验证旅程优化'
category: 'Passkeys Strategy'
---

# 身份验证流程挖掘：下一代 CIAM 学科

## Key Facts

- **身份验证流程挖掘**将 **Celonis** 风格的**事件日志重建**（由 **IEEE
    流程挖掘工作组**在 **2010 年代**为 **ERP** 工作流形式化）映射到通行密钥登录仪式上。 -
    它需要一个**客户端可观测性层**。**IDP
    日志**在服务端记录**尝试**、**成功**和**失败**，但会遗漏 **Conditional
    UI**、生物识别提示、**凭据管理器**选择和无声放弃。 - 在观测到的部署中，只有大约
    **30%** 的合格用户遵循**设计的通行密钥理想路径**，并且 **92%
    的总体成功率**通常掩盖了仅在通行密钥路径上就高达 **40% 的放弃率**。 -
    **前五个偏差变体**通常占所有偏差的 **85%**，因此有针对性的修复比在理想路径上进行任何
    A/B 测试都能更好地推动采用。 - 事件模型需要 **3
    种启动类型**（`text-field`、`one-tap`、`cui`）、**6
    种结果类别**以及按**传输方式**和身份验证器（**Apple**、**Google Password
    Manager**、**iCloud Keychain**、**Windows Hello**、**YubiKey**）细分的**凭据清单**。 -
    流程挖掘数据将**逐步身份验证**从生硬的 OTP 规则（在 **95%** 的合法流量上制造摩擦以抓住
    **5%** 的可疑流量）转变为连续的**风险评分决策**。 - 没有 **IDP**
    原生提供此功能：**Okta**、**Ping**、**ForgeRock** 和 **Auth0**
    拥有**控制平面**，而流程挖掘是一门**数据平面学科**，使得**变体分析**、**队列漂移检测**和**一致性检查**在
    **2027 年**之前成为 CIAM 分析团队的必备技能。

## 1. 简介

通行密钥正在推动 CIAM 向前发展。一流的团队开始对登录旅程进行端到端的检测，对以前从未记录的错误进行分类，并首次查看客户端遥测。绝大多数身份团队还没有做到这一点：没有真正的身份验证可观测性层，没有按会话的事件图，没有客户端的仪式数据。服务端的尝试、成功和失败仍然是全部图景。

身份验证流程挖掘是下一个合乎逻辑的步骤，但前提是必须存在底层事件数据。没有可观测性层，就无从挖掘。有了它，一门新的学科就变得可用了。它直接借鉴了业务流程挖掘，后者在 2010 年代将原始 ERP 事件日志转化为优化的工作流。应用于身份领域，它将设计的登录旅程与实际发生的旅程进行比较，找出偏差路径，然后通过端到端衡量的逐步身份验证、抑制规则或用户体验更改来缩小差距。

本文重新构建了 CIAM 团队应在身份验证可观测性层之上构建的内容。

### 1.1 本文解答的问题

在本文中，我们探讨以下问题：

1. 流程挖掘对 BPM 做了什么？在身份验证中有什么直接相似之处？
2. 为什么通行密钥的推广暴露了这一差距，为什么身份验证日志本身永远不够？
3. 端到端的身份验证流程挖掘事件模型实际上是什么样的？
4. 流程挖掘如何与细粒度的逐步身份验证和授权相结合？
5. 这对 CIAM 供应商格局以及已经拥有 IDP 的身份团队意味着什么？

## 2. 流程挖掘对 BPM 的作用

### 2.1 从事件日志到优化的流程

业务流程挖掘源于这样一种认识：每个 ERP、CRM 或票务系统都会编写事件日志，当这些日志被重建时，揭示的是实际的工作流，而不是维基百科上的工作流。原本应该经过三位审批人的采购订单，结果有 40% 的时间绕过了其中两位。一条记录为直线的索赔流在 18% 的索赔中循环了五次。像 Celonis 推广的那类流程挖掘工具通过带时间戳的事件重建了这些图，并让操作员提出一个新问题：实际发生的流程在哪里偏离了设计的流程，这种偏离的代价是什么？

### 2.2 在身份验证中的相似之处

身份验证具有相同的结构。每次登录都是一个带时间戳的事件序列：页面加载、输入标识符、选择质询、提示生物识别、返回断言。结构上的相似之处是完全一致的。实际的区别在于，与 ERP 或 CRM 不同，这种事件数据尚未以流程挖掘所需的细化形式存在于您的 IDP 日志中。IDP 记录登录结果和使用的方法。它们不记录底层的客户端仪式：[Conditional UI](https://www.corbado.com/glossary/conditional-ui)
调用、生物识别提示、凭据管理器选择，以及在请求到达服务器之前的无声放弃。这种前断言层必须在前端 SDK 层进行检测，并在流程挖掘操作之前重新组装成每个会话的图。

一旦数据就位，就可以应用相同的技术：设计的通行密钥旅程 vs. 实际的通行密钥旅程，设计的恢复流程 vs. 实际的恢复流程，设计的逐步验证 vs. 实际的逐步验证。围绕这项工作的学术学科正在成熟。一个有用的切入点是 IEEE 流程挖掘工作组的[流程挖掘宣言](https://www.tf-pm.org/resources/manifesto)，它列出了一致性检查、变体分析和增强作为三个核心技术。每一项都与身份验证一对一映射。

## 3. 为什么通行密钥的推广暴露了差距

### 3.1 通行密钥迫使团队重新思考前端日志记录

经典的密码身份验证在服务端记录三件事：尝试、成功、失败。这足以运行一个密码系统，因为失败模式很简单：用户输入了错误的字符串，下一次尝试要么成功，要么失败。使用通行密钥，关键时刻转移到了前端：[Conditional UI](https://www.corbado.com/glossary/conditional-ui)
触发，浏览器决定是否显示提示，凭据管理器提供选择，生物识别质询成功或被取消。所有这些都发生在消费者的设备上，在断言到达后端之前。

这种转变是许多团队现在重新思考他们如何记录客户端行为的原因。如果没有前端检测，他们就无法知道用户流失的原因，用户在登录前采取了什么步骤，或者当登录尝试未完成时实际发生了什么。服务器日志只显示结果缺失，而不显示原因。请参阅我们关于身份验证可观测性的深度探讨，了解完整的事件分类。

### 3.2 设计旅程与实际旅程之间的差距

一旦团队拥有了客户端事件，他们就会看到一些新现象：设计的通行密钥旅程（登录页面，看到通行密钥按钮，点击，身份验证，完成）大约只有 30% 的合格用户使用。另外 70% 的用户流向了密码字段、社交登录、魔法链接，或者完全放弃。这是一个流程挖掘问题，而不是日志记录问题。再多的 WebAuthn 错误代码本身也无法缩小这一差距。

### 3.3 为什么身份验证日志永远不够

身份验证日志本身告诉您结果。它们不告诉您路径。所有方法的 92% 登录成功率可以掩盖通行密钥路径上的 40% 放弃率和密码路径上的 15% 放弃率，最终总体表现为“正常”。流程挖掘拒绝这种平均化。它坚持单独查看每个变体，然后按频率、成本和失败率对变体进行排名。

## 4. 身份验证流程挖掘实际上是什么样的

### 4.1 事件模型：流程、事件和结果分类

分析的单位不是单个事件，它是一个**流程**：在消费者设备上进行的一次完整的登录或凭据附加尝试，从身份验证界面加载的那一刻起，到会话完成或放弃的那一刻止。每个流程都包含细粒度事件流，携带标识元数据，并以比简单的“成功或失败”更丰富的结果分类结束。

\*\*流程元数据。\*\*每个流程都有一个流程 ID 和一个时间戳。它与应用程序、操作系统、浏览器和设备品牌绑定。它被标记了访问者类别（真实用户、手动测试人员、自动测试人员、尚未分类），以便在计算任何指标之前将自动化和机器人流量细分出去。它还带有一个流程得分和一个事件计数，这是表明“这个特定会话有多复杂”的两个最简单的信号。

\*\*登录启动。\*\*每个流程都记录了流程是如何开始的。主要的启动类型是
`text-field`（用户输入了他们的标识符）、`one-tap`（重复使用了存储的标识符）和
`cui`（[Conditional UI](https://www.corbado.com/glossary/conditional-ui)
显示了凭据，而没有明确的按钮点击）。启动是一个维度，而不是一个指标：相同的部署在 `cui`
队列上看起来可能与 `text-field`
队列非常不同，跨它们进行平均会恰恰掩盖流程挖掘旨在揭示的行为。

\*\*结果分类。\*\*结果不是“成功”或“失败”，而是映射到不同行为的几个类别之一。通行密钥的一个示例如下：

- `completed` - 仪式完成，用户已通过身份验证。
- `filtered-explicit-abort` - 用户看到了提示并明确取消。
- `filtered-implicit-abort` - 用户离开或超时，未做决定。
- `filtered-passkey-intel` - 客户端智能层故意抑制了通行密钥路径，通常是因为已知该设备/操作系统组合存在问题。
- `filtered-no-start` - 流程从未越过进入步骤。
- `not-loaded` - 身份验证界面从未完成加载。

附加仪式（凭据创建）具有平行的分类，包括当用户已有凭据时的 `completed-exclude-credentials`
情况。

\*\*漏斗层和清单层。\*\*在流程之上，两个聚合层很重要。**漏斗层**随着时间推移，通过结果、启动、完成状态、操作系统和应用程序，为登录和附加流程建立存储桶。**凭据清单层**按同步状态（已同步 vs. 未同步）、传输方式（`internal`、`hybrid`、`usb`、`nfc`、`ble`、`smart-card`）、身份验证器（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)）、操作系统和浏览器对现有通行密钥进行分组。如果没有清单层，就不可能询问给定的偏差变体是否集中在特定的凭据管理器或同步状态上。

这是使流程挖掘变得可处理的最低要求。每个事件携带足够的元数据进行分组、过滤和排名。每个流程都可以被单独追踪，这就是实现下面工作示例的基础。

### 4.2 理想路径 vs. 偏差分析

一旦事件按会话作为有向图存储，您就可以提出流程挖掘问题：有多大比例的会话遵循理想路径，对于没有遵循的会话，按频率排名的前五个偏差变体是什么？在我们的分析数据中，前五个变体通常占所有偏差的 85%。修复其中两个变体通常比在理想路径上进行任何 A/B 测试更能影响数字。

### 4.3 队列漂移检测

变体会漂移。浏览器更新、操作系统推广、凭据管理器更改可以使以前次要的变体突然占据主导地位。队列漂移检测是随着时间的推移观察每个设备/操作系统/浏览器队列的变体分布，而不是只看总体的成功率的学科。这就是团队在几个小时内而不是几个季度内发现隐性回归的方式。

## 5. 从流程挖掘到细粒度的逐步身份验证

### 5.1 为什么逐步验证一直未被充分利用

逐步身份验证已经存在了十多年。它一直未被充分利用，因为大多数团队无论风险如何，都在以相同的方式进行逐步验证：强制要求在每个高于阈值的事务上使用 OTP。这是一条生硬的规则，而不是风险评分的决定。这会在 95% 的合法高价值交易上产生摩擦，仅仅为了阻止 5% 的可疑交易。

### 5.2 风险评分旅程

利用流程挖掘数据，您可以对会话进行持续评分。设备声誉、队列基准成功率、时间异常、偏离用户自己的历史路径、凭据管理器身份、IP 信誉。风险评分然后驱动细粒度的逐步决策：只有当会话的风险得分超过交易价值阈值时，才需要第二个因素。高价值交易的低风险会话顺利通过。低价值交易的高风险会话将被要求进行逐步验证。

## 6. 这对 CIAM 供应商格局意味着什么

### 6.1 作为专业学科的旅程设计

身份验证行业历来将旅程设计捆绑在 IDP 内部。Okta、Ping、ForgeRock、[Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis)
等内部的编排引擎允许您配置流程。但它们做得不好的是观察这些流程。这种不匹配为专业的分析层腾出了空间。

### 6.2 为什么没有 IDP 会原生提供此功能

IDP 供应商优化的是控制平面：谁可以登录，使用什么凭据，在什么策略下。流程挖掘是一门数据平面学科：处理每一个事件、处于规模化状态下，并跨操作系统/浏览器/凭据管理器组合进行标准化。事件数量、基数和跨客户的基准都与原生 IDP 构建背道而驰。请参阅我们通行密钥的买与建指南中的现场说明，了解应用于 SDK 层的相同模式。

### 6.3 分析层作为新的类别

所涌现的是一个轻量级的分析和采用层，它位于 IDP 之上，从前端提取事件，针对跨部署基准对它们进行标准化，并反馈到编排决策中。它不是取代 IDP，而是让 IDP 变得可衡量。

## 7. Corbado 如何帮助实现身份验证流程挖掘

[Corbado](https://www.corbado.com/)
提供了位于现有 IDP 之上的衡量和采用层。它与 Okta、[Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis)、Ory、ForgeRock 以及自定义堆栈集成，而无需取代它们。它增加的具体内容就是流程挖掘功能：

- \*\*端到端事件分类。\*\*客户端 SDK 捕获从页面加载到断言的整个仪式，包括标识符前事件、Conditional
  UI 调用和凭据管理器选择。
- \*\*开箱即用的变体分析。\*\*该平台重建每个队列的旅程图，并按频率、恢复机会和成本对偏差变体进行排名。
- \*\*队列漂移警报。\*\*当特定操作系统、浏览器或凭据管理器的变体分布发生偏移时，该平台会在它成为第二日问题之前对其进行标记。
- \*\*跨部署基准。\*\*因为 Corbado 聚合了跨客户环境的匿名数据，在一个部署中出现的新错误或回归在到达您的环境之前就会被分类和记录下来。请参阅为何选择 Corbado以了解完整的方法。
- \*\*反馈到编排。\*\*风险评分的逐步决策和抑制规则可以被推送回 IDP，或在采用层处理，包括动态紧急停止开关和特定于队列的提醒。

## 8. 结论

通行密钥不是终点。它们是迫使第一波 CIAM 团队开始记录客户端事件的检测楔子。一旦该可观测性层存在，一门新的学科就会构建其上：身份验证流程挖掘。这是身份团队从“登录是否成功”转变为“该用户采取了哪种旅程变体，其成本是多少，以及下一个会话应该如何不同地路由”的方式。率先构建可观测性层，然后立即构建流程挖掘层的团队将为该类别设定基准。停留在整体成功率上的团队将继续错过底层的系统性变体。

## 常见问题解答

### 什么是身份验证流程挖掘？

身份验证流程挖掘是将业务流程挖掘技术应用于登录事件日志。它重建每个会话的事件有向图，将实际的身份验证旅程与设计的旅程进行比较，并按频率和成本对偏差变体进行排名。它位于身份验证可观测性之上和编排之下。

### 它与身份验证分析有何不同？

身份验证分析报告如登录成功率、流失率和通行密钥使用率等指标。流程挖掘更进一步，通过重建每个会话的完整事件序列，并询问存在哪些旅程变体，每个变体发生频率如何，以及每个变体在哪里偏离了设计的理想路径。分析报告结果，而流程挖掘解释路径。

### 为什么通行密钥的采用使这门学科成为必要？

通行密钥的推广是 CIAM 团队首先记录客户端事件的根本原因。一旦这些事件存在，聚合指标就掩盖了太多信息：92% 的成功率可以掩盖在通行密钥路径上高达 40% 的放弃率。流程挖掘拒绝这种平均化，迫使团队单独看待变体。

### 流程挖掘如何与逐步身份验证相联系？

逐步身份验证在基于风险评分而非基于规则时效果最佳。流程挖掘提供会话级别的证据（队列基准、偏离用户历史路径、设备信誉），这使得逐步引擎能够做出细粒度的决定，而不是生硬的阈值决定。

### 我的 IDP 会原生提供此功能吗？

短期内不太可能。IDP 针对控制平面进行了优化。流程挖掘是一门数据平面学科，在跨操作系统、浏览器和凭据管理器组合中具有高事件量和高基数。这种模式与我们今天在 SDK 层看到的模式相匹配，我们的买与建指南中对此进行了介绍。

### CIAM 团队首先应该衡量什么？

从通行密钥路径上的变体频率开始：有多大比例的会话遵循理想路径，以及按频率排名的前五个偏差变体是什么？这一张图表通常足以揭示对整体通行密钥采用率影响最大的两到三个修复方案。