How to Build a Secure High‑Performance User Login System with Token Management

Table of Contents

Introduction

Business Diagram

Process Explanation

Verification Flow Diagram

Conclusion

Introduction

This article introduces the user login process and its technical implementation through diagrams and code, including user login, verification, obtaining user information, and handling blacklist and anonymous interfaces without verification.

Business Diagram

The login process involves user registration and login verification, illustrated with a flowchart for new and existing users.

Process Explanation

Client – Login Interface (typically mobile SMS verification)

Enter phone number

Send verification code

Enter verification code

Check "auto‑register new user"

Server – User Verification

Validate phone number and verification code

Check if user exists (initialize if not)

Generate token after verification

Return token to client

User Information Design

Verification Flow Diagram

Login verification involves two interfaces and two caches:

Verification code interface: sends code to phone number and stores it in cache with expiration.

Login interface: submits phone number and code, reads cache for matching, generates token on success, and returns it to client for subsequent requests.

Token Expiration Policy

Token expiration is defined by client type: mobile apps typically have a longer period (e.g., one week), while web tokens expire in hours; separate endpoints or header inspection can differentiate.

Business Request Token Verification

After login, each client request carries the token; a gateway validates the token using the stored user information cache.

Diagram:

Upon successful verification, internal request headers are rewritten to include user ID, account, and nickname for downstream services.

Logout Operation

The client calls a logout endpoint; the server deletes the token cache and returns HTTP 401, prompting the client to redirect to the login page.

Anonymous Requests (No Login)

Two common solutions for allowing anonymous access:

Authorized token with request‑rate limits.

Path‑based whitelist using regular expressions.

Solution 1: Authorized Token with Rate Limiting

Advantages: traceable usage and controllable request frequency; disadvantages: additional coding and configuration.

Implementation:

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Component;

import java.util.concurrent.TimeUnit;

/**
 * Authorized token request limit cache
 *
 * @author 热黄油啤酒
 * @since 2021-11-01
 */
@Component
public class AuthTokenRequestLimitCache {

    @Autowired
    private RedisTemplate<String, Integer> redisTemplate;

    private static final String AUTH_TOKEN_LIMIT_KEY_PREFIX = "auth_token_limit";

    /**
     * Increment request count and check limit
     *
     * @param token
     * @return whether to allow
     */
    public boolean incrementWithCheck(String token) {
        // 1. Get limit; null means token no longer authorized
        Integer limit = getLimit(token);
        if (limit == null) {
            return false;
        }
        // 2. Build cache key and read
        String key = String.join(":", AUTH_TOKEN_LIMIT_KEY_PREFIX, token);
        Integer count = redisTemplate.opsForValue().get(key);
        // 3. No value means first request in the minute
        if (count == null) {
            redisTemplate.opsForValue().increment(key);
            redisTemplate.expire(key, 1L, TimeUnit.MINUTES);
            return true;
        }
        // Increment and compare with limit
        Long inc = redisTemplate.opsForValue().increment(key);
        return inc <= limit;
    }

    /**
     * Get limit for a token
     *
     * @param token
     * @return limit
     */
    public Integer getLimit(String token) {
        Object limit = redisTemplate.opsForHash().get("auth_token_limit", token);
        return limit == null ? null : (Integer) limit;
    }
}

Typically only GET operations are allowed for authorized tokens; data modification is usually prohibited.

Solution 2: Path Regex Whitelist

Configure the gateway to allow requests whose paths match predefined regular expressions; otherwise, token verification is performed.

Blacklist Handling

A blacklist serves as the final security gate. Users can be added to a set; login checks this set and rejects blacklisted users. If a logged‑in user is later blacklisted, the gateway removes their token cache and returns 401.

Conclusion

The user system is fundamental, yet many developers may not have built one; this article provides a comprehensive overview of the login flow and related features.