A unified token management method, system and medium in multi-protocol API debugging
By concurrently collecting and resolving concurrent refresh signals in the API debugging tool based on priority, combined with atomic lock writing and buffer protection mechanisms, the contention problem caused by multi-way concurrent refresh is solved, ensuring the uniqueness of token refresh and the continuity of debugging, thus improving the efficiency of API debugging.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHENZHEN DEFULIAO TECH CO LTD
- Filing Date
- 2026-03-27
- Publication Date
- 2026-06-16
AI Technical Summary
Existing API debugging tools lack a mutual exclusion control mechanism for multi-way concurrent refresh trigger signals during the token refresh process. This results in the same authentication token being operated on concurrently by multiple tasks, leading to unpredictable refresh results. When concurrency fails, the original valid token is overwritten, affecting the continuity and efficiency of the debugging process.
Concurrent acquisition of multiple refresh trigger signals is adopted, and a unique valid signal is determined based on the trigger priority. A mutually exclusive refresh channel is constructed by writing through atomic locks, and the original token buffer data is retained when the refresh fails, ensuring the isolation and protection of the token during the refresh.
It effectively eliminates multi-way refresh contention, ensures the uniqueness of refresh tasks for the same authentication token in extreme scenarios, protects the original valid token, avoids the impact of refresh failure on the debugging process, and improves the continuity and efficiency of debugging.
Smart Images
Figure CN121940227B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of API debugging, and in particular to a unified token management method, system and medium for multi-protocol API debugging. Background Technology
[0002] With the widespread adoption of distributed microservice architectures and cloud-native technologies, API interfaces have become the core carrier of data interaction between systems, and API debugging tools are fundamental tools for interface development, testing, and integration. During API debugging, the validity of the authentication token directly determines the continuity of the debugging process, and the token refresh mechanism is a core element ensuring this continuity.
[0003] Currently, mainstream API debugging tools include Postman, Insomnia, and Apifox. In token refresh scenarios, these tools generally suffer from the following technical shortcomings:
[0004] On the one hand, the token refresh triggering mechanisms of existing tools are independent of each other. In actual debugging scenarios, multiple refresh triggering signals, such as timed refresh, pre-expiration refresh, and 401 / 403 response-triggered refresh, may be generated simultaneously, initiating multiple refresh requests concurrently for the same authentication token. Existing tools lack a mutual exclusion control mechanism for multiple concurrent refresh triggering signals, resulting in multiple refresh tasks operating on the same authentication token concurrently, creating race conditions and making the refresh results unpredictable.
[0005] On the other hand, existing tools directly overwrite the currently stored authentication token with the return result of the refresh request during the token refresh process. When the refresh request fails, the original valid token has been overwritten or cleared, resulting in no usable authentication token for subsequent API requests, interrupting the debugging process. Users must re-perform the login and token configuration operations to resume debugging, which seriously affects debugging efficiency and continuity.
[0006] Therefore, existing API debugging tools lack a token refresh mechanism that can mutually exclude multiple concurrent refresh trigger signals and retain the original valid token when the refresh fails. Summary of the Invention
[0007] To address the problem in existing API debugging tools where multiple token refresh trigger signals are generated concurrently, the lack of a mutual exclusion control mechanism leads to the concurrent refreshing of the same authentication token and the overwriting of the original valid token when the refresh fails, thus causing debugging interruption, this application provides a unified token management method for multi-protocol API debugging. This method solves the problems of concurrent refresh conflicts and the overwriting of the original valid token by concurrently collecting multiple refresh trigger signals, determining the unique valid trigger signal based on trigger priority, constructing a mutually exclusive refresh channel based on atomic lock write and write protection flags, and retaining the original token buffer data when the refresh fails.
[0008] One aspect of this application provides a unified token management method for multi-protocol API debugging, used in an API debugging device, comprising: receiving response data of an API request; extracting an authentication token and its corresponding lifecycle attribute from the response data according to a preset extraction rule, and encrypting and storing the authentication token; wherein the response data includes a response header, a response body, and a cookie; initiating a refresh request for the stored authentication token based on a preset refresh strategy, and updating the stored authentication token and its corresponding lifecycle attribute according to the refresh result; wherein the lifecycle attribute is data used to describe the validity period of the authentication token, including an expiration timestamp and an expiration duration; hierarchically dividing the stored authentication token into four levels of scopes, and retrieving a target token from the four levels of scopes according to priority matching before sending an API request; wherein the four levels of scopes are the token effective ranges divided according to hierarchical priority, with priority from high to low as single-interface scope, folder scope, workspace scope, and global scope; identifying the protocol type of the API request, performing a validity check on the target token, and injecting the target token into the authentication position of the API request according to the protocol adaptation rule after the check passes.
[0009] Furthermore, the four-level scope includes: global scope, working scope, folder scope, and single-interface scope;
[0010] Furthermore, the preset extraction rules include: JSONPath extraction rules, XPath extraction rules, regular expression extraction rules, and system-built-in extraction templates;
[0011] JSONPath extraction rules are used to extract authentication tokens and their corresponding lifecycle attributes from a JSON response body according to a specified path; where JSONPath is a query syntax for locating and extracting specified node values from JSON data by path expression.
[0012] XPath extraction rules are used to extract authentication tokens from XML / HTML response data by node path; XPath (XML Path Language) is a query language defined by the W3C for locating and extracting data by node path in XML and HTML documents.
[0013] Regular expression extraction rules are used to extract authentication tokens from response headers, response bodies, or cookie text by matching regular expression groups.
[0014] The system includes built-in extraction templates, including extraction rule templates for OAuth2.0, JWT, APIKey, and SessionID authentication systems. OAuth2.0 (Open Authorization 2.0) is an open authorization framework defined by RFC 6749. Its token response data typically includes access_token, token_type, expires_in, and refresh_token fields. The system's built-in extraction templates automatically configure extraction rules for these standard fields. An API Key is a static authentication key issued as a fixed string, usually passed through request headers (such as the X-API-Key field) or URL query parameters, used to identify the caller. A Session ID is a unique identifier assigned by the server to the client session, typically stored in the Set-Cookie field of the response header or in the response body, used to maintain the session state between the client and server.
[0015] Furthermore, based on a preset refresh strategy, a refresh request is initiated for the stored authentication token, including: the preset refresh strategy includes a timed refresh strategy, a pre-expiration refresh strategy, and a 401 / 403 response-triggered refresh strategy; a singleton timer is started for the authentication token based on a preset refresh cycle, and a token refresh request is initiated when the refresh cycle is reached; at most one running instance of the singleton timer exists under the same authentication token.
[0016] The system reads the lifecycle attribute of the authentication token, calculates the difference between the current time and the expiration time, and initiates a token refresh request when the difference reaches a preset refresh threshold. The lifecycle attribute is the expiration timestamp in the JWT token payload or the expiration duration configured by the user. JWT (JSON Web Token) is an open standard (RFC 7519) token based on the JSON format. The payload is the JWT's payload portion, used to store claim information, including standard fields such as exp (expiration timestamp).
[0017] Get the response status code of the API request. When the response status code is 401 / 403, initiate a token refresh request, receive the response data of the token refresh request, extract the new token data from the response data, and retry the API request with the new token data.
[0018] Furthermore, before initiating the token refresh request, the following steps are also included:
[0019] Concurrent acquisition of multiple refresh trigger signals generated by timed refresh strategy, pre-expiration refresh strategy and 401 / 403 response-triggered refresh strategy; refresh trigger signals carry the token identifier of the authentication token to be refreshed;
[0020] The valid trigger signal is determined from multiple refresh trigger signals carrying the same token identifier based on the trigger priority; the trigger priority is: 401 / 403 response trigger refresh strategy > pre-expiration refresh strategy > timed refresh strategy.
[0021] An atomic lock is written to the authentication token corresponding to the token identifier based on a valid trigger signal: where the token identifier is a unique identifier of the authentication token in the storage record, used to locate the corresponding authentication token in the multi-way refresh trigger signal;
[0022] If the atomic lock write fails, all refresh trigger signals for this operation are discarded. The atomic lock write is an operation that sets an exclusive lock flag on the target token identifier through an atomic comparison and swap operation, which is used to ensure that refresh tasks for the same token identifier are not executed concurrently.
[0023] If the atomic lock write is successful, the current token data of the authentication token is written to the original token buffer, a write protection flag is set on the storage record of the authentication token, and a token refresh request is initiated based on a valid trigger signal; wherein, the original token buffer is an isolated storage area used to temporarily store the current valid token data before the token refresh request is initiated, and the token data is kept from being overwritten before the refresh process ends.
[0024] Furthermore, based on the refresh result, the stored authentication token and its corresponding lifecycle attributes are updated, including:
[0025] If the refresh is successful, the new token data is written to the storage record through an atomic write operation, the original token buffer is cleared, and the write protection flag and atomic lock are released; the trigger time of the pre-refresh strategy before expiration is updated according to the lifecycle attributes of the new token data.
[0026] If the refresh fails, the token data in the original token buffer is retained, the consecutive failure count of the authentication token is incremented, and the token refresh request is re-initiated according to the preset backoff time sequence. When the consecutive failure count reaches the preset failure threshold, a circuit breaker flag is written to the storage record to stop the refresh process of the authentication token. The circuit breaker flag is a status identifier written to the authentication token storage record, used to mark that the authentication token has reached the consecutive failure threshold and the automatic refresh process has stopped. It can only be deactivated after manual confirmation.
[0027] Furthermore, the target token is retrieved from the fourth-level scope based on priority matching, including:
[0028] First, search the single interface scope corresponding to the API request. If a valid authentication token exists in the single interface scope, use the retrieved valid authentication token as the target token and stop searching.
[0029] If no valid authentication token exists in a single interface scope, the search will start from the innermost folder scope to which the API request belongs and proceed upwards through each folder scope. If a valid authentication token exists in the current folder scope, the retrieved valid authentication token will be used as the target token and the search will stop.
[0030] If no valid authentication token exists in the folder scope, the search will retrieve the workspace scope of the workspace to which the API request belongs. If a valid authentication token exists in the workspace scope, the retrieved valid authentication token will be used as the target token and the search will stop.
[0031] If no valid authentication token exists in the working scope, the global scope is searched. If a valid authentication token exists in the global scope, the retrieved valid authentication token is used as the target token and the search is stopped.
[0032] Furthermore, this method also includes the step of obtaining the authentication token status:
[0033] Obtain the validity and usage status of the authentication token;
[0034] The system receives the response status code of the API request. When the response status code is 401 / 403, the corresponding authentication token is marked as suspected invalid. When a preset number of 401 / 403 responses are received consecutively, the corresponding authentication token is marked as invalid. When the consecutive failure count reaches a preset failure threshold, the corresponding authentication token is disabled.
[0035] Another aspect of this application also provides a unified token management system for multi-protocol API debugging, for an API debugging apparatus, comprising:
[0036] The token extraction and storage module is used to receive the response data of API requests, extract the authentication token and the corresponding lifecycle attributes of the authentication token from the response data according to the preset extraction rules, and encrypt and store the authentication token.
[0037] The token refresh module initiates a refresh request for the stored authentication tokens based on a preset refresh strategy, and updates the stored authentication tokens and their corresponding lifecycle attributes according to the refresh results.
[0038] The scope management module divides the stored authentication tokens into four levels of scopes and retrieves the target token from the four levels of scopes based on priority matching before sending an API request.
[0039] The token injection module identifies the protocol type of the API request, performs verification on the target token, and injects the target token into the authentication position of the API request according to the protocol adaptation rules after the verification is successful.
[0040] The token status acquisition module obtains the validity and usage status of the authentication token, receives the response status code of the API request, and performs marking and disabling processing on the authentication token based on the response status code.
[0041] Compared to existing technologies, the advantages of this application are:
[0042] This application firstly acquires multiple refresh trigger signals concurrently at the signal source and determines a unique valid trigger signal based on trigger priority. This converges multiple concurrent competitions into a single deterministic input before entering the refresh execution phase, fundamentally eliminating the possibility of multiple refresh tasks executing concurrently for the same authentication token. Furthermore, an atomic lock write mechanism provides mutual exclusion protection for the refresh execution channel, ensuring that even in extreme concurrency scenarios, at most one instance of a refresh task for the same authentication token exists at any given time, thus ensuring the priority decision result is forcibly guaranteed at the execution level. Simultaneously, before issuing a refresh request, the currently valid token data is written to the original token buffer and a write protection flag is set, keeping the original valid token in a protected isolated state during refresh execution. When a refresh fails, the system directly restores the token data from the original token buffer instead of overwriting the stored record with the failure result, thereby strictly limiting the impact of refresh failure to the current refresh task and preventing it from affecting valid tokens in the storage layer. Attached Figure Description
[0043] This application will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein:
[0044] Figure 1 This is a schematic diagram of a system architecture according to this application;
[0045] Figure 2 This is a schematic diagram of a unified token method in multi-protocol API debugging according to this application;
[0046] Figure 3 This is a schematic diagram of the refresh strategy of this application;
[0047] Figure 4 This is a schematic diagram of the token concurrent refresh and atomic lock control in this application;
[0048] Figure 5 This is a schematic diagram of the token scope hierarchical retrieval in this application; Detailed Implementation
[0049] The methods and systems provided in the embodiments of this application will now be described in detail with reference to the accompanying drawings.
[0050] Example 1
[0051] like Figure 1 As shown, the unified token management method of this application is applied to an API debugging tool built on Tauri 2 + Vue 3, adopting a hybrid architecture of Rust backend and TypeScript frontend. It includes: receiving response data and extracting the stored authentication token; initiating a refresh request to update the stored authentication token; retrieving the target token from the fourth-level scope; injecting the target token into the authentication location of the API request; and continuously obtaining the validity and usage status of the authentication token. The specific implementation methods for each step are as follows... Figure 1 As shown.
[0052] Step 1, Extract the authentication token:
[0053] In this embodiment, the response data includes a response header, a response body, and a cookie. The system provides the following four extraction rules:
[0054] The JSONPath extraction rules are used to extract the authentication token and its lifecycle attributes from the JSON-formatted response body according to a specified path. Users configure the JSONPath expressions `.data.accesstoken`, `.data.access_token`, and `.data.expires_in` for the login interface, targeting response bodies with the following formats:
[0055] {
[0056] "code": 200,
[0057] "data": {
[0058] "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
[0059] "token_type": "Bearer",
[0060] "expires_in": 7200
[0061] }
[0062] }
[0063] The system parses the response body using the jsonpath-rust library, extracts the access_token field value as the authentication token, extracts the expires_in field to calculate the token expiration time, and populates the lifecycle attribute.
[0064] XPath extraction rules are used to extract authentication tokens from XML / HTML format response data by node path. The user configures the XPath expression / / response / data / access_token / text(), and the system parses the corresponding node value using the quick-xml library.
[0065] Regular expression extraction rules are used to extract authentication tokens from response headers, response bodies, or cookies by matching regular expression groups. For example, if a user configures the regular expression ` / Bearer\s+([A-Za-z0-9-=]+.[A-Za-z0-9-=]+.[A-Za-z0-9-_.+ / =]*) / `, the system will extract the content of group 1 from the Authorization field of the response header as the authentication token.
[0066] The system has built-in extraction templates, including extraction rule templates for OAuth2.0, JWT, API Key and Session ID authentication systems. After the user selects the corresponding template, the system automatically fills in the extraction rules. It also supports user-defined templates that can be saved and reused.
[0067] Step 2: Encrypt and store the token:
[0068] In this embodiment, when the API debugging device is started for the first time, a 32-byte AES-256-GCM encryption key is generated through the ring cryptography library. The encryption key is then hosted in the operating system's native security component through the keyring-rs library: Keychain on macOS, Credential Manager on Windows, and libsecret on Linux. The encryption key can only be read by the authorized process of the current user. Users can manually trigger key rotation, and all authentication tokens are automatically re-encrypted after rotation.
[0069] For the extracted plaintext authentication token, a 12-byte random initialization vector IV (compliant with NIST SP 800-38D specification) is generated. The plaintext token is then encrypted using an AES-256-GCM AEAD encryption operation with associated data using the encryption key and the IV, generating ciphertext and a 16-byte authentication tag.
[0070] The IV, ciphertext, authentication tag, token unique identifier, and encryption algorithm version are concatenated into structured encrypted data, which is then stored in a local SQLite encrypted database via rusqlite. The database file is configured with operating system-level 600 permission control, allowing only the current user to read and write it.
[0071] When the API debugging device starts, it performs a full scan of the plaintext tokens in the database, automatically executes the above encryption process on them and overwrites the storage, and at the same time uses the zeroize library to overwrite the memory and clear the plaintext token cache in the process memory, disk swap area and temporary files.
[0072] Step 3: Automatic refresh using multi-policy mutually exclusive authentication tokens:
[0073] The system initiates refresh requests for the stored authentication tokens based on a preset refresh strategy, and updates the stored authentication tokens and their corresponding lifecycle attributes according to the refresh results. The mutual exclusion triggering mechanism is a concurrency control mechanism that ensures that at most one refresh task exists for the same authentication token at any given time.
[0074] The preset refresh strategies include timed refresh strategies, pre-expiration refresh strategies, and 401 / 403 response-triggered refresh strategies, such as... Figure 3 As shown.
[0075] The timed refresh strategy involves the user configuring a refresh cycle for authentication tokens with a fixed validity period; in this embodiment, it is set to 3600 seconds. The API debugging device, based on Tokio's asynchronous runtime, starts a singleton timer for this authentication token. At most one instance of the singleton timer exists under the same authentication token to avoid repeated triggering by multiple threads. Every 3600 seconds, a token refresh request is automatically sent to the refresh interface. Upon successful refresh, the stored value and lifecycle attributes of the authentication token are updated.
[0076] Pre-expiration refresh strategy: The API debugging device parses the exp expiration timestamp in the JWT token payload through the jsonwebtoken library, or reads the expires_in expiration duration configured by the user as a lifecycle attribute, and calculates the difference between the current time and the expiration time. In this embodiment, the default preset refresh threshold is 300 seconds (which can be configured by the user to be 60 to 3600 seconds). When the difference reaches 300 seconds, the token refresh process is automatically triggered.
[0077] 401 / 403 response trigger refresh strategy: The API debugging device obtains the response status codes of all API requests through a request interceptor written in Rust. When the response status code is 401 or 403, it determines that the currently used authentication token has expired and triggers the corresponding authentication token refresh process. It receives the response data of the token refresh request, extracts the new token data from the response data, and retryes the original API request with the new token data. The whole process is imperceptible to the user.
[0078] Before initiating a token refresh request, the API debugging device executes the following mutual exclusion control flow:
[0079] like Figure 4As shown, the API debugging device concurrently collects multiple refresh trigger signals generated by the three refresh strategies mentioned above. Each refresh trigger signal carries the token identifier of the authentication token to be refreshed. Based on the trigger priority (401 / 403 response trigger refresh strategy > pre-expiration refresh strategy > timed refresh strategy), a valid trigger signal is determined from the multiple refresh trigger signals carrying the same token identifier. Based on the valid trigger signal, an atomic lock write is performed on the authentication token corresponding to the token identifier using Rust atomic operations: if the atomic lock write fails, it is determined that a refresh task is already being executed, and all refresh trigger signals in this instance are discarded; if the atomic lock write succeeds, the current token data of the authentication token is written to the original token buffer, a write protection flag is set for the storage record of the authentication token, and a token refresh request is initiated based on the valid trigger signal.
[0080] If the refresh is successful, the API debugging device writes the new token data to the storage record through an atomic write operation, clears the original token buffer, and releases the write protection flag and the atomic lock; at the same time, it recalculates and updates the trigger time of the pre-refresh strategy before expiration based on the lifecycle attribute of the new token data (re-parses the exp timestamp).
[0081] If the refresh fails, the API debugging device retains the token data in the original token buffer, accumulates the consecutive failure count of the authentication token, and re-initiates the token refresh request according to the exponential backoff time sequence of 1s / 3s / 10s; when the consecutive failure count reaches the preset failure threshold of 3 times, a circuit breaker flag is written to the storage record, the automatic refresh process of the authentication token is stopped, the token is marked as pending manual confirmation, and a graded alarm is pushed to the user through the front-end pop-up window and system notification.
[0082] Step 4: Retrieve the target token based on the four-level hierarchical scope:
[0083] The stored authentication tokens are hierarchically divided into four scopes, and the target token is retrieved based on priority before sending an API request.
[0084] The fourth-level scope is defined as follows:
[0085] Global scope: The authentication token is effective for all workspaces, all environments, and all API requests within the API debugging device. It is suitable for basic authentication tokens that are universally applicable in the test environment, such as the unified API Key at the gateway layer.
[0086] Workspace scope: Authentication tokens are only effective for all API requests within their respective workspaces and have higher priority than global scopes. Authentication tokens in different workspaces are isolated from each other. This is suitable for unified authentication tokens for a single project and a single environment, such as a dedicated token for the production environment of project A and a dedicated token for the test environment of project B that are completely isolated.
[0087] Folder scope: The authentication token is only effective for API requests within its own folder. It has higher priority than the working scope and the global scope. Subfolders automatically inherit the token configuration of the parent folder. It is suitable for dedicated authentication scenarios divided by module within a project.
[0088] Single API Scope: The authentication token is only valid for the currently specified single API request and has higher priority than all parent scopes. It is suitable for administrator privilege-overriding APIs that require special authentication.
[0089] The API debugging tool uses a Rust-written matching execution unit to retrieve valid tokens in the following priority order before sending an API request:
[0090] First, search the single interface scope corresponding to the current API request; if a valid authentication token exists in the single interface scope, then use the valid authentication token as the target token and stop searching.
[0091] like Figure 5 As shown, if no valid authentication token exists in a single interface scope, the search proceeds upwards from the innermost folder scope to which the API request belongs, level by level (by iterating through the request.folder_hierarchy list). If a valid authentication token exists in the current folder scope, the valid authentication token is used as the target token and the search stops.
[0092] If no valid authentication token exists in the folder scope, the workspace scope of the workspace to which the API request belongs is retrieved. The workspace scope corresponds to the current debugging environment of the workspace (through a combined index of request.workspace_id and request.env_id), and the workspace scopes in different debugging environments are independent of each other. If a valid authentication token exists in the workspace scope, the valid authentication token is used as the target token and the retrieval stops.
[0093] If no valid authentication token exists in the working scope, the global scope is searched; if a valid authentication token exists in the global scope, the valid authentication token is used as the target token.
[0094] If no valid authentication token exists in any of the four scopes, the API debugging device will send a notification to the user that no token is available.
[0095] The global scope, working area scope, folder scope, and single interface scope are arranged in a parent-child hierarchy according to their priority from low to high. If a child scope does not have a dedicated authentication token configured, it inherits the authentication token configuration of the parent scope. If a dedicated authentication token has been configured, it overrides the authentication token configuration of the parent scope.
[0096] Preferably, this embodiment also includes obtaining the validity and usage status of the authentication token, and performing marking and disabling processing on authentication tokens with abnormal status:
[0097] The API debugging device continuously obtains the validity and usage status of authentication tokens through request interceptors. When the response status code of an API request is 401 or 403, the corresponding authentication token is marked as potentially invalid; when two consecutive 401 or 403 responses are received, the corresponding authentication token is marked as invalid; when the consecutive failure count reaches a preset failure threshold of 3 times, the corresponding authentication token is disabled and its participation in subsequent scope retrieval and matching is stopped.
[0098] The API debugging device is set to a 300ms batch processing window to perform batch statistics on the number of times the authentication token is used, the last time it was used, and the request success rate, and writes them to the database all at once to avoid the performance impact of high-frequency single writes.
[0099] The API debugging device scans the stored authentication tokens every day at a preset scan cycle in the early morning. It pushes cleanup reminders to users for expired authentication tokens that cannot be automatically refreshed, authentication tokens that have not been used for 90 consecutive days, and authentication tokens that have been disabled.
[0100] Example 2
[0101] To verify the technical solution in Example 1, systematic verification tests were conducted in the following experimental environment:
[0102] The hardware environment consisted of an Intel Core i7-12700H processor, 32GB of DDR4 memory, and 1TB of NVMe SSD storage; the software environment comprised three platforms: Windows 11 22H2, macOS Sonoma 14.0, and Ubuntu 22.04 LTS, with a development architecture of Tauri 2.0 + Rust 1.75 + Vue 3; the comparison tools were Postman v11.8.0 and Apifox v2.6.31; the test server covered six protocols: HTTP / HTTPS, WebSocket, gRPC, GraphQL, MQTT, and CoAP, as well as mainstream authentication systems such as OAuth2.0, JWT, and API Key.
[0103] Based on the extraction rules described in Example 1, three types of simulated login interfaces were built, returning response data in JSON, XML, and unstructured text formats, respectively. The responses included access_token, expires_in, and token_type fields. Four extraction rules were configured: JSONPath, XPath, regular expressions, and the system's built-in OAuth2.0 template. Each rule was executed independently 100 times to verify the automatic extraction effect of the authentication token and lifecycle attributes, and to verify the storage location of the encryption key in the operating system's native security components, the token's encrypted storage status, and the automatic migration and memory cleanup effect of the plaintext token.
[0104] The experimental results are as follows: JSONPath extraction success rate 100% (100% of 100 times), XPath extraction success rate 100% (100% of 100 times), regular expression extraction success rate 100% (100% of 100 times), and built-in template one-click extraction success rate 100% (100% of 100 times); the operating system's native security components are fully compatible with Windows, macOS, and Linux platforms (100%); after automatic migration and cleanup of plaintext tokens, there are no plaintext residues (100%); encryption algorithm compliance verification: AES-256-GCM complies with the NIST SP 800-38D specification, and the national cryptographic SM4-GCM complies with the GM / T 0002-2012 standard.
[0105] For the three refresh strategies and mutual exclusion triggering mechanism in Implementation Example 1, a token refresh interface was built, with the JWT token validity period set to 2 hours, a pre-refresh threshold of 5 minutes, and a timed refresh cycle of 1 hour. The three refresh strategies were enabled respectively to verify the single-strategy triggering logic and the mutual exclusion of multiple strategies; abnormal scenarios of the refresh interface were simulated to verify the execution logic of exponential backoff retries (1s / 3s / 10s) and the circuit breaker mechanism; a 72-hour continuous long-term debugging test was performed to count the number of debugging interruptions caused by token expiration.
[0106] The experimental results are as follows: the policy triggering accuracy was 100%; the multi-policy mutual exclusion verification showed no duplicate refresh triggers (100% mutual exclusion); the retry and circuit breaker mechanism accuracy was 100%; and the number of interruptions during 72 hours of long-term debugging was 0. These results demonstrate that the mutual exclusion triggering mechanism described in Example 2 effectively eliminates the race conditions when multiple refresh trigger signals are executed concurrently. The original valid tokens are fully preserved even in refresh failure scenarios, ensuring the continuity of the debugging process.
[0107] For the four-level scope division and priority matching retrieval process in Example 1, a test project architecture was built, configuring independent authentication tokens for the four levels of scope: global, working area, folder, and single interface. Nested folders and multi-environment isolation rules for development / testing / production were also configured. A total of 1000 request matching operations at different levels were executed to verify whether the priority matching results conformed to the priority rule of single interface > folder > working area > global, and to verify the inheritance and overriding logic of child scopes on parent tokens and the token isolation effect in multiple environments.
[0108] The experimental results are as follows: priority matching accuracy is 100% (1000 / 1000 times), nested scope inheritance accuracy is 100%, and multi-environment token isolation accuracy is 100%.
[0109] To address the cross-protocol injection issue in Example 1, test servers with Bearer token authentication were built for six protocols: HTTP / HTTPS, WebSocket, gRPC, GraphQL, MQTT, and CoAP. These servers covered gRPC bidirectional streaming, GraphQL subscription, and MQTT QoS 0 / 1 / 2 communication modes. A unified token pool was configured in the system, eliminating the need for separate configuration for each protocol. API requests for each protocol were initiated independently, with each protocol executed 100 times, and the authentication success rate was statistically analyzed.
[0110] The experimental results are as follows: the authentication success rate of the six protocols HTTP / HTTPS, WebSocket, gRPC, GraphQL, MQTT, and CoAP is 100% (100% success rate).
[0111] Regarding the token status acquisition mechanism in Example 1, a token expiration scenario was simulated, and two consecutive 401 responses were returned to verify the automatic marking logic for suspected and expired tokens; a scenario of three consecutive refresh failures was simulated to verify the automatic token disabling and tiered alarm triggering logic; the entire process of token extraction, encryption, refresh, injection, modification, and deletion was executed to verify the integrity of the audit logs and the immutability of the SHA-256 hash verification; the audit log integrity rate and anomaly alarm accuracy rate of the entire process operation over 30 days were statistically analyzed.
[0112] The experimental results are as follows: the accuracy rate of invalidation marking is 100%, the integrity rate of audit logs is 100%, the accuracy rate of abnormal alarms is 100%, and the invalid token recognition rate is 100%; the audit logs have SHA-256 hash verification, and the hash values do not match after modification, verifying the immutability; the key and token encryption databases are completely physically separated, which meets the requirements of Level 3 of the "Network Security Protection 2.0"; there are no plaintext token residues in process memory, disk swap area and temporary files, which meets the data security standards of the financial industry.
[0113] Under the same experimental environment, the core metrics of this application were compared with those of Postman v11.8.0 and Apifox v2.6.31. The results are shown in Table 1 below:
[0114] Table 1 Comparison of core performance indicators of this application and existing mainstream API debugging tools.
[0115]
[0116] Comparative data shows that: the configuration time for single-interface authentication in this application has been reduced from more than 120 seconds to 3 seconds, improving configuration efficiency by more than 97.5%; peak memory usage has been reduced by more than 80% compared to existing tools; based on the four-level scope and unified token injection mechanism, the cost of multi-protocol joint debugging and adaptation has been reduced by more than 90%; the interruption rate during 72-hour long-term debugging has been reduced to 0%, and the interruption rate caused by token expiration has been reduced by 100% compared to Postman (18.2%) and Apifox (12.5%); the token matching response time is 0.2ms, which is more than 500% faster than existing tools.
[0117] The foregoing illustrative description of the invention and its embodiments is not restrictive and can be implemented in other specific forms without departing from the spirit or essential characteristics of the invention. The accompanying drawings are only one embodiment of the invention, and the actual structure is not limited thereto. No reference numerals in the claims should limit the scope of the claims. Therefore, if a person skilled in the art, inspired by this description, designs a similar structure and embodiment without departing from the spirit of the invention, such design should fall within the scope of protection of this application. Furthermore, the word "comprising" does not exclude other elements or steps, and the word "a" preceding an element does not exclude the inclusion of "a plurality" of that element. Multiple elements stated in the product claims may also be implemented by a single element through software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any specific order.
Claims
1. A unified token management method for multi-protocol API debugging, used in an API debugging device, characterized in that, include: The system receives response data from API requests, extracts the authentication token and its corresponding lifecycle attributes from the response data according to preset extraction rules, and stores the authentication token in encrypted form. The response data includes response headers, response body, and cookies. Based on the preset refresh strategy, a refresh request is initiated for the stored authentication token, and the stored authentication token and its corresponding lifecycle attributes are updated according to the refresh result. The stored authentication tokens are hierarchically divided into four levels of scope. Before sending an API request, the target token is retrieved from the four levels of scope based on priority matching. Identify the protocol type of the API request, perform a validity check on the target token, and inject the target token into the authentication location of the API request according to the protocol adaptation rules after the verification is passed; Before initiating the token refresh request, the following is also included: Concurrent acquisition of multiple refresh trigger signals generated by timed refresh strategy, pre-expiration refresh strategy and 401 / 403 response-triggered refresh strategy; refresh trigger signals carry the token identifier of the authentication token to be refreshed; The valid trigger signal is determined from multiple refresh trigger signals carrying the same token identifier based on the trigger priority; the trigger priority is: 401 / 403 response trigger refresh strategy > pre-expiration refresh strategy > timed refresh strategy. An atomic lock is written to the authentication token corresponding to the token identifier based on a valid trigger signal: If the atomic lock write fails, all refresh trigger signals for this operation are discarded. If the atomic lock write is successful, the current token data of the authentication token is written to the original token buffer, a write protection flag is set on the storage record of the authentication token, and a token refresh request is initiated based on a valid trigger signal. Update the stored authentication token and its corresponding lifecycle attributes based on the refresh results, including: If the refresh is successful, the new token data is written to the storage record through an atomic write operation, the original token buffer is cleared, and the write protection flag and atomic lock are released; the trigger time of the pre-refresh strategy before expiration is updated according to the lifecycle attributes of the new token data. If the refresh fails, the token data in the original token buffer is retained, the consecutive failure count of the authentication token is incremented, and the token refresh request is re-initiated according to the preset backoff time sequence; when the consecutive failure count reaches the preset failure threshold, a circuit breaker flag is written to the storage record to stop the refresh process of the authentication token.
2. The unified token management method for multi-protocol API debugging according to claim 1, characterized in that: The four levels of scope include: global scope, working scope, folder scope, and single-interface scope.
3. The unified token management method for multi-protocol API debugging according to claim 2, characterized in that: The preset extraction rules include: JSONPath extraction rules, XPath extraction rules, regular expression extraction rules, and system-built-in extraction templates; JSONPath extraction rules are used to extract the authentication token and its corresponding lifecycle attributes from the JSON response body according to a specified path. XPath extraction rules are used to extract authentication tokens from XML / HTML format response data by node path; Regular expression extraction rules are used to extract authentication tokens from response headers, response bodies, or cookie text by matching regular expression groups. The system has built-in extraction templates, including extraction rule templates for OAuth2.0, JWT, APIKey and SessionID authentication systems.
4. The unified token management method for multi-protocol API debugging according to claim 2, characterized in that: Based on a preset refresh policy, a refresh request is initiated for the stored authentication token, including: The preset refresh strategies include timed refresh strategy, pre-refresh strategy before expiration strategy, and 401 / 403 response triggered refresh strategy; A singleton timer is started for the authentication token based on a preset refresh period. When the refresh period is reached, a token refresh request is initiated. There can be at most one running instance of the singleton timer under the same authentication token. Read the lifecycle attribute of the authentication token, calculate the difference between the current time and the expiration time, and initiate a token refresh request when the difference reaches the preset refresh threshold; the lifecycle attribute is the expiration timestamp in the JWT token payload or the expiration duration configured by the user; Get the response status code of the API request. When the response status code is 401 / 403, initiate a token refresh request, receive the response data of the token refresh request, extract the new token data from the response data, and retry the API request with the new token data.
5. The unified token management method for multi-protocol API debugging according to any one of claims 2 to 4, characterized in that: Retrieve the target token from the fourth-level scope based on priority matching, including: First, search the single interface scope corresponding to the API request. If a valid authentication token exists in the single interface scope, use the retrieved valid authentication token as the target token and stop searching. If no valid authentication token exists in a single interface scope, the search will start from the innermost folder scope to which the API request belongs and proceed upwards through each folder scope. If a valid authentication token exists in the current folder scope, the retrieved valid authentication token will be used as the target token and the search will stop. If no valid authentication token exists in the folder scope, the search will retrieve the workspace scope of the workspace to which the API request belongs. If a valid authentication token exists in the workspace scope, the retrieved valid authentication token will be used as the target token and the search will stop. If no valid authentication token exists in the working scope, the global scope is searched. If a valid authentication token exists in the global scope, the retrieved valid authentication token is used as the target token and the search stops.
6. The unified token management method for multi-protocol API debugging according to claim 1, characterized in that: It also includes the step of obtaining the authentication token status: Obtain the validity and usage status of the authentication token; Receive the response status code of the API request. When the response status code is 401 / 403, mark the corresponding authentication token as suspected invalid. When a preset number of 401 / 403 responses are received consecutively, the corresponding authentication token will be marked as expired. When the consecutive failure count reaches the preset failure threshold, the corresponding authentication token is disabled.
7. A unified token management system for multi-protocol API debugging, used in an API debugging device, executing the method according to any one of claims 1 to 6, characterized in that, include: The token extraction and storage module is used to receive the response data of API requests, extract the authentication token and the corresponding lifecycle attributes of the authentication token from the response data according to the preset extraction rules, and encrypt and store the authentication token. The token refresh module initiates a refresh request for the stored authentication tokens based on a preset refresh strategy, and updates the stored authentication tokens and their corresponding lifecycle attributes according to the refresh results. The scope management module divides the stored authentication tokens into four levels of scopes and retrieves the target token from the four levels of scopes based on priority matching before sending an API request. The token injection module identifies the protocol type of the API request, performs verification on the target token, and injects the target token into the authentication position of the API request according to the protocol adaptation rules after the verification is successful. The token status acquisition module obtains the validity and usage status of the authentication token, receives the response status code of the API request, and performs marking and disabling processing on the authentication token based on the response status code.
8. A computer-readable storage medium storing computer instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 6.