How to Build Distributed Unified Login with Redis, Spring Security, and OAuth2

1. Effect

The authentication token and refresh token, together with user identity information, are stored in Redis instead of using JWT, as illustrated below.

2. Client Types

The system supports several login clients:

WEB

PDA

PAD

Patient app

Mini‑program

This article covers the first three.

3. WEB Client

The login page requires three parameters: username, password, and hospital ID. The request example is:

POST /auth/oauth2/token?grant_type=password&scope=server HTTP/1.1
Host: codeape-gateway:9999
Authorization: Basic dGVzdDp0ZXN0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
username=admin&password=YehdBPev&hosId=1659018792143663105

4. PDA Client

PDA devices (nurse handhelds) authenticate with only username and password because the device SN uniquely identifies the hospital. The login request is:

POST /auth/oauth2/token?grant_type=password&scope=server HTTP/1.1
Host: codeape-gateway:9999
Authorization: Basic dGVzdDp0ZXN0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
username=admin&password=YehdBPev&sn=3981293B102

5. PAD Client

PAD devices (doctor tablets) can log in either like the WEB client (selecting a hospital) or by binding the device MAC address. The project uses the hospital‑selection method with a request similar to the WEB example.

6. Password‑Mode Login

The password‑mode endpoint is imported into Apifox; after execution it returns an access_token (a UUID, not a JWT), a refresh_token, and a user_info object containing username, authorities, IDs, department, hospital, role codes, phone, clientId, SN, and name.

7. Encryption Details

Two fields are encrypted in the request:

Authorization : the client_id:client_secret pair is Base64‑encoded (e.g., Basic web:web).

password : the password is AES‑encrypted.

8. Server Authentication Flow

The overall flow is shown below.

9. Gateway Filters

The gateway performs two pre‑processing steps for login requests:

Captcha validation (disabled for internal clients but enabled for external patient apps).

Password decryption.

Both are implemented as filters configured under codeape-auth.

10. OAuth2ClientAuthenticationFilter

This filter validates client credentials for /oauth2/token requests, extracts the client information, and stores the authenticated client in the SecurityContext. The conversion chain includes ClientSecretBasicAuthenticationConverter and ClientSecretPostAuthenticationConverter.

11. Token Generation and Persistence

After successful authentication, the system generates an access_token using a custom CustomeOAuth2AccessTokenGenerator and a refresh_token. Tokens are persisted in Redis via the custom CodeapeRedisOAuth2AuthorizationService.

12. Login Success Handling

When authentication succeeds, the custom CodeapeAuthenticationSuccessEventHandler writes the token and user information back to the client.

Summary

The article provides a complete walkthrough of implementing a distributed authentication solution using Redis, Spring Security, and OAuth2, covering client types, request encryption, token lifecycle, gateway filtering, and custom extensions for token storage and success handling.