Single-point authentication method and user center end

Abstract

The invention discloses a single-point authentication method and a user center terminal. The method comprises the following login authentication processes: receiving a user name input by a user through a user terminal; the user side is used for receiving an API service access request of a user to the first system and sending the API service access request to the first system side; the first system end is used for identifying that the user does not log in currently when detecting that the access request does not have the Token, and sending a login display request to the user end; calling a Bloom filter to check whether the user name exists or not; if not, determining that the user is not registered, and returning a login failure message to the first system end; the first system end is also used for returning the access request as an invalid request to the user end; a plurality of registered user names are pre-stored in the Bloom filter, and each registered user name is stored in the form of a binary bit vector array. According to the method, the single-point authentication process can be optimized, the consumption of memory resources and the cache breakdown risk generated by a user request are reduced, and the service stability is improved.

Description

Technical Field

[0001] This invention relates to the field of user authentication technology, and in particular to a single sign-on method and a user center terminal. Background Technology

[0002] This section is intended to provide background or context for the embodiments of the invention set forth in the claims. The description herein is not an admission that it is prior art simply because it is included in this section.

[0003] SSO, or Single Sign-On Authentication, is a technology that allows users to access services directly in a multi-system environment without needing to log in again when switching to other systems after logging into one system. In other words, SSO technology was developed to solve the problem of repeated login authentication in distributed systems, aiming to simplify user operations and improve system efficiency and user experience.

[0004] SSO (Single Sign-On) is mainly divided into two stages: users perform login authentication in one system, and users can access other systems directly without logging in. The two stages can be summarized as: ① login authentication, ② token authentication, to achieve direct access to services without logging in.

[0005] In existing technologies, the timing diagram of the login authentication mechanism is as follows: Figure 1 As shown, it mainly includes the following stages:

[0006] ① When a user requests the API service of system A (the first system), system A finds that there is no token in the header message of the user's request, recognizes that the user is not currently logged in, and guides the user to the login page to log in.

[0007] ② The user enters their username and password on the login page and requests to log in. The user center first verifies whether the username exists (firstly matching the user from the cache; if the data is not found in the cache, then searching for the user information in the database). If the authentication of the username existence, password correctness, etc., passes in sequence, the user center will generate and save a token for the user to access API services without logging in later.

[0008] ③ After a user successfully logs in, the returned token is encapsulated in the request header, and the user continues to access the API service of System A. System A verifies the validity of the token, executes the API's business processing, and returns response data to the user.

[0009] The technical problem with the above login authentication mechanism is:

[0010] ① High memory usage: To reduce database pressure, the user center will first check if the username exists in the cache, which will consume a certain amount of cache CPU resources, especially during peak business periods when cache resources are consumed in large quantities.

[0011] ② There is a risk of cache breakdown: If a user submits a login request with an invalid username during high concurrency, the user center will not be able to match the valid user information in the cache server, and will directly access the database to look it up, causing a significant loss of database performance. Summary of the Invention

[0012] This invention provides a single sign-on method applied to a user center to optimize the single sign-on process, reduce memory resource consumption and the risk of cache breakdown caused by user requests, and improve service stability. The method includes the following login authentication process:

[0013] The system receives a login request entered by a user through the user-end login page, the login request including the username; the user-end is used to receive the user's API service access request to the first system, send the access request to the first system, and display the login page when a login display request is received; the first system is used to identify that the user is not currently logged in when it detects that there is no token in the message header of the access request, and send a login display request to the user-end.

[0014] The system calls a Bloom filter to verify if the username exists. If the Bloom filter finds that the username does not exist, it determines that the user is an unregistered user and returns a login failure message to the first system. The first system also returns the user's API service access request to the first system as an invalid request to the user. The Bloom filter pre-stores multiple registered usernames, and each registered username is stored in the form of a binary bit vector array.

[0015] This invention also provides a single sign-on user center terminal to optimize the single sign-on process, reduce memory resource consumption and the risk of cache breakdown caused by user requests, and improve service stability. The user center terminal includes the following units for completing the login authentication process:

[0016] The receiving unit is used to receive a login request entered by a user through the user terminal login page, the login request including the username; the user terminal is used to receive the user's API service access request to the first system, send the access request to the first system terminal, and display the login page when a login display request is received; the first system terminal is used to identify that the user is not currently logged in when it detects that there is no token in the message header of the access request, and send a login display request to the user terminal.

[0017] The first calling unit is used to call the Bloom filter to verify whether the username exists; if the Bloom filter verifies that the username does not exist, it determines that the user is an unregistered user and returns a login failure message to the first system terminal; the first system terminal is also used to return the user's API service access request to the first system as an invalid request to the user terminal; wherein: the Bloom filter pre-stores multiple registered usernames, and each registered username is stored in the form of a binary bit vector array.

[0018] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the single sign-on method described above.

[0019] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the single sign-on method described above.

[0020] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the single sign-on method described above.

[0021] The single sign-on scheme provided in this invention operates as follows: It receives a login request entered by a user through a user-end login page, the login request including a username; the user-end receives a user's API service access request to a first system, sends the access request to the first system, and displays the login page upon receiving a login display request; the first system, upon detecting the absence of a token in the header of the access request, identifies that the user is not currently logged in and sends a login display request to the user-end; it calls a Bloom filter to verify the existence of the username; if the Bloom filter verifies that the username does not exist, it determines that the user is an unregistered user and returns a login failure message to the first system; the first system also returns the user's API service access request to the first system as an invalid request to the user-end; wherein: the Bloom filter pre-stores multiple registered usernames, each registered username being stored in the form of a binary bit vector array.

[0022] The beneficial technical effects of the single sign-on scheme provided in this invention are as follows: It utilizes the Bloom filter's ability to quickly determine the existence of elements, capture invalid requests, and quickly return these invalid requests to the user, reducing the impact on backend user center resources and database resources; it leverages the high space efficiency of the Bloom filter to reduce the consumption of memory resources on the user center server, reduce the risk of cache breakdown caused by user requests, and improve service stability; furthermore, it utilizes the high query efficiency of the Bloom filter to improve the response efficiency and performance of the backend user center API. Attached Figure Description

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

[0024] Figure 1 This is a timing diagram illustrating the principle of the login authentication mechanism in existing technologies;

[0025] Figure 2 This is a schematic diagram of the login authentication process in the single sign-on method of this invention.

[0026] Figure 3 This is a timing diagram illustrating the login authentication mechanism in an embodiment of the present invention.

[0027] Figure 4 This is a timing diagram illustrating the principle of the token authentication mechanism in existing technologies;

[0028] Figure 5 This is a timing diagram illustrating the principle of the Token authentication mechanism in this embodiment of the invention;

[0029] Figure 6 This is a schematic diagram of the business process for preparing data for a Bloom filter in an embodiment of the present invention;

[0030] Figure 7 This is a schematic diagram illustrating the mechanism of data verification using a Bloom filter in an embodiment of the present invention.

[0031] Figure 8 This is a schematic diagram of the structure of the single-point authentication user center in an embodiment of the present invention. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0033] The acquisition, storage, use, and processing of data in this application comply with relevant laws and regulations.

[0034] The existing single sign-on schemes have the following technical problems that urgently need to be solved.

[0035] 1. How to optimize the verification mechanism of login authentication and token authentication to reduce the consumption of cache resources.

[0036] 2. How to reduce the risk of cache breakdown caused by user requests and improve service stability.

[0037] To address the aforementioned technical challenges, the inventors propose a single sign-on (SSO) scheme based on a Bloom filter. A Bloom filter is a highly efficient data structure with advantages such as high space efficiency, high query efficiency, and the ability to quickly determine the existence of elements. The SSO solution proposed in this invention involves: utilizing the Bloom filter's ability to quickly determine element existence to capture invalid requests and quickly return responses to these requests, reducing the impact on backend and database resources; leveraging the Bloom filter's high space efficiency to reduce server memory consumption; and utilizing the Bloom filter's high query efficiency to improve the response efficiency and performance of the backend API. The following provides a detailed description of this SSO scheme.

[0038] Figure 2 This is a schematic diagram of the login authentication process in the single sign-on method of this invention. This authentication method is applied to the user center (e.g., Figure 3 The user center's backend, server, or server (e.g., the backend, server, or server in the system). Figure 2 As shown, the method includes the following login authentication process steps:

[0039] Step 101: Receive a login request entered by the user through the user terminal login page. The login request includes the username. The user terminal is used to receive the user's API service access request to the first system and send the access request to the first system. When a login display request is received, the login page is displayed. The first system is used to identify that the user is not currently logged in when it detects that there is no Token in the message header of the access request. The first system then sends a login display request to the user terminal.

[0040] Step 102: Call the Bloom filter to verify whether the username exists; if the Bloom filter verifies that the username does not exist, determine that the user is an unregistered user, and return a login failure message to the first system terminal; the first system terminal is also used to return the user's API service access request to the first system as an invalid request to the user terminal; wherein: the Bloom filter pre-stores multiple registered usernames, and each registered username is stored in the form of a binary bit vector array.

[0041] The login authentication process in the single sign-on method provided in this embodiment of the invention, during operation, involves: receiving a login request entered by a user through a user-side login page, the login request including the username; the user-side (e.g., ...) Figure 1 , Figures 3-5 The client used by the user in the middle) is used to receive user input from the first system (such as... Figure 1 , Figure 3The API service access request of system A) is sent to the first system end (which may be the server corresponding to the first system). Upon receiving the login display request, the login page is displayed. The first system end is used to identify that the user is not currently logged in when it detects that there is no token in the message header of the access request, and sends a login display request to the user end. It calls a Bloom filter to verify whether the username exists. If the Bloom filter verifies that the username does not exist, it determines that the user is an unregistered user and returns a login failure message to the first system end. The first system end is also used to return the user's API service access request to the first system as an invalid request to the user end. Wherein: the Bloom filter pre-stores multiple registered usernames, and each registered username is stored in the form of a binary bit vector array.

[0042] The beneficial technical effects of the single sign-on method provided in this invention are as follows: It utilizes the Bloom filter's ability to quickly determine the existence of elements, capture invalid requests, and quickly return these invalid requests to the user, reducing the impact on backend user center resources and database resources; it leverages the high space efficiency of the Bloom filter to reduce the consumption of memory resources on the user center server, reduce the risk of cache breakdown caused by user requests, and improve service stability; furthermore, it utilizes the high query efficiency of the Bloom filter to improve the response efficiency and performance of the backend user center API. The login authentication process in this single sign-on method will be described in detail below.

[0043] The user center mentioned in this embodiment of the invention can be Figure 1 , Figures 3-5 The backend, server, and client of the user center can be... Figure 1 , Figures 3-5 The client used by Chinese users. The first system can be... Figure 1 , Figure 3 In system A, the first system end can be the server or service terminal corresponding to the first system. The second system can be... Figure 4 , Figure 5 In System B, the second system end can be the server or service terminal corresponding to the second system.

[0044] The timing diagram of the login authentication mechanism in this embodiment of the invention is shown above. Figure 3 As shown, it mainly includes the following stages:

[0045] ① When a user requests the API service of system A, system A finds that there is no token in the header message of the user's request, recognizes that the user is not currently logged in, and guides the user to the login page to log in.

[0046] ② The user enters their username and password on the login page and requests to log in. The user center calls a Bloom filter to check if the username exists in real time: if the username does not exist, the user is not registered and login fails; if the username exists, the user information is queried using the username as the condition (firstly, the user is matched in the cache; if the data is not found in the cache, the user information is then searched in the database). This process double-checks the existence of the user information to eliminate the risk of misjudgment by the Bloom filter.

[0047] ③ Verify that the user's password is correct. After the password authentication is successful, the user center will generate and save a token for the user to access API services without logging in later.

[0048] ④ After a user successfully logs in, the returned token is encapsulated in the request header, and the user continues to access the API service of System A. System A verifies the validity of the token, executes the API's business processing, and returns response data to the user.

[0049] As can be seen from the above, in one embodiment, the login request also includes a user password, and the login authentication process may further include:

[0050] If the Bloom filter verifies that the username exists, it first matches user information from the cache based on the username. If the data is not found in the cache, it searches for user information in the database.

[0051] If user information is found in the database, the user's password is verified to be correct. If the user password authentication is successful, the user logs in successfully, a token is generated and saved for subsequent API service access without login. The generated token is sent to the user's client. The user's client is also used to encapsulate the returned token into the message header of the access request after the user logs in successfully, and continue to initiate an API service access request to the first system client. The first system client is also used to execute the API business processing when the authentication token is passed, and return response data to the user's client.

[0052] In practical implementation, the embodiments of the present invention can effectively prevent cache breakdown and reduce database pressure: Bloom filter storage can efficiently intercept non-existent invalid data, avoiding the need to continue searching the database when invalid data cannot be found in the cache, thus effectively reducing the risk of cache breakdown from the root.

[0053] As can be seen from the above, in one embodiment, the login authentication process may further include: if user information is found in the database, verifying whether the user information exists, in order to eliminate the risk of misjudgment by the Bloom filter, further reducing the risk of cache breakdown and improving system stability.

[0054] In existing technologies, the timing diagram of the token authentication mechanism is as follows: Figure 4 As shown, it mainly includes the following stages:

[0055] ① When a user requests access to the API service of system B (the second system) across systems, system B extracts and verifies the token from the request header. It finds that the token does not exist in the cache and determines that the user is the initial user.

[0056] ② System B forwards the token to the user center, requesting verification of the token's validity. If the user center successfully authenticates the token, System B records the token and saves it to its cache.

[0057] ③ After System B's authentication token is approved, it continues to request user information (userInfo) from the user center. The user center finds the bound userId through the token, then finds the user information through the userId, and returns it to System B. System B saves the userInfo to the cache for later use.

[0058] ④ At this point, the token authentication process is complete. System B executes its business logic and returns the response data to the user. The user successfully gains seamless access to System B's API services without needing to log in.

[0059] The technical problem with the existing token authentication mechanism is:

[0060] ① High memory usage: To reduce database pressure, when the user center and system B verify the validity of the token and query userInfo (user identifier), they will prioritize execution in the cache. This will consume a certain amount of cache CPU resources, especially during peak business periods when cache resource consumption is relatively high.

[0061] ② There is a risk of cache breakdown: If a user requests to query user information with an invalid userId, the user center will not be able to match the valid user information in the cache server, and will directly access the database to search, causing a large loss of database performance.

[0062] In view of the technical problems existing in the above-mentioned existing token authentication mechanisms, the embodiments of the present invention also propose the following token authentication process.

[0063] The timing diagram of the token authentication mechanism in this embodiment of the invention is as follows: Figure 5 As shown, it mainly includes the following stages:

[0064] ① When a user requests access to the API service of system B from a cross-system request, system B extracts and verifies the token from the request header. If the token is not found in the cache, system B determines that the user is the initial user.

[0065] ② System B forwards the token to the user center, requesting verification of the token's validity. The user center calls a Bloom filter to check if the token exists: if the token does not exist, the user is not logged in; if the token exists, the user is considered logged in. If the token exists, System B records the token and saves it to its cache.

[0066] ③ After the system B authentication token is approved, it continues to request the user information userInfo from the user center. The user center finds the bound userId through the token.

[0067] ④ The user center calls the Bloom filter to check if userId exists: if userId does not exist, the user is not a registered user, and an empty string is returned; if userId exists, the user information is retrieved using userId. The user information userInfo is returned to system B, and system B caches the userInfo information for later use.

[0068] ⑤ At this point, the token authentication process is complete. System B executes its business logic and returns the response data to the user. The user successfully gains seamless access to System B's API services without needing to log in.

[0069] As can be seen from the above, in one embodiment, the single sign authentication method provided by the present invention further includes the following token authentication process:

[0070] The client obtains a token sent from the second system; the client is also used to receive user requests for cross-system API service access to the second system, and to access the second system (such as...) Figure 4 and Figure 5 The API service access request of system B) is sent to the second system end (which can be the server corresponding to the second system); the second system end is used to extract and verify the Token from the message header of the API service access request to the second system. If the Token does not exist in the second system end, the user is determined to be the initial access user, and the Token is forwarded to the user center end to request verification of the Token existence.

[0071] The Bloom filter is invoked to verify the existence of the token. If the Bloom filter finds that the token does not exist, it is determined that the user is not logged in. The Bloom filter pre-stores multiple registration tokens, and each registration token is stored in the form of a binary bit vector array.

[0072] In practical implementation, this embodiment of the invention calls a Bloom filter to verify the existence of the token, quickly returns a response to unlogged-in users, reduces memory resource consumption, reduces the risk of cache breakdown caused by user requests, and further improves service stability.

[0073] As can be seen from the above, in one embodiment, the Token authentication process may further include:

[0074] If the Bloom filter verifies that the token exists, it is considered that the user has logged in, and the authentication token is returned to the second system. The second system is also used to cache the token when it is verified to exist, and when the authentication token is received, it continues to send a query request for user information to the user center based on the token.

[0075] Upon receiving a request to query user information, the system finds the bound user identifier through the token; it then calls a Bloom filter to verify whether the user identifier exists. If the user identifier does not exist, it determines that the user is not a registered user and directly returns an empty string to the second system. The Bloom filter pre-stores multiple registered user identifiers, each of which is stored in the form of a binary bit vector array.

[0076] In specific implementation, when the user is confirmed to be logged in by calling the Bloom filter to verify the Token, the Bloom filter is called to verify whether the user identifier exists. If the user identifier does not exist, it is determined that the user is not a registered user, and an empty string is returned directly to the second system. This reduces the consumption of memory resources, reduces the risk of cache breakdown caused by user requests, and further improves the stability of the service.

[0077] As can be seen from the above, in one embodiment, the Token authentication process may further include:

[0078] If the Bloom filter verifies that the user information exists, the user information is found through the user identifier and returned as a query result to the second system. The second system is also used to cache the user information for later use. The token authentication process is then completed, business processing is performed, and response data is returned to the user, so as to enable the user to successfully access the API service of the second system without logging in.

[0079] In specific implementation, when the user is confirmed to be logged in by calling the Bloom filter to verify the Token, the Bloom filter is called to verify whether the user identifier exists. If the Bloom filter verifies that the user information exists, the user information is found through the user identifier and returned as a query result to the second system. This allows the second system to cache the user information for later use. The Token authentication process is then completed, business processing is performed, and response data is returned to the user, enabling the user to successfully access the API service of the second system without logging in.

[0080] The following describes the data preparation steps in the single sign-on method provided in this embodiment of the invention.

[0081] The prerequisite for using Bloom filters for data validation is that data preparation is completed, such as... Figure 6 As shown, the business process for preparing data for a Bloom filter is as follows:

[0082] Taking storing username as an example:

[0083] ① Call the Bloom filter to store the user's username.

[0084] ② The Bloom filter calls the Hash function to generate a series of random mapping arrays for username.

[0085] ③ The Bloom filter modifies the Bit vector array by using the elements in the random mapping array as indices, changing the elements of the vector array to 1.

[0086] ④ The modification of the Bit vector array is complete, and the Bloom filter has finished saving the username value.

[0087] The advantages of the above-described business process for preparing data for Bloom filters are:

[0088] ① High space efficiency: Bit vector arrays are binary, and binary data storage occupies very little space, which saves more storage space compared to other data structures.

[0089] ② High scalability: Binary vectors are very flexible in adding or reducing data.

[0090] As can be seen from the above, in one embodiment, the single-point authentication method provided by the present invention may further include: a Bloom filter pre-storing each registered username according to the following method:

[0091] Call the Hash function to generate a series of random mapping arrays for the registered usernames;

[0092] Using the elements in the random mapping array as indices, the preset bit vector array is modified, changing each element of the vector array to 1. This process continues until the modification of the bit vector array is complete, at which point the Bloom filter has finished saving the registered username value.

[0093] In specific implementation, this embodiment of the invention demonstrates high space efficiency when using a Bloom filter to pre-store each registered username: the bit vector array is binary, and binary data storage occupies very little space, saving storage space compared to other data structures. Furthermore, this embodiment of the invention offers high scalability: the binary vector is very flexible in adding or reducing data.

[0094] As can be seen from the above, in one embodiment, the single sign authentication method provided by the present invention may further include: a Bloom filter pre-storing each registered token according to the following method:

[0095] Call the Hash function to generate a series of random mapping arrays for the registered token;

[0096] Using the elements in the random mapping array as indices, the preset bit vector array is modified, changing each element of the vector array to 1. This process continues until the bit vector array is completely modified, at which point the Bloom filter has finished saving the registered token value.

[0097] In specific implementation, this embodiment of the invention utilizes a Bloom filter to pre-store each registered token, resulting in high space efficiency: the bit vector array is binary, and binary data storage occupies very little space, saving storage space compared to other data structures. Furthermore, this embodiment of the invention offers high scalability: the binary vector is very flexible in adding or reducing data.

[0098] As can be seen from the above, in one embodiment, the single-point authentication method provided by the present invention may further include: a Bloom filter pre-storing the identifier of each registered user according to the following method:

[0099] Call the Hash function to generate a series of random mapping arrays for registered user identifiers;

[0100] Using the elements in the random mapping array as indices, the preset bit vector array is modified, changing each element of the vector array to 1. This process continues until the modification of the bit vector array is complete, at which point the Bloom filter has finished saving the registered user identifier value.

[0101] In specific implementation, this embodiment of the invention demonstrates high space efficiency when using a Bloom filter to pre-store the identifier of each registered user: the bit vector array is binary, and binary data storage occupies very little space, saving storage space compared to other data structures. Furthermore, this embodiment of the invention offers high scalability: the binary vector is very flexible in adding or reducing data.

[0102] The following describes the steps of the Bloom filter mechanism principle in the single-point authentication method provided by the embodiments of the present invention. For example... Figure 7 As shown, the mechanism by which Bloom filters perform data validation is as follows:

[0103] Taking storing username as an example:

[0104] ① Call the Bloom filter to check if username exists, with the input parameter being: username.

[0105] ② The Bloom filter calls the Hash function to generate a series of random mapping arrays for username.

[0106] ③ The Bloom filter uses the elements in the random mapping array as indices to search for elements in the Bit vector array.

[0107] ④ Perform a union operation on the elements found in the Bit vector array. If the value is 1, then username exists; otherwise, username does not exist.

[0108] The advantages of the Bloom filter's data validation mechanism are:

[0109] Fast lookup speed: The Bloom filter uses the results of multiple hash functions to directly correspond to the positions in the bit array, so the lookup speed is extremely fast.

[0110] As can be seen from the above, in one embodiment, the single-point authentication method provided by the present invention, calling a Bloom filter to verify the existence of the username, may include:

[0111] A Bloom filter retrieves the current username;

[0112] The Bloom filter calls a hash function to generate a series of random mapping arrays for the current username;

[0113] The Bloom filter uses elements in the random mapping array as indices to search for elements in a preset bit vector array;

[0114] The elements found in the bit vector array are joined together. If the value is 1, the current username exists; otherwise, the current username does not exist.

[0115] In specific implementation, in this embodiment of the invention, when calling the Bloom filter to verify whether the username exists, the query performance is high: the result of the Bloom filter using multiple hash functions directly corresponds to the position in the bit array, and then it is sufficient to check whether the value of the element in the vector array is 1. The query performance does not decrease as the number of stored elements increases.

[0116] As can be seen from the above, in one embodiment, the single-point authentication method provided by the present invention, calling a Bloom filter to verify the existence of a token, may include:

[0117] Bloom filter retrieves the current token;

[0118] The Bloom filter calls a hash function to generate a series of random mapping arrays for the current username;

[0119] The Bloom filter uses elements in the random mapping array as indices to search for elements in a preset bit vector array;

[0120] The elements found in the bit vector array are joined together. If the value is 1, the current token exists; otherwise, the current token does not exist.

[0121] In specific implementation, in this embodiment of the invention, when calling the Bloom filter to verify the existence of the Token, the query performance is high: the result of the Bloom filter using multiple hash functions directly corresponds to the position in the bit array, and then it is sufficient to check whether the value of the element in the vector array is 1. The query performance does not decrease as the number of stored elements increases.

[0122] As can be seen from the above, in one embodiment, the single-point authentication method provided by the present invention, calling a Bloom filter to verify the existence of a user identifier, may include:

[0123] A Bloom filter is used to obtain the current user's identifier;

[0124] The Bloom filter calls a hash function to generate a series of random mapping arrays for the current username;

[0125] The Bloom filter uses elements in the random mapping array as indices to search for elements in a preset bit vector array;

[0126] The elements found in the bit vector array are joined together. If the value is 1, the current user ID is determined to exist; otherwise, the current user ID does not exist.

[0127] In specific implementation, in this embodiment of the invention, when calling the Bloom filter to verify whether the user identifier exists, the query performance is high: the result of the Bloom filter using multiple hash functions directly corresponds to the position in the bit array, and then it is sufficient to check whether the value of the element in the vector array is 1. The query performance does not decrease as the number of stored elements increases.

[0128] To facilitate a better understanding of how this invention is implemented, the technical terms are explained in Table 1 below.

[0129] Table 1

[0130]

[0131] In summary, the single sign authentication method provided in the embodiments of the present invention has the following advantages:

[0132] ① It avoids unnecessary resource consumption: The user center first calls the Bloom filter to check if the username exists, excluding requests from unregistered users from impacting backend business, avoiding data queries from the cache server or database, and reducing resource consumption.

[0133] ② Reduced cache breakdown risk: Login requests submitted by unregistered users can be intercepted and processed quickly by the user center using a Bloom filter, reducing the possibility that the user center will directly access the database to look up valid user information if it cannot find it on the cache server (cache breakdown risk).

[0134] ③ Improved API performance: The data set in the Bloom filter comes from the local cache. Querying data from the local cache is much faster than caching services such as Redis and databases such as MySQL.

[0135] This invention also provides a single sign-on user center terminal, as described in the following embodiments. Since the principle behind this user center terminal's problem-solving is similar to that of the single sign-on method, its implementation can refer to the implementation of the single sign-on method; repeated details will not be elaborated further.

[0136] Figure 8 This is a schematic diagram of the structure of the single-point authentication user center in an embodiment of the present invention, as shown below. Figure 8 As shown, the user center includes the following units for completing the login authentication process:

[0137] The receiving unit 01 is used to receive a login request entered by a user through the user terminal login page, the login request including the username; the user terminal is used to receive the user's API service access request to the first system, send the access request to the first system terminal, and display the login page when a login display request is received; the first system terminal is used to identify that the user is not currently logged in when it detects that there is no token in the message header of the access request, and send a login display request to the user terminal.

[0138] The first calling unit 02 is used to call the Bloom filter to verify whether the username exists; if the Bloom filter verifies that the username does not exist, it determines that the user is an unregistered user and returns a login failure message to the first system terminal; the first system terminal is also used to return the user's API service access request to the first system as an invalid request to the user terminal; wherein: the Bloom filter pre-stores multiple registered usernames, and each registered username is stored in the form of a binary bit vector array.

[0139] In one embodiment, the Bloom filter pre-stores each registered username as follows:

[0140] Call the Hash function to generate a series of random mapping arrays for the registered usernames;

[0141] Using the elements in the random mapping array as indices, the preset bit vector array is modified, changing each element of the vector array to 1. This process continues until the modification of the bit vector array is complete, at which point the Bloom filter has finished saving the registered username value.

[0142] In one embodiment, the first calling unit described above, calling a Bloom filter to verify the existence of the username, includes:

[0143] A Bloom filter retrieves the current username;

[0144] The Bloom filter calls a hash function to generate a series of random mapping arrays for the current username;

[0145] The Bloom filter uses elements in the random mapping array as indices to search for elements in a preset bit vector array;

[0146] The elements found in the bit vector array are joined together. If the value is 1, the current username exists; otherwise, the current username does not exist.

[0147] In one embodiment, the login request further includes a user password, and the login authentication process further includes, i.e., the aforementioned first calling unit is used for:

[0148] If the Bloom filter verifies that the username exists, it first matches user information from the cache based on the username. If the data is not found in the cache, it searches for user information in the database.

[0149] If user information is found in the database, the user's password is verified to be correct. If the user password authentication is successful, the user logs in successfully, a token is generated and saved for subsequent API service access without login. The generated token is sent to the user's client. The user's client is also used to encapsulate the returned token into the message header of the access request after the user logs in successfully, and continue to initiate an API service access request to the first system client. The first system client is also used to execute the API business processing when the authentication token is passed, and return response data to the user's client.

[0150] In one embodiment, the login authentication process further includes the first calling unit being used to: if user information is found in the database, verify whether the user information exists in order to rule out the risk of misjudgment by the Bloom filter.

[0151] In one embodiment, the user center terminal may further include the following unit for completing the token authentication process:

[0152] The acquisition unit is used to acquire the Token sent by the second system terminal; the user terminal is also used to receive the user's cross-system API service access request to the second system and send the API service access request to the second system terminal to the second system terminal; the second system terminal is used to extract and verify the Token from the message header of the API service access request to the second system. If the Token does not exist in the second system terminal, the user is determined to be the initial access user, and the Token is forwarded to the user center terminal to request verification of the existence of the Token.

[0153] The second calling unit is used to call the Bloom filter to verify whether the Token exists. If the Bloom filter verifies that the Token does not exist, it is determined that the user has not logged in. The Bloom filter pre-stores multiple registration Tokens, and each registration Token is stored in the form of a binary bit vector array.

[0154] In one embodiment, the token authentication process further includes, i.e., the second calling unit is also used for:

[0155] If the Bloom filter verifies that the token exists, it is considered that the user has logged in, and the authentication token is returned to the second system. The second system is also used to cache the token when it is verified to exist, and when the authentication token is received, it continues to send a query request for user information to the user center based on the token.

[0156] Upon receiving a request to query user information, the system finds the bound user identifier through the token; it then calls a Bloom filter to verify whether the user identifier exists. If the user identifier does not exist, it determines that the user is not a registered user and directly returns an empty string to the second system. The Bloom filter pre-stores multiple registered user identifiers, each of which is stored in the form of a binary bit vector array.

[0157] In one embodiment, the token authentication process further includes, i.e., the second calling unit is also used for:

[0158] If the Bloom filter verifies that the user information exists, the user information is found through the user identifier and returned as a query result to the second system. The second system is also used to cache the user information for later use. The token authentication process is then completed, business processing is performed, and response data is returned to the user, so as to enable the user to successfully access the API service of the second system without logging in.

[0159] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the single sign-on method described above.

[0160] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the single sign-on method described above.

[0161] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the single sign-on method described above.

[0162] In this embodiment of the invention, during the SSO authentication process, a Bloom filter is used to verify the existence of the token, effectively reducing the resource consumption of backend services by invalid requests. During the SSO authentication process, a Bloom filter is also used to verify the existence of the user (whether the user is registered), effectively reducing the resource consumption of backend services by invalid requests.

[0163] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0164] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0165] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0166] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0167] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A single sign-on authentication method, characterized in that, This authentication method is applied to the user center and includes the following login authentication process: The system receives a login request entered by a user through the user-end login page, the login request including the username; the user-end is used to receive the user's API service access request to the first system, send the access request to the first system, and display the login page when a login display request is received; the first system is used to identify that the user is not currently logged in when the message header of the access request does not contain a token, and send a login display request to the user-end. The system calls a Bloom filter to verify if the username exists. If the Bloom filter finds that the username does not exist, it determines that the user is an unregistered user and returns a login failure message to the first system. The first system also returns the user's API service access request to the first system as an invalid request to the user. The Bloom filter pre-stores multiple registered usernames, and each registered username is stored in the form of a binary bit vector array.

2. The method as described in claim 1, characterized in that, Also includes: The Bloom filter pre-stores each registered username as follows: Call the Hash function to generate a series of random mapping arrays for the registered usernames; Using the elements in the random mapping array as indices, the preset bit vector array is modified, changing each element of the vector array to 1. This process continues until the modification of the bit vector array is complete, at which point the Bloom filter has finished saving the registered username value.

3. The method as described in claim 2, characterized in that, Calling a Bloom filter to verify if the username exists includes: A Bloom filter retrieves the current username; The Bloom filter calls a hash function to generate a series of random mapping arrays for the current username; The Bloom filter uses elements in the random mapping array as indices to search for elements in a preset bit vector array; The elements found in the bit vector array are joined together. If the value is 1, the current username exists; otherwise, the current username does not exist.

4. The method as described in claim 1, characterized in that, The login request also includes a user password, and the login authentication process further includes: If the Bloom filter verifies that the username exists, it first matches user information from the cache based on the username. If the data is not found in the cache, it searches for user information in the database. If user information is found in the database, the user password is verified to be correct. If the user password authentication is successful, the user logs in successfully, a token is generated and saved for subsequent API service access without login, and the generated token is sent to the user's client. The user's client is also used to encapsulate the returned token into the message header of the access request after the user logs in successfully, and continue to initiate an API service access request to the first system client. The first system client is also used to execute the API business processing when the authentication token is passed, and return response data to the user's client.

5. The method as described in claim 4, characterized in that, Also includes: If user information is found in the database, verify whether the user information exists to rule out the risk of misjudgment by the Bloom filter.

6. The method as described in claim 1, characterized in that, It also includes the following token authentication process: The user terminal is used to obtain the Token sent from the second system terminal; the user terminal is also used to receive the API service access request from the user across systems to the second system terminal, and send the API service access request to the second system terminal to the second system terminal; the second system terminal is used to extract and verify the Token from the message header of the API service access request to the second system terminal. If the Token does not exist in the second system terminal, the user is determined to be the initial access user, and the Token is forwarded to the user center terminal to request verification of the existence of the Token. The Bloom filter is invoked to verify the existence of the token. If the Bloom filter finds that the token does not exist, it is determined that the user is not logged in. The Bloom filter pre-stores multiple registration tokens, and each registration token is stored in the form of a binary bit vector array.

7. The method as described in claim 6, characterized in that, The token authentication process also includes: If the Bloom filter verifies that the token exists, it is considered that the user has logged in, and the authentication token is returned to the second system. The second system is also used to cache the token when it is verified to exist, and when the authentication token is received, it continues to send a query request for user information to the user center based on the token. Upon receiving a request to query user information, the system finds the bound user identifier through the token; it then calls a Bloom filter to verify whether the user identifier exists. If the user identifier does not exist, it determines that the user is not a registered user and directly returns an empty string to the second system. The Bloom filter pre-stores multiple registered user identifiers, each of which is stored in the form of a binary bit vector array.

8. The method as described in claim 7, characterized in that, The token authentication process also includes: If the Bloom filter verifies that the user information exists, the user information is found through the user identifier and returned as a query result to the second system. The second system is also used to cache the user information for later use. The token authentication process is then completed, business processing is performed, and response data is returned to the user, so as to enable the user to successfully access the API service of the second system without logging in.

9. A single sign-on user center terminal, characterized in that, Includes the following units used to complete the login authentication process: The receiving unit is used to receive a login request entered by a user through the user terminal login page, the login request including the username; the user terminal is used to receive the user's API service access request to the first system, send the access request to the first system terminal, and display the login page when a login display request is received; the first system terminal is used to identify that the user is not currently logged in when it detects that there is no token in the message header of the access request, and send a login display request to the user terminal. The first calling unit is used to call the Bloom filter to verify whether the username exists; if the Bloom filter verifies that the username does not exist, it determines that the user is an unregistered user and returns a login failure message to the first system terminal; the first system terminal is also used to return the user's API service access request to the first system as an invalid request to the user terminal; wherein: the Bloom filter pre-stores multiple registered usernames, and each registered username is stored in the form of a binary bit vector array.

10. The user center terminal as described in claim 9, characterized in that, It also includes the following units for completing the token authentication process: The acquisition unit is used to acquire the Token sent by the second system terminal; the user terminal is also used to receive the user's cross-system API service access request to the second system and send the API service access request to the second system terminal to the second system terminal; the second system terminal is used to extract and verify the Token from the message header of the API service access request to the second system. If the Token does not exist in the second system terminal, the user is determined to be the initial access user, and the Token is forwarded to the user center terminal to request verification of the existence of the Token. The second calling unit is used to call the Bloom filter to verify whether the Token exists. If the Bloom filter verifies that the Token does not exist, it is determined that the user has not logged in. The Bloom filter pre-stores multiple registration Tokens, and each registration Token is stored in the form of a binary bit vector array.

11. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 8.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

13. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

Images