Unified Multi-Account Login: Architecture, Flow, and Database Design

Unified multi‑account login refers to using multiple third‑party accounts (e.g., NetEase, WeChat, QQ) for authentication in internet applications.

Name Explanation : It distinguishes from system‑level accounts; it focuses on external third‑party logins.

Content : The article outlines technical solution details, including flow diagrams and database schema, but does not provide concrete code implementations.

Architecture Evolution

Startup Phase

When user volume is low, a self‑built authentication system (username/password) suffices.

Username/Password Registration and Login

Process: frontend sends credentials, server validates length, uniqueness, encrypts password (MD5 + additional encryption), stores it, checks login attempt thresholds, uses Redis for lockout expiration, and proceeds with post‑login logic such as awarding points.

Mobile Number Registration and Login

Process: user submits phone number, server stores it, generates a verification code stored in Redis with a ~10‑minute TTL, user submits the code, server validates it, then logs in. Password can be added later via a “mobile password supplement” feature.

Database Design – Basic Table

自增id

用户名

密码

手机号

错误次数

1

user1

7fef6171469e80d32c0559f88b377245

13456789012

0

2

user2

7fef6171469e80d32c0559f88b377245

13456789013

0

The table stores id, username, password hash, phone number, and error count, sufficient for the two login schemes.

Third‑Party Account Integration (e.g., QQ SDK)

Sequence: client initiates third‑party login, receives access_token, openid, and login_type; server validates these with the third‑party provider, creates or updates local user records, returns a code, and exchanges the code for a token following OAuth2.0, with token expiration extended on each use.

Detailed Database Schema

Four tables are defined:

users : core user record (user_id, token, expire_in, try_times).

user_auth_rel : links users to authentication methods (id, user_id, auth_id, auth_type).

user_local_auth : stores local credentials (auth_id, user_name, password, mobile).

user_third_auth : stores third‑party credentials (auth_id, openid, login_type, access_token).

This separation allows independent handling of self‑built and third‑party accounts and supports future scaling.

Conclusion

Third‑party integration is technically straightforward; a dedicated table enables easy addition of multiple providers.

The presented design is simple, without sharding or service‑oriented architecture, and serves as a solid foundation for further enhancements.