Mobile App Authentication Pipeline Design
In mobile applications, user identity authentication is a critical module for ensuring account security and meeting compliance requirements. As business scenarios grow more complex (from simple avatar verification to real-name authentication, account recovery, etc.) and technical approaches evolve (from integrating a single SDK to dynamically dispatching multiple third-party services), building a highly cohesive, loosely coupled, and extensible authentication system becomes a real challenge.
High-Level Design
The authentication system design needs to be forward-looking to flexibly handle business changes and technology transitions. A layered, service-oriented architecture is recommended rather than coupling authentication logic directly into business code.
- Business Application Layer: The origin point of authentication requests — scenarios like “Authentication Center” or “Account Appeal.” This layer only cares about when to initiate authentication and what results to receive, not how authentication is performed.
- Authentication Service Layer: The core of the entire pipeline, providing a unified, stable interface to upper layers while shielding complex implementation details from lower layers. All authentication requests go through a unified authentication client.
- SDK Abstraction Layer: Abstracts the capabilities of all third-party authentication SDKs, defining a unified authentication service interface covering atomic capabilities like “initialize” and “start authentication.” Whether it’s Provider A’s SDK or Provider B’s SDK, each implements this unified interface through an adapter.
- Third-Party SDK Layer: The native SDKs provided by each service vendor.
Key Design Decisions
Cloud-Based Dynamic Allocation
Which third-party SDK to use is not hardcoded on the client — instead, the business server dynamically specifies it when issuing authentication credentials. This pattern greatly enhances business flexibility and system fault tolerance, while enabling the server to conduct A/B testing across different authentication providers on dimensions like success rate, latency, and cost, driving decisions with data.
Unified Multi-SDK Abstraction
The foundation of this design lies in unified multi-SDK encapsulation. By defining standardized service interfaces and unified data models, the differences between vendor SDKs are entirely confined within independent adapters. This fully decouples upper-layer business logic from specific SDK implementations, achieving plug-and-play authentication capabilities.
Dynamic Module Loading
Since authentication is not a high-frequency feature and its dependencies (especially native libraries) can be large, the entire authentication module is designed for dynamic loading. The client only loads it through a dynamic module loader when the user first triggers the authentication flow.
Authentication Flow
sequenceDiagram
participant User
participant Business Layer
participant SDK Abstraction
participant Auth Service
participant Server
User->>Business Layer: Trigger authentication
Business Layer->>Business Layer: 1. Business auth scenario
Business Layer->>Business Layer: 2. Build standardized params
Business Layer->>SDK Abstraction: Request auth (with params)
SDK Abstraction->>SDK Abstraction: 6. SDK initialization
SDK Abstraction->>User: 7. Launch auth UI
User->>Auth Service: 8. Perform action (e.g. input credentials)
Auth Service->>Auth Service: 9. Local preprocessing
Auth Service->>Server: Request/verify cloud credentials
Server-->>Auth Service: Return credentials/verification result
Auth Service->>Auth Service: 3. Obtain cloud credentials (done)
Auth Service->>Auth Service: 4. Dynamic SO library loading
Auth Service->>Auth Service: 5. Permission check
Auth Service->>Server: 10. Report auth result
Server-->>Auth Service: Confirm report
Auth Service->>SDK Abstraction: Return auth result
SDK Abstraction->>Business Layer: Return auth result
Business Layer->>User: Display auth result