Token Classification and Hierarchical Design for Identity Authentication in Multi‑Client Systems

Overview

In information systems with account mechanisms, identity verification is crucial. With the rise of mobile internet, many client types lead to a “one server, N clients” pattern, each with different security threats, session lifecycles, permission models, and API call methods.

Consequently, authentication methods differ across scenarios, which this article analyses and organizes.

Use Cases

Common IT service scenarios include:

User logs in via a web browser and uses system services.

User logs in via a mobile device (Android/iOS) and uses system services.

User logs in via open APIs and calls system services.

User authorizes PC login by scanning a QR code on the phone (rare).

User authorizes phone login by scanning a QR code on the PC (common).

Token Types

Based on the scenario division, the following token categories are identified:

Original account‑password category Username and password API application ID / KEY

Session ID category Browser token Mobile token API application token

Interface call category API access token

Identity‑authorization category Cross‑platform QR‑code token (PC ↔ mobile)

Token Comparison

Tokens are compared on natural attributes (usage cost, change cost, environmental risk) and controllable attributes (usage frequency, validity period). Specific examples include the inconvenience of typing passwords, the need to scan QR codes, and risks such as eavesdropping, packet capture, and forgery.

Token Hierarchy

The tokens can be arranged into four layers:

Password layer – traditional username/password or app_id/app_key.

Session layer – session tokens generated after login, with client‑specific lifetimes.

Call layer – access tokens used for API calls, short‑lived and high‑frequency.

Application layer – tokens that grant specific authorizations such as QR‑code or map tokens.

Detailed Token Descriptions

Account‑Password

Traditional username/password and app_id/app_key have special meaning for users, are rarely changed, and if leaked cause long‑term identity compromise.

Client Session Token

Acts as a session, with different lifetimes on web (short) and mobile (long) platforms. Web sessions are vulnerable due to public environments; mobile sessions benefit from personal devices but have higher input cost.

access_token

Used by server‑side applications to call APIs. It is obtained from a longer‑lived session token, should have a short validity to limit impact if intercepted.

pam_token

Generated by an authenticated PC, encoded in a QR code, scanned by a mobile device to obtain a refresh token and then an access token. Lifetime is 2 minutes, refreshed every minute when idle, and deleted after use.

map_token

Generated by a mobile app to authenticate a PC. The PC initially receives an anonymous map_token, which becomes bound to a user after the mobile scan, then a web_token and finally an access_token are derived. Lifetime also 2 minutes, refreshed every minute when idle, and deleted after use.

Conclusion and Outlook

The proposed token‑based authentication architecture addresses token classification, privacy parameter settings, usage scenarios, and hierarchical conversion of tokens with different lifetimes. It can be applied to login, time‑limited coupons, invitation codes, QR‑code authorizations, mobile/email verification codes, multi‑platform API access, and unified identity centers.