Designing a Scalable User Authentication Model: From Simple Login to Real‑Person Verification

Preface

The article starts from the most primitive requirements and, considering requirement changes, derives the evolution of a user system. (Any misunderstandings are welcome for discussion. The story is fictional.)

1. Entrepreneurship

Old Wang, a programmer, starts a web3.0 startup that needs both app and web. The first step is a simple user login feature.

Users can register with email or phone, fill basic info (name, gender, age, etc.), get an initial password, and receive a unique platform ID. Login can be done via phone or email as shown.

2. New Requirement – Third‑Party Login

The product manager proposes using the largest platforms for authorized login to reduce registration friction, pulling basic user info (phone, email) after user consent.

Security concerns arise: email leakage could lead to brute‑force attacks, so login attempts must be limited and accounts frozen after repeated failures.

Old Wang simply adds fields for popular platform IDs and records failed login attempts; once a threshold is reached, further login calls are blocked.

3. New Requirement – User Type Differentiation

As the business grows, corporate users appear, making fields like age and gender unsuitable. The model must be split.

Old Wang designs an inheritance hierarchy: a base user table (parent) with extensions for personal and corporate users.

4. Business Expansion

The startup raises funds, launches NFT projects, and starts a cryptocurrency trading service, which requires real‑person (entity) verification and a transaction password, possibly using fingerprint or facial recognition.

4.1 Login Methods

Login methods identify which user is operating the system. Once logged in, a unique internal userId is used for all actions.

Typical login methods include:

Electronic contacts: phone number, email (supports multi‑factor recovery).

Document numbers: ID card, business license (common in government systems).

System‑generated IDs: e.g., QQ number.

Third‑party login: OAuth to obtain avatar, nickname, unique ID.

Except for system‑generated IDs, all other methods map an external unique identifier to an internal userId. Because external identifiers are virtually unlimited, adding a new field for each one is not scalable; therefore the login method is extracted from the user model.

4.2 Password

Passwords are classified into login passwords and transaction passwords. Transaction passwords support three sub‑types: regular password, fingerprint password, and facial password.

Login methods and login passwords have an N:1 relationship—multiple login identifiers share a single password. Transaction passwords are user‑level; each user has one transaction password, which can have multiple sub‑types.

Benefits of this design:

Different login methods can share the same login password, reducing user burden.

Passwords can coexist in multiple types and sub‑types.

4.3 Real‑Person Verification

Most internet platforms do not need the real identity of registrants, but financial and B2B CRM services require legal identity verification.

Instead of storing real‑person data in every user account (which would duplicate data across multiple accounts), a separate “customer” entity is introduced to hold verified real‑world identity information (ID card, passport, business license). Multiple user accounts can link to a single verified customer entity.

4.4 Other Issues

The model now supports many scenarios: a phone number uniquely identifies a real person, and the same phone can be used to log in to multiple accounts (personal, corporate, etc.). Login methods map external identifiers to internal userIds, while passwords are decoupled from userId via a targetEntity field.

5. Summary

The final model abstracts login identifiers, password types, and real‑person verification into separate, highly extensible components. It can support massive user volumes and diverse business requirements, from simple email login to complex multi‑entity authentication scenarios.