AI API访问的生物识别加强验证：将特权与个人绑定 (ZH)

入职时的验证证明了谁创建了账户。但它无法证明现在是谁正在使用该账户。

这种差距在大多数产品中很常见，但在AI平台上却会产生严重后果，因为账户背后的资产是模型访问、信用和配额。API密钥是一个不记名令牌——谁持有它，谁就是账户。密钥会在团队内部共享，粘贴到代码库中，被出售，或被盗用。在一次干净的入职六个月后，“此账户已验证”只是一句关于过去的话。

生物识别认证弥补了这一差距。它在特权操作发生时重新验证真实用户——无需文档，无需密码，不到两秒，每次认证0.10美元。

主要收获

• 入职验证是一次性快照。生物识别认证是在关键时刻进行的检查。
• 活体检测加上与用户原始验证已存储肖像的人脸匹配。无需文档，无需密码。
• 仅限会话。没有/v3/biometric-auth/端点——它通过workflow_type=BIOMETRIC_AUTHENTICATION的会话运行。
• 关键的实现细节：使用与用户原始验证相同的vendor_data，否则无法检索存储的人脸。
• 正确的触发器：配额增加、信用授予、新API密钥发放、等级升级、添加特权团队成员，以及来自您的流量层的任何行为警报。
• 每次认证0.10美元，按成功付费，不到两秒。

为什么重新认证属于AI平台

三种故障模式使得入职快照不足以应对。

密钥共享和转售。发放给已验证开发者的密钥可能最终流向任何地方。账户仍然是已验证的；但使用它的人不是验证时的人。这是通过合法验证的账户成为僵尸网络入口的机制——对于任何只关注入职的控制来说，这是不可见的。

账户盗用。凭据被钓鱼或撞库，攻击者继承了一个具有既定声誉和更高限额的已验证账户。已验证账户是更具吸引力的盗用目标，而不是更不具吸引力的目标。

事后升级。一月份为适度访问而验证的账户在八月份请求50倍的配额增加。一月份的验证与八月份的请求无关。

在这三种情况下，账户的验证状态未变，但背后的人却不是您所想的。密码、一次性代码或会话令牌无法区分这些情况，因为它们中的每一个都是合法持有凭据的攻击者。只有生物识别检查才能提出关键问题：现在在这里的人是否是验证过的人？

工作原理

生物识别认证重用与常规身份流程相同的LivenessV3和FaceMatchV3组件。唯一的区别是参考图像的来源——它不是来自新提交文档上的肖像，而是使用用户先前验证中已存储的肖像。

这就是为什么它不需要文档，以及为什么它足够快速和便宜，可以用于正常的生产流程中。

仅限会话

没有专用的/v3/biometric-auth/端点。认证通过配置了workflow_type=BIOMETRIC_AUTHENTICATION的工作流会话进行。如果您在API参考中寻找独立端点而找不到，这就是原因。

流程

1. 在控制台中配置一个类型为BIOMETRIC_AUTHENTICATION的工作流，并记下其workflow_id。
2. 创建一个会话：

curl -X POST 'https://verification.didit.me/v3/session/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "workflow_id": "YOUR_BIOMETRIC_AUTH_WORKFLOW_ID",
    "vendor_data": "acct_8842",
    "callback": "https://yourplatform.example/auth/complete"
  }'

1. 通过返回的会话引导用户——无论是托管的，还是使用任何免费SDK嵌入的。
2. 获取决策：

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

或者订阅session.status.updated并接收Webhook。

导致集成失败的唯一细节

使用与用户原始验证相同的vendor_data。

该值是Didit检索存储肖像以进行匹配的方式。如果vendor_data是新的或不同的，则没有存储的人脸可供比较，流程无法执行您请求的操作。如果您需要有意覆盖存储的参考图像，请明确传递portrait_image——但通常的路径是每个账户一个稳定的vendor_data，在入职时设置并永久重用。

这是将vendor_data从一开始就视为您自己架构中的一级标识符的理由。这也是使人脸搜索结果能够清晰映射到您的账户的原因。

读取结果

结果会出现在liveness_checks和face_matches中。两者始终是数组——绝不是单一对象——每个项目都带有一个node_id，以便多实例工作流可以消除步骤的歧义。在各自的步骤生成数据之前，每个都为null。

警告包括LOW_LIVENESS_SCORE、人脸攻击警报、黑名单匹配和人脸匹配相似度低。阈值和拒绝操作是可配置的，因此您可以为大额信用授予设置比常规配额提升更严格的标准。

什么应该触发加强验证

此控制的价值几乎完全取决于触发器设计。触发器太多，您会制造麻烦；触发器太少，它在关键时刻就不会触发。

访问升级——配额增加、信用授予、新API密钥发放、等级升级、转移到您视为敏感的功能层。

账户变更——新的特权团队成员、账单所有者变更、付款目的地变更、密码或MFA重置。

行为警报——最有价值的触发器。当您自己的流量层标记一个账户进行集中查询或出现蒸馏形模式时，生物识别加强验证会提出流量层无法提出的问题：经过验证的用户是否仍然是操作此账户的人？通过会缩小解释范围。失败或放弃本身就是一个强烈的信号。

关联信号——带有DEVICE_RECOVERED_HIGH_CONFIDENCE的会话，或与现有已验证用户匹配的人脸，无论账户请求什么，都应触发加强验证。

休眠加升级——一个休眠数月后突然请求大幅增加的账户。不是单独的休眠；而是两者的组合。

为什么不直接要求密码或代码？

因为每个传统因素都是不记名凭据，而这里的威胁模型是持有凭据的攻击者。

一次性代码发送到文件上的电话号码或地址——攻击者在盗用后会控制这些信息，而合法的密钥共享者只是转发。密码证明对字符串的了解。硬件密钥证明对对象的持有，该对象可以与密钥一起移交。

经过活体检测的人脸匹配证明特定用户此刻在场。对于将特权绑定到个人而言，这是唯一能回答实际问题的因素。以0.10美元和不到两秒的速度，它也足够便宜，可以在真实的触发器上使用，而不是留作紧急情况。

它不做什么也值得说明。重新认证账户背后的人并不能阻止模型提取，也无法检测到它。经过验证的开发者仍然可以滥用他们持有的访问权限。这弥合了“此账户曾被验证过”和“此用户现在在这里”之间的狭窄而真实的差距。模型级输出控制和语义流量检测仍然是独立的层，它们仍然由您掌控。

用例

AI API平台将配额升级、信用授予和密钥发放置于对用户的检查之后。

代理和自动化产品在代理获得新功能或提高支出限额之前要求加强验证。

金融服务在高价值转账或付款目的地变更之前重新认证。

市场平台在付款方式变更之前重新验证卖家——这是最常见的账户盗用收益方式。

任何具有恢复流程的平台使用生物识别重新认证，而不是基于知识的问题，后者是大多数账户安全设计中最薄弱的环节。

常见问题

用户需要再次提交文档吗？

不需要。这就是重点。检查是针对他们原始验证中已存储的肖像进行的——活体检测加人脸匹配，无需文档。

如果用户从未通过Didit验证怎么办？

那么就没有存储的肖像，也就没有什么可以进行认证的。生物识别认证是一个重新验证原语；它假定在相同的vendor_data下进行过先前的验证。

需要多长时间？

推理时间不到两秒。从用户的角度来看，就是一张自拍和片刻等待。

可以在我们自己的界面中运行吗？

是的。Web、iOS、Android、React Native和Flutter SDK都是免费的，白标（0.20美元）可移除Didit品牌。

如果有人举着账户所有者的照片或视频怎么办？

这就是活体检测的作用。Didit的被动活体检测已通过iBeta Level 1演示攻击检测评估，人脸攻击警报会在警告中显示。阈值是可配置的。

费用是多少？

每次认证0.10美元，按成功付费，无最低消费。

每次登录都需要这个吗？

不需要。登录是错误的触发器——它频繁触发，而且大多是无用的。将其附加到特权升级和警报上，在这些情况下，错误成本高，频率低。

准备好开始了吗？

配置一个工作流，将其连接到您的升级点，并在所有地方重复使用。

• 阅读文档——生物识别认证概述和会话API。
• 查看产品——用户验证。
• 查看定价——每次认证0.10美元，按成功付费，无最低消费。
• 免费开始——business.didit.me，每月500次KYC验证免费。