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