Token-Based Authentication System: Scenarios, Types, and Hierarchical Design

1. Overview

In information systems with an account system, identity verification is crucial. With the rise of mobile internet, the number of client types increases, leading to a "one server, N clients" architecture.

Different clients create different usage scenarios, each with distinct security threats, session lifecycles, permission control models, and interface invocation methods, resulting in varied authentication token approaches.

2. Usage Scenarios

Common IT service scenarios include:

User logs in via web browser and uses system services.

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

Open API login and service invocation.

PC authorizes mobile login by scanning a QR code (rare).

Mobile authorizes PC login by scanning a QR code (common).

These scenarios lead to the following token categories:

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

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

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

3. Token Types

Tokens are compared across several dimensions.

Natural Attributes Comparison

Usage Cost : The inconvenience caused by the authentication method, e.g., typing a password or scanning a QR code.

Change Cost : Effort required when a token changes, such as updating passwords, modifying app IDs/KEYs, or rescanning QR codes.

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

Controllable Attributes Comparison

Usage Frequency : How often the token is transmitted over the network.

Validity Period : The lifespan of the token from creation to expiration.

Goal: security and impact control.

Security and privacy focus on:

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

Even if stolen, the impact should be controllable (by limiting validity period).

Principles:

High‑change‑cost tokens should not be altered frequently.

Tokens with high exposure frequency should have short lifespans.

Reduce exposure frequency for tokens that are costly to change.

Quantitative scoring (1‑5) of token 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: session lifecycle authentication after login.

Invocation layer: API call authentication during a session.

Application layer: post‑authentication scenarios such as QR code authorization.

Token hierarchy diagram:

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

User authenticates with username/password (one‑time).

Different terminals generate session tokens with varying lifespans.

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

Session tokens can be refreshed to extend access token lifespan.

Access tokens can generate ultra‑short‑lived QR‑code tokens for authorization.

Benefits of this architecture:

Uniformity: normalizes token lifecycles across platforms.

Decoupling: access tokens can be implemented and deployed independently.

Layered control: platform‑specific permission systems are handled at the session layer.

4.1 Account/Password

Forms include traditional username/password and app_id/app_key. Characteristics:

Special meaning to users; rarely changed.

Changing app_id/app_key requires code redeployment.

Leakage leads to long‑term identity compromise.

4.2 Client Session Token

Functions as a session identifier with platform‑specific lifespans.

Steps:

User exchanges username/password for a session token.

Web Platform (short lifespan)

Often used in public environments, higher theft risk.

Keyboard input is convenient on PC.

Mobile Platform (long lifespan)

Personal device, lower exposure risk.

Touch input is less convenient, higher entry cost.

4.3 access_token

Serves as credential for server‑side API access.

Steps: use a long‑lived session token to obtain an access token.

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

Note: an access_token sits beneath the client token to provide a unified authentication method for API calls.

4.4 pam_token

Generated by a logged‑in PC, representing the original QR code string for PC‑to‑mobile authentication.

Steps:

PC user logs in.

PC generates a pam_token linked to the user.

PC creates a QR code containing the pam_token link.

Mobile scans the QR code, contacts the server, and associates with the user.

Mobile receives a refresh_token (long‑lived session).

Refresh_token is used to obtain an access_token.

Normal API calls proceed.

Remarks: Lifetime: 2 minutes, then deleted. If unused, it rotates every minute. Deleted immediately after use. Rarely used in practice.

4.5 map_token

Enables a logged‑in mobile app to scan a QR code and authenticate a PC, completing PC login (Mobile Auth PC).

Steps:

Mobile authenticates the user.

Unauthenticated PC generates an anonymous map_token.

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

DB also generates a web_token for the user.

PC polls for the web_token using the map_token.

PC obtains an access_token via the web_token.

Normal API calls follow.

Remarks: Lifetime: 2 minutes, then deleted. If unused, it rotates every minute. Deleted immediately after use.

5. Summary and Outlook

The proposed token‑based authentication system addresses:

Token classification.

Privacy parameter configuration.

Usage scenario mapping.

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 authorizations.

Expiring SMS/email verification codes.

Multiple platforms calling a unified API.

Multiple platforms sharing a single authentication center.

Further use cases are left for readers to explore.