Authentication method, authentication device, authentication system, equipment, medium and product

Abstract

The invention provides an authentication method, an authentication device, an authentication system, equipment, a medium and a product, which can be applied to the technical fields of Internet communication technology and information security. The authentication method comprises: in response to an access request received from a client for a target application, analyzing session information in the access request to obtain a version identifier, the session information being generated when an object logs in the target application through the client, and the version identifier representing a version of the target application deployed by the client; and authenticating the access request by using an authentication strategy corresponding to the version identifier to obtain an authentication result, and executing an operation matched with the authentication result.

Description

Technical Field

[0001] This disclosure relates to the fields of Internet communication technology and information security technology, and more specifically, to an authentication method, authentication device, authentication system, equipment, medium, and product. Background Technology

[0002] With the development of internet technology, various types of applications have emerged, and the interaction between users and these applications is increasing day by day. How to effectively ensure the security of users accessing applications is an urgent problem to be solved. Summary of the Invention

[0003] This disclosure provides an authentication method, authentication device, authentication system, equipment, medium, and product.

[0004] According to one aspect of this disclosure, an authentication method is provided, comprising: in response to receiving an access request for a target application from a client, parsing session information in the access request to obtain a version identifier, wherein the session information is generated when an object logs into the target application through the client, and the version identifier represents the version of the target application deployed by the client; and authenticating the access request using an authentication policy corresponding to the version identifier to obtain an authentication result, and performing an operation matching the authentication result.

[0005] According to another aspect of this disclosure, an authentication apparatus is provided, comprising: a parsing module, configured to, in response to receiving an access request from a client for a target application, parse session information in the access request to obtain a version identifier, wherein the session information is generated when an object logs into the target application through the client, and the version identifier represents the version of the target application deployed by the client; and an authentication module, configured to authenticate the access request using an authentication policy corresponding to the version identifier, obtain an authentication result, and perform an operation matching the authentication result.

[0006] According to another aspect of this disclosure, an authentication system is provided, comprising: a client for initiating an access request for a target application to a business server; and the business server for, in response to receiving the access request, parsing session information in the access request to obtain a version identifier, wherein the session information is generated when an object logs into the target application through the client, and the version identifier represents the version of the target application deployed by the client; authenticating the session information using an authentication policy corresponding to the version identifier to obtain an authentication result, and performing an operation matching the authentication result.

[0007] According to another aspect of this disclosure, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0008] According to another aspect of this disclosure, a computer-readable storage medium is provided that stores a computer program or instructions thereon, which, when executed by a processor, implement the steps of the above-described method.

[0009] According to another aspect of this disclosure, a computer program product is provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The above and other objects, features, and advantages of this disclosure will become clearer from the following description of embodiments of the present disclosure with reference to the accompanying drawings, in which:

[0012] Figure 1 This illustration schematically shows a system architecture to which authentication methods can be applied according to embodiments of the present disclosure;

[0013] Figure 2 A flowchart illustrating an authentication method according to an embodiment of this disclosure is shown schematically.

[0014] Figure 3 This illustration schematically shows an example diagram of a login process according to an embodiment of the present disclosure;

[0015] Figure 4 This illustration schematically shows an example diagram of an access process according to an embodiment of the present disclosure;

[0016] Figure 5 This illustration schematically shows an example diagram of an access process according to another embodiment of the present disclosure;

[0017] Figure 6 A block diagram schematically illustrates an authentication apparatus according to an embodiment of the present disclosure; and

[0018] Figure 7 A block diagram of an electronic device suitable for implementing an authentication method according to an embodiment of the present disclosure is shown schematically. Detailed Implementation

[0019] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0020] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0021] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0022] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0023] With the development of internet technology, multiple subdomains can be deployed under a single top-level domain. To achieve seamless switching between various services, single sign-on (SSO) technology can be used. After a user logs in to a service, a shared session with a scope of the top-level domain is generated. This shared session can be read and used by the respective services of all subdomains under that top-level domain, thereby maintaining the user's global login status.

[0024] However, in this shared session approach, since all services rely on the same session, if a service experiences a problem with its session due to insecure transmission channels, it can easily lead to a global spread of risk.

[0025] To address this, a new approach can be adopted: generating an independent session for each second-level domain's business, making it valid within a specific business domain. This way, even if a problem occurs in one business's independent session, it won't affect other businesses. However, in practical applications, relying on version information reported by the client to determine whether to apply the new approach is problematic because this version information can be forged. Forging lower version information can bypass the new solution's protection mechanism, thus rendering the security upgrade ineffective.

[0026] To address this, embodiments of this disclosure propose an authentication scheme. For example, in response to receiving an access request from a client for a target application, the session information in the access request is parsed to obtain a version identifier, wherein the session information is generated when the object logs into the target application through the client, and the version identifier represents the version of the target application deployed on the client; the access request is authenticated using an authentication policy corresponding to the version identifier to obtain an authentication result, and an operation matching the authentication result is performed.

[0027] According to embodiments of this disclosure, upon receiving an access request for a target application, since the session information in the access request is generated when the object logs into the target application through a client, there is no need for large-scale modifications to the client and business server. By parsing the version identifier in the session information, accurate differentiation of the target application version deployed on the client is achieved, thereby enabling dynamic allocation of corresponding authentication policies for access requests for different versions of the target application, improving the targeting of the authentication process and the accuracy of the authentication results.

[0028] The collection, storage, use, processing, transmission, provision, and disclosure of any type of information, such as user personal information, involved in the technical solution of this invention comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0029] In the technical solution of the present invention, the user's authorization or consent is obtained before acquiring or collecting the user's personal information.

[0030] Figure 1 The illustration schematically depicts a system architecture to which authentication methods can be applied according to embodiments of this disclosure. It should be noted that... Figure 1 The examples shown are merely examples of system architectures that can be applied to the embodiments of this disclosure, in order to help those skilled in the art understand the technical content of this disclosure, but do not mean that the embodiments of this disclosure cannot be used in other devices, systems, environments or scenarios.

[0031] like Figure 1As shown, the authentication system 100 according to this embodiment may include a client 110, a service server 120, an account server 130, and a network 140. The network 140 is used as a medium to provide a communication link between the client 110, the service server 120, and the account server 130. The network 140 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0032] Users can use client 110 to interact with business server 120 and account server 130 via network 140 to receive or send messages, etc. Various communication client applications can be installed on client 110, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only). For instance, client 110 can be various electronic devices with a display screen and web browsing support, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0033] The business server 120 and the account server 130 can be servers that provide various services, such as a backend management server that supports websites browsed by users using client 110 (for example only). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal device. The account server 130 can be a backend server cluster used to provide unified user authentication, session management, and verification services.

[0034] In embodiments of this disclosure, the authentication system 100 can be used to perform login and access processes.

[0035] In the login process, client 110 initiates a login request for the target application to account server 130. Account server 130, upon receiving the login request, determines whether the login request includes a target field, wherein the target field is added by the software development kit of the target version of the target application, and the target field is used to indicate that the target application deployed by client 110 is the target version; based on whether the login request includes the target field, it generates session information and sends the session information to client 110.

[0036] It should be noted that the login process in the authentication method provided in this embodiment can generally be executed by the account server 130. Correspondingly, the authentication device provided in this embodiment can generally be located in the account server 130. The login process in the authentication method provided in this embodiment can also be executed by a server or server cluster that is different from the account server 130 and can communicate with the client 110 and the business server 120. Correspondingly, the authentication device provided in this embodiment can also be located in a server or server cluster that is different from the account server 130 and can communicate with the client 110 and the business server 120.

[0037] In the access process, client 110 initiates an access request for the target application to business server 120. Business server 120, upon receiving the access request, parses the session information in the request to obtain a version identifier. The session information is generated when the object logs into the target application through the client, and the version identifier represents the version of the target application deployed by client 120. Using the authentication policy corresponding to the version identifier, the server authenticates the session information to obtain the authentication result, and then performs operations matching the authentication result.

[0038] It should be noted that the access process in the authentication method provided in this embodiment can generally be executed by the business server 120. Correspondingly, the authentication device provided in this embodiment can generally be located in the business server 120. The access process in the authentication method provided in this embodiment can also be executed by a server or server cluster that is different from the business server 120 and can communicate with the client 110 and the account server 130. Correspondingly, the authentication device provided in this embodiment can also be located in a server or server cluster that is different from the business server 120 and can communicate with the client 110 and the account server 130.

[0039] It should be understood that Figure 1 The number of clients, business servers, account servers, and networks shown is merely illustrative. Depending on implementation needs, any number of clients, business servers, account servers, and networks can be included.

[0040] It should be noted that the sequence numbers of the operations in the following methods are for descriptive purposes only and should not be considered as indicating the execution order of the operations. Unless explicitly stated otherwise, the method does not need to be executed in the exact order shown.

[0041] The system architecture of the authentication system provided in this disclosure has been described above. The following will use... Figure 2 The authentication process of this disclosure is further illustrated as an example.

[0042] Figure 2A flowchart illustrating an authentication method according to an embodiment of this disclosure is shown schematically.

[0043] like Figure 2 As shown, the authentication method 200 may include operations S210 to S220.

[0044] In operation S210, in response to receiving an access request from a client for the target application, the session information in the access request is parsed to obtain a version identifier. The session information is generated when the object logs into the target application through the client, and the version identifier represents the version of the target application deployed by the client.

[0045] In operation S220, the access request is authenticated using the authentication policy corresponding to the version identifier, and the authentication result is obtained in order to perform the operation that matches the authentication result.

[0046] In embodiments of this disclosure, the object's consent or authorization can be obtained before acquiring session information. For example, a request to acquire session information can be sent to the object before operation S210. If the object consents or authorizes the acquisition of session information, operation S210 is executed.

[0047] A client is the terminal used by a user to access the target application. For example, a client can be a browser (i.e., a web application) or a mobile application (i.e., an app application). The target application is a specific application under a top-level domain. For example, a top-level domain can host multiple applications such as maps, cloud storage, and social networking.

[0048] An access request is initiated by an object from a client to a business server. The type of access request can match the type of the target application. For example, if the target application is a map application, the access request could be a ride-hailing request initiated by the object in the map application on the app side; alternatively, if the target application is a cloud storage application, the access request could be a resource download request initiated by the object in the cloud storage application on the web side, etc., without further limitation.

[0049] The access request can include the object identifier of the object that initiated the access request. After receiving the access request, the object identifier can be used to verify whether the object is logged in. If the object is logged in, the session information (i.e., cookies) generated when the object logs into the target application through the client can be parsed to extract the version identifier; if the object is not logged in, the client can be prompted to log in.

[0050] Version identifiers can represent the version of the target application deployed on the client. Since the specific content of the session information generated when logging into the target application through the client may be different for different versions of the target application, different authentication strategies are required.

[0051] For example, for a target application, taking version 1 as the latest version, when an object logs in to the target application of this version, a shared session under the first-level domain and an independent session under the second-level domain for the target application can be generated. Therefore, the authentication strategy corresponding to version 1 can be to perform joint authentication on the shared session and the independent session.

[0052] Alternatively, for the same target application, taking version identifier 2 as an example other than the latest version, when the object logs in to the target application of this version, a shared session under the first-level domain can be generated. Therefore, the authentication policy corresponding to version identifier 2 can be the authentication of the shared session.

[0053] After obtaining the authentication result, operations matching the authentication result can be executed. For example, if the authentication result indicates successful authentication, the business logic of the access request can be executed, such as processing a ride-hailing request, querying the current address of the object and returning vehicle information, etc. Alternatively, if the authentication result indicates failed authentication, a prompt message indicating the reason for the failure can be output, such as shared session authentication failed, independent session authentication failed, etc.

[0054] In the embodiments of this disclosure, upon receiving an access request for a target application, since the session information in the access request is generated when the object logs into the target application through a client, there is no need for large-scale modifications to the client and business server. By parsing the version identifier in the session information, accurate differentiation of the target application version deployed on the client is achieved, thereby enabling dynamic allocation of corresponding authentication policies for access requests for different versions of the target application, improving the targeting of the authentication process and the accuracy of the authentication results.

[0055] According to embodiments of this disclosure, session information may be generated in the following manner: in response to receiving a login request from a client for a target application, determining whether the login request includes a target field, wherein the target field is added by the software development kit of the target version of the target application, and the target field is used to indicate that the target application deployed by the client is the target version; and generating session information based on whether the login request includes the target field.

[0056] Target fields are specific fields carried in a login request. Their presence or absence can be used to determine whether the target application integrated by the client is a target version that supports the new security mechanism. For example, after an object initiates a login request through a client that has deployed the target version of the target application, the software development kit (SDK) for that target version can automatically add target fields to the login request. The login request can be a username and password verification request for the object.

[0057] The specific format and placement of the target field can be configured according to actual business needs and are not limited here. For example, taking the target field as a key-value pair, the target version of the software development kit can automatically add the key-value pair to the URL parameters or request body of the login request. For example, the key-value pair could be "newVersion=1". Alternatively, taking the target field as a header field, the target version of the software development kit can automatically add the header field to the request header of the login request.

[0058] After receiving a login request, the account server can determine whether the target field exists in the login request. The method for determining the target field can be configured according to actual business needs and is not limited here. For example, it can check whether a specific key-value pair exists in the URL parameters or request body of the login request; alternatively, it can check whether a specific header field exists in the request header of the login request.

[0059] After determining whether the login request contains the target field, different logic can be used to generate session information. For example, if the target field is included, both a shared session and a separate session can be generated simultaneously; if the target field is not included, only a shared session can be generated, and so on. No restrictions are imposed here.

[0060] During the generation of session information, different version identifiers can be set for the session information based on whether the login request contains the target field; alternatively, session information with different validity periods or encryption strengths can also be generated to match the security requirements and upgrade expectations of different versions.

[0061] In the embodiments of this disclosure, since the target field is automatically added by the target version of the software development kit, more accurate client version identification is achieved by determining whether the login request includes the target field, thereby adaptively generating differentiated session information and laying a data foundation for subsequent real-time differentiated authentication measurement.

[0062] According to embodiments of this disclosure, session information may include at least one of a shared session and a separate session for a target application.

[0063] A shared session can be a session shared by various applications under a top-level domain. All second-level domains under the same top-level domain can access and carry this shared session to achieve single sign-on across applications. For example, taking a web client as an example, after an object logs in to map.xx.com, the account server can generate a shared session for the top-level domain .xx.com. Subsequently, when the object accesses pan.xx.com, the web client can automatically carry this shared session.

[0064] A standalone session can be a session associated with a subdomain corresponding to the target application and used exclusively for that application. For example, again taking a web client as an example, after an object logs in to map.xx.com, the account server can generate a standalone session 1 dedicated to that application. Subsequently, when the object accesses pan.xx.com, it cannot use standalone session 1.

[0065] According to embodiments of this disclosure, generating session information based on whether the login request contains a target field may include: if the login request contains a target field, generating a shared session and an independent session using a first identifier as a version identifier; if the login request does not contain a target field, generating a shared session using a second identifier as a version identifier.

[0066] If the login request includes a target field, indicating that the target application deployed on the client is the target version, a shared session (i.e., C_Share) can be generated using the first identifier as the version identifier. This means the first identifier is written into the shared session as a flag to distinguish the target version. Simultaneously, an independent session (i.e., C_Unique) under the corresponding target application's second-level domain can be generated. For example, the first identifier can be 1, meaning the version identifier is_new_version = 1.

[0067] If the login request does not include the target field, it indicates that the target application deployed on the client is not the target version. In this case, a shared session (i.e., C_Share) can be generated using the second identifier as the version identifier. That is, the second identifier is written into the shared session to serve as a flag to distinguish non-target versions. For example, the second identifier can be 0, i.e., the version identifier is_new_version=0.

[0068] In the embodiments of this disclosure, by differentially generating shared sessions and independent sessions carrying a first identifier, or only generating shared sessions carrying a second identifier, based on whether the login request contains a target field, precise matching between security policies and client capabilities is achieved. This means that for clients upgraded to the target version, attackers cannot directly use shared sessions to access applications protected by independent sessions, thus achieving risk isolation and security enhancement. For clients not upgraded to the target version, this ensures seamless and continuous access and a smooth experience for existing users. Furthermore, this method of embedding the version identifier within the shared session provides a basis for allocating authentication policies in subsequent request processing, thereby contributing to improved access security.

[0069] The authentication method provided in this disclosure has been explained above. The following will use... Figure 3 As an example, the login process of the authentication method provided in this disclosure will be further explained.

[0070] Figure 3The illustration shows an example diagram of a login process according to an embodiment of the present disclosure.

[0071] like Figure 3 As shown, in embodiment 300 of the login process, operations S301 to S306 may be included.

[0072] When operating S301, the client can send a login request for the target application to the account server.

[0073] When operating S302, the account server can determine whether the login request includes the target field.

[0074] If the login request does not contain a target field, the account server can generate session information using operations S303 and S304. In operation S303, the account server can generate shared and independent sessions using a first identifier as the version identifier. In operation S304, the account server can send the shared and independent sessions to the client.

[0075] If the login request does not contain the target field, the account server can generate session information through operations S305 and S306. In operation S305, the account server can generate a shared session using the second identifier as the version identifier. In operation S306, the account server can send the shared session to the client.

[0076] According to an embodiment of this disclosure, operation S220 may include the following operations: when the version identifier is a first identifier, a first sub-policy is executed on the session information to obtain an authentication result, wherein the first sub-policy is used to authenticate access requests from the target version; when the version identifier is a second identifier, a second sub-policy is executed on the session information to obtain an authentication result, wherein the second sub-policy is used to authenticate access requests from non-target versions.

[0077] If the version identifier parsed from the session information is the first identifier, it indicates that the target application deployed on the client is the target version. For example, if the first identifier is 1, and the parsed version identifier is_new_version=1, it means that the target application deployed on the client is the target version. For access requests from the target version of the target application, a first sub-policy can be executed. The first sub-policy may include a set of verification rules for authenticating access requests from clients using the target version.

[0078] If the version identifier parsed from the session information matches the second identifier, it indicates that the target application deployed by the client is a non-target version. For example, if the second identifier is 0, and the parsed version identifier is_new_version=0, it means the target application deployed by the client is a non-target version. For access requests from non-target versions of the target application, a second sub-policy can be executed. The second sub-policy may include a set of verification rules for authenticating access requests from non-target version clients.

[0079] It should be noted that since the first sub-policy applies to the target version and the second sub-policy applies to non-target versions, the first sub-policy has a higher verification strength than the second sub-policy. For example, the first sub-policy may include combined authentication for shared sessions and independent sessions, while the second sub-policy may include authentication for shared sessions. Alternatively, in addition to authenticating session information, the first sub-policy may also require additional signatures for key request parameters, or supplementary authentication by combining access frequency and geographical location.

[0080] In the embodiments of this disclosure, by defining differentiated sub-policies corresponding to version identifiers, the first sub-policy is executed for requests from the target version carrying the first identifier, which enables application-level session isolation for upgraded clients; the second sub-policy is executed for requests from non-target versions carrying the second identifier, which does not affect the compatibility of older versions and user experience. This divide-and-conquer authentication method can dynamically allocate corresponding authentication policies for access requests from target applications of different versions, improving the targeting of the authentication process and the accuracy of the authentication results.

[0081] According to embodiments of this disclosure, session information may include shared sessions and independent sessions; executing a first sub-policy on the session information to obtain an authentication result may include: sending the shared sessions and independent sessions to an account server to use the account server to perform validity verification on the shared sessions and independent sessions respectively, and obtaining a first verification result; if the first verification result indicates that the validity verification is passed, performing consistency verification on the shared sessions and independent sessions to obtain an authentication result.

[0082] After receiving shared and independent sessions from clients, the business server can forward them to a dedicated account server for centralized validity verification. Validity verification refers to the process of checking whether shared and independent sessions are legitimate, not expired, and not tampered with. Validity verification may include decryption, expiration verification, and status verification.

[0083] For example, for a shared session, after receiving the shared session, the account server can decrypt it using a pre-stored key to obtain the decrypted shared session. Based on this, it can check whether the timestamp in the decrypted shared session is within its validity period and query the database based on the session ID to confirm whether the session is still active. If all checks pass, the shared session has passed validity verification. The verification method for independent sessions is similar and will not be elaborated here. The verification processes for shared and independent sessions can be executed sequentially or in parallel, without limitation.

[0084] After obtaining the verification results of the shared session and the independent session, the first verification result can be determined. That is, if both the shared session and the independent session pass the validity verification, the first verification result indicating that the validity verification has passed can be determined; if there is a session in the shared session and the independent session that fails the validity verification, the first verification result indicating that the validity verification has failed can be determined.

[0085] After confirming that both the shared session and the independent session have passed the validity verification, a consistency verification can be performed on both. The consistency verification verifies whether the two logically belong to the same login session, the same object, and the corresponding correct business relationship, thereby preventing session splicing attacks. This can prevent problems from occurring in the shared sessions of other applications under the same top-level domain, which could affect the access security of the target application.

[0086] For example, it can verify whether the object identifiers in shared sessions and independent sessions are the same, or it can verify whether the domain names associated with shared sessions and independent sessions match the current target application.

[0087] In the embodiments of this disclosure, by sending session information to the account server for centralized verification, the authentication logic is decoupled and professionalized, ensuring the consistency of verification rules and the security of key management, and avoiding potential security vulnerabilities caused by duplicate implementations on various business servers. Based on this, a progressive verification process of first validating and then confirming consistency is adopted. First, validating sessions quickly filters out forged, expired, or invalid sessions, improving processing efficiency and attack resistance. Then, confirming consistency is performed under the premise that both shared and independent sessions are valid, logically ensuring that both originate from the same login and are applicable to the target application. This means that session security no longer depends on the confidentiality of the session but on the internal consistency of the session combination, thereby enhancing the reliability of the authentication process.

[0088] The login process in the authentication method provided in this disclosure has been described above. The following will use... Figure 4 As an example, the access flow of the authentication method provided in one embodiment of this disclosure will be further explained.

[0089] Figure 4 The illustration shows an example diagram of an access process according to an embodiment of the present disclosure.

[0090] like Figure 4 As shown, in embodiment 400 of the access process, operations S401 to S409 may be included.

[0091] When operating S401, the client can send an access request for the target application to the business server.

[0092] When operating S402, the business server can parse the session information in the access request to obtain the version identifier.

[0093] When the version identifier is the first identifier, authentication results can be obtained through operations S403 to S406. In operation S403, the business server can send the shared session and the independent session to the account server. In operation S404, the account server can perform validity verification on the shared session and the independent session respectively, obtaining the first verification result. In operation S405, the account server can send the first verification result to the business server. In operation S406, the business server can perform consistency verification on the shared session and the independent session, obtaining the authentication result.

[0094] After obtaining the authentication result, you can perform the operation that matches the authentication result through operation 407 to operation S409.

[0095] For example, if the authentication result indicates that the access request has passed authentication, operations S407 and S408 can be executed. In operation S407, the business server can process the pending information in the access request and obtain the processing result; in operation S408, the business server can send the processing result to the client.

[0096] Alternatively, if the authentication result indicates that the access request failed, operation S409 can be executed. In operation S409, the service server can send a notification message to the client.

[0097] According to embodiments of this disclosure, session information may include a shared session, which may include a login source identifier (i.e., login_from). The login source identifier is a data field recorded in the shared session, used to indicate the application when the client initiates the login request. This login source identifier may be determined and written by the account server based on the source of the login request when logging into the application. For example, when a user logs into a map application, the shared session generated by the account server may contain a "map" field, which is the login source identifier.

[0098] According to embodiments of this disclosure, executing a second sub-policy on session information to obtain an authentication result may include: sending the shared session to an account server to verify the validity of the shared session using the account server, thereby obtaining a second verification result; and, if the second verification result indicates that the validity verification is successful, matching the login source identifier with the identifier of the target application to obtain an authentication result.

[0099] After receiving a shared session from the client, the business server can forward the session to a dedicated account server for centralized validity verification. The specific verification process is described above and will not be repeated here. Once the shared session passes validity verification, the login source identifier can be further matched with the target application identifier. The target application identifier is the identifier of the target application corresponding to the current access request.

[0100] For example, if the login source identifier is "map", and the object is currently accessing a cloud storage application, the identifier of the target application is "drive". Since the two do not match, the authentication result can be determined as failed. If the object is currently accessing a map application, the identifier of the target application is "map". Since the two match, the authentication result can be determined as failed.

[0101] It's important to note that the matching between the login source identifier and the target application's identifier can be either exact or fuzzy. An exact match is considered a match if both are completely identical. A fuzzy match involves pre-configuring a list of authorized identifiers for each login source identifier, signing it, and returning it with the verification result. The business server can then check if its own identifier is in the identifier list to determine if a match has been found.

[0102] In the embodiments of this disclosure, by sending the shared session containing the login source identifier to the account server for validity verification, the authenticity and tamper-proof nature of the shared session, which serves as the basis for authentication, are ensured. Furthermore, by matching the verified login source identifier with the target application identifier, the risk of lateral permission diffusion caused by problems with the shared session in a particular application is effectively curbed. This ensures the access experience of existing users without forcing an upgrade and improves the overall security of the old version's access link.

[0103] The access process in the authentication method provided by an embodiment of this disclosure has been described above. The following will use... Figure 5 As an example, the access flow of the authentication method provided in another embodiment of this disclosure will be further described.

[0104] Figure 5 An example schematic diagram of an access process according to another embodiment of the present disclosure is shown.

[0105] like Figure 5 As shown, in embodiment 500 of the access process, operations S501 to S509 may be included.

[0106] When operating S501, the client can send an access request for the target application to the business server.

[0107] When operating S502, the business server can parse the session information in the access request to obtain the version identifier.

[0108] When the version identifier is the second identifier, authentication results can be obtained through operations S503 to S506. In operation S503, the business server can send the shared session to the account server. In operation S504, the account server can verify the validity of the shared session and obtain a second verification result. In operation S505, the account server can send the second verification result to the business server. In operation S506, the business server can match the login source identifier with the target application's identifier to obtain the authentication result.

[0109] After obtaining the authentication result, you can perform the operation that matches the authentication result through operation 507 to operation S509.

[0110] For example, if the authentication result indicates that the access request has passed authentication, operations S507 and S508 can be executed. In operation S507, the business server can process the pending information in the access request and obtain the processing result; in operation S508, the business server can send the processing result to the client.

[0111] Alternatively, if the authentication result indicates that the access request failed, operation S509 can be executed. In operation S509, the service server can send a notification message to the client.

[0112] According to embodiments of this disclosure, performing operations matching the authentication result may include: if the authentication result is that the access request has passed authentication, processing the pending information in the access request to obtain a processing result; and sending the processing result to the client; if the authentication result is that the access request has failed authentication, sending a prompt message to the client, wherein the prompt message indicates the reason for the authentication failure.

[0113] Pending information refers to the data or instructions that a client carries in its access request, which it hopes the service server will perform on its behalf for a specific operation. For example, if the target application is a map application and the access request is a ride-hailing request, the pending information may include the departure point, destination, and vehicle type preference; if the target application is a map application and the access request is an order query request, the pending information might simply be an order number.

[0114] If the authentication result indicates that the access request has passed, the core business logic can begin execution. The processing result refers to the feedback data or status generated by the business server after executing the corresponding business logic based on the information to be processed. For example, for a ride-hailing request, after the request is authenticated, the business server can invoke a scheduling algorithm to match it with nearby vehicles and obtain the processing result. For instance, the processing result could be a confirmation message "Call successful, driver expected to arrive in 5 minutes" along with the driver's license plate number.

[0115] If the authentication result is that the access request failed, a message explaining the reason for the authentication failure can be sent to the client. The reason for authentication failure refers to the specific category of reasons that led to the authentication failure. For example, reasons may include "invalid shared session", "invalid independent session", "inconsistency between shared session and independent session", "login source identifier does not match the representation of the current target application", etc.

[0116] In the embodiments of this disclosure, when an access request is successfully authenticated, the pending information is processed and a result is returned, ensuring that legitimate users' requests can seamlessly and smoothly obtain the expected service response, thus guaranteeing the continuity of core business processes and the integrity of the user experience. When an access request fails authentication, a prompt message with a clear reason is sent to the client, enabling the client to intelligently adopt differentiated recovery strategies based on different failure types. This helps to quickly locate the problem and improves the maintainability of the authentication process.

[0117] The above are merely exemplary embodiments, but are not limited thereto. Other authentication methods known in the art may also be included, as long as they can improve the targeting of the authentication process and the accuracy of the authentication results.

[0118] Based on the above authentication method, the present invention also provides an authentication device. The following will be combined with... Figure 6 The device is described in detail.

[0119] Figure 6 A block diagram of an authentication device according to an embodiment of the present disclosure is shown schematically.

[0120] like Figure 6 As shown, the authentication device 600 may include a parsing module 610 and an authentication module 620.

[0121] The parsing module 610 is used to respond to an access request from a client for a target application, parse the session information in the access request, and obtain a version identifier. The session information is generated when the object logs into the target application through the client, and the version identifier represents the version of the target application deployed by the client.

[0122] The authentication module 620 is used to authenticate access requests using an authentication policy corresponding to the version identifier, obtain authentication results, and perform operations that match the authentication results.

[0123] According to embodiments of this disclosure, session information is generated as follows: in response to receiving a login request from a client for a target application, determining whether the login request includes a target field, wherein the target field is added by the software development kit of the target version of the target application, and the target field is used to indicate that the target application deployed by the client is the target version; and generating session information based on whether the login request includes the target field.

[0124] According to embodiments of this disclosure, the session information includes at least one of a shared session and an independent session for the target application. The shared session is a session shared by various applications under a first-level domain, and the independent session is a session associated with a second-level domain corresponding to the target application and used for the target application. The session information is generated based on whether the login request contains a target field, including: if the login request contains a target field, using a first identifier as a version identifier to generate a shared session and an independent session; if the login request does not contain a target field, using a second identifier as a version identifier to generate a shared session.

[0125] According to embodiments of this disclosure, the authentication module 620 may include a first authentication submodule and a second authentication submodule.

[0126] The first authentication submodule is used to execute the first sub-policy on the session information when the version identifier is the first identifier, and obtain the authentication result. The first sub-policy is used to authenticate access requests from the target version.

[0127] The second authentication submodule is used to execute the second sub-policy on the session information when the version identifier is the second identifier, and obtain the authentication result. The second sub-policy is used to authenticate access requests from non-target versions.

[0128] According to embodiments of this disclosure, session information includes shared sessions and independent sessions; the first authentication submodule may include a first verification unit and a second verification unit.

[0129] The first verification unit is used to send the shared session and the independent session to the account server so that the account server can perform validity verification on the shared session and the independent session respectively to obtain the first verification result.

[0130] The second verification unit is used to perform consistency verification on shared sessions and independent sessions, and obtain authentication results, provided that the validity verification of the first verification result characterization has passed.

[0131] According to embodiments of this disclosure, the session information includes a shared session, which includes a login source identifier used to indicate the application when the client initiates the login request; the second authentication submodule may include a third verification unit and a matching unit.

[0132] The third verification unit is used to send the shared session to the account server so that the account server can verify the validity of the shared session and obtain the second verification result.

[0133] The matching unit is used to match the login source identifier with the identifier of the target application to obtain the authentication result if the second verification result characterizes the validity verification as passed.

[0134] According to embodiments of this disclosure, the authentication device 600 may further include a processing module, a first sending module, and a second sending module.

[0135] The processing module is used to process the pending information in the access request if the authentication result is that the access request has passed authentication, and obtain the processing result. The first sending module is used to send the processing result to the client.

[0136] The second sending module is used to send a prompt message to the client when the authentication result is that the access request has failed. The prompt message indicates the reason for the authentication failure.

[0137] Figure 7 A block diagram schematically illustrates an electronic device suitable for implementing an authentication method according to embodiments of the present disclosure. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0138] like Figure 7 As shown, device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 702 or a computer program loaded from storage unit 707 into random access memory (RAM) 703. RAM 703 may also store various programs and data required for the operation of device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0139] Multiple components in device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of monitors, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0140] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as authentication methods. For example, in some embodiments, the authentication method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the authentication method described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform authentication methods by any other suitable means (e.g., by means of firmware).

[0141] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0142] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0143] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, 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 machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0144] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0145] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0146] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, distributed system servers, or servers incorporating blockchain technology.

[0147] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0148] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. 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 spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. An authentication method, comprising: In response to receiving an access request for a target application from a client, the session information in the access request is parsed to obtain a version identifier, wherein the session information is generated when the object logs into the target application through the client, and the version identifier represents the version of the target application deployed by the client; and The access request is authenticated using the authentication policy corresponding to the version identifier to obtain the authentication result, and then an operation matching the authentication result is performed.

2. The method according to claim 1, wherein, The session information is generated in the following way: In response to receiving a login request from the client for the target application, determine whether the login request includes a target field, wherein the target field is added by the software development kit of the target version of the target application, and the target field is used to indicate that the target application deployed by the client is the target version; and The session information is generated based on whether the login request contains the target field.

3. The method according to claim 2, wherein, The session information includes at least one of a shared session and an independent session for the target application. The shared session is a session shared by various applications under a first-level domain, and the independent session is a session associated with a second-level domain corresponding to the target application and used for the target application. The step of generating the session information based on whether the login request contains the target field includes: If the login request contains the target field, the shared session and the independent session are generated using the first identifier as the version identifier; as well as If the login request does not contain the target field, the shared session is generated using the second identifier as the version identifier.

4. The method according to any one of claims 1 to 3, wherein, The step of authenticating the access request using the authentication policy corresponding to the version identifier and obtaining the authentication result includes: If the version identifier is a first identifier, a first sub-policy is executed on the session information to obtain the authentication result, wherein the first sub-policy is used to authenticate the access request from the target version; and If the version identifier is the second identifier, the second sub-policy is executed on the session information to obtain the authentication result, wherein the second sub-policy is used to authenticate the access request from a non-target version.

5. The method according to claim 4, wherein, The session information includes shared sessions and independent sessions; The step of executing the first sub-policy on the session information to obtain the authentication result includes: The shared session and the independent session are sent to the account server so that the account server can perform validity verification on the shared session and the independent session respectively to obtain a first verification result; as well as If the validity verification of the first verification result is passed, the consistency verification of the shared session and the independent session is performed to obtain the authentication result.

6. The method according to claim 4, wherein, The session information includes a shared session, which includes a login source identifier, used to indicate the application when the client initiates the login request; The step of executing the second sub-policy on the session information to obtain the authentication result includes: The shared session is sent to the account server so that the account server can verify the validity of the shared session and obtain a second verification result; as well as If the second verification result indicates that the validity verification is successful, the login source identifier is matched with the identifier of the target application to obtain the authentication result.

7. The method according to any one of claims 1 to 6, wherein, The operation that matches the authentication result includes: If the authentication result indicates that the access request has passed authentication, the pending information in the access request is processed to obtain a processing result; and the processing result is sent to the client. If the authentication result indicates that the access request has failed authentication, a prompt message is sent to the client, wherein the prompt message indicates the reason for the authentication failure.

8. An authentication device, comprising: A parsing module is used to respond to a received access request from a client for a target application, parse the session information in the access request, and obtain a version identifier, wherein the session information is generated when the object logs into the target application through the client, and the version identifier represents the version of the target application deployed by the client; and The authentication module is used to authenticate the access request using an authentication policy corresponding to the version identifier, obtain an authentication result, and perform an operation matching the authentication result.

9. An authentication system, comprising: The client is used to initiate access requests for the target application to the business server; as well as The business server is used to respond to the received access request by parsing the session information in the access request to obtain a version identifier, wherein the session information is generated when the object logs into the target application through the client, and the version identifier represents the version of the target application deployed by the client; The session information is authenticated using the authentication policy corresponding to the version identifier to obtain the authentication result, and then an operation matching the authentication result is performed.

10. The system according to claim 9, further comprising: Account server; The client is also used to initiate a login request for the target application to the account server; as well as The account server is configured to, in response to receiving the login request, determine whether the login request includes a target field, wherein the target field is added by the software development kit of the target version of the target application, and the target field is used to indicate that the target application deployed on the client is the target version; generate the session information based on whether the login request includes the target field; and send the session information to the client.

11. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

12. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

13. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images