Token-Based Identity Authentication: Classification, Scenarios, and Security Considerations

1. Overview

In information systems that maintain an account hierarchy, verifying a user's identity is essential. With the rise of mobile internet, a single server now serves many heterogeneous clients, leading to diverse authentication requirements.

Different client types introduce distinct usage scenarios, each with its own security threats, session lifecycles, permission models, and interface call patterns. Consequently, the authentication methods for these scenarios also differ.

2. Usage Scenarios

Typical IT service scenarios include:

User logs in via a web browser.

User logs in via a mobile app (Android/iOS).

Third‑party applications use open APIs to log in.

PC scans a QR code to authorize a mobile login (rare).

Mobile scans a QR code to authorize a PC login (common).

These scenarios lead to several token categories:

2.1 Original Account‑Password Tokens

Username and password.

API application ID/KEY.

2.2 Session ID Tokens

Browser token.

Mobile token.

API application token.

2.3 Interface Call Tokens

Interface access token.

Identity‑authorization token.

Cross‑platform (PC ↔ mobile) token.

3. Token Types Comparison

The tokens are compared across natural attributes (usage cost, change cost, environmental risk) and controllable attributes (usage frequency, validity period).

Natural Attributes

1. Usage Cost

Passwords require users to type credentials manually.

QR codes require users to scan with a mobile device.

2. Change Cost

Changing a password forces users to remember and re‑enter a new secret.

Changing an app_id/app_key requires code modification and redeployment.

Changing a QR code requires the user to open the app again for scanning.

Controllable Attributes

1. Usage Frequency – how often the token is transmitted over the network.

2. Validity Period – the lifespan from creation to expiration.

Goal: security and impact mitigation.

Security and privacy are achieved when tokens are hard to steal and, if stolen, have limited impact due to short validity.

High exposure frequency increases capture risk.

Long lifespan amplifies damage after capture.

Principles:

Do not frequently change high‑cost tokens.

Reduce exposure frequency for stable tokens.

Keep the lifespan of frequently exposed tokens short.

4. Token Hierarchy

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

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

Session layer – session tokens with platform‑specific lifecycles.

Invocation layer – tokens used for API calls.

Application layer – tokens for higher‑level authorization scenarios.

The hierarchical flow is:

User authenticates with username/password to obtain a session token.

Platform‑specific session tokens are generated.

Session tokens are exchanged for short‑lived API access tokens.

Access tokens can be refreshed to extend their lifespan.

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

4.1 Account‑Password Tokens

These include traditional username/password and application app_id/app_key. They are meaningful to users, rarely changed, and if leaked, can lead to persistent identity theft.

4.2 Client Session Tokens

Function: act as a session identifier with platform‑specific lifecycles.

Steps:

User logs in with credentials to receive a session token.

Web session tokens have short lifespans due to public environments and easy keyboard input.

Mobile session tokens have longer lifespans because the device is personal, though input is less convenient.

4.3 Access Token

Function: credential for server‑side API access.

Steps: a long‑lived session token is exchanged for an access token. Because access tokens are used frequently, their lifespan should be short to limit damage if intercepted.

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

4.4 pam_token

Function: QR‑code string generated by a logged‑in PC for mobile authentication.

Process:

PC user logs in.

PC generates a pam_token.

PC creates a QR code from the pam_token.

Mobile scans the QR code, contacts the server, and links 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 generated by a logged‑in mobile app to authorize a PC.

Process:

Mobile app authenticates the user.

Unauthenticated PC creates an anonymous map_token.

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

Database also creates a web_token for the user.

PC polls for the web_token using the map_token.

PC exchanges the web_token for an access_token.

Subsequent API calls proceed normally.

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

5. Conclusion and Outlook

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

It can be applied to various application‑layer scenarios such as user login, time‑limited coupons, invitation codes, QR‑code authorizations, SMS/email verification codes, multi‑platform API access, and unified identity providers.

Further use cases remain to be explored.