在移动应用中，用户身份认证是保障账户安全、满足合规需求的关键模块。随着业务场景的复杂化（如从单一的头像认证到实名认证、账号找回等多场景）和技术方案的演进（如从集成单个 SDK 到动态调度多个第三方服务），如何构建一个高内聚、低耦合、可扩展的认证系统，成为了一项挑战。
宏观设计
认证系统的设计需要具备前瞻性，以灵活应对业务变化和技术选型更迭。为实现此目标，推荐采用分层的、服务化的架构，而非将认证逻辑直接耦合在业务代码中。
- 业务应用层：认证需求的发起点，例如”认证中心”、“账号申诉”等场景。这一层只关心”何时”发起认证和”拿到什么结果”，而不关心”如何”完成认证。
- 认证服务层：作为整个链路的核心，它对上层提供统一、稳定的接口，对下层屏蔽复杂的实现细节。所有认证请求都通过一个统一的认证客户端发起。
- SDK 抽象层：将所有第三方认证 SDK 的能力进行抽象，定义了统一的认证服务接口，涵盖了”初始化”、“启动认证”等原子能力。无论是服务商 A 的 SDK 还是服务商 B 的 SDK，都通过一个适配器实现这个统一接口。
- 第三方 SDK 层：即各个服务商提供的原生 SDK。
关键设计
云端动态分配
具体使用哪个第三方 SDK，不由客户端硬编码决定，而是由业务服务器在下发认证凭证时动态指定。这种模式极大地提升了业务的灵活性和系统的容灾能力，同时方便服务端实现对不同认证服务商在成功率、耗时、费用等维度的A/B 测试，用数据驱动决策。
多 SDK 统一封装与抽象
该设计的基石在于对多 SDK 的统一封装。通过定义统一的服务标准接口和统一的数据模型，将不同服务商 SDK 的差异性完全收敛在独立的适配器中。这使得上层业务逻辑完全与具体的 SDK 实现解耦，实现了认证能力的可插拔。
模块动态化
考虑到认证功能并非高频使用，且其依赖的库（尤其是底层库）体积较大，将整个认证模块设计为动态加载。当用户首次触发认证流程时，客户端才通过动态模块加载器去加载。
认证流程
sequenceDiagram
participant 用户
participant 业务应用层
participant SDK抽象层
participant 认证服务层
participant 服务端
用户->>业务应用层: 触发认证
业务应用层->>业务应用层: 1. 业务认证场景
业务应用层->>业务应用层: 2. 构建标准化参数
业务应用层->>SDK抽象层: 请求调起认证 (带参数)
SDK抽象层->>SDK抽象层: 6. SDK初始化
SDK抽象层->>用户: 7. 调起认证界面
用户->>认证服务层: 8. 执行操作 (例如输入凭证)
认证服务层->>认证服务层: 9. 本地预处理
认证服务层->>服务端: 请求获取/验证云端凭证
服务端-->>认证服务层: 返回云端凭证/验证结果
认证服务层->>认证服务层: 3. 获取云端凭证 (完成)
认证服务层->>认证服务层: 4. 动态加载SO库
认证服务层->>认证服务层: 5. 权限校验
认证服务层->>服务端: 10. 上报认证结果
服务端-->>认证服务层: 确认上报
认证服务层->>SDK抽象层: 返回认证结果
SDK抽象层->>业务应用层: 返回认证结果
业务应用层->>用户: 显示认证结果
编辑于 04/06/2026