Token-Based Authentication: Scenarios, Types, Comparison, and Hierarchical Structure

1. Overview

In information systems with an account framework, identity verification is crucial. The rise of mobile internet has created a "one server, many clients" pattern, leading to diverse usage scenarios, security threats, session lifecycles, permission models, and interface call methods.

2. Usage Scenarios

Typical IT service scenarios include:

User logs in via web browser.

User logs in via mobile (Android/iOS).

User accesses services through open APIs.

PC login authorized by scanning a QR code on a mobile device.

Mobile login authorized by scanning a QR code on a PC.

These scenarios yield different token categories.

3. Token Categories

Tokens are grouped into three main types:

1) Original Account/Password Tokens

Username and password.

API application ID/KEY.

2) Session ID Tokens

Browser token.

Mobile token.

API application token.

3) Interface Call Tokens

Interface access token.

Authorization token.

PC‑mobile mutual authorization token.

4. Token Comparison

Natural Attributes

Usage Cost : inconvenience such as manual entry of usernames/passwords or QR‑code scanning.

Change Cost : need to remember new passwords or modify application code for changed IDs/KEYs.

Environmental Risks : risks of eavesdropping, packet capture, and forgery.

Controllable Attributes

Usage Frequency : transmission frequency in the network.

Effective Time : token lifespan from creation to expiration.

Final goal: security and impact.

Security and privacy focus on making tokens hard to steal and ensuring that, if stolen, the impact remains limited.

Principles: avoid frequent changes for high‑cost tokens, reduce exposure frequency, and keep short lifespans for frequently exposed tokens.

5. Token Hierarchy

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

Password layer – traditional username/password authentication.

Session layer – authentication during a user session.

Invocation layer – API call authentication within a session.

Application layer – post‑authentication scenarios such as QR‑code or mobile verification.

5.1 Account/Password

Features:

Often carry special meaning for users.

Rarely changed; modification incurs high cost.

Leakage leads to long‑term identity theft.

5.2 Client Session Token

Functions as a session identifier with platform‑specific lifecycles.

Web tokens have short lifespans due to public environment risks and convenient keyboard entry.

Mobile tokens have longer lifespans because devices are personal but input is less convenient.

5.3 Access Token

Serves as a credential for server‑side API access; it should have a short lifespan to limit damage if intercepted.

Note: an access token is added under the client token to unify authentication across different client lifecycles.

5.4 pam_token

Generated by an authenticated PC, encoded into a QR code for mobile scanning, then exchanged for a refresh token and finally an access token.

PC user logs in.

PC generates pam_token.

PC creates QR code from pam_token.

Mobile scans QR and links to user.

Mobile receives refresh_token.

Refresh token is used to obtain access_token.

Normal API calls proceed.

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

5.5 map_token

Enables mobile‑to‑PC authentication:

Mobile authenticates the user.

Unauthenticated PC creates an anonymous map_token.

Mobile scans and binds map_token to the user in the database.

Database generates a corresponding web_token.

PC uses map_token to locate the web_token.

PC obtains access_token via the web_token.

Subsequent API calls proceed normally.

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

6. Conclusion and Outlook

The proposed token‑based authentication system addresses token classification, privacy parameter settings, usage scenarios, and hierarchical conversion across lifecycles.

Applicable scenarios include user login, time‑limited coupons, invitation codes, QR‑code authorizations, OTP verification, multi‑platform API usage, and unified authentication centers.

Further exploration of use cases is encouraged.