Method and system for dynamically maintaining Token

Abstract

The invention provides a method and a system for dynamically maintaining a Token, computing equipment and a computer readable storage medium, in the method, after a server generates a first Token after login verification of a client is passed and before the first Token is returned to the client, the first Token is stored in a first database, and an index mapping table of a unique identifier of the Token is established; 'pseudo-stateful 'management of the Token is realized by intercepting a client request; when the risk of Token leakage occurs, the corresponding record in the first database can be directly deleted or the interface is called to forcibly expire the Token. Furthermore, all active Tokens of the user are stored by taking a user name as a key to form a global view of the login user, an automatic cleaning function, manual revocation and a self-defined capacity control strategy are integrated through a dynamic maintenance strategy, the Token number upper limit and validity period rule of a single user are supported to be dynamically adjusted, and flexible management of concurrent login of multiple devices is realized.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, system, computing device, and computer-readable storage medium for dynamically maintaining a token. Background Art

[0002] In the field of identity authentication in distributed systems, JSON Web Token (JWT) is widely adopted due to its stateless nature. However, its validity depends on client storage and the token's own expiration date. Existing technologies have the following flaws: once issued by the server, traditional JWTs cannot be automatically revoked by the server. If a token leak occurs, attackers can exploit long-lived tokens to gain continuous, illegal access to the system. Furthermore, tokens are stored in a decentralized manner on the client side, preventing the server from fully understanding the user's login session, making it difficult to implement concurrent login control for multiple devices. Furthermore, it is impossible to dynamically adjust the upper limit on the number of tokens a user can hold or adjust the expiration date of specific tokens based on business needs. Summary of the Invention

[0003] In view of this, the present application provides a method, system, computing device and computer-readable storage medium for dynamically maintaining Tokens to address the technical defects existing in the prior art.

[0004] According to a first aspect of an embodiment of the present application, a method for dynamically maintaining a token is provided, comprising:

[0005] The server responds to the client's login request and generates a first token for the currently logged-in user after verifying the login request.

[0006] Before returning the first Token to the client, storing relevant information of the first Token in a first database;

[0007] Intercept all requests from the client, parse the second token in the request header, search in the first database, and if there is a matching second token, continue to execute subsequent business processes, otherwise return failure.

[0008] According to a second aspect of an embodiment of the present application, a system for dynamically maintaining a token is provided, including:

[0009] A server, a first database, and a gateway;

[0010] The server responds to the login request of the client and generates a first token of the currently logged-in user after verifying the login request;

[0011] After the server stores the relevant information of the first token in the first database, it returns the first token to the client;

[0012] The gateway intercepts all requests from the client and parses the second Token in the request header;

[0013] Search the first database. If a matching second Token exists, continue to execute the subsequent business process. Otherwise, return failure.

[0014] According to a third aspect of an embodiment of the present application, a computing device is provided, comprising a memory, a processor, and computer instructions stored in the memory and executable on the processor, wherein the processor implements the steps of the method for dynamically maintaining a token when executing the instructions.

[0015] According to a fourth aspect of an embodiment of the present application, a computer-readable storage medium is provided, which stores computer instructions, and the instructions are executed by a processor to perform the steps of the method for dynamically maintaining a token.

[0016] In an embodiment of the present application, after the server generates a login token, before returning it to the client, it stores it in the first database and establishes an index mapping table for the token's unique identifier, binds the originally stateless JWT to the user's identity, and implements "pseudo-state" management of the token by intercepting client requests. When there is a risk of token leakage, the corresponding record in the first database can be directly deleted or the interface can be called to force it to expire. Furthermore, all active tokens of the user are stored with the username as the key to form a global view of the logged-in user. Through the dynamic maintenance strategy, automatic cleanup functions (such as TTL), manual revocation and custom capacity control strategies are integrated to support dynamic adjustment of the upper limit of the number of tokens and validity period rules for a single user, forming flexible management of concurrent logins on multiple devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 is a structural block diagram of a computing device provided in an embodiment of the present application;

[0018] Figure 2 This is a flowchart of a method for dynamically maintaining a token provided in an embodiment of the present application. DETAILED DESCRIPTION

[0019] The following description sets forth many specific details to facilitate a thorough understanding of the present application. However, the present application can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the scope of the present application. Therefore, the present application is not limited to the specific implementations disclosed below.

[0020] The terms used in one or more embodiments of the present application are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of the present application. The singular forms "a", "the" and "the" used in one or more embodiments of the present application and the appended claims are also intended to include plural forms, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in one or more embodiments of the present application refers to and includes any or all possible combinations of one or more associated listed items.

[0021] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of the present application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of one or more embodiments of the present application, first may also be referred to as second, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "in response to determining."

[0022] In this application, a method, system, computing device, and computer-readable storage medium for dynamically maintaining tokens are provided, which are described in detail one by one in the following embodiments.

[0023] Figure 1 1 shows a block diagram of a computing device 100 according to an embodiment of the present application. Components of the computing device 100 include, but are not limited to, a memory 110 and a processor 120. The processor 120 is connected to the memory 110 via a bus 130, and a database 150 is used to store data.

[0024] The computing device 100 also includes an access device 140 that enables the computing device 100 to communicate via one or more networks 160. Examples of these networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 140 may include one or more of any type of network interface (e.g., a network interface card (NIC)), whether wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, a near field communication (NFC) interface, and the like.

[0025] In one embodiment of the present application, the above components of the computing device 100 and Figure 1 Other components not shown in the figure may also be connected to each other, for example, via a bus. Figure 1The computing device structure block diagram shown is for illustrative purposes only and is not intended to limit the scope of the present application. Those skilled in the art may add or replace other components as needed.

[0026] The computing device 100 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook computer, etc.), a mobile phone (e.g., a smartphone), a wearable computing device (e.g., a smartwatch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or PC. The computing device 100 may also be a mobile or stationary server.

[0027] JWT (JSON Web Token) is a compact and self-contained way to securely transmit information between parties. It's an open standard (RFC 7519) that defines a compact and self-contained way to transmit information between parties as JSON objects. This information can be verified and trusted due to its digital signature.

[0028] For example, consider a web application where users can log in and access resources. When a user attempts to log in, they enter their username and password. The server checks the user's username and password. If they are correct, the server creates a JWT containing the user's information and some claims.

[0029] For example, the created JWT contains the following information:

[0030] Header:

[0031]

[0032] Payload:

[0033]

[0034] The server uses the key to sign the header and payload to generate a complete JWT, for example:

[0035] eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVC...

[0036] The server returns this JWT to the user's browser, which typically stores it locally or as a cookie. The next time the user attempts to access a protected resource, they include this JWT in the request header. The server extracts the JWT from the request header and verifies the signature and payload. If verification is successful and the request has not expired, the server allows access to the requested resource.

[0037] The advantage of this method is that the user does not need to re-provide the username and password at each request. However, once the traditional JWT is issued, the server cannot actively invalidate it. If the Token is leaked, the attacker can use the long-term Token to continuously access the system illegally. Moreover, the Token is stored by the client in a decentralized manner, and the server cannot master the whole picture of the user login session, making it difficult to manage multi-device login.

[0038] Therefore, in order to solve the above problems, a method and system for dynamically maintaining Token, a computing device and a computer readable storage medium are provided in the embodiments of the present application, which are described in detail one by one in the following embodiments. The processor 120 in the processor 120 Figure 1 The processor 120 in the processor 120 Figure 2 The method for dynamically maintaining Token shown in the method comprises the following steps:

[0039] Step 202: The server generates a first Token for the current user in response to the login request of the client after the login request is verified.

[0040] In this step, when the server receives the login request of the client, the username, password and / or other parameters of the login request are verified. After verification, the server generates a first Token for the user.

[0041] In the specification of JWT, jti (JWT ID) is an optional standard declaration, which aims to uniquely identify a Token. This means that if jti is used when creating a JWT, each Token should have a unique jti value. Therefore, in the embodiments of the present application, a different UUID or other type of unique identifier is created as the jti for each Token when generating the Token, so as to facilitate individual management and tracking of each Token.

[0042] In a feasible implementation, the server determines whether the user is a user in the frequent login list. If so, the server directly returns the Token generated in advance for the user. In this way, for special users who need a large number of login requests at the same time, in order to avoid service paralysis caused by too frequent requests, the server will generate Tokens for these users in advance. These users will directly return the Tokens generated in advance when requesting login.

[0043] Step 204: Before returning the first Token to the client, store the related information of the first Token in the first database.

[0044] In this step, after the server generates the login Token (first Token) of the current user, it stores the first Token in the first database before returning it to the client.

[0045] In a feasible implementation, the first database is an in-memory key-value database, such as redis.

[0046] Furthermore, the information of the first token is stored in a hash table of the in-memory key-value database. In a feasible implementation, the hash table of Redis is a set of key-value pairs. The outer layer uses the key to identify the entire set, and the inner layer uses the field-value to store specific data. For example:

[0047] Key:user:1001

[0048] Field-Value:{name:"Zhang San",age:28,city:"Beijing"}

[0049] In this embodiment of the present application, "prefix + user name" is used as the key of the hash table, where the prefix is ​​used to distinguish different functions in redis:

[0050] Key:TokenPrefix:John

[0051] Furthermore, in the hash table, jti is used as the field field, and the string containing the first token is stored in the value value. Preferably, the expiration time of the token can also be stored in the value value. And the automatic expiration policy of the Redis key is set according to the expiration time of the token:

[0052] field|value

[0053] jti1|{"Token":"eyJhbGciOiJIUzI1NiIs...","expiresAt":1616242622}

[0054] In a feasible implementation, the Token expiration time in the hash table is periodically traversed, and when the current time is greater than or equal to the expiration time, the corresponding Token is invalidated or removed from the first database.

[0055] In another feasible implementation, when the set of tokens of the same user in the first database exceeds a limit, the token with the earliest expiration time is removed from the first database to prevent the accumulation of invalid credentials.

[0056] Furthermore, the generated first Token is returned to the client.

[0057] Step 206: intercept all requests from the client, parse and obtain the second token in the request header; search in the first database, if there is a matching second token, continue to execute the subsequent business process, otherwise return failure.

[0058] In this step, all client requests are intercepted at the gateway layer, and the second token in the client request header is parsed. Furthermore, in addition to verifying the signature validity and expiration time of the second token, the following operations are performed:

[0059] Extract the user name and the unique identifier of the second Token from the second Token.

[0060] Using the extracted username, construct a key, such as TokenPrefix:username, to locate the user's Token record in the first database.

[0061] Specifically, the first database queries the corresponding hash table based on the constructed key, retrieves the unique identifier in the record, and confirms whether the second token exists. If the query returns a result indicating that the hash table contains a unique identifier that matches the second token, the second token is valid and has not been illegally used. The gateway will allow the request to pass and proceed to the subsequent business logic layer. Conversely, if there is no relevant record, the second token is illegal or has been recycled. The gateway will immediately return an exception message to inform the client that the request was rejected. This mechanism protects the system from abnormal token operations.

[0062] In another feasible implementation, when it is detected that the second Token has been leaked, the corresponding Token record in the first database is directly deleted, or an interface is called to force its expiration.

[0063] In the embodiments of the present application, in order to solve the various problems in the prior art caused by the stateless nature of JWT, whose validity depends on client storage and the expiration time field of the Token itself, and the lack of unified and effective management, an index mapping table of the unique identifier of the Token is established through the first database, and the originally stateless JWT is bound to the state record in the first database, and the "pseudo-state" management of the Token is realized by intercepting the client request; when there is a risk of Token leakage, the corresponding record in the first database can be directly deleted or the interface can be called to force it to expire. Furthermore, all active Tokens of the user are stored with the username as the key to form a global view of the logged-in user, and the dynamic maintenance strategy integrates automatic cleanup functions (such as TTL), manual revocation and custom capacity control strategies, supports dynamic adjustment of the upper limit of the number of Tokens and validity period rules for a single user, and forms flexible management of concurrent logins of multiple devices.

[0064] Corresponding to the method embodiments described above, the present application also provides an embodiment of a system for dynamically maintaining Token, which comprises:

[0065] a server, a first database, and a gateway;

[0066] the server generates a first Token of a current login user in response to a login request of a client, and generates the first Token after the login request is verified;

[0067] the server stores the related information of the first Token into the first database, and returns the first Token to the client;

[0068] the gateway intercepts all requests from the client, and parses a second Token in a request header;

[0069] the first database is searched, and if the second Token matches, subsequent business processes are continued, otherwise, a failure is returned.

[0070] The above is a schematic scheme of the system for dynamically maintaining Token. It should be noted that the technical scheme of the system for dynamically maintaining Token and the technical scheme of the method for dynamically maintaining Token belong to the same concept, and the details of the technical scheme of the system for dynamically maintaining Token which are not described in detail can be seen from the description of the technical scheme of the method for dynamically maintaining Token.

[0071] In an embodiment of the present application, a computing device is also provided, which comprises a memory, a processor, and computer instructions stored in the memory and executable on the processor, and the processor executes the instructions to implement the steps of the method for dynamically maintaining Token.

[0072] In an embodiment of the present application, a computer readable storage medium is also provided, which stores computer instructions, and the instructions are executed by a processor to implement the steps of the method for dynamically maintaining Token.

[0073] The above is a schematic scheme of the computer readable storage medium. It should be noted that the technical scheme of the storage medium and the technical scheme of the method for dynamically maintaining Token belong to the same concept, and the details of the technical scheme of the storage medium which are not described in detail can be seen from the description of the technical scheme of the method for dynamically maintaining Token.

[0074] The above-described embodiments of the application have several aspects, no single one of which is solely responsible for the application's desirable attributes. Without limiting the scope of the application as expressed by the claims which follow, some further embodiments make these aspects even more useful. Other embodiments can result in less desirable attributes.

[0075] The computer readable medium can include any entity or apparatus capable of carrying the computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, software distribution medium, etc. It should be noted that the computer readable medium can include appropriate contents according to the requirements of legislation and patent practice in the jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, the computer readable medium does not include electrical carrier signals and telecommunication signals.

[0076] It should be noted that for the foregoing method embodiments, the acts described therein can be performed in a different order from the order described, and that some acts can be performed in parallel or concurrently. In addition, those skilled in the art will appreciate that the embodiments described herein are merely exemplary and that various modifications can be made without departing from the spirit and scope of the application. Accordingly, the description is not intended to limit the application to the particular forms described. Rather, it is intended to cover all modifications, equivalents, and alternatives falling within the scope of the application.

[0077] In the above embodiments, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the relevant description of other embodiments.

[0078] The preferred embodiments of the application disclosed above are only used to help explain the application. The alternative embodiments do not describe all the details and do not limit the application to the specific embodiments described. Obviously, according to the content of the application, many modifications and changes can be made. The application selects and describes these embodiments in order to better explain the principles and practical applications of the application, so that those skilled in the art can well understand and utilize the application. The application is limited by the claims and their full scope and equivalents.

Claims

1. A method for dynamically maintaining a token, characterized in that: include: The server responds to the client's login request and generates a first token for the currently logged-in user after verifying the login request. Before returning the first Token to the client, storing relevant information of the first Token in a first database; Intercept all requests from the client, parse the second token in the request header, search in the first database, and if there is a matching second token, continue to execute subsequent business processes, otherwise return failure.

2. The method according to claim 1, wherein Generating a first token of the currently logged-in user after verifying the login request includes: When generating the first Token, a unique identifier is created for each of the first Tokens.

3. The method according to claim 2, wherein Storing the relevant information of the first token in the first database includes: The relevant information of the first token is stored in a hash table of an in-memory key-value database; wherein "prefix + user name" is used as the key of the hash table, the unique identifier is used as a field in the hash table, and the string of the first token is used as the value of the field.

4. According to the method of claim 3, storing the relevant information of the first token in the first database further comprises: The field value of the hash table also stores the expiration time of the first Token; And set the automatic expiration policy of the key of the current hash table according to the expiration time.

5. The method according to claim 4, wherein The method further includes: when the set of tokens of the same user in the first database exceeds a limit, removing the first token with the earliest expiration time from the first database.

6. The method according to claim 1, wherein The parsing to obtain the second token in the request header and searching the first database include: Extracting a second username and a unique identifier from the second Token; A key of a hash table is constructed according to the second user name, and a corresponding hash table is queried in the first database according to the constructed key to determine whether there is a matching unique identifier.

7. The method according to claim 1, wherein The method further includes: when it is detected that the second Token has been leaked, directly deleting the corresponding Token record in the first database or calling an interface to force it to expire.

8. The method according to claim 1, wherein Generating a first token of the currently logged-in user after verifying the login request includes: Determine whether the user is on the frequent login list. If so, directly return the token pre-generated for the user.

9. A system for dynamically maintaining tokens, characterized in that: The system includes: A server, a first database, and a gateway; The server responds to the login request of the client and generates a first token of the currently logged-in user after verifying the login request; After the server stores the relevant information of the first token in the first database, it returns the first token to the client; The gateway intercepts all requests from the client and parses the second Token in the request header; Search the first database. If there is a matching second Token, continue to execute the subsequent business process; otherwise, return failure.

10. A computing device comprising a memory, a processor, and computer instructions stored in the memory and executable on the processor, wherein: When the processor executes the instructions, the steps of the method according to any one of claims 1 to 8 are implemented.

11. A computer-readable storage medium storing computer instructions, characterized in that: When the instruction is executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

Images