A method and system for collaborative management of token lifecycle and session synchronization control

Abstract

This invention discloses a method and system for collaborative management of token lifecycle and synchronization control of sessions, relating to the field of session token management technology. The method establishes an encrypted mapping data structure in the main control module to record the correspondence between user identity tokens and local permission tokens of two or more subsystems, and supports index retrieval based on user identifiers. The main control module collaboratively updates the identity token and local tokens based on parameters such as token expiration time, network latency, processing latency, and running status. Upon receiving a global deregistration request, it controls multiple subsystems to deregister local tokens and delete mapping information according to dynamically calculated batch numbers and priority order. All update and deregistration operations are completed through a unified communication interface with identity authentication, security verification, and exception retry mechanisms, without modifying the original permission control mechanisms of the subsystems, thus improving the security, consistency, and scalability of cross-system session management.

Description

Technical Field

[0001] This invention relates to the field of session token management technology, and in particular to a method and system for collaborative management of token lifecycle and session synchronization control. Background Technology

[0002] In distributed application systems or scenarios where multiple subsystems operate collaboratively, user identity tokens and local permission tokens of each subsystem are the core credentials for access control and session management. In existing technologies, token lifecycle management is typically handled independently by each subsystem. Differences in token generation, update, and deregistration strategies across subsystems lead to the following problems: inconsistent expiration times, update cycles, and invalidation policies for local permission tokens in different subsystems can easily cause mismatches between user identity tokens and token states in some subsystems, resulting in access failures or abnormal permissions. In user identity token update or global deregistration scenarios, there is a lack of a central control mechanism to coordinate token operations across multiple subsystems. Batch updates or deregistration often require calling subsystem interfaces one by one, which is inefficient and susceptible to network latency. Existing systems lack sufficient integrity verification for token update or deregistration requests, and lack a unified identity authentication, security verification, and retry mechanism, posing security risks and reliability vulnerabilities. During global deregistration, there is a lack of a strategy to dynamically adjust the batch size and priority based on network status, system load, and other operational metrics, leading to timeouts in some subsystems, increased overall latency, and negatively impacting user experience.

[0003] Therefore, there is an urgent need for a technical solution that can perform unified, coordinated, secure, and efficient lifecycle management and session synchronization control of user identity tokens and local permission tokens in a distributed multi-subsystem environment, in order to solve the problems of asynchronous lifecycles, lack of unified security mechanisms, and inefficient batch operations, thereby improving the security, consistency, and execution efficiency of the system. Summary of the Invention

[0004] This invention aims to address the problems of asynchronous lifecycles, lack of unified security mechanisms, and low efficiency of batch operations in the aforementioned background technologies by providing a token lifecycle collaborative management and session synchronization control method and system. This system enables unified management and secure synchronization control of tokens across multiple subsystems, thereby improving system security, consistency, and execution efficiency.

[0005] To achieve the above objectives, the present invention adopts the following technical solution:

[0006] On one hand, the present invention provides a method for token lifecycle collaborative management and session synchronization control, including:

[0007] Step 1: Establish a mapping data structure in the main control module that includes user identifier, subsystem identifier, local permission token information and status field. The mapping data structure is used to record the correspondence between user identity token and local permission token in two or more subsystems, and supports encrypted storage and index retrieval based on user identifier.

[0008] Step 2: When the main control module detects that the user identity token needs to be updated based on the update trigger time calculated by multiple parameters such as token expiration time, network latency, processing latency and running status, it executes the user identity token update operation, coordinates each target subsystem to complete the synchronous update operation of the corresponding local permission token, and updates the corresponding relationship in the mapping data structure.

[0009] Step 3: When the main control module receives a user's global logout request, based on the corresponding relationship recorded in the mapping data structure, it controls two or more subsystems to complete the logout operation of the local permission token according to the dynamically calculated batch number and the priority order of the targets within the batch, and deletes the associated information in the mapping data structure after all logout operations are completed.

[0010] Step 4: The user identity token update operation, the local permission token update operation, and the cancellation operation are all completed through the unified communication interface. The unified communication interface has identity authentication, security verification, and abnormal retry mechanism, and does not require modification of the original permission control mechanism of the subsystem.

[0011] Preferably, the mapping data structure is configured in the following ways:

[0012] Receive user identity token generation or update events;

[0013] Parse the user identifier and target subsystem information contained in the event;

[0014] In response to the parsed user identifier and target subsystem information, a mapping data structure is dynamically generated to establish the mapping relationship between the user identity token and the target subsystem local permission token;

[0015] The mapping data structure includes the following fields: user identifier field, subsystem identifier field, local permission token field, creation time field, validity status field, and synchronization status field;

[0016] The local permission token field is stored in encrypted form, and a secondary index structure with the user identifier as the key is established in the cache to support index retrieval based on the user identifier.

[0017] Preferably, the update trigger time of the user identity token Calculated using the following formula:

[0018] ;

[0019] in: For the current time, For the first Local permission token expiration time for each subsystem For the first Network latency of individual subsystems For the first Processing delay of each subsystem For the first Operating load of each subsystem With connection quality The delay correction function; the main control module calculates the update trigger time of the user identity token. Then, a user identity token update request is sent to the identity authentication system and all target subsystems, and upon receiving the returned new token, the corresponding relationship in the mapping data structure is updated.

[0020] Preferably, at the time when the user identity token is updated. While sending update requests, a security verification operation is performed, which includes: based on update request parameters. The user identity token and target subsystem identifier Calculate the verification value The formula for calculating the verification value is:

[0021] ;

[0022] in: It is an irreversible cryptographic hash function. The parameters are connected sequentially. The main control module compares the verification value with the expected value. Only when the comparison is consistent, it sends a local permission token refresh request to the corresponding target subsystem in the mapping data structure. After receiving the new token returned by the target subsystem, it updates the corresponding relationship in the mapping data structure.

[0023] Preferably, when the main control module controls two or more target subsystems to perform local permission token cancellation, it dynamically determines the number of target subsystems in each batch based on the following formula. :

[0024] ;

[0025] in: This indicates the number of target subsystems included in each batch; Indicates the maximum allowed batch size; This indicates the total time window currently available for logout operations; This represents the average deregistration time for each target subsystem; This indicates the adjustment coefficient set based on historical execution efficiency data; the main control module follows... The value divides all target subsystems into several batches, and executes the deregistration call in batch order.

[0026] Preferably, the main control module calculates the processing priority value within each batch of target subsystems based on the following formula. And perform cancellation according to priority based on the value:

[0027] ;

[0028] in: Indicates the first Processing priority values ​​for each target subsystem; Indicates the first Real-time operating load metrics of each target subsystem; Indicates the first Network link status indicators for each target subsystem; and These represent the first and second performance impact coefficients, respectively, set based on historical performance data; the main control module, within each batch, according to... The deregistration calls are initiated sequentially from high to low value until the deregistration of all target subsystems within the batch is completed.

[0029] Preferably, when the main control module performs batch-based local permission token cancellation, it calculates an execution deviation value based on the actual execution time, execution success rate, network latency, and link quality performance indicators of the previous batch execution. If the execution deviation value exceeds a preset threshold, it adjusts the batch quantity parameters. and the performance impact coefficient in the priority calculation formula and Dynamic corrections are performed, and the corrected parameters are used for calculating the batch quantity and intra-batch priority ranking in the next round.

[0030] Preferably, the unified communication interface includes:

[0031] The identity authentication step verifies the identity of update and logout requests based on the token identifier and request parameters.

[0032] The security verification step calculates a verification value for operation requests that have passed identity authentication and compares it with the expected verification value. Only when the comparison matches is the request confirmed that it has not been tampered with and that its integrity is maintained.

[0033] The abnormal retry step involves re-initiating the corresponding operation according to the preset retry policy when a call failure, network interruption, or response timeout is detected, until the maximum number of retries is reached or the target operation is completed.

[0034] The implementation of the unified communication interface does not require modification of the subsystem's original permission control mechanism.

[0035] On the other hand, the present invention also provides a token lifecycle collaborative management and session synchronization control system, comprising:

[0036] The main control module is used to establish a mapping data structure, which includes user identifier, subsystem identifier, local permission token information and status field, and supports encrypted storage and index retrieval based on user identifier;

[0037] The update control module is used to perform a user identity token update operation and coordinate the update of the local permission token when it is detected that the user identity token needs to be updated based on multiple parameters such as token expiration time, network latency, processing latency and running status. At the same time, it updates the corresponding relationship in the mapping data structure.

[0038] The deregistration control module is used to control multiple subsystems to perform local permission token deregistration based on the correspondence in the mapping data structure, according to the dynamically calculated batch number and the priority order of the targets within the batch, and to delete the associated information in the mapping data structure after all deregistrations are completed.

[0039] The communication interface module is used to complete user identity token update operations, local permission token update operations, and logout operations, and has identity authentication, verification value comparison, and exception retry mechanisms.

[0040] On the other hand, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the token lifecycle collaborative management and session synchronization control method as described in any of the preceding claims.

[0041] The beneficial effects of this invention are as follows: By establishing a mapping data structure in the main control module that includes user identifiers, subsystem identifiers, local permission token information, and status fields, this invention achieves centralized management of the correspondence between user identity tokens and local permission tokens of multiple subsystems. Encrypted storage and user identifier-based index retrieval ensure data security and efficient access. The main control module can accurately determine the update time of the identity token based on multiple parameters such as token expiration time, network latency, processing latency, and operating status. This allows for proactive synchronization of the identity token and local permission tokens before the token expires, avoiding session interruptions and access anomalies caused by delays or asynchrony. When a user initiates a global logout request, the system can utilize the recorded information in the mapping data structure to coordinate multiple subsystems to complete the logout of local permission tokens in an orderly and efficient manner, according to dynamically calculated batch numbers and priority within each batch. After all logouts are completed, associated information is cleared, completely eliminating residual access permissions and fundamentally improving the system's security capabilities. The unified communication interface provides identity authentication, security verification, and retry mechanisms for token updates and cancellations without requiring modifications to the original access control mechanisms of the subsystems. This not only ensures the security and reliability of operations but also provides strong compatibility and scalability during system integration, thereby effectively improving the stability, consistency, and security of session lifecycle management in multi-heterogeneous system environments. Attached Figure Description

[0042] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein:

[0043] Figure 1 This is a flowchart of the method of the present invention;

[0044] Figure 2 This is a timing diagram of the dynamic refresh process of the user identity token and the local permission token in an embodiment of the present invention;

[0045] Figure 3 This is a timing diagram of the global deregistration collaboration process in an embodiment of the present invention;

[0046] Figure 4 This is a schematic diagram of the modular structure of the system according to an embodiment of the present invention. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the described embodiments of the present invention are within the scope of protection of the present invention.

[0048] Example 1

[0049] like Figure 1 As shown, this is an embodiment of the present invention, which provides a token lifecycle collaborative management and session synchronization control method, including:

[0050] Step 1: Establish the mapping data structure

[0051] A mapping data structure containing user identifier, subsystem identifier, local permission token information, and status field is established in the main control module. The mapping data structure is used to record the correspondence between user identity tokens and local permission tokens in two or more subsystems, and supports encrypted storage and index retrieval based on user identifiers. The mapping data structure is preferably stored in key-value pair format, and each record uniquely corresponds to a token mapping relationship between a user and a subsystem.

[0052] The mapping data structure can be implemented in the following ways:

[0053] Receive user identity token generation or update events;

[0054] Parse the user identifier and target subsystem information contained in the event;

[0055] In response to the parsed user identifier and target subsystem information, a mapping data structure is dynamically generated to establish the mapping relationship between the user identity token and the target subsystem local permission token;

[0056] The mapping data structure includes the following fields: user identifier field, subsystem identifier field, local permission token field, creation time field, validity status field, and synchronization status field;

[0057] Preferably, the mapping data structure can be represented in tabular or JSON format, for example:

[0058] {

[0059] "userId": "U12345",

[0060] "systemId": "SYS-A",

[0061] "localToken": "enc_xxx",

[0062] "createTime": "2025-08-12T09:00:00Z",

[0063] "validStatus": "active",

[0064] "syncStatus": "in-sync

[0065] }

[0066] This format facilitates storage and cross-module parsing.

[0067] The local permission token field is stored in encrypted form, preferably using the AES-256 symmetric encryption algorithm. The key is managed uniformly by the security module and rotated periodically to improve data security. A secondary index structure with the user identifier as the key is established in the cache. The secondary index is preferably implemented based on a hash table to complete the index retrieval based on the user identifier in O(1) time complexity and support high concurrency access.

[0068] When generating the mapping data structure, the main control module can perform integrity verification on the input fields. If necessary fields are missing or parsing fails, an error log is recorded and the mapping is regenerated according to a preset retry strategy (e.g., a maximum of three retries). When consecutive failures exceed a threshold, an abnormal alarm mechanism is triggered to ensure the stability of system operation.

[0069] Step 2: Calculate the token update trigger time and execute the update.

[0070] When the main control module detects that the user identity token needs to be updated based on the update trigger time calculated by multiple parameters such as token expiration time, network latency, processing latency and running status, it executes the user identity token update operation, coordinates each target subsystem to complete the synchronous update operation of the corresponding local permission token, and updates the corresponding relationship in the mapping data structure.

[0071] The user identity token update trigger time Calculated using the following formula:

[0072] ;

[0073] in: For the current time, For the first Local permission token expiration time for each subsystem For the first Network latency of individual subsystems For the first Processing delay of each subsystem For the first Operating load of each subsystem With connection quality The delay correction function;

[0074] Preferably, the delay correction function The coefficients can be dynamically adjusted based on historical monitoring data to improve the accuracy of update trigger time prediction.

[0075] The main control module calculates... Then, a token update request is sent to the identity authentication system and all target subsystems. The request can be transmitted through the unified communication interface and carries the necessary identity authentication parameters to ensure that the request source is legitimate. After receiving the returned new token, the correspondence in the mapping data structure is updated.

[0076] In this embodiment, if the main control module calculates the update trigger time of the user identity token... If the remaining valid time is found to be less than a set threshold (e.g., 30 minutes), a token update request is immediately sent to the identity authentication system and all target subsystems. The request can be transmitted through a unified communication interface and carries necessary identity authentication parameters (e.g., timestamp, user identifier, digital signature, etc.) to ensure the legitimacy of the request source. After receiving the returned new token, the corresponding relationship in the mapping data structure is updated.

[0077] Security verification operation

[0078] The update trigger time of the user identity token While sending update requests, a security verification operation is performed, which includes: based on update request parameters. The user identity token and target subsystem identifier Calculate the verification value The formula for calculating the verification value is:

[0079] ;

[0080] in: It is an irreversible cryptographic hash function, preferably a secure hash algorithm such as SHA-256 or SM3; This indicates that the parameters are concatenated in order, and the concatenation order should be fixed during system initialization to avoid ambiguity in parsing. It can be a random number (nonce) or a timestamp to prevent replay attacks;

[0081] The main control module compares the verification value with the expected value, and only sends a local permission token update request to the corresponding target subsystem in the mapping data structure when the comparison is consistent, in order to prevent forged or tampered requests from being executed; after receiving the new token returned by the target subsystem, it updates the correspondence in the mapping data structure.

[0082] Preferably, when security verification fails, the system will record a security event log (including the failure time, the request source IP, the failure reason code, etc.) and can trigger an early warning mechanism to send alerts via SMS, email or monitoring platform to support subsequent security audits.

[0083] In the test environment of this embodiment, when A random number of 16 bytes in length. The length is 32 bytes. When the length is 8 bytes, the total input length is 56 bytes. After SHA-256 calculation, a 256-bit hash value is generated and stored as a 64-bit hexadecimal string.

[0084] Step 3: Global Unregistration and Batch Control

[0085] When the main control module receives a user's global logout request, it controls two or more subsystems to complete the logout operation of the local permission token based on the correspondence between the user's identity token and the target subsystem's local permission token recorded in the mapping data structure, according to the dynamically calculated batch number and the priority order of the targets within the batch. After all logout operations are completed, the associated information in the mapping data structure is deleted.

[0086] When the main control module controls two or more target subsystems to perform local permission token deregistration, it dynamically determines the number of target subsystems in each batch based on the following formula. :

[0087] ;

[0088] in: This indicates the number of target subsystems included in each batch, and the calculation result is the integer value after rounding down. Indicates the maximum allowed batch size; This indicates the total time window currently available for logout operations; This represents the average deregistration time for each target subsystem; This indicates the adjustment coefficient set based on historical execution efficiency data; the main control module follows... The value divides all target subsystems into several batches, and executes the deregistration call in batch order.

[0089] In actual implementation, This can be configured based on business scenarios, such as requiring global logout to be completed within 5 seconds. ; This can be obtained through statistical data from a recent period (such as the average of the last 100 calls); It can be dynamically adjusted according to network congestion and system load, and the value range is usually 0.5~1.5.

[0090] For example: when At that time, the calculation yielded:

[0091]

[0092] That is, each batch can process the deregistration of 7 subsystems simultaneously.

[0093] Within each batch of target subsystems, the main control module calculates the processing priority value based on the following formula. And execute the cancellation according to priority value:

[0094] ;

[0095] in: Indicates the first Processing priority values ​​for each target subsystem; Indicates the first Real-time operating load metrics of each target subsystem; Indicates the first Network link status indicators for each target subsystem; and These represent the first and second performance impact coefficients, respectively, set based on historical performance data. The larger the value, the higher the processing priority of the target subsystem. The main control module processes data according to... The deregistration calls are initiated sequentially from high to low value until the deregistration of all target subsystems within the batch is completed.

[0096] In practical applications, Floating-point values ​​between 0 and 1 can be used (e.g., CPU utilization or average queue wait rate). It can take floating-point values ​​between 0 and 1 (such as the inverse value of Ping packet loss rate or latency quality score). Weights can be set according to business strategies, for example This indicates that the importance of the runtime load is slightly higher than that of the network status.

[0097] Example: Suppose the performance indicators of the three target subsystems within a certain batch are as follows:

[0098] System A:

[0099] System B:

[0100] System C:

[0101] Pick ,but:

[0102] ;

[0103] The sorting result is: System C > System B > System A, meaning that the local permission token of System C will be revoked first.

[0104] When performing batch-based local permission token deregistration, the main control module calculates an execution deviation value based on the actual execution time, success rate, network latency, and link quality performance indicators of the previous batch execution. If the execution deviation value exceeds a preset threshold, the module adjusts the batch quantity parameter. and the performance impact coefficient in the priority calculation formula and Dynamic corrections are performed, and the corrected parameters are used for calculating the batch quantity and intra-batch priority ranking in the next round.

[0105] Step 4: Perform operations using the unified communication interface

[0106] User identity token update operations, local permission token update operations, and cancellation operations are all completed through a unified communication interface. The unified communication interface has identity authentication, security verification, and abnormal retry mechanisms, and does not require modification of the original permission control mechanism of the subsystem.

[0107] The unified communication interface includes:

[0108] The identity authentication step verifies the identity of update and logout requests based on the token identifier and request parameters.

[0109] The security verification step calculates a verification value for operation requests that have passed identity authentication and compares it with the expected verification value. Only when the comparison matches is it confirmed that the request has not been tampered with and that its integrity is maintained.

[0110] The abnormal retry step involves re-initiating the corresponding operation according to the preset retry policy when a call failure, network interruption, or response timeout is detected, until the maximum number of retries is reached or the target operation is completed.

[0111] The implementation of the unified communication interface does not require modification of the subsystem's original permission control mechanism.

[0112] In a preferred embodiment, if the target operation is not completed after reaching the maximum number of retries, the system will trigger a subsequent response mechanism, such as:

[0113] Record failure logs for later troubleshooting;

[0114] Trigger an alarm notification to prompt maintenance personnel or security administrators to intervene and handle the situation;

[0115] Enter manual intervention mode, where the administrator can manually initiate the recovery or deregistration operation.

[0116] These measures ensure that there are controllable remedial measures available even in extreme situations, thereby further improving the reliability and security of the system.

[0117] like Figure 4 As shown, the present invention also provides a token lifecycle collaborative management and session synchronization control system, including:

[0118] The main control module is used to establish a mapping data structure, which includes user identifier, subsystem identifier, local permission token information and status field, and supports encrypted storage and index retrieval based on user identifier;

[0119] The update control module is used to perform a user identity token update operation and coordinate the update of the local permission token when it is detected that the user identity token needs to be updated based on multiple parameters such as token expiration time, network latency, processing latency and running status. At the same time, it updates the corresponding relationship in the mapping data structure.

[0120] The deregistration control module is used to control multiple subsystems to perform local permission token deregistration based on the correspondence in the mapping data structure, according to the dynamically calculated batch number and the priority order of the targets within the batch, and to delete the associated information in the mapping data structure after all deregistrations are completed.

[0121] The communication interface module is used to complete user identity token update operations, local permission token update operations, and logout operations, and has identity authentication, verification value comparison, and exception retry mechanisms.

[0122] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs all the steps described above, including establishing a mapping data structure, calculating the update trigger time, performing token updates and security verification, performing global deregistration by batch and priority, and performing the above operations through a unified communication interface.

[0123] Example 2

[0124] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the following embodiments are only used to illustrate the present invention and do not constitute a limitation on the scope of protection of the present invention.

[0125] I. Dynamic refresh process of user identity token and local permission token (e.g.) Figure 2 (As shown)

[0126] When the main control module detects that the user identity token needs to be updated, it can dynamically determine the triggering time based on the multi-parameter calculation formula described in the claims (including token expiration time, network latency, processing latency, and runtime latency correction function, etc.). In this embodiment, when the client monitors in real time that the remaining validity time of the user identity token is less than or equal to 30 minutes, it sends a refresh request to the Identity Authentication System (IAM) by refreshing the token.

[0127] After successful authentication, the system returns a new user identity token and pushes a token update event to the token mapping service in the main control module via a message middleware (Kafka). The token mapping service parses the user identifier, subsystem identifier, and other information contained in the event, performs a "key update" operation in the cache implementation (Redis) of the mapping data structure, replaces the old identity token hash value with the new identity token hash value, and sets a 5-minute expiration time for the old mapping record.

[0128] On the subsystem side, when the business gateway detects that the remaining validity period of the local permission token is less than or equal to 10 minutes when forwarding a request, it triggers a call to the unified communication interface to initiate a local permission token refresh request to the main control module. The unified communication interface performs a security verification operation when forwarding the request, calculating a verification value based on the refresh request parameters, the current user's identity token, and the target subsystem identifier, and comparing it with the expected value. Only if the verification matches will a refresh call be initiated to the corresponding subsystem's permission engine.

[0129] After the subsystem's permission engine generates a new local permission token, the token mapping service encrypts the new token using a subsystem-specific key (managed through the Key Management System (KMS)) and updates the local permission token field of the corresponding entry in the mapping data structure, thereby maintaining the synchronization between the user identity token and the local permission token. Finally, the new identity token is returned to the client.

[0130] II. Global Logout Collaboration Process (e.g.) Figure 3 (As shown)

[0131] When a user submits a global logout request through the Identity Authentication System (IAM) interface, IAM immediately invalidates the user's refresh token and all active user identity tokens. Subsequently, IAM broadcasts the global logout event to all target subsystems via a message broker (Kafka). The token mapping service in the master module receives this event as a consumer and, based on the user identifier contained in the event, quickly retrieves the user's local permission token record across all subsystems from the cache implementation of the mapping data structure (Redis) using a secondary index (with the user identifier as the key).

[0132] To ensure efficient and controllable deregistration of multiple subsystems, the main control module can calculate the number of target subsystems in each batch based on the batch number dynamic calculation formula described in the claims, combined with the currently available deregistration time window, the average deregistration time of each target subsystem, and the historical execution efficiency adjustment coefficient. It can also determine the execution order within the batch based on the priority calculation formula (considering factors such as operating load and network link status).

[0133] The token mapping service calls the token deregistration interface of each target subsystem according to the batch division and priority order mentioned above. After receiving the call, the subsystem permission engine destroys the corresponding local session and confirms the deregistration result. When all target subsystems in a batch have completed deregistration, the main control module calculates the execution deviation value based on the actual time, success rate, and link status. If it exceeds the preset threshold, the performance impact coefficient in the batch number and priority calculation is dynamically adjusted for scheduling the next deregistration batch.

[0134] Once all batches are executed, the token mapping service will delete all token mapping records for that user in Redis in batches, that is, delete the associated information in the mapping data structure to ensure that there are no residual access permissions in the system.

[0135] In summary, this invention, in a multi-heterogeneous distributed system environment, achieves coordinated execution of dynamic token refresh and global deregistration across systems through unified scheduling and secure communication mechanisms of the main control module, ensuring the uniformity and security of session lifecycle management. This invention has a clear structure and strong adaptability, enabling smooth integration without altering existing system permission architectures. It is suitable for business scenarios involving power, finance, government affairs, and other multi-system integration, and has significant implications and broad application prospects for improving cross-system security management and industry digital collaboration capabilities.

[0136] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0137] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0138] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope disclosed in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for collaborative management of token lifecycle and session synchronization control, characterized in that, The method includes: A mapping data structure containing user identifier, subsystem identifier, local permission token information and status field is established in the main control module. The mapping data structure is used to record the correspondence between user identity token and local permission token in two or more subsystems, and supports encrypted storage and index retrieval based on user identifier. When the main control module detects that the user identity token needs to be updated based on the update trigger time calculated by multiple parameters such as token expiration time, network latency, processing latency and running status, it executes the user identity token update operation, coordinates each target subsystem to complete the synchronous update operation of the corresponding local permission token, and updates the corresponding relationship in the mapping data structure. The mapping data structure can be implemented in the following ways: Receive user identity token generation or update events; Parse the user identifier and target subsystem information contained in the event; In response to the parsed user identifier and target subsystem information, a mapping data structure is dynamically generated to establish the mapping relationship between the user identity token and the target subsystem local permission token; The mapping data structure includes the following fields: user identifier field, subsystem identifier field, local permission token field, creation time field, validity status field, and synchronization status field; The local permission token field is stored in encrypted form, and a secondary index structure with the user identifier as the key is established in the cache to support index retrieval based on the user identifier. The user identity token update trigger time Calculated using the following formula: ； in: For the current time, For the first Local permission token expiration time for each subsystem For the first Network latency of individual subsystems For the first Processing delay of each subsystem For the first Operating load of each subsystem With connection quality The delay correction function; the main control module calculates the update trigger time of the user identity token. Then, a user identity token update request is sent to the identity authentication system and all target subsystems, and the corresponding relationship in the mapping data structure is updated after receiving the returned new token; When the main control module receives a user's global logout request, it controls two or more subsystems to complete the logout operation of the local permission token based on the corresponding relationship recorded in the mapping data structure, according to the dynamically calculated batch number and the priority order of the targets within the batch. After all logout operations are completed, the associated information in the mapping data structure is deleted. User identity token update operations, local permission token update operations, and cancellation operations are all completed through a unified communication interface. The unified communication interface has identity authentication, security verification, and abnormal retry mechanisms, and does not require modification of the original permission control mechanism of the subsystem.

2. The token lifecycle collaborative management and session synchronization control method according to claim 1, characterized in that, The update trigger time of the user identity token While sending update requests, a security verification operation is performed, which includes: based on update request parameters. The user identity token and target subsystem identifier Calculate the verification value The formula for calculating the verification value is: ； in: It is an irreversible cryptographic hash function. The parameters are connected sequentially. The main control module compares the verification value with the expected value, and only sends a local permission token update request to the corresponding target subsystem in the mapping data structure when the comparison is consistent. After receiving the new token returned by the target subsystem, the module updates the correspondence in the mapping data structure.

3. The token lifecycle collaborative management and session synchronization control method according to claim 1, characterized in that, When the main control module controls two or more target subsystems to perform local permission token deregistration, it dynamically determines the number of target subsystems in each batch based on the following formula. The expression is: ； in: This indicates the number of target subsystems included in each batch; Indicates the maximum allowed batch size; This indicates the total time window currently available for logout operations; This represents the average deregistration time for each target subsystem; This indicates the adjustment coefficient set based on historical execution efficiency data; the main control module follows... The value divides all target subsystems into several batches, and executes the deregistration call in batch order.

4. The token lifecycle collaborative management and session synchronization control method according to claim 3, characterized in that, Within each batch of target subsystems, the main control module calculates the processing priority value based on the following formula. And execute the cancellation according to priority value: ； in: Indicates the first Processing priority values ​​for each target subsystem; Indicates the first Real-time operating load metrics of each target subsystem; Indicates the first Network link status indicators for each target subsystem; and These represent the first and second performance impact coefficients, respectively, set based on historical performance data; the main control module, within each batch, according to... The deregistration calls are initiated sequentially from high to low value until the deregistration of all target subsystems within the batch is completed.

5. The token lifecycle collaborative management and session synchronization control method according to claim 4, characterized in that, When performing batch-based local permission token deregistration, the main control module calculates an execution deviation value based on the actual execution time, success rate, network latency, and link quality performance indicators of the previous batch execution. If the execution deviation value exceeds a preset threshold, the module adjusts the batch quantity parameter. and the performance impact coefficient in the priority calculation formula and Dynamic corrections are performed, and the corrected parameters are used for calculating the batch quantity and intra-batch priority ranking in the next round.

6. The token lifecycle collaborative management and session synchronization control method according to claim 1, characterized in that, The operation process of the unified communication interface includes: The identity authentication step verifies the identity of update and logout requests based on the token identifier and request parameters. The security verification step calculates a verification value for operation requests that have passed identity authentication and compares it with the expected verification value. Only when the comparison matches is it confirmed that the request has not been tampered with and that its integrity is maintained. The abnormal retry step involves re-initiating the corresponding operation according to the preset retry policy when a call failure, network interruption, or response timeout is detected, until the maximum number of retries is reached or the target operation is completed. The implementation of the unified communication interface does not require modification of the subsystem's original permission control mechanism.

7. A control system for a token lifecycle collaborative management and session synchronization control method, applied to the token lifecycle collaborative management and session synchronization control method as described in any one of claims 1-6, characterized in that, The system includes: The main control module is used to establish a mapping data structure, which includes user identifier, subsystem identifier, local permission token information and status field, and supports encrypted storage and index retrieval based on user identifier; The update control module is used to perform a user identity token update operation and coordinate the update of the local permission token when it is detected that the user identity token needs to be updated based on multiple parameters such as token expiration time, network latency, processing latency and running status. At the same time, it updates the corresponding relationship in the mapping data structure. The deregistration control module is used to control multiple subsystems to perform local permission token deregistration based on the correspondence in the mapping data structure, according to the dynamically calculated batch number and the priority order of the targets within the batch, and to delete the associated information in the mapping data structure after all deregistrations are completed. The communication interface module is used to complete user identity token update operations, local permission token update operations, and cancellation operations, and has identity authentication, verification value comparison, and abnormal retry mechanisms.

8. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the token lifecycle collaborative management and session synchronization control method as described in any one of claims 1 to 6.

Images