Identity verification method and device, equipment, medium and product

Abstract

The invention provides an identity verification method and device, equipment, a medium and a product, and relates to the technical field of data security. The method comprises the following steps: in response to a received service request sent by a client, determining whether a token parameter exists in a preset database or not under the condition of determining that the service request comprises the token parameter; in response to existence of the token parameter in the preset database, determining whether the user logs in or not according to the token parameter; if it is determined that the user logs in, determining whether a pre-stored user identifier, stored in a preset database, of the token parameter is consistent with a target user identifier included in the service request, and determining that verification is passed in response to the fact that the pre-stored user identifier is consistent with the target user identifier; and if it is determined that the user does not log in, determining whether verification is passed based on the type of the service request. The method is suitable for different scenes of user login or non-login, the sensitive parameters can be prevented from being tampered, and the data security is improved.

Description

Technical Field

[0001] This application relates to the field of data security technology, and in particular, to an authentication method, apparatus, device, medium, and product. Background Art

[0002] Identity authentication is an important technical means to ensure the stability and security of the server side, and also ensures the security of data transmission. Common authentication methods include the SSH (Secure Shell) protocol, SSL (Secure Sockets Layer) certificate verification, and traditional login account and password verification.

[0003] The SSH protocol ensures the security of remote connections through the combination of public and private keys; the SSL certificate establishes an encrypted connection between the client and the server to ensure the security of data transmission; and the login account and password verification, as the most traditional method, is still widely used today.

[0004] However, existing authentication methods usually rely on a single verification mode, such as only supporting real-name login verification, and cannot flexibly handle mixed scenarios, and lack a sensitive parameter anti-tampering mechanism. Summary of the Invention

[0005] This application provides an authentication method, apparatus, device, medium, and product to solve the technical problems that the authentication method cannot flexibly handle different scenarios and lacks a sensitive parameter anti-tampering mechanism.

[0006] In a first aspect, this application provides an authentication method, and the method includes:

[0007] In response to receiving a service request sent by a client, when it is determined that the service request includes a token parameter, determine whether the token parameter exists in a preset database;

[0008] In response to the token parameter existing in the preset database, determine whether the user is logged in according to the token parameter;

[0009] If it is determined that the user has logged in, determine whether the pre-stored user identifier stored in the preset database for the token parameter is consistent with the target user identifier included in the service request, and in response to the pre-stored user identifier being consistent with the target user identifier, determine that the verification is passed;

[0010] If it is determined that the user has not logged in, determine whether the verification is passed based on the type of the service request.

[0011] In a possible design, the determining whether the user is logged in according to the token parameter includes:

[0012] Determine whether there is a pre-stored user identifier corresponding to the token parameter in the preset database;

[0013] If there is a corresponding pre-stored user identifier, determine that the user has logged in;

[0014] If there is no corresponding pre-stored user identifier, determine that the user has not logged in.

[0015] In a possible design, if it is determined that the user has not logged in, then determine whether the verification passes based on the type of the service request, including;

[0016] If it is determined that the user has not logged in, determine whether the type of the service request is a preset operation type;

[0017] If it is determined that the type of the service request is a preset operation type, determine that the verification fails;

[0018] If it is determined that the type of the service request is not a preset operation type, determine that the verification passes.

[0019] In a possible design, after it is determined that the type of the service request is a preset operation type and it is determined that the verification fails, the method further includes:

[0020] Send a login interface to the client so that the user can enter the account password to log in.

[0021] In a possible design, the method further includes:

[0022] In response to the pre-stored user identifier being inconsistent with the target user identifier, determine that the verification fails;

[0023] Send the verification result of the failed verification to the client; or modify the target user identifier to the pre-stored user identifier and execute the service request.

[0024] In a possible design, before determining whether the token parameter exists in the preset database when it is determined that the service request includes a token parameter, the method further includes:

[0025] Obtain the client interface identifier corresponding to the service request;

[0026] Determine whether the client interface identifier exists in the preset authorization list;

[0027] If it exists in the preset authorization list, execute the service request;

[0028] When it is determined that the service request includes a token parameter, determining whether the token parameter exists in the preset database includes:

[0029] If it does not exist in the preset authorized list, when it is determined that the service request includes a token parameter, determine whether the token parameter exists in the preset database.

[0030] In a possible design, after receiving the service request sent by the client, the method further includes:

[0031] When it is determined that the service request does not include a token parameter, generate the token parameter according to the service request.

[0032] In a possible design, generating the token parameter according to the service request includes:

[0033] If the service request includes a user identifier, generate the token parameter according to the service source identifier, device number, and user identifier, and store the token parameter, the service source identifier, the device number, and the user identifier in an associated manner;

[0034] If the service request does not include a user identifier, generate the token parameter according to the service source identifier and device number, and store the token parameter, the service source identifier, and the device number in an associated manner.

[0035] In a second aspect, the present application provides an authentication device, and the device includes:

[0036] A parameter situation determination module, configured to, in response to receiving a service request sent by a client, when it is determined that the service request includes a token parameter, determine whether the token parameter exists in a preset database;

[0037] A login situation determination module, configured to, in response to the token parameter existing in the preset database, determine whether a user has logged in according to the token parameter;

[0038] A verification result determination module, configured to, if it is determined that the user has logged in, determine whether the pre-stored user identifier stored in the preset database for the token parameter is consistent with the target user identifier included in the service request, and in response to the pre-stored user identifier being consistent with the target user identifier, determine that the verification is passed;

[0039] The verification result determination module is further configured to, if it is determined that the user has not logged in, determine whether the verification is passed based on the type of the service request.

[0040] In a third aspect, the present application provides an authentication device, and the device includes: a processor, and a memory communicatively connected to the processor;

[0041] The memory stores computer-executable instructions;

[0042] The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of the first aspect.

[0043] In a fourth aspect, the present application provides a computer-readable storage medium storing computer-executable instructions, which are used to implement the method according to any one of the first aspect when executed by a processor.

[0044] In a fifth aspect, the present application provides a computer program product including a computer program, which implements the method according to any one of the first aspect when executed by a processor.

[0045] The authentication method, device, equipment, medium and product provided by the present application, in response to receiving a service request sent by a client, when it is determined that the service request includes a token parameter, determines whether the token parameter exists in a preset database; in response to the token parameter existing in the preset database, determines whether the user is logged in according to the token parameter; if it is determined that the user is logged in, determines whether the pre-stored user identifier stored in the preset database corresponding to the token parameter is consistent with the target user identifier included in the service request, and in response to the pre-stored user identifier being consistent with the target user identifier, determines that the authentication is passed; if it is determined that the user is not logged in, determines whether the authentication is passed based on the type of the service request. After receiving the service request sent by the client, if it is determined that the service request includes a token parameter, determines whether the token parameter exists in the preset database, and verifies the validity of the token parameter by querying the preset database, which can ensure that only requests with valid token parameters can be further processed; when it is determined that the token parameter exists in the preset database, determines whether the user is logged in according to the token parameter, so as to adopt different authentication methods according to different login states, so that accurate and effective identity authentication can be obtained in different scenarios; when the user is logged in, determines whether the pre-stored user identifier stored in the preset database corresponding to the token parameter is consistent with the target user identifier included in the service request, ensuring that the user identifier in the request matches the user identifier stored in the database, preventing users from operating under the identity of other users, preventing sensitive parameters from being tampered with, and enhancing the security of the system and the protection of user data; when the user is not logged in, determines whether the authentication is passed based on the type of the service request, so that certain types of requests (such as obtaining public information) can be made without logging in, while sensitive operations require the user to log in, improving the flexibility of the system. Description of the Drawings

[0046] The drawings here are incorporated into the specification and form a part of this specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0047] Figure 1 It is an application scenario diagram of the identity authentication method provided by an embodiment of the present application;

[0048] Figure 2 It is a flowchart of the identity authentication method provided by an embodiment of the present application;

[0049] Figure 3 It is a flowchart of the identity authentication method provided by another embodiment of the present application;

[0050] Figure 4 It is a schematic structural diagram of the identity authentication device provided by an embodiment of the present application;

[0051] Figure 5 It is a schematic structural diagram of the identity authentication device provided by an embodiment of the present application.

[0052] Through the above-mentioned drawings, specific embodiments of the present application have been shown, and there will be more detailed descriptions hereinafter. These drawings and text descriptions are not intended to limit the scope of the concept of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. Detailed Embodiments

[0053] Here, the exemplary embodiments will be described in detail, and the examples are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0054] It should be noted that in the embodiments of the present application, certain software, components, and models may be mentioned. They should be considered exemplary, and their purpose is only to illustrate the feasibility in the implementation of the technical solution of the present application, but it does not mean that the applicant has already or necessarily used this solution.

[0055] To clearly understand the technical solution of the present application, the solutions of the prior art will be introduced in detail first.

[0056] Authentication is an important technical means to ensure the stability and security of the server side, and at the same time, it also ensures the security of data transmission. For example, the SSH protocol uses a combination of public and private keys to ensure the security of remote connections. However, if the private key is leaked, the server may be attacked, and the compatibility of SSH key authentication is poor, with a small scope of application; SSL certificate authentication uses digital certificates to ensure that the communication between the server and the client is secure and encrypted. However, the processes of applying for, issuing, updating, and revoking certificates require strict management and are costly; the most traditional authentication method is to verify through the password of the login account. However, the current commonly used authentication methods have a relatively single verification mode, only supporting real-name login verification, and cannot flexibly handle mixed scenarios, such as both logged-in and non-logged-in situations, and lack a mechanism to prevent tampering of sensitive parameters.

[0057] Therefore, when facing the technical problems in the prior art, to adapt to identity verification in different scenarios, corresponding identity verification methods are formulated according to whether the user is logged in or not. Therefore, when a service request is received and it is determined that it includes a token parameter, it is determined whether the token parameter exists in the preset database, and a preliminary judgment is made in a simple way. This can not only quickly determine whether the source of the service request is secure, but also save system resources and avoid unnecessary resource waste; if it is determined that the token parameter exists in the preset database, subsequent steps are carried out to determine whether the user is logged in according to the token parameter, and thus the specific method of subsequent identity verification is determined; to prevent sensitive parameters from being tampered with, when it is determined that the user has logged in, a secondary verification is carried out by determining whether the pre-stored user identifier stored in the preset database for the token parameter is consistent with the target user identifier included in the service request. The verification result determined in this way is more accurate, effectively preventing the situation where a user misuses the data of other users for business operations and improving the security of data transmission; on the other hand, to improve the overall flexibility of the system, when it is determined that the user has not logged in, it is determined whether the verification passes based on the type of the service request, and certain types of requests (such as browsing public information, etc.) are allowed to be carried out without logging in. This not only makes the verification method applicable to mixed scenarios, but also improves the overall flexibility of the system.

[0058] Figure 1 The application scenario diagram of the identity verification method provided by an embodiment of the present application is as Figure 1 shown. The application scenario diagram of the identity verification method provided by this embodiment includes: a server 101, a client device 102, and a preset database 103.

[0059] It should be noted that the preset database 103 stores token parameters corresponding to different service requests. The token parameters are generated by the server 101 when it first receives a service request and stored in the preset database 103. The same service type corresponds to the same token parameter. For example, the junior journalist service module corresponds to one token parameter, and the junior author service module corresponds to one token parameter, etc.

[0060] It can be understood that after the server 101 generates the token parameter, in addition to storing it in the preset database 103, the server 101 also sends the token parameter to the client device 102 so that the requests for the same service sent by the client device 102 subsequently all include the token parameter for identity verification.

[0061] Specifically, when the server 101 receives a service request sent by the client device 102, in the case of determining that the service request includes a token parameter, the server 101 determines whether the token parameter exists in the preset database 103. For example, the server 101 sends a query token parameter instruction to the preset database 103 to determine whether the token parameter exists in the preset database 103. If it is determined that the token parameter exists in the preset database 103, the server 101 determines whether the user is logged in according to the token parameter. If it is determined that the user has logged in, the server 101 determines whether the pre-stored user identifier stored in the preset database according to the token parameter is consistent with the target user identifier included in the service request. For example, the server 101 sends a query pre-stored user identifier instruction to the preset database 103. When the pre-stored user identifier is consistent with the target user identifier, the server 101 determines that the verification is passed. If it is determined that the user has not logged in, the server 101 determines whether the verification is passed based on the type of the service request.

[0062] Among them, if the server 101 determines that the verification is passed, the server 101 executes the service request. If the server 101 determines that the verification fails, the server 101 may send a message indicating that the verification fails to the client device 102 so that the user can perform the next operation, such as real-name login, etc. This embodiment does not make any limitations in this regard.

[0063] The following uses specific embodiments to elaborate in detail on the technical solution of the present application and how the technical solution of the present application solves the above technical problems. These several specific embodiments can be combined with each other, and for the same or similar concepts or processes, they may not be repeated in some embodiments. The following will describe the embodiments of the present application in conjunction with the accompanying drawings.

[0064] Figure 2 It is a flowchart of an identity verification method provided by an embodiment of the present application, as Figure 2As shown in the figure, the execution subject of this embodiment is an authentication device, which can be implemented by a computer program, or by a medium storing relevant computer programs, such as a USB flash drive and / or an optical disc, etc., or can be integrated in an authentication device, such as a server, etc. The authentication method provided in this embodiment includes the following steps:

[0065] Step 201, in response to receiving a service request sent by a client, when it is determined that the service request includes a token parameter, determine whether the token parameter exists in a preset database.

[0066] Among them, the service request refers to a request for a service operation initiated by the client, which can be classified based on the service type, such as a little journalist module service request, a little author module service request, etc. This embodiment does not make any limitations on this.

[0067] Among them, the token parameter is a string used to identify the user identity or session state, and is a unique string generated by the authentication device corresponding to the service request.

[0068] Among them, the preset database refers to a database that is pre-set in the authentication device and used to store token parameters. For example, it can be a remote dictionary service database Redis, or other databases. This embodiment does not make any limitations on this.

[0069] Optionally, the authentication device can generate a token parameter corresponding to the service request when it first receives the service request, and store it in the preset database, or pre-write and store the token parameter corresponding to the service request in the preset database, or store the token parameter in the preset database by other means. This embodiment does not make any limitations on this.

[0070] It should be noted that the token parameter not only needs to be stored in the preset database, but also will be synchronized to the client so that the token parameter can be carried in the service request sent by the client later for authentication.

[0071] Specifically, when the authentication device receives a service request sent by the client and determines that the service request includes a token parameter, determine whether the token parameter exists in the preset database. For example, the token parameter can be sent to the preset database to enable the preset database to query and determine whether the token parameter exists, or determine whether the token parameter exists in the preset database by other means. This embodiment does not make any limitations on this.

[0072] Optionally, a filter Servlet can be customized in the authentication device to intercept the service request before it reaches the target interface, so as to authenticate the service request, or intercept it by other means. This embodiment does not make any limitations on this.

[0073] It can be understood that after receiving a service request, the authentication device first determines whether the service request includes a token parameter. If it does, it determines whether the token parameter exists in a preset database; if not, other operations will be performed, such as rejecting the service request or generating a corresponding token parameter according to the service request, which is not limited in this embodiment.

[0074] Step 202, in response to the token parameter existing in the preset database, determine whether the user is logged in according to the token parameter.

[0075] Specifically, after determining that the token parameter carried in the service request exists in the preset database, determine whether the user is logged in. For example, the token parameter can be input into the preset database, and check whether the user information corresponding to the token parameter in the preset database includes a character for identifying the user's login status. If it does, it means the user is logged in; or directly check whether the token parameter includes a character for identifying the user's login status, which is not limited in this embodiment.

[0076] It can be understood that if the method of searching in the preset database is used for determination, when storing the token parameter in the preset database, the corresponding user information, such as login status information, login device information, etc., will also be associated and stored.

[0077] Step 203, if it is determined that the user is logged in, determine whether the pre-stored user identifier stored in the preset database for the token parameter is consistent with the target user identifier included in the service request, and in response to the pre-stored user identifier being consistent with the target user identifier, determine that the authentication is passed.

[0078] Among them, the pre-stored user identifier refers to the user identifier corresponding to the token parameter pre-stored in the preset database, which is used to represent the user information corresponding to the token parameter.

[0079] Among them, the target user identifier refers to the user identifier automatically carried in the service request, which is used to represent the user information of the user sending the service request.

[0080] It can be understood that if the user is in a logged-in state, the service request must include a target user identifier.

[0081] Specifically, when it is determined that the user is logged in, extract the target user identifier from the service request, input the token parameter in the service request into the preset database to find the stored pre-stored user identifier corresponding to it, compare the pre-stored user identifier with the target user identifier. If the two user identifiers are consistent, the authentication of the service request is passed.

[0082] Optionally, if the pre-stored user identifier is inconsistent with the target user identifier, that is, the verification fails, a message rejecting the request can be sent to the client, or the target user identifier can be modified to the pre-stored user identifier for operation, or other operations. This embodiment does not limit this.

[0083] Step 204, if it is determined that the user is not logged in, determine whether the verification passes based on the type of the service request.

[0084] Specifically, if it is determined that the user is not logged in, it means that the service request does not include the target user identifier. Then, determine whether the verification passes based on the type of the service request. Since the service request can be of multiple types, a list can be pre-stored in the authentication device, such as which service request types allow the user to operate without logging in and which service request types do not allow the user to operate without logging in. When it is determined that the user is not logged in, directly determine whether the verification passes according to which list the service request type is in; or other methods can be used for verification. This embodiment does not limit this.

[0085] Optionally, if the verification fails, a message rejecting the request can be sent to the client, and then jump to the login interface so that the user can log in; or other operations can be performed. This embodiment does not limit this.

[0086] The authentication method provided by the embodiments of this application, in response to receiving a service request sent by a client, when it is determined that the service request includes a token parameter, determines whether the token parameter exists in a preset database; in response to the token parameter existing in the preset database, determines whether the user has logged in according to the token parameter; if it is determined that the user has logged in, determines whether the pre-stored user identifier stored in the preset database for the token parameter is consistent with the target user identifier included in the service request, and in response to the pre-stored user identifier being consistent with the target user identifier, determines that the authentication is passed; if it is determined that the user has not logged in, determines whether the authentication is passed based on the type of the service request. After receiving the service request sent by the client, when it is determined that the service request includes a token parameter, determines whether the token parameter exists in the preset database, and verifies the validity of the token parameter by querying the preset database, which can ensure that only requests with valid token parameters can be further processed; when it is determined that the token parameter exists in the preset database, determines whether the user has logged in according to the token parameter, so as to adopt different authentication methods according to different login states, so that accurate and effective identity authentication can be obtained in different scenarios; when the user has logged in, determines whether the pre-stored user identifier stored in the preset database for the token parameter is consistent with the target user identifier included in the service request, ensuring that the user identifier in the request matches the user identifier stored in the database, preventing users from operating under the identity of other users, preventing sensitive parameters from being tampered with, and enhancing the security of the system and the protection of user data; when the user has not logged in, determines whether the authentication is passed based on the type of the service request, enabling certain types of requests (such as obtaining public information) to be made without logging in, while sensitive operations require the user to log in, improving the flexibility of the system.

[0087] As an optional implementation manner, on the basis of the above embodiment, determining whether the user has logged in according to the token parameter includes:

[0088] Determines whether there is a pre-stored user identifier corresponding to the token parameter in the preset database;

[0089] If there is a corresponding pre-stored user identifier, determines that the user has logged in;

[0090] If there is no corresponding pre-stored user identifier, determines that the user has not logged in.

[0091] Specifically, after receiving the service request, the service request will be parsed, the token parameter will be extracted from it, and the extracted token parameter will be used as a query condition to find in the preset database whether there is a pre-stored user identifier corresponding to the token parameter. If a pre-stored user identifier corresponding to the token parameter is found in the preset database, it means that the user has logged in; if no pre-stored user identifier corresponding to the token parameter is found in the preset database, it means that the user has not logged in.

[0092] Optionally, to further improve the reliability of identity verification and the security of data transmission, an expiration period can be set for the token parameters. When performing verification, it is verified whether the token parameters have expired. If they have expired, the service request is rejected.

[0093] The identity verification method provided by the embodiments of this application determines whether a user is logged in according to the token parameters, including: determining whether there is a pre-stored user identifier corresponding to the token parameters in a preset database; if there is a corresponding pre-stored user identifier, it is determined that the user is logged in; if there is no corresponding pre-stored user identifier, it is determined that the user is not logged in. By querying the database to verify the token parameters and determine whether the user is logged in, the query speed is relatively fast, which can meet the performance requirements in high-concurrency scenarios, reduce the overall calculation frequency of the device, save resource consumption, and the preset database can be expanded as the number of users increases, supporting the large-scale user login verification requirements.

[0094] As an optional implementation manner, on the basis of the above embodiment, if it is determined that the user is not logged in, it is determined whether the verification passes based on the type of the service request, including:

[0095] If it is determined that the user is not logged in, it is determined whether the type of the service request is a preset operation type;

[0096] If it is determined that the type of the service request is a preset operation type, it is determined that the verification fails;

[0097] If it is determined that the type of the service request is not a preset operation type, it is determined that the verification passes.

[0098] Among them, the preset operation type is an operation type pre-stored in the identity verification device, such as a submission operation, an update operation, etc. The corresponding name or identifier of the operation type can be stored, and this embodiment does not limit this.

[0099] Specifically, if the user is not logged in, the corresponding operation type is obtained from the service request. For example, different HTTP methods (such as GET, POST, PUT, DELETE, etc.) may be included in the service request, and different request methods correspond to different operation types. The obtained operation type is used as a query condition to query in the identity verification device. If it is queried that the type of the service request is a preset operation type, it is determined that the verification fails. If it is not queried, it means that the type of the service request is not a preset operation type, and it is determined that the verification passes.

[0100] The identity authentication method provided by the embodiments of the present application, if it is determined that the user is not logged in, then determines whether the authentication is passed based on the type of the service request, including: if it is determined that the user is not logged in, determines whether the type of the service request is a submission operation type; if it is determined that the type of the service request is a submission operation type, then determines that the authentication fails; if it is determined that the type of the service request is not a submission operation type, then determines that the authentication passes. By setting a preset operation type to determine whether the authentication passes, not only can the authentication result be quickly determined, but also the preset operation type can be dynamically adjusted according to the actual situation to meet different service requirements, and for some non-sensitive operations, users are allowed to operate in a non-logged-in state, improving the user experience.

[0101] As an optional implementation manner, on the basis of the above embodiment, if it is determined that the type of the service request is a preset operation type, after determining that the authentication fails, the method further includes:

[0102] Sending a login interface to the client so that the user can enter the account password to log in.

[0103] Specifically, when it is determined that the type of the service request is a preset operation type, it indicates that the service request needs to be executed in a logged-in state, then determines that the authentication fails, and sends a login interface to the client so that the user can enter the account password to log in.

[0104] The identity authentication method provided by the embodiments of the present application, if it is determined that the type of the service request is a submission operation type, after determining that the authentication fails, the method further includes: sending a login interface to the client so that the user can enter the account password to log in. After determining that the authentication fails, sending the login interface to the client in a timely manner can not only notify the user that the service request needs to be completed when logged in, but also facilitate the user to quickly log in without having to click the login interface by themselves, improving the user experience.

[0105] As an optional implementation manner, on the basis of the above embodiment, the method further includes:

[0106] In response to the pre-stored user identifier being inconsistent with the target user identifier, it is determined that the authentication fails;

[0107] Sending the authentication result of the failed authentication to the client; or modifying the target user identifier to the pre-stored user identifier and executing the service request.

[0108] Specifically, when the pre-stored user identifier is inconsistent with the target user identifier, it indicates that some users may be using the token parameters of other users to make requests at this time, which belongs to the situation where sensitive parameters are tampered with. Then it is determined that the verification fails at this time. If the verification fails, the verification result of failure can be sent to the client to guide the user to perform subsequent operations; or the target user identifier can be modified to the pre-stored user identifier, such as dynamically rewriting the user identifier through ParameterRequestWrapper, and using the parameters of the pre-stored user identifier to execute the service request. The authentication method provided by the embodiments of the present application further includes: in response to the pre-stored user identifier being inconsistent with the target user identifier, determining that the verification fails; sending the verification result of failure to the client; or modifying the target user identifier to the pre-stored user identifier and executing the service request. In the case where the verification fails, the verification result of failure can be sent to the client to provide the user with clear error prompts and guidance information, helping the user quickly locate the problem and make corrections; through intelligent analysis and automatic correction, after modifying the target user identifier to the pre-stored user identifier and then executing the service request, it can effectively prevent sensitive parameters from being tampered with.

[0109] As an alternative implementation, on the basis of the above embodiments, when it is determined that the service request includes a token parameter, before determining whether the token parameter exists in the preset database, the method further includes:

[0110] Obtaining the client interface identifier corresponding to the service request;

[0111] Determining whether the client interface identifier exists in the preset authorization list;

[0112] If it exists in the preset authorization list, execute the service request;

[0113] When it is determined that the service request includes a token parameter, determining whether the token parameter exists in the preset database includes:

[0114] If it does not exist in the preset authorization list, then when it is determined that the service request includes a token parameter, determine whether the token parameter exists in the preset database.

[0115] Among them, the client interface identifier refers to the information used to uniquely identify the communication interface between the client and the server. For example, it can be a string, a digital code, or a name, etc., and is used to identify and process requests from a specific client or client application on the server side.

[0116] Among them, the preset authorization list refers to a pre-defined and stored list of client interface identifiers. The interface identifiers in the preset authorization list represent the clients that are authorized to access resources or execute specific service requests.

[0117] Specifically, when receiving a service request, the request header or specific fields can be parsed first to extract the client interface identifier corresponding to the service request. The extracted client interface identifier is compared with the entries in the preset authorization list. For example, the URI.contains tool is used for comparison. If the client interface identifier exists in the preset authorization list, the client is considered authorized, and its service request does not need to be authenticated and can directly execute the service request. If the client interface identifier does not exist in the preset authorization list, the client is considered unauthorized, and the service request sent by it needs to be authenticated and verified according to the subsequent verification steps.

[0118] For the authentication method provided in the embodiments of the present application, before determining whether the token parameter exists in the preset database when it is determined that the service request includes the token parameter, the method further includes: obtaining the client interface identifier corresponding to the service request; determining whether the client interface identifier exists in the preset authorization list; if it exists in the preset authorization list, execute the service request. When it is determined that the service request includes the token parameter, determining whether the token parameter exists in the preset database includes: if it does not exist in the preset authorization list, then when it is determined that the service request includes the token parameter, determining whether the token parameter exists in the preset database. Using the preset authorization list can simplify the authorization management process, reduce the workload of manual configuration and review, and the preset authorization list can be dynamically managed to flexibly adapt to changes in business requirements and clients. By comparing the preset authorization list with the client interface identifier, legal client requests can be accurately identified and authorized, thus preventing unauthorized access and operations.

[0119] As an optional implementation manner, on the basis of the above embodiments, after receiving the service request sent by the client, the method further includes:

[0120] When it is determined that the service request does not include the token parameter, generating a token parameter according to the service request.

[0121] Specifically, the received service request may not include the token parameter. Therefore, after receiving the service request, it is first determined whether the service request includes the token parameter. If it does not include the token parameter, the corresponding token parameter needs to be generated. For example, it can be determined whether the service request is sent by a logged-in user. The service request sent by a logged-in user calls interface A to generate the corresponding token parameter, and the service request sent by a non-logged-in user calls interface B to generate the corresponding token parameter. There can also be other generation methods, which are not limited in this embodiment.

[0122] After generating the token parameter, it also needs to be stored in the preset database.

[0123] The authentication method provided by the embodiments of this application, after receiving a service request sent by a client, the method further includes: when it is determined that the service request does not include a token parameter, generating a token parameter according to the service request. When the service request does not include a token parameter, generating a corresponding token parameter for subsequent authentication. Tokens usually do not contain sensitive information such as the user's password, effectively reducing the situation of password leakage; the token parameter can be used for authentication and authorization based on the service request, helping to prevent cross-site request forgery attacks and improving data security.

[0124] As an alternative implementation, based on the above embodiment, generating a token parameter according to the service request includes:

[0125] If the service request includes a user identifier, generating a token parameter according to the service source identifier, device number, and user identifier, and associatively storing the token parameter, service source identifier, device number, and user identifier;

[0126] If the service request does not include a user identifier, generating a token parameter according to the service source identifier and device number, and associatively storing the token parameter, service source identifier, and device number.

[0127] Among them, the service source identifier refers to a symbol used to identify the source of the service request. For example, the service source can be distinguished according to a specific application, website, or system.

[0128] Among them, the device number is an identifier used to uniquely identify a user device, such as IMEI, MAC address, etc.

[0129] Specifically, after receiving the service request, it is determined whether it includes a user identifier. If it does, a token parameter is generated according to the service source identifier, device number, and user identifier, such as using an encryption algorithm, hash function, etc., to ensure its uniqueness and security. Then, the generated token parameter is associatively stored with its corresponding service source identifier, device number, and user identifier, that is, the information packet corresponding to the token parameter includes the service source identifier, device number, and user identifier, etc.; correspondingly, if the service request does not include a user identifier, an encryption algorithm, hash function, etc. can also be used to generate the corresponding token parameter, or other interfaces can be called to generate it. This embodiment does not make a limitation on this. Since it does not include a user identifier, when associatively storing, the information packet corresponding to the token parameter includes the service source identifier and device number.

[0130] It can be understood that after generating the token parameter, in addition to associatively storing it, it will also be returned to the client so that the client can carry the token parameter when sending a service request for authentication.

[0131] The authentication method provided by the embodiment of the present application generates token parameters according to a service request, including: if the service request includes a user identifier, generating token parameters according to the service source identifier, device number, and user identifier, and associatively storing the token parameters, the service source identifier, device number, and user identifier; if the service request does not include a user identifier, generating token parameters according to the service source identifier and device number and associatively storing the token parameters, the service source identifier, and device number. By generating token parameters by combining the service source identifier, device number, and user identifier (if any), it can effectively prevent attackers from forging token parameters for illegal access, prevent sensitive parameters from being tampered with, and improve data security.

[0132] Figure 3 is a flowchart of the authentication method provided by another embodiment of the present application. As Figure 3 shown, the authentication method provided in this embodiment includes the process of generating token parameters, the specific verification steps when the user is logged in or not logged in, and the specific steps after the verification passes or fails. Then the authentication method provided in this embodiment includes the following steps:

[0133] Step 301, in response to receiving a service request sent by the client, determine whether the service request includes a token parameter.

[0134] Step 302, if so, determine whether the token parameter exists in the preset database.

[0135] Step 303, if not, generate token parameters according to the service request, store them in the preset database, and continue to execute Step 304.

[0136] Step 304, if the token parameter exists in the preset database, determine whether there is a pre-stored user identifier corresponding to the token parameter in the preset database.

[0137] Step 305, if the token parameter does not exist in the preset database, reject the service request.

[0138] Step 306, if there is a corresponding pre-stored user identifier, determine that the user is logged in.

[0139] Step 307, if there is no corresponding pre-stored user identifier, determine that the user is not logged in.

[0140] Step 308, if it is determined that the user is logged in, determine whether the pre-stored user identifier stored in the preset database for the token parameter is consistent with the target user identifier included in the service request.

[0141] Step 309, in response to the pre-stored user identifier being consistent with the target user identifier, determine that the verification passes and execute the service request.

[0142] Step 310, in response to the pre-stored user identifier being inconsistent with the target user identifier, it is determined that the verification fails, and the verification result of the failed verification is sent to the client; or the target user identifier is modified to the pre-stored user identifier, and the service request is executed.

[0143] Step 311, if it is determined that the user is not logged in, determine whether the type of the service request is a submission operation type.

[0144] Step 312, if it is determined that the type of the service request is not a submission operation type, it is determined that the verification passes and the service request is executed.

[0145] Step 313, if it is determined that the type of the service request is a submission operation type, it is determined that the verification fails.

[0146] Step 314, in response to the failed verification, send a login interface to the client so that the user can enter the account password to log in.

[0147] In this embodiment, the implementation manners and technical effects of steps 301 - 314 are similar to those of the corresponding solutions in the above embodiment, and will not be elaborated here.

[0148] Figure 4 It is a schematic structural diagram of an identity authentication device provided by an embodiment of the present application. As Figure 4 shown, the identity authentication device provided in this embodiment is located in the identity authentication device. Then, the identity authentication device 40 provided in this embodiment includes: a parameter situation determination module 41, a login situation determination module 42, and a verification result determination module 43.

[0149] Among them, the parameter situation determination module 41 is configured to, in response to receiving a service request sent by the client, determine whether a token parameter exists in a preset database when it is determined that the service request includes a token parameter; the login situation determination module 42 is configured to, in response to the token parameter existing in the preset database, determine whether the user is logged in according to the token parameter; the verification result determination module 43 is configured to, if it is determined that the user has logged in, determine whether the pre-stored user identifier stored in the preset database for the token parameter is consistent with the target user identifier included in the service request, and in response to the pre-stored user identifier being consistent with the target user identifier, determine that the verification passes; the verification result determination module 43 is further configured to, if it is determined that the user is not logged in, determine whether the verification passes based on the type of the service request.

[0150] The identity authentication device provided in this embodiment can execute Figure 2 the method provided in the embodiment. The specific implementation principle and technical effect are similar, and will not be elaborated here.

[0151] Optionally, when determining whether a user is logged in according to the token parameter, the login status determination module 42 is specifically configured to: determine whether there is a pre-stored user identifier corresponding to the token parameter in a preset database; if there is a corresponding pre-stored user identifier, determine that the user is logged in; if there is no corresponding pre-stored user identifier, determine that the user is not logged in.

[0152] Optionally, when determining whether the verification passes based on the type of the service request if it is determined that the user is not logged in, the verification result determination module 43 is specifically configured to: if it is determined that the user is not logged in, determine whether the type of the service request is a submission operation type; if it is determined that the type of the service request is a submission operation type, determine that the verification fails; if it is determined that the type of the service request is not a submission operation type, determine that the verification passes.

[0153] Optionally, the authentication device provided in this embodiment further includes a sending module.

[0154] Correspondingly, the sending module is configured to send a login interface to the client so that the user can input an account password to log in.

[0155] Optionally, the authentication device provided in this embodiment further includes a modification module.

[0156] Correspondingly, the verification result determination module 43 is further configured to determine that the verification fails in response to the pre-stored user identifier being inconsistent with the target user identifier; the sending module is further configured to send the verification result of the failed verification to the client; the modification module is configured to modify the target user identifier to the pre-stored user identifier and execute the service request.

[0157] Optionally, the authentication device provided in this embodiment further includes an acquisition module, an interface identifier determination module, and an execution module.

[0158] Correspondingly, the acquisition module is configured to acquire the client interface identifier corresponding to the service request; the interface identifier determination module is configured to determine whether the client interface identifier exists in a preset authorization list; the execution module is configured to execute the service request if it exists in the preset authorization list; the parameter status determination module 41, when determining that the service request includes a token parameter, determines whether the token parameter exists in the preset database, and is specifically configured to: if it does not exist in the preset authorization list, when determining that the service request includes a token parameter, determine whether the token parameter exists in the preset database.

[0159] Optionally, the authentication device provided in this embodiment further includes a generation module.

[0160] Correspondingly, the generation module is configured to generate a token parameter according to the service request when it is determined that the service request does not include a token parameter.

[0161] Optionally, when generating the token parameter according to the service request, the generation module is specifically configured to: if the service request includes a user identifier, generate the token parameter according to the service source identifier, the device number, and the user identifier, and associate and store the token parameter, the service source identifier, the device number, and the user identifier; if the service request does not include a user identifier, generate the token parameter according to the service source identifier and the device number, and associate and store the token parameter, the service source identifier, and the device number.

[0162] Figure 5 FIG. 4 is a schematic structural diagram of an authentication device provided by an embodiment of the present application. As Figure 5 shown, the authentication device 50 provided in this embodiment includes: a processor 51 and a memory 52 communicatively connected to the processor.

[0163] Wherein, the memory 52 stores computer-executable instructions; the processor 51 executes the computer-executable instructions stored in the memory 52 to implement the authentication method provided in the above embodiment. For relevant descriptions, reference may be made to the relevant descriptions and effects corresponding to the steps in the accompanying drawings, and details are not described herein.

[0164] Wherein, the program may include program code, and the program code includes computer-executable instructions. The memory 52 may include a high-speed RAM memory, and may also include a non-volatile memory, such as at least one disk memory.

[0165] In this embodiment, the processor 51 and the memory 52 are connected through a bus. The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, Figure 5 only a thick line is used to represent it in FIG. 4, but it does not mean that there is only one bus or one type of bus.

[0166] An embodiment of the present application further provides a computer-readable storage medium, in which computer-executable instructions are stored. When the controller executes the computer-executable instructions, each step in the method in the above embodiment is implemented.

[0167] An embodiment of the present application further provides a computer program product, including a computer program, which implements each step of the method in the above embodiments when executed by a controller.

[0168] The various embodiments described above in the present application can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard parts (ASSPs), system on chips (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include: being implemented in one or more computer programs, which can be executed and / or interpreted on a programmable system including at least one programmable processor. The programmable processor can be a dedicated or general programmable processor, and can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit the data and instructions to the storage system, the at least one input device, and the at least one output device.

[0169] The computer-executable instructions for implementing the method of the present application can be written in any combination of one or more programming languages. These computer-executable instructions can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the computer-executable instructions are executed by the processor or controller, the functions / operations specified in the flowchart and / or block diagram are implemented. The computer-executable instructions can be executed entirely on the machine, partially on the machine, executed partially on the machine as an independent software package and partially on a remote machine, or executed entirely on a remote machine or electronic device.

[0170] In the context of the present application, a computer-readable storage medium can be a tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. A computer-readable storage medium can be a machine-readable signal medium or a machine-readable storage medium. A computer-readable storage medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of a computer-readable storage medium include an electrical connection based on one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read only memory (ROM), an erasable programmable read only memory (EPROM), an optical fiber, a portable compact disc read only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can include: resistive random access memory (RRAM), dynamic random access memory (DRAM), static random access memory (SRAM), enhanced dynamic random access memory (EDRAM), high-bandwidth memory (HBM), hybrid memory cube (HMC), and so on.

[0171] The systems and techniques described herein can be implemented in a computing system that includes backend components (e.g., as a data electronic device), or a computing system that includes middleware components (e.g., an application electronic device), or a computing system that includes frontend components (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system can be interconnected to each other by digital data communication in any form or medium (e.g., a communication network). Examples of a communication network include: a local area network (LAN), a wide area network (WAN), and the Internet.

[0172] It should be noted that, for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that this application is not limited by the described action sequence, because according to this application, certain steps can be carried out in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application. In other words, the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in the disclosure of this application can be executed in parallel, sequentially, or in different orders, as long as the desired results of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0173] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same moment, but can be executed at different moments, and the execution order of these sub-steps or stages is not necessarily sequential, but can be executed alternately or in turns with at least a part of other steps or sub-steps or stages of other steps.

[0174] It should be understood that the above device embodiments are illustrative only, and the devices of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical function division, and there can be other division methods in actual implementation. For example, multiple units, modules, or components can be combined, or can be integrated into another system, or some features can be ignored or not executed.

[0175] In addition, unless otherwise specified, in each embodiment of this application, each functional unit / module can be integrated in one unit / module, or each unit / module can exist physically alone, or two or more units / modules can be integrated together. The above integrated unit / module can be implemented in the form of hardware or in the form of a software program module.

[0176] When the integrated unit / module is implemented in the form of hardware, the hardware can be a digital circuit, an analog circuit, etc. The physical implementation of the hardware structure includes but is not limited to transistors, memristors, etc.

[0177] When the integrated unit / module is implemented in the form of a software program module and sold or used as an independent product, it can be stored in a computer-readable memory. Based on such an understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. And the aforementioned memory includes: various media such as USB flash drives, read-only memories ROM, random access memories RAM, mobile hard disks, magnetic disks, or optical discs that can store computer-executable instructions.

[0178] In the above embodiments, the descriptions of the various embodiments each have their own focuses. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of concise description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as within the scope described in this specification.

[0179] Those skilled in the art will easily think of other implementation manners of this application after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptive changes of this application. These variations, uses, or adaptive changes follow the general principles of this application and include the common general knowledge or conventional technical means in the technical field not disclosed in this application. The specification and embodiments are only regarded as exemplary.

[0180] It should be understood that this application is not limited to the exact structure already described and shown in the drawings, and various modifications and changes can be made without departing from its scope. Therefore, the above specific implementation manners do not constitute a limitation to the protection scope of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this application should be included within the protection scope of this application.

Claims

1. An authentication method, characterized in that, The method includes: In response to receiving a service request sent by a client, when it is determined that the service request includes a token parameter, determining whether the token parameter exists in a preset database; In response to the token parameter existing in the preset database, determining whether the user is logged in according to the token parameter; If it is determined that the user is logged in, determining whether the pre-stored user identifier stored in the preset database for the token parameter is consistent with the target user identifier included in the service request, and in response to the pre-stored user identifier being consistent with the target user identifier, determining that the verification is passed; If it is determined that the user is not logged in, determining whether the verification is passed based on the type of the service request.

2. The method according to claim 1, characterized in that The determining whether the user is logged in according to the token parameter includes: Determining whether there is a pre-stored user identifier corresponding to the token parameter in the preset database; If there is a corresponding pre-stored user identifier, determining that the user is logged in; If there is no corresponding pre-stored user identifier, determining that the user is not logged in.

3. The method according to claim 1, wherein The if it is determined that the user is not logged in, determining whether the verification is passed based on the type of the service request includes; If it is determined that the user is not logged in, determining whether the type of the service request is a preset operation type; If it is determined that the type of the service request is a preset operation type, determining that the verification fails; If it is determined that the type of the service request is not a preset operation type, determining that the verification is passed.

4. The method according to claim 3, characterized in that, After the if it is determined that the type of the service request is a preset operation type, determining that the verification fails, the method further includes: Sending a login interface to the client so that the user can input an account password to log in.

5. The method according to claim 1, wherein The method further includes: In response to the pre-stored user identifier being inconsistent with the target user identifier, determining that the verification fails; Sending the verification result of the failed verification to the client; or modifying the target user identifier to the pre-stored user identifier and executing the service request.

6. The method according to claim 1, characterized in that, Before determining whether the token parameter exists in the preset database when it is determined that the service request includes a token parameter, the method further includes: Obtaining the client interface identifier corresponding to the service request; Determining whether the client interface identifier exists in a preset authorization list; If it exists in the preset authorization list, executing the service request; The determining whether the token parameter exists in the preset database when it is determined that the service request includes a token parameter includes: If it does not exist in the preset authorization list, when it is determined that the service request includes a token parameter, determining whether the token parameter exists in the preset database.

7. The method according to claim 1, wherein After receiving the service request sent by the client, the method further includes: When it is determined that the service request does not include a token parameter, generating the token parameter according to the service request.

8. The method according to claim 7, characterized in that The generating the token parameter according to the service request includes: If the service request includes a user identifier, generate the token parameter according to the service source identifier, the device number, and the user identifier, and store the token parameter, the service source identifier, the device number, and the user identifier in an associated manner; If the service request does not include a user identifier, generate the token parameter according to the service source identifier and the device number, and store the token parameter, the service source identifier, and the device number in an associated manner.

9. An authentication device, characterized in that, The device includes: A parameter situation determination module, configured to, in response to receiving a service request sent by a client, determine whether the token parameter exists in a preset database when it is determined that the service request includes the token parameter; A login situation determination module, configured to, if the token parameter exists in the preset database, determine whether the user has logged in according to the token parameter; A verification result determination module, configured to, if it is determined that the user has logged in, determine whether the pre-stored user identifier stored in the preset database for the token parameter is consistent with the target user identifier included in the service request, and determine that the verification is passed in response to the pre-stored user identifier being consistent with the target user identifier; The verification result determination module is further configured to, if it is determined that the user has not logged in, determine whether the verification is passed based on the type of the service request.

10. An authentication device, characterized in that, [[ID=X]]The device includes: a processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, Computer-executable instructions are stored in the computer-readable storage medium, and when the computer-executable instructions are executed by a processor, they are used to implement the method according to any one of claims 1-8.

12. A computer program product, including a computer program, which when executed by a processor implements the method according to any one of claims 1-8. It should be noted that in the original text, there is a possible error in the line . It seems to be a duplicate of another line with some incorrect "X" in it. I translated it as is based on the rules, but it might need to be corrected in the original content.

Images