Integrating Redis with Spring Security OAuth2 for Distributed Unified Authentication in the Code Ape Chronic Disease Cloud Management System

1. Effect of the Implementation

The system stores identity information and tokens directly in Redis instead of using JWT. Tokens are simple UUID strings, e.g., 9d22b664-8540-48d1-98ed-4df1ce90b74f , which are shorter than JWTs.

2. Which Clients Need to Log In?

The Code Ape chronic disease cloud management system has the following clients:

WEB

PDA

PAD

Patient app

Mini‑program

Below are the first three; the remaining two are introduced later.

2.1 WEB Client

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

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

Because the system is multi‑tenant, the hospital ID must be selected during login.

2.2 PDA Client

PDA devices are used by nurses; they only need username and password. The device’s unique SN number is registered in the system (Device Management → Device List → Add) and is used to bind the PDA to a specific hospital, so no hospital selection is required.

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

2.3 PAD Client

PADs are used by doctors during ward rounds. Two login schemes are supported: (1) the same as the WEB client (hospital selection) and (2) login by binding the device’s MAC address.

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

3. Password‑Mode Login

The login interface is imported into Apifox using a provided script. After running the request, the response contains the following important fields:

3.1 access_token

The token generated after successful authentication; subsequent resource requests only need to carry this token.

Note: The token is a UUID, not a JWT.

3.2 refresh_token

Used to obtain a new access_token when the original expires, without re‑authenticating.

3.3 user_info

Contains user details such as username, authorities, IDs, department, hospital, phone, clientId, SN, and name.

4. Encryption of Password‑Mode Fields

Two parts of the request are encrypted:

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

password : the password is encrypted with AES.

5. Server‑Side Authentication Flow

After the request reaches the gateway, the flow proceeds step‑by‑step as shown in the diagram.

5.1 Gateway Pre‑Processing

The gateway applies two filters:

Captcha verification (disabled for internal clients, enabled for patient apps).

Password decryption.

Both filters are configured under codeape-auth in the gateway configuration.

5.2 OAuth2ClientAuthenticationFilter

This filter authenticates the client (client credentials) for /oauth2/token requests, converting the Authorization header into an Authentication object via a set of converters.

5.3 AuthenticationConverter

Based on request parameters and grant type, it builds the appropriate authentication token (e.g., OAuth2ResourceOwnerPasswordAuthenticationToken ).

5.4 RegisteredClientRepository

Looks up client details first in Redis cache ( codeape/sys_oauth_client_details ) and falls back to the database via a Feign call.

5.5 OAuth2TokenEndpointFilter

Intercepts token requests, creates an OAuth2AuthenticationToken , and delegates to the AuthenticationManager to produce an access token.

5.6 AuthenticationProvider

Spring Security’s AuthenticationProvider validates username/password, checks user status, and returns an authenticated token. Custom providers such as OAuth2ResourceOwnerPasswordAuthenticationProvider and OAuth2ResourceOwnerSmsAuthenticationProvider extend the base logic.

5.7 DaoAuthenticationProvider

Retrieves user details via UserDetailsService (implemented by CodeapeAppUserDetailsServiceImpl , CodeapePDAUserDetailsServiceImpl , and CodeapeUserDetailsServiceImpl ) and validates the password with a PasswordEncoder .

5.8 OAuth2AccessToken Generation

The custom CustomeOAuth2AccessTokenGenerator creates the UUID‑based access token.

5.9 OAuth2AuthorizationService Persistence

Tokens are persisted in Redis using the custom CodeapeRedisOAuth2AuthorizationService , allowing fast lookup and automatic expiration.

5.10 AuthenticationSuccessHandler

Upon successful authentication, CodeapeAuthenticationSuccessEventHandler formats and returns the token payload to the client.

Summary

The article provides a complete walkthrough of how the Code Ape chronic disease cloud management system implements a Redis‑backed Spring Security OAuth2 authentication flow, covering client types, request formats, encryption, gateway filters, converters, providers, token generation, persistence, and success handling.