How to Build a Unified Multi‑Account Login System with Third‑Party OAuth

Name Explanation

A multi‑account system allows an application to accept several third‑party identities (e.g., NetEase, WeChat, QQ) as login credentials instead of a single system‑level account.

Architecture Evolution

Initial native authentication (username/password)

Typical early‑stage flow:

Front‑end sends username and password to the server.

Server validates length, uniqueness and other business rules. The password is MD5‑hashed on the client, then stored with an additional encryption layer to avoid clear‑text storage.

After successful validation the record is persisted and any post‑registration logic (e.g., awarding points) is executed.

During login the server first checks a login‑attempt counter stored in Redis. If the counter exceeds a configurable threshold (e.g., 5 attempts) the account is temporarily locked using a Redis key with an expiration time.

If the threshold is not exceeded, the server verifies the credentials. Incorrect passwords increment the counter; once the limit is reached the lock is applied.

On successful authentication the server issues a session token and runs any post‑login business logic (e.g., point accrual).

Phone‑number registration & login

This flow treats the phone number as an implicit registration step followed by a verification‑code login.

User submits a phone number; the server stores it and generates a random verification code.

The code‑phone pair is cached in Redis with a typical TTL of 10 minutes.

User receives the SMS, enters the code, and the server validates it against Redis. A mismatch returns an error.

When validation succeeds the login proceeds and a session token is issued.

Optional password support can be added later as a “phone‑number password supplement” feature.

Basic native user table

id | username | password (MD5) | phone        | error_count
---+----------+----------------+--------------+------------
1  | user1    | 7fef6171469e...| 13456789012  | 0
2  | user2    | 7fef6171469e...| 13456789013  | 0

Third‑Party Account Integration (OAuth2.0 example with QQ SDK)

Sequence of interactions:

Client launches the third‑party login UI; after successful authentication the provider returns access_token, openid and expire_in.

Client forwards access_token, openid and a login_type identifier (e.g., qq, wechat) to the application server.

Server validates the token and openid against the corresponding third‑party user center.

If validation succeeds, the server checks whether a local record for the ( login_type, openid) pair exists.

Client exchanges the code for a long‑lived token according to the OAuth2.0 protocol. The token’s expiration is refreshed on each request to achieve a “never‑offline” experience.

Database design for a hybrid multi‑account system

Four tables separate native and third‑party credentials while linking them to a business‑level user record.

users (business user)
  user_id, token, expire_in, try_times

user_auth_rel (association)
  id, user_id, auth_id, auth_type   // auth_type: 'local' or 'third'

user_local_auth (native credentials)
  auth_id, user_name, password, mobile

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

This schema keeps self‑built accounts and third‑party accounts distinct, supporting a natural evolution from a pure native system to a hybrid one.

Summary

Integrating third‑party providers is straightforward; adding a dedicated user_third_auth table enables multiple OAuth2.0 providers without complicating the core login logic.

The presented design is a simple, non‑sharded, monolithic implementation suitable for modest user volumes. Scaling to large user bases would require sharding, service separation, and stronger security measures (e.g., salted password hashing, rate‑limiting, token revocation).