Designing a Secure Multi‑Client Token Authentication System

1. Overview

In information systems with an account framework, identity verification is crucial. With the rise of mobile internet, many client types appear, forming a "one server, N clients" pattern. Different client contexts lead to distinct security threats, session lifecycles, permission models, and interface call methods, resulting in varied authentication token approaches.

2. Usage Scenarios

Common IT service scenarios include:

User logs in via web browser.

User logs in via Android/iOS mobile app.

User accesses system through open API.

PC login authorized by scanning QR code on mobile (rare).

Mobile login authorized by scanning QR code on PC (common).

These scenarios yield different token categories:

Original account/password types

Username and password

API app ID/KEY

Session ID types

Browser token

Mobile token

API app token

Interface call type

Interface access token

Identity authorization type

PC‑mobile mutual authorization token

3. Token Types

Tokens are compared across natural attributes (usage cost, change cost, environmental risk) and controllable attributes (usage frequency, validity period).

Natural attributes

Usage cost – e.g., entering username/password versus scanning QR code.

Change cost – e.g., remembering a new password versus updating API keys.

Environmental risk – risks of eavesdropping, packet capture, forgery.

Controllable attributes

Usage frequency – network transmission frequency.

Validity period – token lifespan from creation to expiration.

The goal is security and impact control: tokens should be hard to steal and, if stolen, have limited effect.

4. Token Hierarchy

Based on the comparison table, tokens can be layered into four levels:

Password layer : traditional username/password or app ID/KEY.

Session layer : session tokens with platform‑specific lifecycles.

Call layer : access tokens for API calls.

Application layer : tokens used after API access for further authentication scenarios.

4.1 Account/Password

Traditional username/password and app ID/KEY share equivalent effects. They carry special meaning, are rarely changed, and if leaked, cause severe, long‑lasting identity compromise. Hence, transmission opportunities should be minimized.

4.2 Client Session Token

Acts as a session identifier with platform‑specific lifecycles. Web tokens have short lifespans due to public environments and convenient keyboard input. Mobile tokens have longer lifespans because devices are personal, though input cost is higher.

4.3 Access Token

Serves as a credential for server‑side API access. It is obtained by exchanging a longer‑lived session token and should have a short lifespan to limit damage if intercepted.

4.4 pam_token

Generated by an authenticated PC, encoded into a QR code, scanned by a mobile device to obtain a refresh token and subsequently an access token. It lives for 2 minutes, rotates every minute when unused, and is deleted immediately after use.

4.5 map_token

Used for mobile‑to‑PC authentication: the mobile app logs in, the PC creates an anonymous map_token, the mobile scan links it to a user, generating a web_token and finally an access_token. It shares the same 2‑minute lifecycle as pam_token.

5. Summary and Outlook

The proposed token‑based authentication system addresses token classification, privacy parameter settings, usage scenarios, and hierarchical conversion across lifecycles. It applies to various application‑level contexts such as user login, time‑limited coupons, invitation codes, QR‑code authorizations, mobile/email verification codes, multi‑platform API calls, and unified identity centers.