可复用KYC与传统IAM系统集成：开发者蓝图 (ZH)
本文为开发者提供了将可复用KYC解决方案与现有身份和访问管理（IAM）系统集成的蓝图，涵盖架构模式、API设计和数据同步策略，旨在实现无缝、高效的身份验证。.
解耦身份验证将可复用KYC视为独立的服务层，与核心IAM分离，以保持灵活性并简化与遗留系统的集成。
优先采用API优先设计利用强大的RESTful API和webhook实现可复用KYC平台与IAM之间的无缝数据交换，支持实时更新和事件驱动架构。
拥抱可验证凭证理解可验证凭证（VCs）如何表示KYC认证，为用户跨服务共享验证数据提供标准化和保护隐私的方法。
制定数据同步策略实施清晰的策略，将可复用KYC系统中的KYC状态和验证属性同步回IAM，以实现一致的授权决策。
在数字身份至关重要的时代，企业面临着严格的法规遵从性（KYC/AML）和无摩擦用户体验的双重挑战。传统的身份和访问管理（IAM）系统虽然在身份验证和授权方面功能强大，但往往难以满足现代身份验证的动态实时需求。可复用KYC的出现提供了一个引人注目的解决方案，允许用户一次性验证其身份，并授权其在多个服务中重复使用。本文为开发者提供了一个将可复用KYC与现有（通常是单一的）企业IAM系统集成的蓝图。
理解可复用KYC和IAM集成挑战
可复用KYC从重复的、特定于服务的身份验证根本性地转变为以用户为中心的模型，在该模型中，个人拥有并控制其已验证的身份属性，通常表示为可验证凭证。这与许多遗留IAM系统形成鲜明对比，后者围绕内部用户目录、集中式身份验证协议（如LDAP、SAML或OAuth）以及通常专有的数据存储设计。
IAM集成与可复用KYC的主要挑战在于弥合这些架构和理念上的鸿沟。遗留系统可能缺乏处理可验证凭证、处理去中心化标识符（DID）或支持可复用KYC固有的用户同意驱动数据共享模型的原生能力。此外，维护数据一致性、确保合规性审计跟踪以及避免对关键业务流程造成中断是CTO和合规官关注的关键问题。
考虑一个管理员工和客户身份的典型企业IAM。它可能使用Active Directory管理员工，使用自定义数据库管理客户，并使用Okta或Auth0等联合身份提供商进行SSO。引入可复用KYC意味着集成一个新的身份验证状态和属性的真实来源，该来源必须被这些多样化的IAM组件无缝消费，而无需进行彻底的改造。
集成可复用KYC的架构模式
成功地将可复用KYC集成到企业IAM中需要深思熟虑的架构方法。我们建议采用解耦的、API优先的策略，将可复用KYC平台视为一个专业服务层。
1. 身份验证服务层模式
此模式将可复用KYC平台定位为一个独立的、仅负责身份验证和凭证颁发服务的服务。您现有的IAM仍然是身份验证和授权决策的主要来源，但它会咨询KYC服务以获取已验证的身份属性。
- 松散耦合：KYC服务独立运行，最大限度地减少对核心IAM的影响。
- 标准化接口：通过定义良好的RESTful API和webhook进行通信。
- 数据同步：KYC验证状态和相关属性（例如“is_verified”、“age_over_18”、“aml_status”）被推送到或拉取到IAM的用户配置文件中。
示例流程：
- 用户通过您的应用程序启动入职。
- 应用程序重定向到可复用KYC平台（例如，Didit托管的验证链接）。
- 用户完成KYC，并颁发可验证凭证并存储在其数字钱包中。
- 可复用KYC平台（Didit）在成功验证后向您的应用程序后端发送webhook。
- 您的后端使用已验证状态和相关属性更新IAM中的用户配置文件。
- IAM后续的身份验证/授权决策可以利用这些更新的属性。
2. 事件驱动同步模式
对于更动态的环境，事件驱动架构可以确保实时一致性。当用户的KYC状态发生变化时（例如，初始验证、AML重新筛选命中），可复用KYC平台会发出一个事件。一个集成层（例如，消息队列或无服务器函数）会消费此事件并更新相关的IAM组件。
{
"eventType": "kyc.verification.completed",
"timestamp": "2023-10-27T10:30:00Z",
"payload": {
"userId": "user_abc123",
"did": "did:didit:user_abc123",
"verificationStatus": "VERIFIED",
"verifiedAttributes": {
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "1990-01-01",
"isPEP": false,
"amlScreeningDate": "2023-10-27"
},
"credentialId": "vc_xyz456"
}
}
此webhook payload可用于更新您的内部用户存储或触发IAM中的进一步操作。
API设计和数据模型考虑
在设计您的身份架构的API时，请关注其简洁性、安全性和可扩展性。您的IAM将主要与可复用KYC系统交互，以：
- 启动验证：为用户触发新的KYC会话。
- 检索验证状态：查询用户的KYC当前状态。
- 获取已验证属性：获取KYC系统证明的特定身份数据。
- 接收Webhook通知：获取状态变化的实时更新。
要同步的关键数据点：
- 用户ID映射：将IAM中的用户与其在可复用KYC系统中的身份（例如，Didit的
clientUserId）关联起来至关重要。 - 验证状态：一个简单的布尔值（
isVerified: true/false）或枚举状态（PENDING、VERIFIED、DECLINED）。 - 合规性标志：
isPEP、onSanctionsList、amlScore、ageOver18。 - 凭证引用：指向已颁发的可验证凭证的指针，如果您的IAM需要存储这些凭证以进行审计或将来参考。
例如，Didit的API允许您通过简单的POST请求启动验证会话，提供clientUserId以链接到您的内部用户。完成后，webhook会提供全面的payload，然后可以解析并用于更新您的企业IAM中的用户配置文件。
Didit如何帮助实现可复用KYC和IAM集成
Didit旨在简化可复用KYC与各种身份架构（包括遗留系统）的集成。我们的平台提供一个单一API，可协调身份验证、生物识别、AML筛选和可验证凭证颁发。
- 单一API集成：Didit提供统一的RESTful API，使其易于与任何现有IAM系统集成。
- Webhook驱动更新：实时webhook通知您的IAM系统验证状态更改和已验证属性，从而实现用户配置文件的即时更新。
- 天生支持可复用KYC：Didit原生支持可验证凭证和eIDAS2兼容性，允许用户一次性验证并重复使用其身份，从而简化了您的IAM的后续入职和重新验证过程。
- 灵活的工作流程编排：我们的可视化工作流程构建器允许您定义复杂的KYC流程（例如，ID验证+活体检测+AML），并且结果可以轻松映射到IAM中的属性。
- 全面的数据点：Didit提供细粒度的验证结果，包括欺诈信号、AML筛选结果和生物识别匹配分数，这些可以丰富您的IAM的用户配置文件，用于高级基于风险的身份验证和授权策略。
- 开发者友好的SDK：Web和移动SDK允许在您的应用程序中无缝嵌入验证过程，而服务器到服务器API为无头集成提供完全控制。
通过利用Didit，开发者可以实现现代的可复用KYC解决方案，从而增强安全性与合规性、改善用户体验，并与现有的企业IAM基础设施无缝集成，同时减轻遗留系统的负担。
准备好开始了吗？
将可复用KYC与您的传统IAM集成不一定是一项艰巨的任务。通过采用模块化方法、利用强大的API并选择像Didit这样的综合平台，您可以现代化您的身份验证流程，增强安全性，并提供卓越的用户体验。探索Didit的文档，了解如何构建更具弹性和面向未来的身份架构。
常见问题：可复用KYC和IAM集成
什么是可复用KYC，它与传统KYC有何不同？
可复用KYC允许用户一次性向受信任的提供商验证其身份，然后通过可验证凭证在多个服务和平台中安全地重复使用该已验证身份。传统KYC通常要求用户每次在新服务注册时都进行完整的验证流程。
为什么将可复用KYC与现有IAM系统集成对企业很重要？
集成可复用KYC有助于企业通过减少入职摩擦来改善用户体验，通过强大、标准化的验证来增强安全性，并更有效地实现合规性。它还允许遗留IAM系统利用现代身份验证功能，而无需进行彻底改造，从而延长了其生命周期和价值。
开发者在集成可复用KYC时有哪些主要的技术考虑？
开发者应关注API优先的通信设计、安全的数据同步策略（例如webhook）、系统间的用户ID映射，以及如何消费和利用可验证凭证。身份验证服务层等架构模式对于维护系统模块化至关重要。
可复用KYC能否降低身份验证成本？
是的，通过允许用户重复使用其已验证身份，企业可以潜在地降低重复验证成本。像Didit这样的平台提供按成功付费的定价和批量折扣，进一步优化了身份验证的成本效益，尤其是在无缝集成到现有IAM工作流程中时。