Authentication link double-token refreshing method and device and computer equipment

Abstract

The invention discloses an authentication link double-token refreshing method and system, and relates to the field of computer network security. The method comprises the following steps: in a token refreshing process, a client sends a refreshing token and an iteration anchor point to a server; the server verifies the continuity of the iteration anchor point and the historical token state; and after verification is passed, token refreshing is executed, and a new iteration anchor point is generated. The iteration anchor point is a failure time identifier of the failure token, and the verification comprises consistency judgment and anti-replay verification. Meanwhile, an authentication link file is established, strong binding of the token and the link is achieved, and a full-life-cycle log is recorded. Triple protection is constructed through an iteration anchor point, a link identifier and an equipment identifier, the problems of authentication link breakage, safety verification looseness and abnormity non-traceability are solved, and non-inductive refreshing, attack interception and full-link traceability are realized.

Description

Technical Field

[0001] This invention relates to the field of computer network security authentication technology, specifically to an authentication-linked dual-token refresh method, apparatus, and computer device. Background Technology

[0002] While current dual-token authentication schemes can achieve seamless refresh after token expiration, they generally suffer from the following drawbacks: The iteration process of refresh tokens and access tokens lacks a record of the entire process from "first login to multiple refreshes until the token expires." Once an attacker steals a refresh token, they can attempt to bind it to expired access tokens in other authentication chains to initiate unauthorized refresh operations. Current schemes only verify the validity of the refresh token itself to determine the legitimacy of the request, failing to combine this with comprehensive verification of key chain information such as device identifiers and login history, making them vulnerable to cross-device attacks and replay attacks. Furthermore, due to the lack of key nodes that can connect multiple rounds of token iteration, when abnormal events occur in the system, it is impossible to effectively trace the token's generation source and flow path, making it difficult to accurately locate the source of the attack and posing a significant challenge to security operations. Summary of the Invention

[0003] In view of this, the present invention provides a dual-token refresh method, apparatus and computer device for authentication link-based authentication, in order to solve the problems of authentication link breakage, loose security verification and untraceable anomalies in existing dual-token authentication schemes.

[0004] Firstly, the present invention provides a dual-token refresh method for authentication chain, which spans the entire lifecycle of the authentication chain and includes: Authentication chain initialization and daily request verification: When a client user successfully logs in for the first time, the server generates a globally unique LinkID and creates a corresponding authentication link file; it issues an initial Access Token (AT), Refresh Token (RT), and iteration anchor to the client; the LinkID is embedded in both the Access Token (AT) and the Refresh Token (RT). During the validity period of the access token (AT), when a client initiates a business API request to the server, it must include the currently valid access token (AT) and the link identifier (LinkID) in the request. The server queries the authentication link file based on the link identifier (LinkID), verifies the validity of the access token (AT) and its binding relationship with the authentication link, and processes the business request and records the operation log after successful verification.

[0005] Token refresh process: When a token needs to be refreshed, the client sends a token refresh request to the server. The request includes the refresh token (RT), the link identifier (LinkID), and the iteration anchor. The server queries the corresponding authentication link file based on the link identifier (LinkID) to verify the validity of the refresh token (RT) and its association with the current authentication link, and to obtain the expected iteration anchor point. The server verifies the consistency between the iteration anchor in the request and the expected iteration anchor. If the verification is successful, the server performs a token refresh operation, generating a new access token (AT) and a new refresh token (RT), and generates a new iteration anchor point for the next refresh based on the new access token (AT) to maintain the continuity of the link.

[0006] In one optional implementation, the iteration anchor is the expiration time identifier of the previously expired access token; during verification, the server determines whether the iteration anchor is consistent with the expected anchor recorded by the server, and whether the iteration anchor has not been used to successfully perform token refresh.

[0007] In one optional implementation, the authentication link file records at least: the initial login IP, the device fingerprint hash value generated based on the client hardware and software environment, the login time, the source IP of each refresh request, and the type of abnormal event; the business API request verification and the token refresh request verification are both performed based on this file.

[0008] In one optional implementation, both the business API request verification and the token refresh request verification include verifying the consistency between the device identifier extracted from the request and the device identifier recorded in the authentication link file; the device identifier is a hash value of a device fingerprint generated based on the client hardware and software environment.

[0009] In one optional implementation, when token refresh verification fails and a combined anomaly of device identifier change and iteration anchor point being used is detected simultaneously, an active defense strategy is triggered, which includes: forcibly terminating the current authentication link, sending a multi-factor authentication request, and sending a security alert to the administrator.

[0010] Secondly, the present invention provides an authentication-linked dual-token refresh device, comprising: The link initialization module is used to generate a link identifier (LinkID), create an authentication link profile, and issue an initial token and anchor point when a user logs in for the first time. The business request verification module is used to receive business API requests initiated by clients, query the authentication link file based on the link identifier (LinkID) and access token (AT) in the request, and verify the validity of the token and the link binding relationship. The request processing module is used to receive token refresh requests sent by the client, the requests including refresh token (RT), link identifier (LinkID) and iteration anchor; The continuity verification module is used to confirm the continuity between the current request and the historical token state by verifying the consistency between the iterative anchor point and the expected anchor point recorded by the server. The link file management module is used to create and maintain an authentication link file indexed by the link identifier (LinkID) for the session, and to support the verification operations of the service request verification module and the continuity verification module based on the file. The device consistency verification module is used to extract the current device identifier from the business API request or the token refresh request, and verify its consistency with the historical device identifier recorded in the authentication link file. The token and anchor management module is used to perform a token refresh operation after the verification is successful, generating a new access token (AT), a new refresh token (RT), and a new iteration anchor for the next refresh; An anomaly defense module is used to trigger an active defense strategy when the device consistency verification module fails the verification and the continuity verification module detects a compound anomaly that the iterative anchor point is reused.

[0011] Thirdly, the present invention provides a computer device, including: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the authentication link-based dual-token refresh method described in the first aspect or any corresponding embodiment.

[0012] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions, the computer instructions being used to cause a computer to execute the authentication link-based dual-token refresh method of the first aspect or any corresponding embodiment described above.

[0013] Fifthly, the present invention provides a computer program product, including computer instructions for causing a computer to execute the authentication link-based dual-token refresh method described in the first aspect or any corresponding embodiment thereof.

[0014] This invention achieves the following beneficial effects by introducing a continuity verification mechanism for iterative anchors: First, this method effectively prevents unauthorized binding attacks because attackers, after stealing a refresh token, cannot obtain the iterative anchor—the expiration time identifier of the previous access token recorded by the server—and thus cannot illegally use the refresh token in other authentication links. Second, this method defends against replay attacks because each successful refresh operation invalidates and updates the current iterative anchor; repeatedly sending refresh requests containing old anchors will be identified and rejected by the server. Finally, this method ensures the continuity of the authentication link state while maintaining a seamless refresh experience for users. Legitimate clients can automatically refresh the token using the stored correct iterative anchor, allowing users to continue receiving services without manual intervention after the token expires. Attached Figure Description

[0015] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating the authentication-linked dual-token refresh method according to an embodiment of the present invention. Figure 2 This is a full lifecycle flowchart of the authentication-linked dual-token refresh method according to an embodiment of the present invention; Figure 3 This is a flowchart of the authentication chain initialization process according to an embodiment of the present invention; Figure 4 This is a flowchart illustrating the authentication chain persistence process according to an embodiment of the present invention; Figure 5 This is an iterative flowchart of the authentication chain according to an embodiment of the present invention; Figure 6 This is a flowchart illustrating the authentication chain termination process according to an embodiment of the present invention; Figure 7 This is a flowchart of the abnormal link tracing process according to an embodiment of the present invention; Figure 8 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0017] 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 embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] According to an embodiment of the present invention, an authentication link-based dual-token refresh method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here. Example

[0019] This embodiment provides an authentication-linked dual-token refresh method, which can be used in the aforementioned mobile terminals, such as mobile phones and tablets, as well as in multi-terminal environments such as web browsers and mini-programs. Figure 1 This is a flowchart of the authentication-linked dual-token refresh method according to an embodiment of the present invention, as follows: Figure 1 As shown, the process includes the following steps: In step S101, the client detects that the access token has expired and sends a token refresh request to the server. The request includes the refresh token, iteration anchor, link identifier, and device identifier.

[0020] When a client detects that its current access token has expired or is about to expire, it automatically triggers a token refresh process. The client retrieves the following key information from its local secure storage: a refresh token, the iteration anchor (T_prev_exp) issued by the server during the last token refresh, a link ID uniquely identifying the current authentication link, and a device ID generated based on the client's hardware and software environment. This information is transmitted to the server's token refresh interface via an encrypted channel. The iteration anchor serves as a crucial credential for associating with historical token states, ensuring that the current refresh request can be correctly associated with a specific historical token iteration node.

[0021] In step S102, the server receives a refresh request, verifies the continuity between the current request and the historical token state by verifying the iteration anchor point, and checks the consistency of the device identifier.

[0022] Upon receiving a refresh request, the server first queries the corresponding authentication link file based on the link identifier. Then, it performs triple verification: First, it verifies the validity of the refresh token and its relevance to the link; second, it verifies the continuity of the iteration anchor, checking whether the iteration anchor provided by the client is completely consistent with the previous valid anchor recorded by the server, and that this anchor has not been used in other refresh requests (to prevent replay attacks); third, it verifies the consistency of the device identifier, ensuring that the device originating from the request matches the device characteristics recorded in the link file. Failure at any layer of verification will trigger the corresponding security handling mechanism.

[0023] In step S103, after successful verification, the server generates a new access token, refresh token, and iteration anchor and returns them to the client. The client then updates its local storage to complete the seamless refresh.

[0024] Once all verifications are successful, the server performs a token refresh operation: generating a new access token (with a shorter validity period, such as 1 hour), a new refresh token (with a longer validity period, such as 7 days), and a new iteration anchor based on the new access token's expiration time. Simultaneously, the server updates the authentication chain file, records this refresh operation, marks the old token as invalid, and adds the used iteration anchor to the used set. Upon receiving the new token and anchor, the client securely updates its local storage, allowing users to continue using the application without any manual intervention, achieving a truly seamless refresh experience.

[0025] The authentication link-based dual-token refresh method provided in this embodiment establishes a strong correlation between token iterations by introducing an iterative anchor mechanism. Combined with device identification verification and link file management, it achieves triple security protection. The technical effects are: effectively preventing replay attacks, ensuring the integrity and continuity of the authentication link, providing full lifecycle operation traceability, and maintaining a seamless refresh experience for users while ensuring security. It solves the technical problems of authentication link breakage and loose security verification in traditional dual-token schemes.

[0026] This embodiment provides a dual-token refresh method for authentication chaining, applied to mobile app scenarios. When a user logs in to the mobile app for the first time by entering their account and password, the client automatically collects device identification information, including device model, operating system version, device unique identifier, and other hardware and software environment characteristics. The collected device information is hashed to generate a DeviceID (device unique identifier), and the account, password hash value, and DeviceID are sent to the server authentication interface via an encrypted channel. Upon receiving the login request, the server first verifies the correctness of the account and password, then checks if the device identifier is a frequently used device. If it is a new device, a secondary verification via SMS verification code is triggered. After successful verification, the server generates a LinkID, a unique identifier that persists throughout the entire authentication chain's lifecycle.

[0027] The server generates an initial access token (AT) valid for 1 hour. The AT embeds a LinkID to ensure the token is bound to the current link, and records its expiration timestamp T0 as the iteration anchor point for the first refresh. An initial refresh token (RT) is generated, valid for 7 days. The RT also embeds a LinkID and records the parent iteration anchor point as the initial anchor point, identifying that the RT was generated upon the first login. The server creates a link file indexed by the LinkID, recording basic information including LinkID, user account, DeviceID, login time, and login IP; token information including the initial AT, initial RT, AT expiration time T0, and RT expiration time; anchor information including the currently valid iteration anchor point T0; and status information including the link status as active and the historical operation log initially empty. The server returns the LinkID, initial AT, initial RT, and iteration anchor point T0 to the client, which stores them encrypted, completing the authentication link initialization.

[0028] During the authentication process, when a user initiates an API request, the client must include the authentication link information, sending the AT and LinkID to the server via the request header. For sensitive interfaces, the request header additionally includes the DeviceID for secondary verification by the server. The server queries the authentication link file using the LinkID to confirm the link status is active. It verifies the validity of the AT, including whether the signature is correct, whether it is within its validity period, and whether the LinkID embedded in the AT matches the LinkID in the request header. For sensitive interfaces, it additionally verifies whether the DeviceID matches the DeviceID in the authentication link file. After successful verification, the server appends an operation log to the authentication link file, recording the request time, request IP, request interface, and remaining validity of the AT, providing a basis for subsequent traceability. Then, the server processes the API request and returns the result, completing the operation seamlessly for the user.

[0029] When the AT expires, the authentication link iteration phase begins. The client retrieves RT, LinkID, T_prev_exp, and DeviceID from storage and sends them to the server refresh interface. T_prev_exp is the expiration timestamp of the previous expired AT. It is the initial anchor point T0 during the first refresh and the expiration time of the previous AT during subsequent refreshes. After receiving the request, the server performs a triple association verification: The first layer is the link and RT association verification. The link file is queried through the LinkID to confirm that the RT exists in the file, has not expired, and has not been added to the blacklist. At the same time, the LinkID embedded in the RT is verified to be consistent with the LinkID in the request header to prevent the RT from being used across links. The second layer is the iterative anchor association verification. The T_prev_exp in the request is extracted and compared with the expiration time of the previous round of AT recorded in the link file in milliseconds to ensure that the two are completely consistent. This proves that the current refresh request corresponds to a real expired AT in the link. Then, it is checked whether the T_prev_exp in the link file has been associated with a new Token. If it has been associated, it is judged as a replay attack. The third layer is the device association verification. The DeviceID in the request is verified to be consistent with the DeviceID in the link file. If the DeviceID is inconsistent, a secondary verification via SMS verification code is triggered. Only after the verification is successful can the refresh continue.

[0030] After successful verification, the server generates a new AT and a new RT. The new AT is valid for 1 hour and embeds a LinkID, recording its expiration timestamp T_new_exp. The new RT is valid for 7 days and embeds a LinkID, recording the parent iteration anchor point as the current T_prev_exp. Simultaneously, the server updates the link file, marking the old AT and RT as invalid, recording the reason for invalidation as replacement by the new token, storing the new AT, new RT, and new AT expiration time T_new_exp, updating the current valid iteration anchor point to T_prev_exp for use in the next refresh, and appending refresh logs to record the refresh time, refresh IP, old anchor point T_prev_exp, and the source of the new anchor point. The server returns the new AT, new RT, new AT expiration time T_new_exp, and T_prev_exp to the client. The client overwrites the old token and stores it encrypted, completing the link iteration without the user's awareness.

[0031] The authentication link is terminated when circumstances such as RT expiration, user voluntary logout, or detected abnormal attack occur. When a user logs out, the client sends the LinkID and RT to the server's termination interface. The server verifies the validity of the RT and terminates the link, which is considered a voluntary termination. When the RT expires and is not refreshed, the server automatically terminates the link. When an abnormal attack is detected, such as the RT of the same LinkID being refreshed simultaneously on different IPs, or T_prev_exp being reused, the server immediately terminates the link, which is considered a passive termination. After termination, the server updates the link file, changes the link status to terminated, records the termination reason (including voluntary logout, RT expiration, or abnormal attack), records the termination time, the IP address at the time of termination, and the DeviceID, and adds all valid AT and RT in the link to a global blacklist to prevent reuse by attackers. The link file and operation logs are retained for at least 3 months to meet security audit requirements for subsequent anomaly tracing. The server returns a link termination success response, the client clears the locally stored LinkID, AT, RT, and T_prev_exp, and guides the user to recreate the link upon the next login.

[0032] When an account anomaly occurs, administrators can quickly locate the source of the problem through the anomaly link tracing mechanism. Administrators enter the user account or LinkID, filter links with an abnormal or terminated status, view the refresh logs in the link file, locate the expiration time of the previous AT by the parent iteration anchor point of the new RT, and further query the operation logs corresponding to that AT to obtain the refresh request IP and DeviceID that generated the AT. If the IP or DeviceID is unfamiliar, it is determined to be an illegal refresh caused by token theft, and targeted measures are taken such as forcing the user to change their password, freezing the account, and blacklisting the abnormal IP. If multiple links exhibit the same anomaly, such as the same IP initiating refreshes using different T_prev_exp, global protection rules are set based on the anchor point and IP information to block all refresh requests from that IP.

[0033] This embodiment verifies the technical effectiveness of the invention through practical application, achieving full lifecycle traceability of the authentication chain and significantly improving the efficiency of security event location. Every step from the initial login to the termination of the chain is recorded in the chain archive, allowing for rapid tracing of the event source in case of anomalies. The multi-layered association verification mechanism significantly enhances attack protection capabilities. Through LinkID binding to Token, device identifier verification, and iterative anchor point verification, cross-chain attacks, cross-device attacks, and replay attacks are completely blocked. A seamless refresh experience is achieved while ensuring security; users do not need to frequently enter account passwords or verification codes. Automatic refresh via RT occurs after AT expires, making the operation imperceptible and effectively balancing security protection and user experience. Example

[0034] When implementing this authentication-linked dual-token refresh method in a web application scenario, the client runs in a browser environment. When a user accesses the web application through a browser, during the initial login process, the client automatically generates a device identifier based on the browser fingerprint, including characteristic parameters such as the User Agent string, screen resolution, time zone, language preference, and Canvas fingerprint hash, which are combined to generate a unique DeviceID. Due to the stateless nature of web applications, the client stores the LinkID, AT, RT, and iteration anchors in dual backups: an HttpOnly Cookie (a small text file specifically for HTTP) and LocalStorage. Sensitive token information is additionally encrypted. During the authentication link's duration, each API request automatically injects an Authorization Bearer Token and an X-Link-ID (a custom link identifier header) into the request header via JavaScript. For sensitive operations such as payment transactions, the consistency between the browser environment fingerprint and the DeviceID recorded during initialization is additionally verified. When an AT expires, the front-end route interceptor automatically initiates a refresh request, refreshing the token through a hidden iframe or a dedicated refresh endpoint, avoiding interruptions to the user experience from page redirection. When the authentication process terminates, the client clears all stored authentication data and redirects to the login page, while the server synchronously clears the session state. Example

[0035] When implementing this authentication chain dual-token refresh method in a mini-program application scenario, the client runs on mini-program platforms such as WeChat and Alipay. Upon startup, the mini-program automatically calls the platform API (Application Programming Interface) to obtain device identification, including basic information such as device brand, model, operating system version, and client version number. This information is then combined with the mini-program's unique openid (user open identifier) ​​or unionid (user unified identifier) ​​to generate a composite DeviceID. Due to the limitations of the mini-program sandbox environment, authentication data is stored in the persistent storage system provided by the mini-program and protected using the mini-program framework's data encryption capabilities. During the authentication chain initialization phase, the mini-program obtains temporary credentials through wx.login (WeChat login interface) or an equivalent API, and sends them to the server along with the user's entered account and password to create the authentication chain. During the API request process, the mini-program globally encapsulates the wx.request (WeChat network request interface) method, automatically including AT and LinkID in the request header. The token refresh process is executed silently using the WeChat Mini Program's background capabilities. It checks the session status via wx.checkSession (WeChat session check interface) and automatically triggers the refresh process when the AT expires, completely unaware of the user's experience. When the user actively logs out or an anomaly is detected, the Mini Program clears local storage and calls the server's logout interface, while simultaneously using the Mini Program platform's notification capabilities to send a security alert to the user. Example

[0036] In modern network application authentication systems, dual-token mechanisms have become the mainstream technical solution. While the traditional combination of AccessToken and RefreshToken solves session management and user experience issues to some extent, it has significant shortcomings in terms of security, traceability, and protection capabilities. The authentication link-based dual-token refresh method proposed in this invention achieves a qualitative leap in authentication security by introducing a triple mechanism of iterative anchor points, link identifiers, and device binding.

[0037] The table below compares the core technical mechanisms of the authentication chain-based dual-token refresh method with traditional solutions.

[0038] Traditional solutions employ simple token issuance mechanisms, lacking the necessary correlation between Access Tokens and Refresh Tokens, leading to breaks in the authentication chain. This invention utilizes iterative anchoring technology to establish a strong association between each token refresh operation and historical states, forming an immutable authentication chain. This chain structure not only enhances system security but also provides a complete data foundation for subsequent auditing and traceability.

[0039] The table below compares the security capabilities of the authentication-linked dual-token refresh method with traditional solutions. In terms of actual safety protection, the two solutions show significant differences in performance:

[0040] Traditional solutions rely primarily on post-incident detection and token revocation mechanisms when facing replay attacks, resulting in a significant security window. This invention, however, fundamentally eliminates the possibility of replay attacks by utilizing the one-time use characteristic of iterative anchors. Regarding preventing token theft, traditional solutions lack effective device binding mechanisms, while this invention ensures the legitimacy of token use through device fingerprinting technology and a secondary verification mechanism.

[0041] The table below compares the security protection capabilities, system performance, and maintainability of the authentication-linked dual-token refresh method with traditional solutions. From the perspectives of system implementation and operation and maintenance, the two solutions each have their own characteristics:

[0042] Although this invention requires more development resources in the initial implementation phase, its centralized link archive management and efficient anomaly tracing capabilities can significantly reduce the cost of handling security incidents in long-term operation. Especially in fields with extremely high security requirements, such as finance and government, the security guarantees provided by this invention can create significant business value.

[0043] The table below compares the user experience of the authentication chain-based dual-token refresh method with traditional solutions. In terms of user experience, both solutions achieve the basic goal of seamless refresh, but there are differences in the details:

[0044] Traditional solutions often resort to simply terminating the session when equipment is replaced or anomalies are detected, which significantly impacts user experience. This invention, however, employs a tiered security response mechanism, employing different handling strategies based on risk levels to ensure security while maximizing the continuity of the user experience.

[0045] The table below compares the technical metrics of the authentication chain-based dual-token refresh method with traditional solutions.

[0046] These quantitative data fully demonstrate the significant technological advantages of this invention. In particular, in terms of replay attack protection and anomaly tracing, this invention represents a near-qualitative leap, providing reliable technical support for application scenarios with high security requirements.

[0047] A comprehensive comparative analysis shows that the authentication-linked dual-token refresh method of this invention significantly outperforms traditional dual-token authentication schemes in terms of security, traceability, and user experience. Although the implementation complexity is increased, this investment is entirely necessary and worthwhile in application scenarios with high security requirements. This invention, through its innovative iterative anchor mechanism and complete state management, provides a more secure, reliable, and user-friendly authentication solution for modern network applications. Example

[0048] This embodiment also provides an authentication link-based dual-token refresh device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0049] This embodiment provides an authentication-linked dual-token refresh device, including: The authentication link initialization module is used to create a unique authentication link when a user logs in for the first time, generate a link identifier, initial dual tokens and initial iteration anchors, and establish the corresponding link file.

[0050] The token refresh processing module is used to receive token refresh requests initiated by the client, perform multiple security verifications, and generate new dual tokens and iterative anchors after the verifications are successful.

[0051] The link status management module is used to maintain the status information of the authentication link, including the management and transition of states such as link activation, anomaly detection, and link termination.

[0052] The security audit and traceability module is used to record the entire lifecycle operation log of the authentication chain, providing the ability to quickly locate and trace abnormal events.

[0053] The device identification management module is used to generate and verify client device identifications and supports a security verification mechanism for device binding.

[0054] In some optional implementations, the token refresh processing module includes: The request verification unit is used to perform format validation and basic security checks on refresh requests to ensure the legitimacy of the requests.

[0055] The triple verification unit is used to perform link and token association verification, iterative anchor continuity verification, and device identifier consistency verification.

[0056] The token generation unit is used to generate new access tokens, refresh tokens, and iteration anchors after successful verification.

[0057] The response processing unit is used to securely return the newly generated token and anchor to the client.

[0058] In some alternative implementations, the triple verification unit includes: The link association verification subunit is used to verify the association between the refresh token and the current authentication link, ensuring that the token is used in the correct link.

[0059] The anchor verification subunit is used to perform millisecond-level precise comparisons of iterative anchors, verifying the consistency and one-time use characteristics of the anchors.

[0060] The device verification subunit is used to compare the requested device identifier with the device identifier recorded in the link file and handle the case of device mismatch.

[0061] In some optional implementations, the link state management module includes: The status monitoring unit is used to monitor the activity status of the authentication link in real time and detect abnormal behavior patterns.

[0062] The termination processing unit is used to handle normal and abnormal termination of the link, including token blacklist management and file archiving.

[0063] Anomaly response unit is used to trigger corresponding protective measures when a security threat is detected.

[0064] In some optional implementations, the security audit traceability module includes: The log recording unit is used to record all operational events throughout the authentication process.

[0065] The query analysis unit provides multi-dimensional query capabilities based on link identifier, time range, and operation type.

[0066] The traceability analysis unit is used to reconstruct the timeline of security events through iterative anchor chain analysis to locate the source of the anomaly.

[0067] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0068] The authentication chain-based dual-token refresh device provided in this embodiment achieves full lifecycle management of the authentication chain through modular design. The modules work collaboratively to ensure the security and reliability of the authentication process. The device adopts a layered architecture design, giving the system good scalability and maintainability, and enabling it to adapt to the needs of different scales and application scenarios. Example

[0069] In this embodiment, the apparatus for implementing the above-described authentication link-based dual-token refresh method is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above-described functions.

[0070] This invention also provides a computer device having the above-described features. Figure 8 The authentication linking dual-token refresh device shown is illustrated.

[0071] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 8 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 8 Take a processor 10 as an example.

[0072] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0073] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0074] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0075] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0076] The computer device also includes an input device 30 and an output device 40. The processor 10, memory 20, input device 30, and output device 20 can be connected via a bus or other means. Figure 8 Taking the example of a connection between China and Israel via a bus.

[0077] Input device 30 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the computer device, such as a touchscreen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 40 may include display devices, auxiliary lighting devices (e.g., LEDs), and haptic feedback devices (e.g., vibration motors). The aforementioned display devices include, but are not limited to, liquid crystal displays, light-emitting diodes, displays, and plasma displays. In some alternative embodiments, the display device may be a touchscreen.

[0078] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0079] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0080] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A dual-token refresh method for authentication chain, characterized in that, The method includes: Receive a token refresh request sent by the client, the request containing a refresh token, a link identifier, and an iteration anchor point; The corresponding authentication link file is queried based on the link identifier to verify the validity of the refresh token and its association with the current authentication link, and to obtain the expected iteration anchor point. Verify the consistency between the iteration anchor in the request and the expected iteration anchor; If the verification passes, a token refresh operation is performed to generate a new access token and a new refresh token, and a new iteration anchor point for the next refresh is generated based on the new access token.

2. The method according to claim 1, characterized in that, The method also includes a device identification verification step: Extract the current device identifier from the token refresh request. The device identifier is a device fingerprint hash value generated based on the client hardware and software environment. Verify the consistency between the current device identifier and the historical device identifier recorded in the authentication link file.

3. The method according to claim 1, characterized in that, The method also includes an authentication link initialization step: When a client user successfully logs in for the first time and authentication is successful, a globally unique link identifier is generated. Create an authentication link profile indexed by the link identifier, and generate an initial access token, refresh token, and iteration anchor for this session; The authentication link file records at least the following: the initial login IP, the device fingerprint hash value generated based on the client hardware and software environment, the login time, the source IP of each refresh request, and the type of abnormal event.

4. The method according to claim 1, characterized in that, The method also includes a business request verification step: During the validity period of the access token, receive business API requests initiated by the client, the requests carrying the currently valid access token and the link identifier; The authentication link file is queried based on the link identifier to verify the validity of the access token and its binding relationship with the link identifier.

5. The method according to claim 1, characterized in that: The iteration anchor point is the expiration time identifier of the access token that has expired in the previous round; The verification of consistency includes: determining whether the iteration anchor in the request is consistent with the expected anchor recorded by the server, and whether the iteration anchor has been used to successfully execute token refresh.

6. The method according to claim 2, characterized in that, The method also includes active defense steps: When device identification verification fails and an anomaly is detected that the iterative anchor point has already been used, an active defense strategy is triggered. The strategy includes: forcibly terminating the current authentication link, sending a multi-factor authentication request to the client, and sending a security alert to the administrator.

7. A dual-token refresh device for authentication chaining, characterized in that, include: The request processing module is used to receive token refresh requests sent by the client, the requests including refresh tokens, link identifiers, and iteration anchors; The continuity verification module is used to confirm the continuity between the current request and the historical token state by verifying the consistency between the iterative anchor point and the expected anchor point recorded by the server. The link file management module is used to create and maintain authentication link files indexed by the link identifier for sessions, and to support authentication operations based on the file; The device consistency verification module is used to extract the current device identifier from the token refresh request and verify the consistency between the current device identifier and the historical device identifier recorded in the authentication link file. The token and anchor management module is used to perform a token refresh operation after the verification is successful, generating a new access token, a new refresh token, and a new iteration anchor for the next refresh. An anomaly defense module is used to trigger an active defense strategy when the device consistency verification module fails the verification and the continuity verification module detects that the iterative anchor point is reused, the strategy includes forcibly terminating the current authentication link, sending a multi-factor authentication request, and sending a security alert to the administrator.

8. A computer device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the method of any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the method described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes computer instructions for causing a computer to perform the method described in any one of claims 1 to 6.

Images