Mastering Token-Based Authentication: Types, Scenarios, and Best Practices

1. Overview

In information systems that maintain an account framework, identity verification is crucial. With the rise of mobile Internet, client types have proliferated, leading to a "one server, many clients" architecture.

Different clients create distinct usage scenarios, each presenting varying security threats, session lifecycles, permission models, and interface call patterns. Consequently, authentication methods also differ.

The article will analyze and organize these scenarios.

2. Usage Scenarios

Common IT service scenarios include:

User logs in via a web browser.

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

User logs in through an open API.

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

User authorizes a mobile login by scanning a QR code on the PC (common).

These scenarios lead to the following 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.

Authorization token.

Cross‑platform PC‑mobile token.

3. Token Types

Tokens are compared across several dimensions.

3.1 Natural Attributes

Usage Cost : The inconvenience caused by each method, e.g., typing a password versus scanning a QR code.

Passwords require users to open a page and type each character.

QR codes require users to take out a phone and scan.

Change Cost : Effort needed when a token changes.

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

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

Changing a QR code requires the user to open the app and scan again.

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

3.2 Controllable Attributes

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

Validity Period : The lifespan from creation to expiration.

Ultimate goal: security and impact.

Security and privacy focus on:

Making tokens hard to steal or reuse (by limiting transmission frequency).

Ensuring that even if stolen, the impact is limited (by shortening validity).

Key privacy conclusions:

Tokens exposed frequently are more likely to be intercepted.

Tokens with long lifespans cause more severe damage if captured.

Guiding principles:

Do not frequently change high‑cost tokens.

Reduce exposure frequency for stable tokens.

Keep the lifespan of frequently exposed tokens short.

After quantifying each attribute (1‑5 points), a comparison table is produced.

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

4. Token Hierarchy

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

Password layer – traditional username/password authentication.

Session layer – authentication for the duration of a user session.

Invocation layer – authentication for API calls during a session.

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

The hierarchy diagram:

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

User authenticates with username/password, generating a one‑time credential.

Different terminals create session tokens with varying lifespans.

Client session tokens exchange for short‑lived, frequently exposed interface access 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:

Unified handling of token lifecycles across platforms.

Decoupled core API authentication via access tokens.

Layered permission control, allowing each platform to manage its own policies.

4.1 Account/Password

Typical forms include traditional username/password and app_id/app_key. Characteristics:

Often carry special meaning for users and are rarely changed.

Changing them incurs high cost (user memorization or application redeployment).

If leaked, they provide long‑term identity theft.

4.2 Client Session Token

Acts as a session identifier with platform‑specific lifespans.

Usage Steps: User logs in with credentials, receives a session token.

Web Platform

Short lifespan due to public environment and easy keyboard input.

Mobile Platform

Longer lifespan because the device is personal, but input cost is higher.

4.3 Access Token

Credential for server‑side API calls. Obtained by exchanging a long‑lived session token. Because it is used frequently, its lifespan should be short to limit damage if intercepted.

Note: Adding an access token under the client token ensures a unified authentication method for API calls across different client lifecycles.

4.4 pam_token

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

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

4.5 map_token

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

Steps:

Mobile app authenticates the user.

Unauthenticated PC generates an anonymous map_token.

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

Database also creates a web_token for the same user.

PC polls for the web_token using the map_token.

PC exchanges the web_token for an access_token.

Subsequent API calls are performed normally.

5. Summary and Outlook

The proposed token‑based authentication system addresses:

Token classification.

Privacy‑related parameter settings.

Application scenarios.

Hierarchical conversion among tokens with different lifecycles.

Potential application areas include:

User login.

Time‑limited coupon distribution.

Time‑limited invitation codes.

Time‑limited QR‑code authorizations.

SMS/Email verification codes.

Multi‑platform API access.

Unified identity authentication across platforms.

Further scenarios can be explored by practitioners.