Token Types, Hierarchies, and Usage Scenarios in Multi‑Client Authentication Systems

1. Overview

In information systems that maintain an account structure, identity verification is crucial. With the rise of the mobile‑Internet era, a single server often serves many heterogeneous clients, leading to diverse authentication needs.

2. Usage Scenarios

User logs in via a web browser.

User logs in on a mobile device (Android/iOS).

Third‑party applications use open APIs to log in.

PC login is authorized by scanning a QR code on a mobile device (less common).

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

These scenarios give rise to different token categories.

3. Token Categories

1) Raw credentials

Username and password.

API application ID / KEY.

2) Session IDs

Browser‑side token.

Mobile‑side token.

API application token.

3) Interface call tokens

Interface access token.

Authorization token.

Cross‑device (PC ↔ mobile) token.

4. Token Attribute Comparison

Natural attributes

Usage cost : e.g., users must manually type usernames/passwords, or scan QR codes.

Change cost : updating passwords, rotating API keys, or regenerating QR codes requires user or developer effort.

Environmental risk : risks of eavesdropping, packet capture, or forgery.

Controllable attributes

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

Validity period : lifespan from creation to expiration.

Goal: security and impact control.

Security and privacy are achieved by minimizing exposure frequency and limiting token lifespan, so that even if a token is stolen, its impact remains bounded.

Principles:

Do not frequently change high‑cost tokens.

Reduce exposure frequency for stable tokens.

Shorten lifespan for tokens with high exposure frequency.

5. Token Hierarchical Relationship

The tokens can be organized into four layers:

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

Session layer : session tokens generated after login, with client‑specific lifespans.

Invocation layer : tokens used for API calls during a session.

Application layer : tokens that grant permission for specific application‑level scenarios.

Typical flow in a multi‑client system:

User authenticates with username/password to obtain a one‑time credential.

Different terminals generate session tokens with distinct lifespans.

Client session tokens are exchanged for short‑lived, frequently‑exposed interface tokens.

Session tokens can be refreshed to extend the access_token lifespan.

Access tokens can generate the shortest‑lived QR‑code tokens for authorization.

Benefits of this architecture include uniformity across platforms, decoupling of core API authentication, and layered permission control.

4.1 Account/Password

Presented as traditional username/password or app ID/app key. Characteristics: meaningful to users, rarely changed, and highly damaging if leaked.

4.2 Client Session Token

Acts as a session identifier; lifespan varies by client.

Web platform

Short lifespan due to public environment and convenient keyboard input.

Mobile platform

Longer lifespan because the device is personal and less exposed, though input is less convenient.

4.3 access_token

Credential for server‑side API access. Obtained by exchanging a longer‑lived session token. High transmission frequency, so its validity period is kept short to limit impact if intercepted.

Note: Adding an access_token under the client token unifies authentication for API calls with differing lifespans.

4.4 pam_token

Generated by a logged‑in PC to create a QR‑code string for mobile authentication.

PC user logs in.

PC generates a pam_token linked to the user.

PC encodes the pam_token into a QR code.

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

Mobile receives a long‑lived refresh_token.

Refresh token is used to obtain an access_token.

Normal API calls proceed.

Lifetime: 2 minutes, then deleted. Refreshes every minute when unused. Deleted immediately after use. Rarely used in practice.

4.5 map_token

Used when a logged‑in mobile app scans a QR code to authenticate a PC.

Mobile app authenticates the user.

Unauthenticated PC generates an anonymous map_token.

Mobile scans QR code, creating a map_token linked to the user in the database.

Database also creates a web_token for the user.

PC repeatedly queries the map_token to retrieve the web_token.

PC uses the web_token to obtain an access_token.

Subsequent API calls proceed normally.

Lifetime: 2 minutes, then deleted. Refreshes every minute when unused. Deleted immediately after use.

6. Summary and Outlook

The proposed token‑based authentication system addresses token classification, privacy parameter configuration, usage scenarios, and layered conversion relationships. It can be applied to various application‑level contexts such as user login, time‑limited coupons, invitation codes, QR‑code authorizations, OTPs, multi‑platform API access, and single‑sign‑on across platforms.

Further scenarios await discovery.