Designing a Scalable Multi‑Account Login System: From Phone Number Registration to One‑Click Login

Most modern apps support multiple third‑party login methods (WeChat, QQ, Weibo, etc.), making a well‑designed account table and login flow essential for scalability.

1. Self‑built login system – Users register with a phone number; a random verification code is stored in Redis with a short TTL and sent via SMS. After verification, the account is created using phone+password . Problems include poor user experience and password‑forgetting issues.

1.1 Optimized registration/login – Password becomes optional; users can log in directly with phone+code and later set a password, keeping phone+password as an alternative.

2. Third‑party account integration – Example: Weibo login returns an access_token which is used to call the Weibo API and fetch user info. The system creates a local account linked to the Weibo ID, allowing future logins via the same third‑party credential. Similar steps apply to QQ, WeChat, etc.

3. Analysis of the original account model – Both native and third‑party logins follow a user‑info + password pattern, where the third‑party password is effectively the access_token .

4. New account architecture – The user data is split into a user base table (nickname, avatar, etc.) and a user authorization table (provider type, identifier, credential, token, verification status). The base table stores no passwords; the authorization table holds a one‑to‑many relationship with the base table.

5. New login flow – Continue using phone+code . For email/phone login, the server checks type='phone' and identifier='手机号' , validates password_hash against credential , and retrieves the user via user_id . Third‑party login checks type='weixin' with identifier='微信 openId' , validates the token, and logs the user in.

6. Advantages – Unlimited login type expansion, unified verified flag in the authorization table, easier tracking of login history (time, IP), and the ability to bind multiple accounts of the same provider.

7. Disadvantages – Increased code complexity, synchronization issues when a user has multiple native login methods (email, phone, username) and changes the password, and more edge‑case handling for third‑party binding.

8. One‑click login – Uses carrier SIM data to obtain the device’s phone number, eliminating the need for manual entry. Steps: SDK initialization with AppKey/AppSecret, invoking the authorization page, user consent, receiving a token, server‑side token exchange for the phone number, and finally logging in or registering with that number.