A multi-dimensional interceptor-based third-party service security authentication and token hosting system

CN122994052APending Publication Date: 2026-10-27GLOBAL CARD SYSTEMS CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611285195.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-08-24
Publication Date
2026-10-27

AI Technical Summary

Technical Problem

[0004]本发明所要解决的技术问题是提供一种基于多维度拦截器的第三方服务安全认证与令牌托管系统及方法,以解决现有微服务架构中第三方服务调用存在的令牌管理分散、令牌临近过期导致接口调用失败,以及对外开放接口缺乏参数完整性校验与防重放攻击防护的技术问题

Benefits of technology

[0006]可见,通过微服务应用层内的第三方令牌管理器和第三方认证拦截器,以及外部请求接入层内的签名验证过滤器的分层协同配合,彻底解耦了业务逻辑与鉴权逻辑,统一了令牌生命周期管理,全面保障了系统内外接口调用的稳定性与高安全性。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122994052A_ABST
    Figure CN122994052A_ABST
Patent Text Reader

Abstract

The application provides a third-party service security authentication and token hosting system and method based on a multi-dimensional interceptor, and solves the technical problems of scattered token management and lack of external interface security verification in a micro-service architecture. The system includes a micro-service application layer and an external request access layer. The micro-service application layer deploys a business module, a third-party token manager, and a third-party authentication interceptor. The third-party token manager hosts access tokens using distributed caching and distributed locks, supports asynchronous refreshing and degradation fallback; the third-party authentication interceptor injects authentication information into the request header before the service request is initiated; the external request access layer deploys a signature verification filter, performs parameter integrity checking, hash algorithm signature verification, and anti-replay protection based on atomic operations on external access requests. The application realizes the decoupling of business and authentication logic, and guarantees the security of service calls.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of security authentication technology under microservice architecture, and in particular to a third-party service security authentication and token escrow system based on multi-dimensional interceptors. Background Technology

[0002] In a microservice architecture, systems frequently need to call application programming interfaces (APIs) of third-party services. These third-party services typically employ authentication protocols, requiring callers to provide valid access tokens. Traditional implementations suffer from the following problems: each business module handles its own token acquisition, caching, and refresh logic, leading to code redundancy and difficulty in maintenance; if the access token expires and is not refreshed in time, API calls will fail, impacting business continuity; when exposing APIs to the outside, there is a lack of effective request validity verification and replay attack protection mechanisms; and the business code is tightly coupled with the authentication logic, hindering system expansion and maintenance.

[0003] Therefore, how to provide a third-party service security authentication and token escrow system based on multi-dimensional interceptors has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a third-party service security authentication and token escrow system and method based on a multi-dimensional interceptor, so as to solve the technical problems of decentralized token management, interface call failure due to the expiration of tokens, and lack of parameter integrity verification and anti-replay attack protection for externally exposed interfaces in the existing microservice architecture.

[0005] The technical solutions adopted to solve the above technical problems are as follows: A third-party service security authentication and token escrow system based on a multi-dimensional interceptor includes: a microservice application layer with deployed business modules; a third-party token manager configured in the microservice application layer for unified management of access token acquisition, caching, and refreshing, wherein the third-party token manager uses distributed caching combined with distributed locks to implement token management; a third-party authentication interceptor configured in the microservice application layer to intercept service requests initiated by the business modules, obtain the access token from the third-party token manager, and inject it into the request header of the service request; an external request access layer for receiving external access requests; and a signature verification filter configured in the external request access layer for performing parameter integrity verification, hash algorithm signature verification, and replay attack protection based on atomic operations on the external access requests.

[0006] As can be seen, by working together in a layered manner with the third-party token manager and third-party authentication interceptor in the microservice application layer and the signature verification filter in the external request access layer, the business logic and authentication logic are completely decoupled, the token lifecycle management is unified, and the stability and high security of the system's internal and external interface calls are fully guaranteed.

[0007] Furthermore, the third-party token manager prioritizes reading the access token from the distributed cache. If the access token does not exist or the remaining validity period of the access token is less than a preset time threshold, a re-acquisition operation or a refresh operation is triggered.

[0008] It is evident that by utilizing the cache-first read mechanism, the frequency of network calls to third-party interfaces is reduced, thereby decreasing the overall interface request overhead of the system.

[0009] Furthermore, when the existence of the access token is detected and the remaining validity period is less than the preset time threshold, the third-party token manager triggers the refresh operation through an asynchronous thread and returns the existing access token to the current request.

[0010] As can be seen, using an asynchronous thread to trigger the refresh and directly return the existing token prevents the token refresh process from blocking the current business request and ensures the continuity of business processing under high concurrency.

[0011] Furthermore, when the access token is detected to be nonexistent, the third-party token manager acquires the distributed lock and executes double-check logic to prevent multiple threads from simultaneously performing the reacquisition operation.

[0012] It is evident that the use of distributed locks and double-checked control ensures the atomicity of token acquisition in a distributed cluster environment, avoiding concurrent conflicts and duplicate requests.

[0013] Furthermore, when the refresh operation triggered by the asynchronous thread fails, causing the access token to become invalid, the third-party token manager triggers a fallback strategy, automatically reverting to the re-login process to obtain a new access token.

[0014] As can be seen, the introduction of degradation and rollback logic ensures that the system can automatically restore the token state in extreme failure scenarios, thus maintaining the availability of the overall architecture.

[0015] Furthermore, the microservice application layer also includes a scheduled task module, which checks the remaining validity period of the access token by obtaining the distributed lock period, and performs a refresh operation when the remaining validity period is less than a preset time threshold.

[0016] As can be seen, the timed refresh mechanism, combined with the distributed lock, ensures that only a single node performs refresh detection in the cluster environment, avoiding repeated calls to third-party interface resources.

[0017] Furthermore, the third-party authentication interceptor determines the client name and only performs the access token injection operation on the specified third-party service request; while injecting the access token, it automatically adds the service identifier and content type to the request header of the service request; when the access token is empty, it refuses to set the request header.

[0018] It is evident that by utilizing the targeted interception mechanism and injecting additional information, the integrity of the outgoing request structure is ensured, and the sending of invalid authentication information is proactively intercepted, thereby improving the accuracy of request authentication processing.

[0019] Furthermore, the signature verification filter verifies the integrity of parameters including the signature value, application identifier, timestamp, and random number, and performs deduplication verification on the random number in conjunction with the distributed cache to prevent replay of the external access request.

[0020] It is evident that implementing multi-dimensional parameter integrity checks and cache anti-replay logic effectively resisted malicious interception and repeated request sending attacks.

[0021] Furthermore, the signature verification filter uses the signature value, the application identifier, the timestamp, the random number, and the application key as basic parameters. It sorts the basic parameters and the business parameters excluding the basic parameters by parameter name and performs signature calculation. The calculation result is then compared with the input signature value.

[0022] As can be seen, by using standardized parameter extraction, sorting, and hash algorithm comparison, the data consistency of the request during transmission was confirmed, preventing the business parameters from being tampered with.

[0023] This invention also provides a third-party service security authentication and token escrow method based on a multi-dimensional interceptor, applied to a microservice architecture, including the following steps: unified escrow acquisition, caching, and refreshing of access tokens, using distributed caching combined with distributed locks to implement token management; intercepting service requests initiated by business modules, acquiring the access token, and injecting it into the request header of the service request; receiving external access requests, and performing parameter integrity verification, hash algorithm signature verification, and replay attack protection based on atomic operations on the external access requests.

[0024] As can be seen, by executing the above methods and steps in a coordinated manner, the decoupling of business logic and authentication logic is achieved, token lifecycle management and external request security verification are standardized, and the stability and security of service calls under the microservice architecture are guaranteed. Attached Figure Description

[0025] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments of the invention and, together with their description, serve to explain the principles of the invention.

[0026] Figure 1 This is an architecture diagram of the third-party service security authentication and token escrow system based on multi-dimensional interceptors, as described in this invention. Figure 2 This is a flowchart of the token acquisition and refresh process in this invention; Figure 3 This is a flowchart of the signature verification process in this invention. Detailed Implementation

[0027] Various exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the invention.

[0028] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the invention or its application or use.

[0029] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, they should be considered part of the specification.

[0030] In all the examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0031] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0032] Combination Figure 1 A third-party service security authentication and token escrow system based on multi-dimensional interceptors is deployed in the microservice application layer and the external request access layer. The microservice application layer includes business modules, third-party authentication interceptors, a third-party token manager, a distributed cache, a distributed lock, and a scheduled task module. The external request access layer includes a signature verification filter.

[0033] Specifically, the third-party authentication interceptor is implemented based on the request interceptor component, the signature verification filter is implemented based on the filter component, the distributed cache is implemented using the Redis cache component, and the distributed lock is implemented using the Redisson component.

[0034] In microservice calls to third-party services, a third-party authentication interceptor performs an interception judgment before the business module initiates a service request. The third-party authentication interceptor judges the client name and allows requests that do not conform to the set name directly; for requests that conform to the specified third-party service name, it sends an instruction to the third-party token manager to obtain an access token.

[0035] Combination Figure 2 The workflow for a third-party token manager to acquire and refresh access tokens is as follows: Upon receiving an acquisition command, the third-party token manager first performs a query, reading the access token from the distributed cache and determining if the access token exists. If the access token exists, it proceeds to the validity check step, calculating whether the remaining validity period is greater than a preset time threshold (e.g., 10 minutes). If the remaining validity period is greater than the preset time threshold, it directly returns the current access token and ends the process; if the remaining validity period is less than the preset time threshold, the third-party token manager triggers a refresh operation through an asynchronous thread, simultaneously returning the existing access token to the current request and ending the process. If the access token does not exist, the third-party token manager acquires a distributed lock and executes double-checking logic to prevent multiple threads from simultaneously performing reacquisition operations. If the double-checking result indicates that another thread has already acquired the access token, it directly returns the access token and ends the process. If the double-checking result indicates that there is indeed no access token, it proceeds to the re-login process: sequentially calling the login interface to acquire a new access token, storing the new access token in the distributed cache, releasing the distributed lock, and finally returning the new access token and ending the process. During this process, if the refresh operation triggered by the asynchronous thread fails and the access token becomes invalid, the third-party token manager triggers a fallback strategy, automatically reverting to the re-login process to obtain a new access token.

[0036] Upon receiving the returned access token, the third-party authentication interceptor automatically adds additional verification parameters, such as service identifier and content type, to the request header of the service request while injecting the access token. Before performing the injection, the third-party authentication interceptor performs a null value check on the access token. If the access token is null, it refuses to set the request header and logs the operation. Subsequently, it sends the request to the third-party service application programming interface.

[0037] Combination Figure 3In security authentication scenarios involving exposed interfaces, the signature verification filter performs parameter integrity checks, hash algorithm signature verification, and atomic operation-based replay attack protection on external access requests. Upon receiving an external request, the signature verification filter first extracts the signature value (signature), application identifier (appId), timestamp (timestamp), and nonce, then proceeds to the parameter integrity verification step. If any parameter is missing, causing the parameter integrity verification to fail, an exception is thrown and processing ends. If the parameter integrity verification passes, the filter proceeds to the step of constructing a list of data to be signed. The signature verification filter uses the signature value, application identifier, timestamp, nonce, and application key (appSecret) as basic parameters, and combines these basic parameters with the business parameters (excluding the basic parameters) sorted by parameter name. After the data list is constructed, a hash algorithm is called to calculate the signature, and the calculation result is compared with the input signature value. If the signature comparison results are inconsistent, a verification failure exception is thrown and processing ends. If the signature comparison results are consistent, a deduplication check is performed on the nonce using distributed caching to prevent replay of external access requests. After successful verification, the release request step is executed, and the request data is sent to the business application programming interface.

[0038] To further illustrate the specific implementation of the hierarchical concept in this system, three embodiments are provided below that map higher-level technical features to lower-level specific components: Example 1: Third-party service invocation scenario.

[0039] The microservice needs to call the application programming interface (API) of a third-party logistics service to query logistics information. The business logic defines the third-party service interface through the request client component (FeignClient component), configuring the target service name and request path. A third-party authentication interceptor automatically intercepts requests and performs judgments, only affecting the defined target third-party service. The third-party authentication interceptor obtains an access token from the third-party token manager. When the access token is not empty, it automatically injects it along with the service identifier (X-Service-Id) and content type (Content-Type) into the request header (Authorization). The third-party token manager first reads the access token from the distributed cache (Redis). If it determines that the remaining validity period of the access token is less than the set preset time threshold (e.g., 600 seconds), it triggers a refresh operation through an asynchronous framework (CompletableFuture asynchronous thread) without blocking the current request; if the access token does not exist, the token acquisition process is called again.

[0040] Example 2: Security authentication scenario for externally accessible APIs.

[0041] The system exposes an order query interface to verify the caller's identity and prevent replay attacks. The caller constructs request parameters and generates a signature value, collecting parameters including the signature value, application identifier, timestamp, random number, application key, and specific business order number. A hash value is calculated using the SHA1 algorithm and used as the final signature value. A signature verification filter extracts the signature value, application identifier, timestamp, and random number for integrity verification. Subsequently, a list of data to be signed is constructed, the SHA1 algorithm is used to calculate the signature, and the results are compared. If the comparison passes, atomic deduplication protection is performed using a distributed cache (Redis), ultimately allowing the request to proceed.

[0042] Example 3: Timed refresh scenario in a cluster environment.

[0043] In a production environment with multiple service nodes deployed, the microservice application layer also includes a scheduled task module. The system is configured to periodically check the remaining validity of access tokens at set intervals (e.g., every 5 minutes). When a scheduled task is triggered, the current cluster node attempts to acquire a distributed lock (Redisson lock). If the distributed lock is successfully acquired within the specified time, the current node checks the remaining expiration time of the access token in the distributed cache. If the remaining expiration time is less than a preset time threshold (e.g., 1800 seconds), the refresh interface is called to update the access token status and overwrite the distributed cache. After the task is completed or an exception occurs, the node releases the distributed lock, thereby ensuring that only one node in the cluster performs the refresh operation, avoiding repeated calls to third-party interfaces.

[0044] In summary, the third-party service security authentication and token escrow system based on multi-dimensional interceptors, through the layered collaboration of a third-party token manager and third-party authentication interceptor within the microservice application layer, and a signature verification filter within the external request access layer, standardizes the logic for obtaining, caching, and refreshing access tokens, as well as the hash verification and deduplication / replay prevention steps for external requests. This decouples business logic from authentication logic and ensures the security of service calls.

[0045] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of the invention. Those skilled in the art should understand that modifications can be made to the above embodiments without departing from the scope and spirit of the invention. The scope of the invention is defined by the appended claims.

Claims

1. A third-party service security authentication and token escrow system based on a multi-dimensional interceptor, characterized in that, Include: The microservice application layer contains business modules. A third-party token manager, configured in the microservice application layer, is used to uniformly manage the acquisition, caching, and refreshing of access tokens. The third-party token manager uses distributed caching combined with distributed locks to implement token management. A third-party authentication interceptor is configured in the microservice application layer to intercept service requests initiated by the business module, obtain the access token from the third-party token manager, and inject it into the request header of the service request. External request access layer, used to receive external access requests; A signature verification filter is configured in the external request access layer to perform parameter integrity verification, hash algorithm signature verification, and replay attack protection based on atomic operations on the external access request.

2. The third-party service security authentication and token escrow system based on a multi-dimensional interceptor as described in claim 1, characterized in that, The third-party token manager first reads the access token from the distributed cache. If the access token does not exist or the remaining validity period of the access token is less than a preset time threshold, a re-acquisition operation or a refresh operation is triggered.

3. The third-party service security authentication and token escrow system based on a multi-dimensional interceptor as described in claim 2, characterized in that, When the existence of the access token is detected and the remaining validity period is less than the preset time threshold, the third-party token manager triggers the refresh operation through an asynchronous thread and returns the existing access token to the current request.

4. The third-party service security authentication and token escrow system based on a multi-dimensional interceptor as described in claim 2, characterized in that, When the access token is detected to be non-existent, the third-party token manager acquires the distributed lock and executes double-check logic to prevent multiple threads from performing the reacquisition operation simultaneously.

5. The third-party service security authentication and token escrow system based on a multi-dimensional interceptor according to claim 3, characterized in that, When the refresh operation triggered by the asynchronous thread fails and the access token becomes invalid, the third-party token manager triggers a fallback strategy, automatically reverting to the re-login process to obtain a new access token.

6. The third-party service security authentication and token escrow system based on a multi-dimensional interceptor according to claim 2, characterized in that, The microservice application layer also includes a scheduled task module. The scheduled task module checks the remaining validity period of the access token by obtaining the distributed lock period, and performs a refresh operation when the remaining validity period is less than a preset time threshold.

7. The third-party service security authentication and token escrow system based on a multi-dimensional interceptor as described in claim 1, characterized in that, The third-party authentication interceptor determines the client name and only performs the access token injection operation on the specified third-party service request; while injecting the access token, it automatically adds the service identifier and content type to the request header of the service request; when the access token is empty, it refuses to set the request header.

8. The third-party service security authentication and token escrow system based on a multi-dimensional interceptor according to claim 1, characterized in that, The signature verification filter verifies the integrity of parameters including signature value, application identifier, timestamp, and random number, and performs deduplication verification on the random number in conjunction with the distributed cache to prevent replay of external access requests.

9. The third-party service security authentication and token escrow system based on a multi-dimensional interceptor according to claim 8, characterized in that, The signature verification filter uses the signature value, the application identifier, the timestamp, the random number, and the application key as basic parameters. It sorts the basic parameters and the business parameters excluding the basic parameters by parameter name, performs signature calculation, and compares the calculation result with the input signature value.

10. A method for third-party service security authentication and token escrow based on a multi-dimensional interceptor, characterized in that, When applied to a microservices architecture, the following steps are included: Unified management of access token acquisition, caching, and refresh; token management is achieved using a combination of distributed caching and distributed locks. Before the business module initiates a service request, it intercepts the request, obtains the access token, and injects it into the request header of the service request. Receive external access requests and perform parameter integrity verification, hash algorithm signature verification, and replay attack protection based on atomic operations on the external access requests.