Designing a Multi‑Layer Token Authentication System for Secure Multi‑Client Apps

1 Overview

In information systems with account structures, identity verification is crucial.

With the rise of mobile internet, client types increase, leading to a "one server, N clients" pattern.

Different clients create various user scenarios:

Different environmental security threats

Different session lifecycles

Different user permission control systems

Different levels of interface invocation methods

Consequently, authentication methods also differ.

This article analyzes and organizes these scenarios.

2 Use Cases

Common IT service scenarios include:

User logs into the system via a web browser.

User logs into the system via a mobile device (Android/iOS).

User logs in using open APIs.

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

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

These scenarios yield the following token categories:

1. Original account/password category

Username and password

API app ID/KEY

2. Session ID category

Browser token

Mobile token

API app token

3. Interface call category

Interface access token

4. Identity authorization category

Token for mutual PC‑mobile authorization

3 Token Types

Tokens are compared across several dimensions:

Intrinsic attributes

1. Usage cost

Authentication may cause inconvenience, e.g.:

Account/password requires user to open a page and type each character.

QR code requires the user to take out a phone and scan.

2. Change cost

When a token changes, the user must adapt, e.g.:

Changing username/password requires memorizing and re‑entering the new password.

Changing API app ID/KEY requires third‑party apps to modify code and redeploy.

Changing an authorization QR code requires the user to reopen the app and scan again.

3. Environmental risk

Risk of being eavesdropped.

Risk of packet capture.

Risk of forgery.

Adjustable attributes

Usage frequency Frequency of transmission over the network.

Validity period Lifetime from creation to expiration.

The ultimate goal is security and impact.

Security and privacy are reflected in:

Tokens are hard to steal or misuse (by controlling transmission frequency).

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

Basic conclusions about privacy breaches:

High exposure frequency makes interception easier.

Longer lifespan leads to more severe consequences if intercepted.

Principles to follow:

Do not change high‑cost tokens lightly.

Reduce exposure frequency for tokens that should not change often.

Keep the lifespan of frequently exposed tokens as short as possible.

After quantifying each metric (1–5), the comparison table is shown:

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

4 Token Hierarchy

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

Password layer The most traditional numeric identity verification between user and system.

Session layer Authentication of the session lifecycle after user login.

Invocation layer Authentication of API calls during the session.

Application layer Scenarios or identity authentication after the user obtains interface access permissions.

Token hierarchy diagram:

In a multi‑client information system, the generation and application of these tokens are related as follows:

User enters username and password for one‑time authentication.

Different terminals generate session tokens with different lifespans.

Client session tokens exchange short‑lived but frequently exposed interface access tokens from the server.

Session tokens can generate and refresh longer‑lived access tokens.

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

Benefits of this architecture:

Uniformity: solves the normalization of token lifecycles across platforms.

Decoupling: core API access tokens can be implemented and deployed independently.

Layered control: different platforms can have distinct permission systems resolved at the session layer.

4.1 Account Password

General account/password appears as:

Traditional username and password.

Application app_id/app_key.

Characteristics:

Special significance (e.g., users may choose memorable credentials).

Rarely changed (changing app_id/app_key requires redeployment).

Leakage has far‑reaching impact.

Therefore, transmission opportunities should be minimized.

4.2 Client Session Token

Function: acts as a session, with different lifecycles per client.

Steps:

User uses account/password to obtain a session token.

Platform differences:

Web platform – short lifespan

Reasons:

Security of environment (often public, higher theft risk).

Input convenience (keyboard on PC is easy).

Mobile platform – long lifespan

Reasons:

Mobile devices are personal and less exposed.

Input via small touch screen is cumbersome, raising cost.

4.3 access_token

Function: credential for server‑side API access.

Steps:

Use a longer‑lived session token to exchange for an interface access token.

Its exposure frequency correlates with API call frequency; it should have a short lifespan to limit damage if intercepted.

Note: An access_token sits below client tokens to provide a unified authentication method for API calls.

4.4 pam_token

Function: original string of a QR code generated by an already logged‑in PC (PC Auth Mobile).

Steps:

User has authenticated on PC.

PC generates a pam_token linked to the user.

PC creates a QR code containing the pam_token link.

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

Mobile obtains a refresh_token (long‑lived session).

Refresh_token is used to get an access_token.

Normal API calls proceed.

Notes:

Lifetime: 2 minutes, then expired.

If unused, it changes every minute.

Deleted immediately after use.

This mode is rarely used.

4.5 map_token

Function: QR‑code authentication where a logged‑in mobile app authorizes a PC (Mobile Auth PC).

Steps:

Mobile app authenticates the user.

Unauthenticated PC generates an anonymous map_token.

Mobile scans and creates a map_token in the DB linked to the user (signing).

DB also generates a web_token for the user.

PC continuously uses map_token to locate the user's web_token.

PC uses web_token to obtain an access_token.

Subsequent normal API calls.

Notes:

Lifetime: 2 minutes, then expired.

If unused, it changes every minute.

Deleted immediately after use.

5 Summary and Outlook

The token‑based authentication system presented addresses:

Token classification.

Privacy parameter settings for tokens.

Token usage scenarios.

Layered conversion relationships among tokens with different lifecycles.

The design can be applied in the application layer to scenarios such as:

User login.

Time‑limited coupon distribution.

Time‑limited invitation code distribution.

Time‑limited QR‑code authorization.

Time‑limited mobile/email verification codes.

Multiple platforms calling the same API set.

Multiple platforms using a single identity authentication center.

Further use cases await discovery.

Technical implementation of token lifecycles will be covered in a future article.

Supplementary content: technical implementation of lifecycle‑aware tokens.

1 http://www.cnblogs.com/beer/p/6030882.html "Expiration without waiting" – technical solutions for lifecycle data.

Source: https://www.cnblogs.com/beer/p/6029861.html