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

1. Overview

In information systems with account structures, identity verification is crucial. With the rise of mobile internet, many client types appear, forming a "one server, N clients" pattern, each bringing distinct 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 Android/iOS mobile app.

User accesses system services through open APIs.

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

Mobile login authorized by scanning a QR code on the PC (common).

These scenarios lead to different categories of authentication tokens:

1) Basic Username/Password Category

Username and password.

API application ID/KEY.

2) Session ID Category

Browser token.

Mobile token.

API application token.

3) Interface Call Category

Interface access token.

Identity authorization token.

PC‑mobile mutual‑authorization token.

3. Token Comparison Dimensions

Tokens are compared on natural attributes (usage cost, change cost, environmental risk) and controllable attributes (usage frequency, validity period). The article lists specific drawbacks for each token type, such as the inconvenience of typing passwords versus scanning QR codes, and the impact of credential changes.

Natural Attribute Comparison

1. Usage Cost

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

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

2. Change Cost

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

Changing an API ID/KEY requires code modification and redeployment.

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

Environmental risks include eavesdropping, packet capture, and forgery.

Controllable Attribute Comparison

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

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

Final goal: security and impact.

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

4. Token Hierarchical Relationship

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‑authorization scenarios and identity verification.

The hierarchical diagram (see image) illustrates the flow:

In a multi‑client system, the token lifecycle proceeds as follows:

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

Different terminals generate session tokens with varying lifespans.

Client session tokens are exchanged 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 include:

Unified token lifecycle across platforms.

Decoupled core API authentication via access tokens.

Layered permission control, allowing each platform to resolve its own access rules at the session layer.

4.1 Username/Password

Two forms are considered: traditional username/password and application ID/KEY. Their characteristics include meaningfulness to users, infrequent changes, and severe impact if leaked, thus transmission should be minimized.

4.2 Client Session Token

Acts as a session identifier with platform‑specific lifespans. Web tokens have short lifespans due to public environments, while mobile tokens live longer but have higher input cost.

4.3 Access Token

Serves as the credential for server‑side API calls. It is obtained by exchanging a longer‑lived session token and should have a short lifespan to limit damage if intercepted.

Note: Adding an access token under the client token ensures a unified authentication method for API calls regardless of client token lifespan.

4.4 pam_token

Generated by a logged‑in PC, this token encodes a QR code that mobile devices can scan to authenticate the PC.

PC user logs in.

PC generates a pam_token linked to the user.

PC creates a QR code from the pam_token.

Mobile scans the QR code and associates the request 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

Allows a logged‑in mobile app to scan a QR code and authenticate a PC, establishing a shared session.

Mobile authenticates the user.

Unauthenticated PC generates an anonymous map_token.

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

The database also generates a web_token for the user.

PC polls the map_token to retrieve the web_token.

PC uses the web_token to obtain an access_token.

Subsequent API calls proceed normally.

Remarks: Lifetime: 2 minutes, then deleted. If unused, it rotates every minute. Deleted immediately 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 in the application layer for scenarios such as user login, time‑limited coupons, invitation codes, QR‑code authorizations, mobile/email verification codes, multi‑platform API access, and unified identity authentication centers.

Further use cases are left for readers to explore.

Author: 哈莫 Source: http://cnblogs.com/beer/p/6029861.html Copyright: Content originates from the web; rights belong to the original author. We credit the author and source unless proven otherwise.