A token-based authentication method and authentication device

Abstract

The embodiment of the application discloses a token-based authentication method and authentication device. The method comprises the following steps: in response to a token refresh request carrying a first token sent by a client, generating a second token, and recording a refresh time anchor point corresponding to the first token as a current time; returning the second token and a token generation time thereof to the client; in response to an authentication request carrying a target token and a token generation time thereof, acquiring a refresh time anchor point corresponding to the target token; comparing the token generation time carried in the authentication request with the refresh time anchor point corresponding to the target token; and if the token generation time carried in the authentication request is earlier than the refresh time anchor point corresponding to the target token, authentication fails. The application can guarantee user safety while maintaining service stability.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a token-based authentication method and authentication device. Background Technology

[0002] In the fields of cybersecurity and identity authentication, tokens are core credentials for user authentication in mobile internet applications, used to verify the legitimacy of a user's identity between the client and server. In the event of a large-scale token breach, relevant technologies need to accurately invalidate risky tokens without affecting the normal user experience, thereby ensuring account security.

[0003] In related technologies, the methods for dealing with token leaks typically include the following: first, batch invalidating tokens identified as leaked, forcing users to log in again; second, requiring users to actively log in again via push notifications; and third, waiting for the tokens to expire naturally. However, these solutions objectively have their own limitations: batch invalidation makes it difficult to distinguish between risky tokens and tokens from normal users, easily leading to a large number of normal users being passively logged out; relying on user-initiated actions cannot guarantee immediacy and coverage; and waiting for natural expiration, if the token validity period is long or permanently valid, will make the attack window for leaked tokens too long.

[0004] Therefore, in scenarios involving large-scale token leaks, the relevant technologies struggle to simultaneously meet the constraints of "accurately invalidating risk tokens" and "not affecting the normal user experience," making it difficult to achieve an effective balance between ensuring user security and maintaining service stability. This has become a pressing technical problem in the current authentication and authorization field. Summary of the Invention

[0005] In view of this, this application provides a token-based authentication method and authentication device to maintain service stability while ensuring user security.

[0006] This application provides the following solution: According to the first aspect, a token-based authentication method is provided, the method comprising: In response to a token refresh request sent by the client carrying the first token, a second token is generated, and the refresh time anchor point corresponding to the first token is recorded as the current time; Return the second token and its generation time to the client; In response to an authentication request carrying a target token and its generation time, obtain the refresh time anchor point corresponding to the target token; Compare the token generation time carried in the authentication request with the refresh time anchor point corresponding to the target token; If the token generation time carried in the authentication request is earlier than the refresh time anchor point corresponding to the target token, the authentication will fail.

[0007] Optionally, the step of recording the refresh time anchor point corresponding to the first token as the current time includes: In the token storage table of the database, update the refresh time field corresponding to the first token to the current timestamp.

[0008] Optionally, the method further includes: synchronously writing the updated value of the refresh time field into the cache as a refresh time anchor point; The step of obtaining the refresh time anchor point corresponding to the target token includes: reading the refresh time anchor point corresponding to the target token from the cache.

[0009] Optionally, the method further includes: In response to the token refresh request, an asynchronous message for canceling the first token is generated and the asynchronous message is written to a message queue; In response to reading the asynchronous message from the message queue, a cancellation flag is set for the first token record; In response to the authentication request carrying the target token and its generation time, if the target token has an cancellation mark, the authentication fails.

[0010] Optionally, generating an asynchronous message for canceling the first token in response to the token refresh request includes: in a scenario where token information is stored in a database based on a hash structure, generating an asynchronous message for canceling the first token in response to the token refresh request; The step of setting a cancellation flag for the first token record includes: setting a cancellation flag for the first token in the hash-based database.

[0011] Optionally, the method further includes: receiving a risk marking instruction carrying either a session identifier or a token identifier, and recording a risk mark for either the session identifier or the token identifier; In response to the authentication request carrying the target token and its generation time, if the session identifier corresponding to the authentication request has a risk flag or the token identifier corresponding to the target token has a risk flag, then the authentication fails.

[0012] Optionally, the method further includes: sending an active refresh command to the client through a long connection between the server and the client; The token refresh request is sent by the client in response to the active refresh command.

[0013] According to the second aspect, a token-based authentication device, the device comprising: The data receiving unit is configured to receive a token refresh request carrying a first token sent by the client; The token refresh unit is configured to generate a second token in response to the token refresh request and record the refresh time anchor point corresponding to the first token as the current time; The data sending unit is configured to return the second token and its generation time to the client; The data receiving unit is also configured to carry an authentication request for the target token and its generation time. The token authentication unit is configured to, in response to the authentication request, obtain the refresh time anchor point corresponding to the target token; compare the token generation time carried in the authentication request with the refresh time anchor point corresponding to the target token; if the token generation time carried in the authentication request is earlier than the refresh time anchor point corresponding to the target token, then authentication fails.

[0014] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any one of the first aspects above.

[0015] According to the fourth aspect, an electronic device is provided, comprising: One or more processors; and A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method described in any one of the first aspects above.

[0016] According to a fifth aspect, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the steps of the method described in any of the first aspects above.

[0017] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application introduces a dynamically updated "refresh time anchor" for the token, comparing the token's static creation time with this dynamically updated refresh time anchor. This ensures that once a legitimate user obtains a new token through refreshing, the old leaked token will be automatically deemed invalid because its creation time is earlier than the latest refresh time anchor. This eliminates the need to force the user offline, accurately invalidating the leaked risk token without the user's awareness, thus protecting user security while maintaining service stability.

[0018] Of course, any product implementing this application does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a system architecture diagram applicable to the embodiments of this application.

[0021] Figure 2 A flowchart of a token-based authentication method provided in an embodiment of this application.

[0022] Figure 3 This is a schematic diagram of the storage and read refresh time anchor points provided in the embodiments of this application.

[0023] Figure 4 The interaction sequence diagram is provided for the token-based authentication method in the embodiments of this application.

[0024] Figure 5 A schematic block diagram of a token-based authentication device provided in an embodiment of this application.

[0025] Figure 6 A schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0027] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0028] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0029] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0030] In the field of identity authentication and authorization technology, to ensure user account security, the commonly used technical solution is a static verification mechanism based on tokens. Specifically, after a user logs in, the server generates a token containing the user's identifier and issues it to the client. Subsequent requests from the client include this token, and the server verifies the token's existence, validity period, and absence of expiration by querying the database or cache. Its basic working principle is a static comparison based on the token's "existence" and "validity period." Its widespread use is primarily due to its ability to implement simple and direct authentication logic effectively, with relatively low implementation costs.

[0031] However, this solution performs poorly when applied to internet applications serving hundreds of millions of users and facing large-scale token leaks. A fundamental contradiction lies in the fact that while the solution optimizes the user login experience by setting a long token validity period, its inherent design inevitably compromises security. Once a token is leaked, attackers can exploit it for a considerable period. Specifically, in scenarios involving large-scale token leaks, when it's necessary to invalidate leaked tokens without affecting legitimate users, existing solutions either force all users to re-login due to their inability to distinguish between risky and legitimate tokens, passively wait for user intervention via push notifications, or allow leaked tokens to remain valid indefinitely. None of these solutions strike a balance between ensuring user security and maintaining service stability.

[0032] In view of this, this application provides a new approach. To facilitate understanding of this application, the system architecture on which this application is based will first be described. Figure 1 An exemplary system architecture that can be applied to embodiments of this application is shown, such as Figure 1 As shown, the system architecture may include: a client and an authentication device set on the server side.

[0033] The server and client are the two main components of an application service. The server, using a server as its primary hardware infrastructure, may include one or more software service modules. In this embodiment, it is mainly responsible for handling the receiving and sending binding relationships, forming a collaborative front-end and back-end with the client.

[0034] The user terminal where the client resides can include, but is not limited to, smart mobile terminals, wearable devices, and PCs (Personal Computers). Smart mobile devices can include devices such as mobile phones, tablets, PDAs (Personal Digital Assistants), and connected car terminals. Wearable devices can include devices such as smartwatches, smart glasses, smart bracelets, VR (Virtual Reality) devices, AR (Augmented Reality) devices, and mixed reality devices (i.e., devices that support both virtual and augmented reality), etc.

[0035] The client can be an application located on the user's terminal, or it can be a plugin or software development kit (SDK) or other functional unit set in the application.

[0036] A server can be a standalone server, a server cluster, or a cloud server. A cloud server, also known as a cloud computing server or cloud host, is a hosting product within the cloud computing service system, designed to address the shortcomings of traditional physical hosts and Virtual Private Servers (VPS) services, such as high management difficulty and weak service scalability.

[0037] In one scenario, the client can send token refresh requests and authentication requests to the server, and receive authentication results or instructions from the server. The server-side authentication device can perform token-based authentication using the method provided in the embodiments of this application, as detailed in the relevant descriptions in subsequent embodiments.

[0038] It should be understood that Figure 1 The authentication devices and clients shown are merely illustrative. Depending on implementation needs, any number of authentication devices and clients can be included.

[0039] Figure 2 This is a flowchart of a token-based authentication method provided in an embodiment of this application. This method can be... Figure 1 The authentication device in the system shown is executed. For example... Figure 2 As shown, the method may include the following steps: Step 201: In response to the token refresh request sent by the client carrying the first token, generate the second token and record the refresh time anchor point corresponding to the first token as the current time.

[0040] Step 203: Return the second token and its generation time to the client.

[0041] Step 205: In response to the authentication request carrying the target token and its generation time, obtain the refresh time anchor point corresponding to the target token; compare the token generation time carried in the authentication request with the refresh time anchor point corresponding to the target token; if the token generation time carried in the authentication request is earlier than the refresh time anchor point corresponding to the target token, then authentication fails.

[0042] As can be seen from the above process, this application introduces a "refresh time anchor" that is dynamically updated with refresh behavior for the token. The static creation time of the token is compared with the dynamically updated refresh time anchor. This means that once a legitimate user obtains a new token through refresh, the old leaked token will be automatically determined to be invalid because its creation time is earlier than the latest refresh time anchor. Therefore, without forcing the user to go offline, the leaked risk token is accurately invalidated without the user's awareness, thus ensuring user security while maintaining service stability.

[0043] The following describes in detail each step of the above process and the effects that can be further produced, with reference to the embodiments. It should be noted that the terms "first" and "second" used in this disclosure do not have limitations on size, order, or quantity, but are only used to distinguish them by name. For example, "first token" and "second token" are used to distinguish two tokens by name.

[0044] First, the above step 201, namely "in response to the token refresh request carrying the first token sent by the client, generate the second token, and record the refresh time anchor point corresponding to the first token as the current time", will be described in detail with reference to the embodiment.

[0045] A token refresh request indicates that the user's currently held primary token needs to be updated. The methods for triggering token refresh requests provided in this application are flexibly configurable to adapt to different service scenarios and client states. Specifically, a token refresh request can be initiated proactively by the client or triggered by the server.

[0046] 1. The client actively initiates a token refresh request. Under normal circumstances, the client will proactively send a token refresh request to the server according to a preset strategy. For example: Scheduled refresh: The client can set a timer to automatically trigger a token refresh request at regular intervals (such as the half-life of the token's validity period) to maintain the long-term validity of the session.

[0047] Service event triggering: When a client detects a specific service event, such as when the client is cold or warm starting, when entering a page that requires a higher level of security, or when initiating a sensitive transaction, it can proactively initiate a token refresh request to obtain a new token.

[0048] Risk Awareness and Response: When the client application's own risk control mechanism detects suspicious environmental changes, such as changes in device fingerprints or IP address anomalies, it proactively initiates a token refresh request to avoid potential token leakage risks.

[0049] This method serves as a standard refresh chain, allowing normal users' tokens to be refreshed naturally with their usage activities.

[0050] 2. The server triggers the client to initiate an active refresh and repair request. To cover situations where the client fails to actively refresh the token due to various reasons, such as long-term background operation, prolonged user inactivity, or client-side logical defects, or to address situations involving historical abnormal data (such as expired PassTokens or multiple clients logging into the same account), this application embodiment introduces a server-driven refresh mechanism.

[0051] Specifically, the server can send a proactive refresh command to a specific client through an established long-lived connection, such as a WebSocket or SSE (Server-Sent Events) channel. This proactive refresh command can include necessary context information, such as the client identifier and refresh reason code. Upon receiving the proactive refresh command, the client will immediately respond and, following a pre-defined refresh procedure, send a token refresh request to the server, carrying the currently used first token.

[0052] By using the server to proactively trigger the client's token refresh behavior through a long connection channel, an automated "error correction-repair" closed loop is formed. This effectively solves the problem of refresh stalling due to client-side logic defects or historical abnormal data, which prevents the silent failure mechanism from taking effect. This significantly improves the coverage and effectiveness of the silent failure mechanism across all users.

[0053] In summary, the client-initiated refresh and server-triggered refresh complement each other, together forming a complete chain for token lifecycle management in the authentication method of this application. The former ensures normal, silent failure under normal circumstances, while the latter provides a powerful, proactively intervened repair capability, ensuring that the entire system can maintain a high level of token security governance even when facing complex, long-tail client scenarios.

[0054] Regardless of the scenario, when the client sends a token refresh request, it can call a predefined interface, such as ` / rest / n / token / infra / RefreshToken`. Upon receiving the token refresh request, the server generates a new second token with a completely new token generation time, typically set to the current time (e.g., the current timestamp of the system time). Simultaneously, the server records the refresh time anchor point corresponding to the first token as the current time.

[0055] This step, by updating the refresh time anchor, provides a time reference for subsequent determination of token age. More generally, the action of recording the refresh time anchor corresponding to the first token can be implemented in several ways. One possible method is to update the refresh time field corresponding to the first token to the current timestamp in the token storage table of the database.

[0056] The token storage table in the database has a pre-defined refresh time field (e.g., named update_time, of millisecond-level timestamp). This field records the time when the corresponding token was last refreshed by the refresh interface. When a token refresh request is processed, the server performs the following operations within a transaction: locate the record row of the first token in the token storage table, and update the value of the update_time field of that record to the server's current system timestamp (current time).

[0057] For example, suppose the user_token_v2_xxx table in the database stores the first token Token_A, with a create_time of 17000000000000. When a user calls the RefreshToken interface, the server generates a new token Token_B and executes the SQL statement UPDATE user_token_v2_xxx SET update_time = 1700010000000 WHERE token_id = 'Token_A' within the same transaction, thus recording the refresh time anchor point corresponding to Token_A as 1700010000000.

[0058] This write operation follows the regular data update process of the database, ensuring data consistency through transactions. Because the database provides persistent storage, this refresh time anchor will not be lost due to service restarts or cache invalidation.

[0059] By adding a refresh time field to the token storage table of a relational database to record time anchors, a structured and persistent storage method is provided, ensuring that refresh time anchor data will not be lost due to service restarts or memory clearing, thus guaranteeing the reliability and recoverability of the core data of the silent failure mechanism.

[0060] Besides the methods mentioned above, other methods can also be used to record the refresh time anchor point corresponding to the first token as the current time, such as storing the refresh time anchor point in an in-memory database, writing it to a log file, etc.

[0061] Furthermore, such as Figure 3 As shown, after updating the refresh time field in the token storage table of the database, the server synchronously writes the updated field value as the refresh time anchor into the cache (e.g., Memcached). This cache is deployed independently of the database and primarily handles the load of high-frequency read requests.

[0062] For example, when the server updates the `update_time` field in the database to the current timestamp (e.g., 1700010000000) within a transaction, it immediately writes a key-value pair to the cache node. The key is the unique identifier of the first token (e.g., `Token_A`), and the value is the refresh time anchor. This write operation is executed sequentially within the same request processing cycle as the database update, ensuring that the data in the cache remains consistent with the data in the database.

[0063] Subsequently, as Figure 3 As shown, in the subsequent authentication process, when an authentication request carrying the target token (which may be an old token that has been refreshed) and its token generation time is received, the token generation time carried in the authentication request is obtained. The server first reads the refresh time anchor point corresponding to the target token from the cache. The read operation is located directly by key name, without querying the database. If the cache is hit, the refresh time anchor point is directly obtained for subsequent comparison; if the cache is not hit (e.g., due to cache eviction or crash), the process is downgraded to reading the value from the database, and optionally, the cache is populated.

[0064] By introducing a cache to synchronously mirror the refresh time anchor in the database, high-concurrency authentication requests can directly read the refresh time anchor from the cache for comparison. This avoids the huge I / O pressure and response latency caused by directly querying the database for each authentication, significantly improving the overall throughput of the authentication chain and reducing the response time, thus supporting efficient authentication for hundreds of millions of users.

[0065] After generating the second token, the server returns the second token and its generation time to the client in step 203 above. In this embodiment, the first token, the second token, and the subsequent target token can all be service tokens, which are tokens issued by the server and used to access the service. A service token is equivalent to an access token, with a short lifespan (e.g., several minutes to several hours). The client needs to include it in every request to call the service, and the server uses it to verify the legitimacy of the request.

[0066] The following describes in detail step 205, namely, "in response to an authentication request carrying a target token and its generation time, obtain the refresh time anchor point corresponding to the target token; compare the token generation time carried in the authentication request with the refresh time anchor point corresponding to the target token; if the token generation time carried in the authentication request is earlier than the refresh time anchor point corresponding to the target token, then authentication fails," with reference to the embodiments.

[0067] The server receives an authentication request that arrives at a certain point in time. The term "authentication request" broadly refers to any network request initiated by the client that requires the server to verify the validity of the client's token. Authentication requests can be regular service data requests, requests to maintain a connection, or resource loading requests, etc.

[0068] The core characteristics of this authentication request are: first, it must carry a target token to be verified; second, it must also carry the creation time (createTime) of the target token. The server determines whether to allow the request by comparing the token creation time in the request with the "refresh time anchor" maintained by the server.

[0069] This authentication request could be issued by a malicious entity holding the leaked token, or it could be issued by a legitimate client that has just refreshed its token. Upon receiving the request, the server retrieves the refresh time anchor point corresponding to the target token; for example... Figure 3As shown, the token generation time carried in the authentication request is compared with the refresh time anchor point corresponding to the obtained target token. This comparison logic is the key difference between the technical solution of this application and related technologies. The comparison result directly determines whether the authentication passes. If the result is that the token generation time carried in the authentication request is earlier than the refresh time anchor point corresponding to the target token, it means that the token being authenticated is an old token that was created before the most recent refresh operation. Since normal users will definitely hold a new token after refreshing (whose generation time is no earlier than the anchor point), any authentication request whose creation time is earlier than the refresh time anchor point can be identified as being initiated by a black market entity holding a leaked old token. In this case, the server will determine that the authentication has failed and reject the request. Conversely, if the token generation time is no earlier than the refresh time anchor point, it means that the target token is a valid token, the authentication passes, and the service logic corresponding to the request is allowed to continue.

[0070] Additionally, if the refresh time anchor corresponding to the target token cannot be obtained from either the cache or the database, authentication is deemed to have failed, and the request is rejected.

[0071] To further cover special verification links where the core time anchor scheme cannot be applied due to technical limitations, this application also provides a delayed deregistration scheme based on asynchronous messages. In response to a token refresh request, an asynchronous message for deregistering the first token is generated and written to a message queue; in response to reading the asynchronous message from the message queue, a deregistration flag is recorded for the first token; in response to an authentication request carrying the target token and its generation time, if the target token has a deregistration flag, authentication fails.

[0072] Specifically, after responding to the client's token refresh request carrying the first token, the server generates an asynchronous message for canceling the first token while simultaneously generating the second token. This asynchronous message contains a unique identifier for the first token (such as TokenId) and is written to a message queue (such as RabbitMQ, Kafka, or a delayed message queue).

[0073] The asynchronous message stored in the message queue is consumed with a delay, the delay time of which is configurable (e.g., set to N minutes, such as 5 minutes). When the consumer reads the asynchronous message from the message queue, it records a cancellation flag for the first token. This cancellation flag is stored in the storage medium of the corresponding token verification link (e.g., setting a boolean field or flag bit in the Redis Hash structure to indicate that the token has been cancelled).

[0074] Subsequently, when the authentication service receives an authentication request carrying the target token (which may be the first token) and its generation time, in addition to performing time-anchored comparison logic, it can also check whether the target token has a cancellation mark. If the target token has a cancellation mark, the authentication is directly deemed to have failed, and the request is rejected.

[0075] As can be seen, by introducing a message queue to implement an asynchronous delayed cancellation mechanism, the token expiration handling logic is decoupled from the core refresh link. This allows for the automatic expiration of old tokens in a non-blocking, eventually consistent manner, even for storage links that do not support dynamic time anchor updates. This expands the applicability of the silent expiration scheme while ensuring zero impact on the performance of the upstream refresh interface.

[0076] In some token verification chains, token information is stored in a hash-based database (such as RedisHash, corresponding to the Kiwi chain in the system). This storage structure organizes data in the form of a hash table, with each record consisting of fields and values. It naturally supports storing multiple attributes (such as token validity period, user ID, etc.), but it does not provide sorting or range query capabilities based on field values. Therefore, it cannot directly support a solution that achieves silent expiration by comparing the token creation time with the refresh time anchor.

[0077] For this type of scenario, this embodiment can adopt the asynchronous cancellation scheme described above. When the server receives a token refresh request, if it confirms that the storage medium of the current token is a hash-based database, then in this scenario, the server responds to the refresh request by generating an asynchronous message for canceling the first token. This message contains the unique identifier of the first token (such as TokenId). Subsequently, when the asynchronous message is consumed, the consumer locates the hash record corresponding to the first token in the hash-based database and sets a dedicated cancellation flag field (such as revoked, status, etc.) in this record, setting its value to indicate a "cancelled" status (such as the integer 1 or the boolean value true). This flag field does not change other attributes of the original token (such as createTime, expireTime), and is only used to indicate that the token has been cancelled.

[0078] During subsequent authentication, when an authentication request carrying the target token (possibly the first token) and its generation time is received, the server reads the hash record corresponding to the target token from the hash-based database. If a cancellation flag is detected in the record (e.g., the value of the `revoked` field is 1), authentication is directly deemed to have failed, and the request is rejected.

[0079] As can be seen, the embodiments of this application specify the specific application scenarios and implementation carriers of the asynchronous delayed cancellation scheme, and clarify that in specific technical scenarios based on hash structure storage such as Redis Hash, cancellation is achieved by setting a cancellation flag for its data structure. This provides an implementation method that is parallel to and compatible with the time anchor scheme based on relational databases, and has stronger technical adaptability, ensuring the effective operation of the silent failure mechanism under different technology stacks.

[0080] In the implementation of the asynchronous deregistration scheme, the message queue latency parameter can be configured based on system load and service tolerance. For example, the latency can be set to N minutes, with a typical value of 5 minutes. The design of this latency value needs to be based on a balance analysis between the peak rate of refresh requests (RefreshToken QPS) and the consumption rate.

[0081] Taking actual test data as an example, in a scenario with hundreds of millions of daily active users, the peak QPS of the RefreshToken interface is approximately 4000. If the consumption rate is configured to 5000 messages / second, the theoretical calculation of the queue backlog is: Backlog duration = RefreshToken QPS × Delay in seconds / Consumption rate = 4000 × (5 × 60) / 5000 ≈ 4 minutes.

[0082] That is, after a 4-minute consumption delay, the messages in the queue can be completely processed, and the system as a whole is in a stable state. If the consumption rate is increased to more than 20,000 messages per second, there is almost no backlog in the queue, and all deregistration messages can be processed in real time.

[0083] This asynchronous cancellation scheme has the following technical advantages: The logout operation adopts an asynchronous processing mode, which only needs to write a short message to the message queue and return immediately without waiting for subsequent database or cache write operations. This ensures the low response latency of the RefreshToken interface and does not affect the user experience due to the addition of logout logic.

[0084] The introduction of the delay mechanism provides a buffer window for concurrent refresh actions that may occur within a short period of time. For example, if a user triggers two token refresh requests within one second due to network jitter, both cancellation messages are written to the queue, but the actual cancellation operation is executed only after a delay. This avoids anomalies that might occur during the handover process of old and new tokens if synchronous cancellation were used. For instance, the second refresh might attempt to cancel the new token generated by the first refresh before the client has a stable hold of the new token. The delay mechanism ensures that all new tokens have sufficient time to be received and cached by the client before cancellation.

[0085] The entire logout process is completely transparent to the user. The user does not need to perform any active operation and will not be aware of the asynchronous logout behavior in the background; the login state remains normal throughout. This mechanism is executed only on the server side and does not involve any user interface or push notifications.

[0086] In addition to normalized silent failure based on time anchors and auxiliary mechanisms based on asynchronous cancellation, this embodiment also provides a precise failure capability to support immediate and targeted cancellation operations for specific high-risk sessions or tokens.

[0087] In this scheme, the server receives risk marking instructions from external sources (such as a risk control system or security operations platform). These instructions carry a session identifier (Sid, used to identify the application's origin, such as a session established during a login) and / or a token identifier (TokenId, a unique identifier for a token, used to precisely point to a specific token record). For example, the risk control system can issue a risk marking instruction carrying the session identifier and / or token identifier by calling the risk marking interface provided by the authentication device. Upon receiving the instruction, the authentication device, in response to the risk marking instruction, records a risk mark in a separate storage medium (such as a cache or a risk mark table in a database) for the session identifier and / or token identifier specified in the risk marking instruction.

[0088] In the subsequent authentication process, when an authentication request carrying the target token and its generation time is received, the authentication service needs to perform two checks: Extract the session identifier corresponding to the authentication request (usually obtained from the context of the request or the session associated with the token) and the token identifier (such as TokenId) of the target token.

[0089] Then, the system queries the risk token storage to check if the session identifier and the token identifier both contain a risk token. If either contains a risk token, authentication fails, and the request is rejected.

[0090] For example, security operations personnel might discover a batch of tokens at risk of leakage through the risk control system, but be unsure which user devices are affected. In this case, the operations personnel can issue a risk marking command by specifying a particular Sid (corresponding to a batch of at-risk sessions). The server records the risk mark for that Sid. Subsequently, any authentication request carrying that Sid (even if the token itself appears normal at the time of the event) will be rejected, thus achieving precise invalidation of that batch of sessions. Similarly, commands can be issued for a single leaked TokenId to achieve targeted attacks.

[0091] By adding an independent risk marking and authentication interception mechanism based on session identifiers or token identifiers, a more granular and precise failure capability is provided that complements the refresh time anchor mechanism. This enables security operators to take immediate and proactive failure measures on identified risk individuals without waiting for them to refresh naturally, thus improving the comprehensive risk management system from normal silent failure to precise strikes in special cases.

[0092] The following is combined with Figure 4 This paper provides a detailed explanation of the interaction sequence of the token-based authentication method described in this application. For ease of understanding, the interaction entities are divided into: user (the final operator), client (a device with an application installed, such as a mobile app), SDK (an authentication software development kit integrated into the client, responsible for token management, automatic refresh, and communication with the server), and server (a backend system that provides token issuance, refresh, and authentication services). This interaction sequence mainly includes the following stages.

[0093] Phase 1: Actively Refresh the Process Step 1.1: The user performs an operation on the client (such as opening the application or clicking on a function entry).

[0094] Step 1.2: Based on the above operations, the client detects that the token needs to be refreshed.

[0095] Step 1.3: The SDK calls the RefreshToken interface to send a token refresh request, which carries the old ServiceToken (i.e., the first token).

[0096] Step 1.4: After receiving the token refresh request, the server generates a new ServiceToken (i.e., the second token) and sets its creation time (createTime) to the current timestamp. In the token storage table of the database, the update_time (refresh time field) corresponding to the first token is updated to the current timestamp. This updated timestamp serves as the refresh time anchor for the new ServiceToken. Simultaneously, the updated refresh time anchor value is synchronously written to Memcached for low-latency reading during subsequent authentication.

[0097] Step 1.5: The server returns a refresh success response to the SDK. The response includes the new ServiceToken (second token) and its createTime (token generation time), and may also include other metadata (such as expiration date).

[0098] Step 1.6: The SDK updates the client's local ServiceToken, creating a new ServiceToken and recording its createTime. After this, all subsequent requests from the client will carry the new ServiceToken and its createTime.

[0099] Phase 2: A normal user's client initiates a service request. Step 2.1: The user triggers the client to initiate a service request (such as service access). Step 2.2: The client sends a service request carrying the new ServiceToken (i.e., the target token) and its createTime.

[0100] Step 2.3: The SDK sends a service request to the server.

[0101] Step 2.4: The server performs authentication, including: retrieving the update_time corresponding to the new ServiceToken from the cache or database, extracting the createTime carried in the authentication request; comparing the two: if the createTime is not earlier than the update_time, and the ServiceToken itself has not expired and has no cancellation mark, then the ServiceToken authentication is deemed successful.

[0102] Steps 2.5 to 2.7: Service data is returned step by step from the server to the SDK, from the SDK to the client, and from the client to the user.

[0103] Phase 3: The black market client initiates a service request. Suppose that the malicious actors stole the old ServiceToken.

[0104] Step 3.1: The black market triggers the client to initiate a service request (such as service access). Step 3.2: The client sends a service request carrying the old ServiceToken (i.e., the target token) and its createTime.

[0105] Step 3.3: The SDK sends a service request to the server.

[0106] Step 3.4: The server performs authentication, including: retrieving the update_time corresponding to the old ServiceToken from the cache or database, and extracting the createTime carried in the authentication request; comparing the two: since the createTime of the old ServiceToken is earlier than the update_time, the ServiceToken authentication is determined to have failed.

[0107] Steps 3.5-3.7: The server returns a response indicating that the request was rejected, from the SDK to the client, and from the client to the user.

[0108] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0109] Figure 5 A schematic block diagram of a token-based authentication device provided in an embodiment of this application, such as... Figure 5 As shown, the device 500 includes: a data receiving unit 501, a token refreshing unit 502, a data sending unit 503, and a token authentication unit 504. The main functions of each component include: The data receiving unit 501 is configured to receive a token refresh request carrying a first token sent by the client.

[0110] The token refresh unit 502 is configured to generate a second token in response to a token refresh request and record the refresh time anchor point corresponding to the first token as the current time.

[0111] The data sending unit 503 is configured to return a second token and its generation time to the client.

[0112] The data receiving unit 501 is also configured to carry an authentication request for the target token and its generation time.

[0113] The token authentication unit 504 is configured to, in response to an authentication request, obtain the refresh time anchor point corresponding to the target token; compare the token generation time carried in the authentication request with the refresh time anchor point corresponding to the target token; if the token generation time carried in the authentication request is earlier than the refresh time anchor point corresponding to the target token, then authentication fails.

[0114] As one possible implementation method, when the token refresh unit 502 records the refresh time anchor point corresponding to the first token as the current time, it can be configured to update the refresh time field corresponding to the first token to the current timestamp in the token storage table of the database.

[0115] Furthermore, the token refresh unit 502 can also be configured to synchronously write the updated refresh time field value as a refresh time anchor point into the cache. When obtaining the refresh time anchor point corresponding to the target token, the token authentication unit 504 can be configured to read the refresh time anchor point corresponding to the target token from the cache.

[0116] Furthermore, the token refresh unit 502 is also configured to: in response to a token refresh request, generate an asynchronous message for canceling the first token and write the asynchronous message to a message queue; in response to reading the asynchronous message from the message queue, record a cancellation flag for the first token. The token authentication unit 504 can also be configured to: in response to an authentication request carrying the target token and its generation time, if the target token has a cancellation flag, authentication fails.

[0117] As one possible implementation, when the token refresh unit 502 generates an asynchronous message for canceling the first token in response to a token refresh request, it can be configured to: in a scenario where token information is stored in a database based on a hash structure, generate an asynchronous message for canceling the first token in response to a token refresh request. When setting a cancellation flag for the first token record, it can be configured to: set a cancellation flag for the first token in the database based on a hash structure.

[0118] Furthermore, the data receiving unit 501 is also configured to receive a risk marking instruction carrying either a session identifier or a token identifier. Correspondingly, the token refresh unit 502 can be configured to record a risk marking for either the session identifier or the token identifier. The token authentication unit 504 can also be configured to, in response to an authentication request carrying a target token and its generation time, fail authentication if either the session identifier corresponding to the authentication request or the token identifier corresponding to the target token has a risk marking.

[0119] Furthermore, the data sending unit 503 can also be configured to send an active refresh command to the client via a long-lived connection between the server and the client. Correspondingly, the token refresh request is sent by the client in response to the active refresh command.

[0120] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or device embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to the description of the method embodiments. The system and device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0121] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0122] In addition, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0123] And an electronic device, comprising: One or more processors; and A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method described in any of the foregoing method embodiments.

[0124] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0125] in, Figure 6An exemplary architecture of an electronic device is shown, which may include a processor 610, a video display adapter 611, a disk drive 612, an input / output interface 613, a network interface 614, and a memory 620. The processor 610, video display adapter 611, disk drive 612, input / output interface 613, network interface 614, and memory 620 can communicate with each other via a communication bus 630.

[0126] The processor 610 can be implemented using a general-purpose CPU, microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits to execute relevant programs and implement the technical solution provided in this application.

[0127] The memory 620 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 620 can store the operating system 621 for controlling the operation of the electronic device 600, and the basic input / output system (BIOS) 622 for controlling the low-level operations of the electronic device 600. Additionally, it can store a web browser 623, a data storage management system 624, and an authentication device 500, etc. The aforementioned authentication device 500 can be the application program that specifically implements the aforementioned steps in this embodiment. In summary, when the technical solution provided in this application is implemented through software or firmware, the relevant program code is stored in the memory 620 and is called and executed by the processor 610.

[0128] Input / output interface 613 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touch screens, microphones, various sensors, etc., and output devices may include displays, speakers, vibrators, indicator lights, etc.

[0129] Network interface 614 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0130] Bus 630 includes a pathway for transmitting information between various components of the device, such as processor 610, video display adapter 611, disk drive 612, input / output interface 613, network interface 614, and memory 620.

[0131] It should be noted that although the above-described device only shows the processor 610, video display adapter 611, disk drive 612, input / output interface 613, network interface 614, memory 620, bus 630, etc., in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the solution of this application, and does not necessarily include all the components shown in the figures.

[0132] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer program product. This computer program product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0133] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A token-based authentication method, characterized in that, The method includes: In response to a token refresh request sent by the client carrying the first token, a second token is generated, and the refresh time anchor point corresponding to the first token is recorded as the current time; Return the second token and its generation time to the client; In response to an authentication request carrying a target token and its generation time, obtain the refresh time anchor point corresponding to the target token; Compare the token generation time carried in the authentication request with the refresh time anchor point corresponding to the target token; If the token generation time carried in the authentication request is earlier than the refresh time anchor point corresponding to the target token, the authentication will fail.

2. The method according to claim 1, characterized in that, The record of the refresh time anchor point corresponding to the first token is the current time, including: In the token storage table of the database, update the refresh time field corresponding to the first token to the current timestamp.

3. The method according to claim 2, characterized in that, The method further includes: synchronously writing the updated value of the refresh time field into the cache as a refresh time anchor point; The step of obtaining the refresh time anchor point corresponding to the target token includes: reading the refresh time anchor point corresponding to the target token from the cache.

4. The method according to claim 1, characterized in that, The method further includes: In response to the token refresh request, an asynchronous message for canceling the first token is generated and the asynchronous message is written to a message queue; In response to reading the asynchronous message from the message queue, a cancellation flag is set for the first token record; In response to the authentication request carrying the target token and its generation time, if the target token has an cancellation mark, the authentication fails.

5. The method according to claim 4, characterized in that, The step of generating an asynchronous message for canceling the first token in response to the token refresh request includes: in a scenario where token information is stored in a database based on a hash structure, generating an asynchronous message for canceling the first token in response to the token refresh request; The step of setting a cancellation flag for the first token record includes: setting a cancellation flag for the first token in the hash-based database.

6. The method according to claim 1, characterized in that, The method further includes: receiving a risk marking instruction carrying either a session identifier or a token identifier, and recording a risk mark for either the session identifier or the token identifier; In response to the authentication request carrying the target token and its generation time, if the session identifier corresponding to the authentication request has a risk flag or the token identifier corresponding to the target token has a risk flag, then the authentication fails.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: sending an active refresh command to the client through a long connection between the server and the client; The token refresh request is sent by the client in response to the active refresh command.

8. A token-based authentication device, characterized in that, The device includes: The data receiving unit is configured to receive a token refresh request carrying a first token sent by the client; The token refresh unit is configured to generate a second token in response to the token refresh request and record the refresh time anchor point corresponding to the first token as the current time; The data sending unit is configured to return the second token and its generation time to the client; The data receiving unit is also configured to carry an authentication request for the target token and its generation time. The token authentication unit is configured to, in response to the authentication request, obtain the refresh time anchor point corresponding to the target token; compare the token generation time carried in the authentication request with the refresh time anchor point corresponding to the target token; if the token generation time carried in the authentication request is earlier than the refresh time anchor point corresponding to the target token, then authentication fails.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, include: One or more processors; as well as A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 7.

Images