Token‑Based Authentication: Classification, Scenarios, and Hierarchical Design

1. Overview

In information systems that maintain an account system, identity verification is crucial. With the rise of mobile internet, many client types appear, leading to a "one server, N clients" pattern.

Different clients create different user scenarios, each with distinct security threats, session lifecycles, permission models, and interface call methods, resulting in varied authentication token types.

The article will analyse and organise these scenarios.

2. Usage Scenarios

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 through an open API and calls system services.

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

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

From these scenarios, the following token categories emerge:

Raw account/password: username/password, API app ID/KEY.

Session ID: browser token, mobile token, API application token.

Interface call: API access token, identity‑authorisation token, cross‑platform token.

3. Token Types

Tokens are compared across several dimensions.

Natural attributes

Usage cost: the inconvenience when using the token (e.g., typing a password, scanning a QR code).

Passwords require manual entry.

QR codes require pulling out a phone to scan.

Change cost: effort required when the token changes.

Changing a password forces the user to remember and re‑enter it.

Changing an API app ID/KEY requires developers to modify code and redeploy.

Changing a QR‑code token forces the user to reopen the app and scan again.

Environmental risk: exposure to eavesdropping, packet capture, or forgery.

Controllable attributes

Usage frequency: how often the token is transmitted over the network.

Validity period: the lifespan of the token from creation to expiration.

Final goal: security and impact.

Security and privacy considerations:

Tokens should be hard to steal or misuse (control transmission frequency).

If a token is stolen, its impact should be limited (control validity period).

Key conclusions about privacy breaches:

High exposure frequency increases capture risk.

Longer lifespan amplifies the damage after capture.

Guiding principles:

Do not change high‑cost tokens lightly.

Reduce exposure frequency for stable tokens.

Keep the lifespan short for frequently exposed tokens.

Quantitative scoring (1‑5) of each token’s natural and controllable attributes yields the comparison table shown below.

Note: user_name/passwd and app_id/app_key have equivalent effects.

4. Token Hierarchy

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

Password layer: traditional username/password authentication.

Session layer: authentication for the user’s login session.

Invocation layer: authentication for API calls during a session.

Application layer: authentication for scenarios after obtaining API access rights.

In a multi‑client system, the token flow is:

User enters username and password for one‑time authentication.

Different terminals generate session tokens with distinct lifecycles.

Client session tokens exchange short‑lived, frequently exposed interface tokens.

Session tokens can be refreshed to extend access_token lifespan.

Access_token can generate the shortest‑lived QR‑code token for authorisation.

Benefits of this architecture:

Unified token lifecycle across platforms.

Decoupled core API authentication (access_token) for independent deployment.

Layered permission control, allowing each platform to resolve its own access rules at the session layer.

4.1 Account/Password

Typical forms:

Traditional username and password.

Application app_id/app_key.

Characteristics:

Often carry special meaning for users.

Rarely changed; app_id/app_key changes require code redeployment.

Leakage leads to long‑term identity compromise.

4.2 Client Session Token

Functions as a session identifier; each client type has its own lifespan.

Usage steps: user authenticates with account/password, receives a session token.

Platform differences:

Web platform (short lifespan)

Higher environmental risk (public computers).

Keyboard entry is convenient.

Mobile platform (long lifespan)

Personal device reduces exposure risk.

Touch input is less convenient, increasing cost.

4.3 access_token

Function: credential for server‑side API access.

Usage steps: exchange a long‑lived session token for an access_token.

Because its exposure frequency matches API call frequency, its lifespan should be kept short to limit damage if intercepted.

Note: an additional access_token under the client token unifies authentication for APIs with different client lifecycles.

4.4 pam_token

Function: QR‑code string generated by an already‑authenticated PC for mobile scanning.

Process:

PC user logs in.

PC generates a pam_token linked to the user.

PC creates a QR‑code containing the pam_token.

Mobile scans the QR‑code, contacts the server, and binds to the user.

Mobile receives a refresh_token (long‑lived session).

Refresh_token is used to obtain an access_token.

Normal API calls proceed.

Remarks: lifespan 2 minutes, rotates every minute when idle, deleted immediately after use, rarely used in practice.

4.5 map_token

Function: QR‑code authorisation where a logged‑in mobile app authenticates a PC.

Process:

Mobile app authenticates the user.

Unauthenticated PC generates an anonymous map_token.

Mobile scans the QR‑code, creates a map_token linked to the user in the DB.

DB also generates a web_token for the same user.

PC repeatedly queries the DB with map_token to obtain the web_token.

PC uses the web_token to fetch an access_token.

Subsequent normal API calls are performed.

Remarks: lifespan 2 minutes, rotates every minute when idle, deleted immediately after use.

5. Summary and Outlook

The proposed token‑based authentication system addresses:

Token classification.

Privacy‑related token parameter settings.

Token usage scenarios.

Hierarchical conversion among tokens with different lifecycles.

Applicable application‑layer scenarios include:

User login.

Time‑limited coupon distribution.

Time‑limited invitation codes.

Time‑limited QR‑code authorisation.

Time‑limited SMS/email verification codes.

Multiple platforms calling a unified API.

Multiple platforms sharing a single authentication centre.

Further use cases await discovery.

(End)