Login verification method and device, electronic equipment and storage medium

Abstract

This application provides a login verification method, apparatus, electronic device, computer-readable storage medium, and product, relating to the field of Internet technology. The method includes: sending a first login request to a first server of a first application; receiving a verification instruction sent by the first server; displaying a login verification interface; and, in response to receiving a selection operation for verification options of the associated application, sending an authorization verification request to a second server of the associated application through a client of the associated application, thereby triggering the second server to send the current login account of the associated application to the first server, so that the first server can perform login verification based on the current login account and associated login accounts in a target mapping relationship stored in the first server. This application solves the problem of being unable to log in to applications in scenarios where security verification cannot be performed using older devices or where it is inconvenient to request assistance from others for verification.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and more specifically, to a login verification method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] For applications with high security requirements, a series of device trust verification steps are typically required when a user attempts to log in on a new device for the first time. These verifications may include scanning a QR code on another device, requesting assistance from someone else, or performing real-name authentication via facial recognition. Through these measures, applications can effectively prevent unauthorized device logins, thereby ensuring the security of user accounts.

[0003] However, in some situations, users may face difficulties in completing trust verification. For example, if a user's device is damaged or lost, their account is not yet verified, and they cannot contact others to assist with verification, they may be unable to log in to the application through the normal verification process. This can prevent them from accessing important data or continuing their work, impacting daily use and workflow. Especially when urgently needing to access their account, the current login verification mechanism can cause significant inconvenience and even serious work delays and efficiency losses. Summary of the Invention

[0004] This application provides a login verification method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can solve the problem that existing login verification methods cannot log in to trusted devices. The technical solution is as follows: According to a first aspect of the embodiments of this application, a login verification method is provided, which is executed by a client of a first application running in a terminal, including: Send a first login request to the first server of the first application, the first login request including the first login account of the first application and the first terminal identifier of the terminal; The system receives a verification command sent by the first server and displays a login verification interface. The verification command is sent by the first server when it determines that the first terminal identifier and the target terminal identifier are different. The target terminal identifier is a terminal identifier stored in the first server that corresponds to the first login account. The login verification interface displays login verification options, including associated application verification options based on the associated applications of the first application. In response to receiving a selection operation for the verification option of the associated application, an authorization verification request is sent from the client of the associated application to the second server of the associated application, so as to trigger the second server to send the current login account of the associated application to the first server, so that the first server can perform login verification based on the current login account and the associated login account in the target mapping relationship stored in the first server; The target mapping relationship is the correspondence between the first login account and the associated login account, and the associated login account is the login account of the associated application used when binding the login operation of the associated application with the first application.

[0005] According to a second aspect of the embodiments of this application, a login verification method is provided, executed by a first server of a first application, the method comprising: The receiving terminal sends a first login request through the client of the first application, the first login request including the first login account of the first application and the first terminal identifier of the terminal; If the first terminal identifier is different from the target terminal identifier, a verification instruction is sent to the client of the first application. The target terminal identifier is the terminal identifier stored in the first server that corresponds to the first login account. The verification instruction is used to trigger the client of the first application to display a login verification interface that includes login verification options. The login verification options include associated application verification options based on the associated applications of the first application. The system receives the current login account of the associated application from the second server of the associated application. The current login account is sent by the second server to the first server after receiving an authorization verification request from the client of the associated application. The authorization verification request is sent by the client of the first application to the second server in response to receiving a selection operation for the verification option of the associated application. Login verification is performed based on the current login account and the target mapping relationship stored in the first server. The target mapping relationship is the correspondence between the first login account and the associated login account. The associated login account is the login account of the associated application used when binding the login operation of the associated application with the login operation of the first application.

[0006] According to a third aspect of the embodiments of this application, a login verification method is provided, the method comprising: The client of the first application running on the terminal sends a first login request to the first server of the first application. The first login request includes the first login account of the first application and the first terminal identifier of the terminal. The first server receives the first login request and, if the first terminal identifier is different from the target terminal identifier, sends a verification instruction to the client of the first application. The target terminal identifier is the terminal identifier stored in the first server that corresponds to the first login account. When the client of the first application receives the verification instruction sent by the first server, it displays a login verification interface, wherein the login verification interface displays login verification options, including associated application verification options based on the associated applications of the first application; When the client of the first application receives a selection operation for the verification option of the associated application, it sends an authorization verification request to the second server of the associated application through the client of the associated application running on the terminal. The second server receives the authorization verification request and, based on the authorization verification request, sends the current login account of the associated application to the first server; The first server receives the current login account sent by the second server and performs login verification based on the current login account and the associated login account in the target mapping relationship stored in the first server; The target mapping relationship is the correspondence between the first login account and the associated login account, and the associated login account is the login account of the associated application used when binding the login operation of the associated application with the first application.

[0007] According to a fourth aspect of the embodiments of this application, a login verification device is provided, which is applied to a client of a first application running in a terminal, the device comprising: The module for sending a first login request is used to send a first login request to the first server of the first application. The first login request includes the first login account of the first application and the first terminal identifier of the terminal. The verification instruction receiving module is used to receive a verification instruction sent by the first server and display a login verification interface. The verification instruction is sent by the first server when it is determined that the first terminal identifier and the target terminal identifier are different. The target terminal identifier is a terminal identifier stored in the first server that corresponds to the first login account. The login verification interface displays login verification options, including associated application verification options based on the associated applications of the first application. The response selection operation module is used to respond to receiving a selection operation for the verification option of the associated application, and to send an authorization verification request to the second server of the associated application through the client of the associated application, so as to trigger the second server to send the current login account of the associated application to the first server, so that the first server can perform login verification based on the current login account and the associated login account in the target mapping relationship stored in the first server; wherein, the target mapping relationship is the correspondence between the first login account and the associated login account, and the associated login account is the login account of the associated application used when binding the login operation of the associated application with the first application.

[0008] According to a fifth aspect of the embodiments of this application, a login verification device is provided, the device being applied to a first server of a first application, the device comprising: The module for receiving a first login request is configured to receive a first login request sent by the terminal through the client of the first application, wherein the first login request includes the first login account of the first application and the first terminal identifier of the terminal; The verification instruction sending module is used to send a verification instruction to the client of the first application when the first terminal identifier is different from the target terminal identifier. The target terminal identifier is a terminal identifier stored in the first server that corresponds to the first login account. The verification instruction is used to trigger the client of the first application to display a login verification interface that includes login verification options. The login verification options include associated application verification options based on the associated applications of the first application. The login account receiving module is used to receive the current login account of the associated application sent by the second server of the associated application. The current login account is sent by the second server to the first server after receiving an authorization verification request sent by the client of the associated application. The authorization verification request is sent by the client of the first application to the second server in response to receiving a selection operation for the verification option of the associated application. The verification module is used to perform login verification based on the current login account and the target mapping relationship stored in the first server. The target mapping relationship is the correspondence between the first login account and the associated login account. The associated login account is the login account of the associated application used when binding the login operation of the associated application with the login operation of the first application.

[0009] According to a sixth aspect of the embodiments of this application, an electronic device is provided, the electronic device including a memory, a processor and a computer program stored in the memory, wherein the processor executes the program to implement the steps of the methods provided in the first and second aspects.

[0010] According to a sixth aspect of the embodiments of this application, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps of the methods provided in the first, second, and third aspects.

[0011] According to a seventh aspect of the present application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium, wherein when a processor of a computer device reads the computer instructions from the computer-readable storage medium, the processor executes the computer instructions, causing the computer device to perform steps implementing the methods provided as in the first, second, and third aspects.

[0012] The beneficial effects of the technical solution provided in this application embodiment are as follows: By sending a first login request to the first server of the first application, the first server determines whether the terminal corresponding to the first terminal identifier is a terminal that has already logged into the first application through the first login account, based on the first login account and the first terminal identifier in the first login request. When the terminal is logging into the first application for the first time through the first login account, the first server sends a verification command to the client of the first application, that is, performs security verification on the terminal device. After receiving the verification command, the client of the first application displays a login verification interface, which includes login verification options. In this application embodiment, the login verification options include verification options for associated applications, so that security verification can be performed through associated applications of the first application already logged in on the terminal.

[0013] In this embodiment, by establishing a correspondence between a first login account and an associated login account, when a user clicks the associated application verification option, the client of the first application sends an authorization verification request to the second server of the associated application through the client of the associated application. The second server then sends the current login account of the associated application to the client of the first application, allowing the first server to determine the current login account of the associated application and complete the login verification. This embodiment provides a new login verification scheme that, by binding the first login account of the first application with the associated login account of the associated application, enables cross-application login verification when logging into the first application for the first time on a new device, avoiding the problem of login failure due to device changes. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0015] Figure 1 This is a schematic diagram of the system architecture for implementing the login verification method provided in the embodiments of this application; Figure 2 A flowchart illustrating a login verification method provided in an embodiment of this application; Figure 3 A flowchart illustrating the sending of a verification command is provided for an embodiment of this application; Figure 4 A system architecture diagram for login verification provided in this application embodiment. Figure 5 An interactive schematic diagram of a login verification method provided in an embodiment of this application; Figure 6 This is a schematic diagram of an authorization verification process provided in an embodiment of this application; Figure 7 A schematic diagram illustrating a storage target mapping relationship provided in an embodiment of this application; Figure 8 A schematic diagram illustrating a storage target mapping relationship provided in an embodiment of this application; Figure 9 A schematic diagram illustrating a storage target mapping relationship provided in an embodiment of this application; Figure 10 A schematic diagram illustrating another storage target mapping relationship provided in an embodiment of this application; Figure 11 A schematic diagram illustrating another storage target mapping relationship provided in an embodiment of this application; Figure 12 This application provides an interactive diagram illustrating a login verification process. Figure 13 A visual illustration of a login verification method provided in an embodiment of this application; Figure 14 A flowchart illustrating a login verification method provided in an embodiment of this application; Figure 15 A flowchart illustrating another login verification method provided in an embodiment of this application; Figure 16 This application provides an illustration of a login verification method. Figure 17 This is a schematic diagram of the structure of a login verification device provided in an embodiment of this application; Figure 18 This is a schematic diagram of the structure of a login verification device provided in an embodiment of this application; Figure 19 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0016] The embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions of the embodiments of this application.

[0017] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this application mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element establish a connection relationship through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term; for example, “A and / or B” can be implemented as “A,” or as “B,” or as “A and B.”

[0018] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0020] First, let's introduce and explain several terms used in this application: Login typically refers to the process by which a user verifies their identity by entering credentials (such as a username and password) and gains access to a computer system, website, or application. Login is a mechanism for verifying user identity, ensuring that only authorized users can access specific resources or services.

[0021] Application binding refers to a connection or dependency established between an application or system and a specific service, resource, data, or device. Its main function is to enable the application to access and use the bound resources or services through a specified interface or protocol.

[0022] The login verification method, apparatus, electronic device, computer-readable storage medium, and computer program product provided in this application aim to solve the technical problem that the login verification method provided by the prior art cannot log in to trusted devices in some scenarios.

[0023] The technical solutions of this application and their effects are described below through several exemplary embodiments. It should be noted that the following embodiments can be referenced, borrowed from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0024] Figure 1 This is a schematic diagram of the system architecture for implementing the login verification method provided in this application embodiment. The system architecture diagram illustrates the login verification process between terminal 10, first server 20, and second server 30. Terminal 10 runs a client 101 of a first application and a client 102 of an associated application. First server 20 is the server corresponding to client 101 of the first application, and second server 30 is the server of the second application.

[0025] like Figure 1 As shown, icons B1-B9 are displayed on the terminal screen, representing clients of different applications. These applications can be social media applications, office applications, and entertainment / game applications, etc. B9 and B3 represent the application icons of client 101 of the first application and client 102 of the second application, respectively. The first application can be an enterprise collaborative office application, and the second application can be an instant messaging application. User A can click the application icon of the first application and enter a first login account on the login interface of the first application. In response to the user's login operation, client 101 of the first application sends a first login request to the first server 20. This request includes the first login account of the first application and the terminal's identification information. After receiving the request, the first server 20 compares the terminal identification with the stored target terminal identification. If they are different, it means that terminal 10 is logging into the first application for the first time with the first login account, so security verification is required. The first server 10 then returns a verification instruction to the terminal, requesting login verification.

[0026] After receiving the verification command, the terminal displays a login verification interface, providing different login verification options, including the option to verify using a second application. When user A selects the option to verify using a second application, the client 102 of the second application sends an authorization verification request to the second server 30. The second server 30 then sends the currently logged-in account of the associated application to the first server.

[0027] The first server 30 pre-stores the correspondence between the first login account of the first application and the login account of the second application. After receiving the current login account of the second application sent by the second server, the first server compares the current login account with the stored associated login account to perform login verification. If the comparison on the first server 20 matches, the terminal 10 running on the first server 10 logs into the first application using the first login account. This embodiment of the application realizes security verification through a second application that is already logged in on the terminal and is bound to the first application, solving the problem of untimely login caused by the loss of old devices or inability to contact other persons for security verification in the prior art.

[0028] In the embodiments of this application, the first server 20 and the second server 30 can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing cloud computing services. The terminal 10 (also referred to as a user terminal or user device) can be a smartphone, tablet computer, laptop computer, desktop computer, intelligent voice interaction device (e.g., smart speaker), wearable electronic device (e.g., smartwatch), in-vehicle terminal, smart home appliance (e.g., smart TV), AR / VR device, etc., but is not limited thereto. The terminal can be directly or indirectly connected to the first server, the terminal to the second server, or the first server to the second server via wired or wireless communication; this disclosure does not impose any limitations on this connection.

[0029] This application provides a login verification method, such as... Figure 2 As shown, this method is executed by a client of a first application running in the terminal, and includes: S201. Send a first login request to the first server of the first application. The first login request includes the first login account of the first application and the first terminal identifier of the terminal.

[0030] In this embodiment of the application, the first application may be an enterprise collaborative office application. The user can enter a first login account on the login interface of the first application. The first login account may be the application login account obtained by the user when registering the first application. The login account may be a unique identifier string or a user's identity identifier, which may be the user's mobile phone number or email address. Entering the first login account may also include entering the password corresponding to the first login account.

[0031] In this embodiment of the application, after the user finishes entering the login information on the login interface of the first application, he / she can click the login button on the login interface of the first application. In response to the user's click operation on the login button, the client of the first application sends a first login request to the first server of the first application. The first login request is used to request to log in to the first application on the terminal using a first login account. The first login request includes the first login account and the first terminal identifier of the terminal. The terminal identifier can be a unique identifier of the terminal device.

[0032] As an optional embodiment, the first login request may also carry at least some of the following information: timestamp, terminal device type, geographical location information, network information, and application identifier, to enhance the security, reliability, and verifiability of the login request.

[0033] S202. Receive the verification command sent by the first server and display the login verification interface.

[0034] like Figure 3 As shown, Figure 3 This is a flowchart illustrating a verification command sent according to an embodiment of this application. In this embodiment, the verification command is sent by the first server when it determines that the first terminal identifier and the target terminal identifier are different. The target terminal identifier is a terminal identifier stored in the first server corresponding to the first login account. The login verification interface displays login verification options, including an associated application verification option based on the associated applications of the first application.

[0035] In this embodiment of the application, after receiving the first login request, the first server obtains the first login account and the first terminal identifier, wherein the first terminal identifier is the unique identifier of the terminal that initiates the login request, and the target terminal identifier is the terminal identifier stored in the first server that is bound to the first login account.

[0036] When the first server detects that the current terminal's first terminal identifier does not match the stored target terminal identifier, it considers the current login abnormal or risky, triggers a security verification process, and sends a verification command to the first application's client. When user A logs into the first application using a new device, if the first server has not stored relevant information about that device, it considers that the device to be abnormal or risky, and in order to protect the user's first login account information in the first application, security verification is required.

[0037] It should be understood that terminal identifiers are crucial information for distinguishing different devices. Terminal identifiers can include device ID, IMEI, MAC address, etc. By verifying whether the first terminal identifier matches the target terminal identifier, it is possible to prevent the first login account from being used by unauthorized devices, thereby improving account security.

[0038] like Figure 3 As shown, when a user logs in on a bound device, the terminal identifier matches the target terminal identifier recorded by the server, and login to the first application is possible without additional verification. When a user logs in on a new device or an unauthorized device, the terminal identifier differs from the target terminal identifier, and the server triggers an additional verification process, such as logging in through a previously verified old device or selecting a contact service station to confirm the user's identity.

[0039] In this embodiment, the login verification interface displayed on the terminal provides users with options to perform verification operations to complete the login verification process. The design of the login verification options can include multiple verification methods to meet the security verification needs in different scenarios. Among them, the login verification options include associated application verification options based on associated applications. Associated applications refer to other applications on the current terminal that are bound to or have a mapping relationship with the first application account. For example, an enterprise collaborative office application can be bound to an instant messaging application account, and a social media account can be bound to a payment application.

[0040] This application provides a method for verification based on an associated application bound to a first application, which solves the problem of being unable to log in to the first application in scenarios where security verification cannot be performed on older devices or where it is inconvenient to request assistance from others for verification.

[0041] like Figure 4 As shown, Figure 4 The system architecture diagram for login verification provided in this application embodiment is as follows: the front-end H5 (HTML5) page is a lightweight front-end page technology that is loaded by a browser embedded in the first application. The client of the first application and the server of the first application have a login verification relationship, and the client of the associated application and the server of the associated application also have a login verification relationship. The first server and the second server have an authorization verification relationship.

[0042] In this embodiment, the login verification interface can be an H5 page. This interface can send a request to the client of the first application via a JavaScript application programming interface (JSAPI) to inquire whether the first application is installed on the device. After receiving the request from the H5 page, the client of the first application determines whether the associated application is installed on the device using the software development kits (SDKs) of each associated application of the first application. The associated application SDK checks whether the associated application is installed on the device. If associated application A is installed on the terminal, the client of the first application will return a "Associated application A is installed" status; if associated application A is not installed, it will return a "Associated application A is not installed" status.

[0043] In this embodiment, the H5 page can be pre-configured with at least one associated application verification option for the first application to perform security verification. Based on the judgment result returned by the client of the first application, the page determines which associated application verification option needs to be displayed. For each associated application verification option, if the corresponding associated application is installed on the terminal, the H5 page will display the associated application verification option in the interface for the user to select; if the corresponding associated application is not installed on the device, the H5 page will not display the associated application verification option.

[0044] In this embodiment, the verification method is customized based on whether the device has an associated application installed, avoiding unnecessary verification selections and simplifying the user's operation process.

[0045] S203. In response to receiving a selection operation for the verification option of the associated application, an authorization verification request is sent to the second server of the associated application through the client of the associated application, so as to trigger the second server to send the current login account of the associated application to the first server, so that the first server can perform login verification based on the current login account and the associated login account in the target mapping relationship stored in the first server.

[0046] In this embodiment of the application, the target mapping relationship is the correspondence between the first login account and the associated login account. The associated login account is the login account of the associated application used when binding the login operation of the associated application with the login operation of the first application. Binding the login operation of the associated application with the login operation of the first application means binding the user's login account in the associated application with the user's login account in the first application, so that when logging into the first application later, the user can log into the first application through the login account of the associated application and obtain the information and resources in the first application under the user's application login account.

[0047] In this embodiment, when a user selects an associated application verification option, the client of the first application calls the client of the associated application and sends an authorization verification request to the second server of the associated application. The second server is the server corresponding to the associated application, used to manage user accounts and login status of the associated application. The client of the associated application is logged in on the terminal, meaning the terminal has passed trusted device verification to log in to the associated application. The associated application can be an application that has been pre-authenticated with real-name authentication. Therefore, the user can log in to the associated application on the terminal using real-name authentication methods such as fingerprint authentication or facial recognition. If the first application has not been pre-authenticated with real-name authentication, then the first application cannot perform security verification through fingerprint recognition or facial recognition. The security of the login process can be further enhanced by the fact that the associated application is already logged in on the terminal, preventing the first login account from being stolen or abused.

[0048] Therefore, based on the pre-established target mapping relationship, when the current login account of the associated application is consistent with the associated login account, it can be concluded that the first application and the associated login account belong to the same user. Therefore, when the terminal is a trusted device for the association that belongs to the same user, the terminal is also a trusted device for the first application.

[0049] Specifically, to enable the first server to obtain the currently logged-in account of the associated application, the client of the first application sends an authorization verification request through the client of the associated application. After receiving the authorization verification request, the second server sends the currently logged-in account of the associated application to the first server. The currently logged-in account of the associated application is the account the user is currently logged into in the associated application on the terminal. For example, if a user is using account A to log in to a payment application, then account A is the currently logged-in account for that payment application.

[0050] In this embodiment, after receiving the currently logged-in account of the associated application, the first server verifies it according to the stored target mapping relationship. This target mapping relationship refers to the binding relationship between the first login account and the login account of the associated application. The first server can perform login verification by comparing whether the current login account matches the associated login account stored in the target mapping relationship.

[0051] In one scenario of this application embodiment, when user A logs into a social application, the first server detects an anomaly in the current terminal and requires verification. The user chooses to use a payment application associated with the first application for verification. The client of the social application calls the client of the payment application to initiate an authorization verification request to the server of the payment application. The server of the payment application confirms that the current login account of the social application on the terminal is B, and sends account B to the first server as the basis for verification.

[0052] This application's embodiments implement a secure and convenient login verification method by verifying the terminal identifier and combining it with associated application verification options. When an abnormal login is detected, the server triggers a verification process, and the user can complete identity confirmation through the associated application, thereby preventing the account from being used by unauthorized devices and improving account security and user experience.

[0053] In this embodiment, by establishing a correspondence between a first login account and an associated login account, when a user clicks the associated application verification option, the client of the first application sends an authorization verification request to the second server of the associated application through the client of the associated application. The second server then sends the current login account of the associated application to the client of the first application, allowing the first server to determine the current login account of the associated application and complete the login verification. This embodiment provides a new login verification scheme that, by binding the first login account of the first application with the associated login account of the associated application, enables cross-application login verification when logging into the first application for the first time on a new device. This ensures trustworthiness while avoiding login failures due to device changes.

[0054] As an optional embodiment of this application, an authorization verification request is sent from the client of the associated application to the second server of the associated application to trigger the second server to send the current login account of the associated application to the first server, including: The client of the associated application sends an authorization verification request to the second server; the authorization verification request includes the currently logged-in account of the associated application. The client of this associated application obtains the authorization verification information sent by the second server based on the currently logged-in account in the authorization verification request; The authorization verification information is sent from the first server to the second server, so that the second server can verify the received authorization verification information and send the current login account of the associated application to the first server after the verification is successful.

[0055] In this embodiment of the application, when a user selects to perform authorization verification through an associated application in the first application, the client of the first application will respond to the selection operation and initiate an authorization verification request to the second client of the associated application through the client of the associated application. The request contains the current login account of the associated application.

[0056] like Figure 5 As shown, Figure 5This is an interactive schematic diagram of a login verification method provided in an embodiment of this application. After receiving an authorization verification request sent by the client of an associated application, the second server obtains the current login account of the associated application from the authorization verification request, and generates authorization verification information based on the current login account and returns it to the client of the associated application. The client of the associated application sends the received authorization verification information to the client of the first application. In order to realize login verification, the client of the first application sends the authorization verification information to the first server. When performing login verification, the first server sends the obtained authorization verification information to the second server. The second server can compare the received authorization verification information with the authorization verification information sent to the client of the associated application to verify the received authorization verification information. If the verification is successful, the second server sends the current login account of the associated application to the first server; if the verification fails, the second server sends a verification failure message to the first server.

[0057] In this embodiment, the current login account of the associated application is obtained through the interaction between the client of the first application, the first server, the client of the associated application, and the second server. The current login account of the associated application is bound to the user's identity information, which can ensure that the user's identity information is correctly transmitted and verified in the associated application, and guarantee the consistency and security of user information.

[0058] As an optional embodiment of this application, the authorization verification information is generated by the second server encrypting the current login account in the authorization verification request using a preset encryption algorithm; The second server verifies the received authorization verification information by including: The received authorization verification information is decrypted using the decryption algorithm corresponding to the encryption algorithm to obtain the decrypted login account. The decrypted login account is then compared with the current login account in the authorization verification request. If the comparison matches, the verification is confirmed to be successful.

[0059] like Figure 6 As shown, Figure 6 This is a schematic diagram of an authorization verification process provided in an embodiment of this application. In this embodiment, the second server receives an authorization verification request sent by the client of the associated application, obtains the current login account of the associated application from the authorization verification request, and can use a preset encryption algorithm to encrypt the current login account in the authorization verification request to generate authorization verification information. The preset encryption algorithm refers to an algorithm that has been set in the system to ensure the consistency of encryption and decryption.

[0060] The default encryption algorithm used is either symmetric or asymmetric encryption. The choice of encryption algorithm and key depends on the actual security requirements. For example, if the authorization verification information sent by the second client includes the currently logged-in account "user123", the second server can encrypt the currently logged-in account "user123" using Advanced Encryption Standard (AES) to generate an encrypted string of data, which is the authorization verification information.

[0061] In this embodiment, after the second server receives the authorization verification information sent by the first server, it can use a decryption algorithm corresponding to the encryption algorithm to decrypt the encrypted data and obtain the decrypted result. The second server can then compare the decrypted result with the current login account in the authorization verification request to verify whether the login account submitted by the user when sending the authorization verification request matches the decrypted result.

[0062] If the comparison matches, it means the account submitted by the user matches the account in the encrypted data, the verification is successful, and the user's identity is valid. If the comparison does not match, it means the account information in the request does not match the decrypted data, the verification fails, possibly due to tampering or other security issues. For example, if the decrypted login account is "user123" and the current login account in the authorization verification request is also "user123", then they match, the verification passes, and the user can continue to log in or perform other operations. If they do not match, it indicates that authentication has failed, which may trigger an error or security warning.

[0063] In this embodiment, the current login account in the authorization verification request is encrypted using an encryption algorithm, and the received authorization verification information is decrypted using a corresponding decryption algorithm to obtain the decrypted result. The decrypted result is then compared with the current login account in the authorization verification request. If the comparison is consistent, the second server can send the current login account of the associated application in the authorization verification request to the first server.

[0064] As an optional embodiment, the second server may also generate authorization verification information and decrypt the received authorization verification information in the following manner: When a user selects the associated application verification login option, the client of the first application can call the associated application through the associated application's SDK interface, causing the terminal interface to jump to the associated application's authorization login interface. When the user clicks the authorization button on the authorization login interface, the client of the associated application sends an authorization verification request to the second server. This authorization login request can be in URL format, including the first application's first login account (appid) and the parameter `response_type=code`, which indicates that the request is for authorization verification information. Upon receiving the authorization verification request, the second server performs a hash operation on all information in the request, randomly generates an authorization code as the authorization verification information, establishes a mapping between the authorization verification information and the current login account of the associated application in the authorization verification request, and stores the authorization verification information and the mapping in the second server's database. The second server can also set a validity period for this authorization verification information to a preset duration. The second server sends the authorization verification information to the client of the second application, the client of the second application sends the authorization verification information to the client of the first application, the client of the first application sends the authorization verification information to the first server, and the first server then sends the authorization verification information to the second server.

[0065] When the second server receives the authorization verification information, it can first check whether the authorization verification information exists in the database. If not, it can return a verification failure to the first server. If the authorization verification information exists, it can further check whether the difference between the generation time of the authorization verification information and the time when the second server receives the authorization verification information is within a preset time period. If it is not within the preset time period, it can return a verification failure to the first server. If it is within the preset time period, it can send the current login account of the associated application corresponding to the authorization verification information to the first server.

[0066] By generating and verifying authorization verification information through a second server, the security and integrity of data transmission can be ensured, preventing malicious tampering, forgery, or man-in-the-middle attacks, while also verifying the legitimacy of the request.

[0067] As an optional embodiment of this application, the target mapping relationship is stored by the first server in the following manner before receiving the first login request: Receive a first login binding request for a first application. The first login binding request is used to bind the first login account of the first application to the login account of the second application. The first login binding request includes the login account of the second application. The second application is designated as an associated application of the first application, the login account of the second application is designated as an associated login account of the first login account, and the correspondence between the first login account and the associated login account is stored in the first server.

[0068] like Figure 7 As shown, Figure 7 This application provides a flowchart illustrating a storage target mapping relationship, including steps S701-S706. In this application embodiment, the first login binding request may be generated by the client of the first application in response to the user's binding operation when the user binds the first login account of the first application to the second application's login account in the binding interface of the first application. It should be understood that the terminal sending the first login binding request may not be the same terminal as the terminal sending the first login request; the clients of the first application in various terminals are collectively referred to as the clients of the first application.

[0069] In this embodiment, the first login binding request includes the login account of the second application. After receiving the first login binding request, the first server binds the first login account of the first application and the login account of the second application to bind the login operations of the second application and the first application. After binding, the second application becomes an associated application of the first application, and the login account of the second application becomes an associated login account of the first login account. Users can use this associated login account to perform login operations on the first application to obtain information and resources in the first application under the user's application login account. The first server can store the correspondence between the first login account and the associated login account as a target mapping relationship in the first server.

[0070] It should be understood that users may have multiple accounts across multiple applications or platforms. For example, a user may have registered and logged into a first application and a second application on terminal A. To enable cross-application login, the user will bind their first login account for the first application and their second login account for the second application. In this case, the first server can establish a target mapping relationship. After the user logs into the second application on a new terminal B, the user can then select the associated application B for security verification when logging into the first application.

[0071] In this embodiment, when a user binds a first application to other applications, the corresponding target mapping relationship is stored. This enables security verification to be performed through the associated application when the first application is successfully logged in on the terminal. This improves the efficiency of terminal login verification while ensuring the security of the verification process.

[0072] like Figure 8 As shown, Figure 8This is a schematic diagram illustrating a target mapping relationship provided in an embodiment of this application. By binding the login account of a second application to the application login account of a first application, the second application becomes an associated application of the first application. A target mapping relationship is created by storing the correspondence between the application login accounts of the first and second applications.

[0073] As an optional embodiment of this application, the first login account is created by the first server in the following way: Receive a registration request for the first application. The registration request includes an object identifier for registration. The object identifier is either the identity identifier of the requesting object or the login account of the second application. In response to the registration request, create the application login account for the first application and store the application login account as the first login account for the first application; Specifically, if the object identifier is the login account of the second application, the login binding request is a registration request; if the object identifier is an identity identifier, the first login account is either an identity identifier or a generated application login account.

[0074] In this embodiment, when a user uses the first application for the first time, the user needs to register for the first application using their own relevant information and will obtain an application login account for the first application. After the user fills in the relevant information on the registration interface of the first application, the client of the first application will send a registration request to the first server. The registration request includes an object identifier for registration. This object identifier can be the identity identifier of the user requesting to register for the first application, or it can be the login account of the user requesting to register for the first application in the second application. The identity identifier can be the user's email address or mobile phone number.

[0075] In this embodiment, the first application can be registered using a user's identity identifier or a user's login account in the second application. It should be understood that the second application is an application specified by the vendor of the first application that allows registration or binding to the first application. For example, when registering for the first application A, the registration interface may display a preset registration method, which includes at least registering using an identity identifier or registering using a login account in the second application.

[0076] In this embodiment, after receiving a registration request, if the registration request contains a user's identity identifier, the first server can send verification information to the terminal corresponding to that identity identifier and instruct the client of the first application to display an interface for entering verification information. After the user enters the correct verification information, the first server creates an application login account for the first application and instructs the client of the first application to display a registration success interface, allowing the user to obtain the application login account. When the registration request contains a user's identity identifier, the user can log in to the first application using either the identity identifier or the application login account.

[0077] like Figure 9 As shown, Figure 9 This is a schematic diagram illustrating a storage target mapping relationship provided in an embodiment of this application. When a user registers using an identity identifier, an application login account for a first application is created. A login account for a second application can be bound to the application login account for the first application. At this time, the target mapping relationship can be the correspondence between the application login account for the first application, the login account for the second application, and the identity identifier. Therefore, when a user logs into the first application on terminal C, they can use the identity identifier and the application login account for the first application to log in. If this is the first time terminal C is using this identity identifier and the login identifier for the first application to log in, security verification will be triggered. If terminal C has already installed and is running the second application, and the login account for the second application corresponds to the user, then the second application can be used as an associated application of the first application for security verification.

[0078] In this embodiment, after receiving a registration request, if the registration request contains a login account for the second application, then the registration request is a login binding request based on the second application binding the first application. It should be understood that if the login account for the second application is used to register the first application, and an application login account for the first application is created, then the login account for the second application and the application login account for the first application are bound together. Therefore, using the login account for the second application to register the first application is a way to bind the login account for the second application to the application login account for the first application.

[0079] In this embodiment of the application, after the first server receives the registration request, if the registration request contains the login account of the second application, the first server can instruct the client of the first application to perform information verification. This information verification can be performed by the client that has used the second application scanning the QR code on the registration interface of the first application, or by the client of the second application interacting with the second server for verification.

[0080] like Figure 10 As shown, Figure 10This is a schematic diagram illustrating another storage target mapping relationship provided in an embodiment of this application. The user registers the first application using their second application login account, generating an application login account for the user in the first application. The first service card can store the application login account of the first application and the login account of the second application, thus obtaining a target mapping relationship. It should be understood that in this case, the first login account of the first application can be the application login account of that first application. Since the first server stores the application login account of the first application and the login account of the second application, the second application can be used as an associated application of the first application. When a user logs into the first application for the first time on a new device, security verification is performed based on the second application that the user has already installed and is running on the new device.

[0081] As an optional embodiment of this application, when the object identifier is a login account of the second application, the correspondence between the first login account and the associated login account is stored in the first server, and then the method further includes: Receive a second login binding request for the first application. The second login binding request includes an identity identifier, which is used to bind the identity identifier to the application login account. In response to the second login binding request, the identity identifier is bound and stored with the application login account, and the identity identifier is used as the first login account.

[0082] In this embodiment, when a user registers for the first application using the login account of the second application, to enable login to the first application through multiple login methods, the user's identity identifier can be bound to the application login account of the first application. This allows the user to log in to the first application using their identity identifier and access information and resources within the first application under their application login account. The user can enter their identity identifier information on the binding interface of the first application. In response to the user's binding operation, the client of the first application sends a second login binding request to the first server. Upon receiving the second login binding request, the first server obtains the user's identity information. The first server can then send verification information to the terminal corresponding to this identity information and instruct the client of the first application to display an interface for entering verification information. After the user enters the correct verification information, the user's identity identifier is bound to the application login account of the first application.

[0083] like Figure 11 As shown, Figure 11 This is a schematic diagram of another storage target mapping relationship provided in an embodiment of this application. When a user registers for the first application using the login account of the second application, the user obtains the application login account of the first application. When the user subsequently binds the identity identifier to the application login account of the first application, the first server can store the relationship between the application login account of the first application, the login account of the second application, and the identity identifier.

[0084] The first login account can be both the application login account and identity representation for the first application. Users can log in to the first application using both the first login account and the login account for the second application, supporting multiple login methods.

[0085] As an optional embodiment of this application, the login verification method further includes: Receive login verification result sent by the first server; wherein, the login verification result is the verification result of the first server based on the current login account and the associated login account. If the current login account and the associated login account are the same, the verification result is considered successful. In the case that the verification result is successful, the target terminal identifier stored in the first server is updated to the first terminal identifier in the first login request. If the login verification result is successful, a second login request is sent to the first server. The second login request includes the first login account and the first terminal identifier, so that the first server can verify the login of the first login account based on the first terminal identifier and the updated target terminal identifier. If the first login account is the same as the updated target terminal identifier, the login success result is sent to the client of the first application.

[0086] like Figure 12 As shown, Figure 12 This is an interactive diagram illustrating a login verification process provided in an embodiment of this application. In this embodiment, the first server performs login verification based on the current login account and associated login account of the associated application, and obtains a login verification result. If the current login account and associated login account of the associated application are different, the login verification result is a verification failure; if the current login account and associated login account of the associated application are the same, the login verification result is a verification success. The first server updates the target terminal identifier using the first terminal identifier to maintain the uniqueness of the terminal device and the association of the login information, so that the first server can correctly distinguish each device, thereby effectively preventing unauthorized login and ensuring security.

[0087] In this embodiment, when the client of the first application receives the login verification result sent by the first server, if the login verification result is a verification failure, the terminal interface will display a verification failure message; if the login verification result is a verification success message, the client of the first application can display a verification success message. The user can click the login button again to make the client of the first application send a second login request to the first server. At this time, the second login request includes the first login account and the first terminal identifier. Since the first server has already used the first terminal identifier as the target terminal identifier, the first server will send the login success result to the client of the first application. The user can enter the first application and browse the information and resources in the first application.

[0088] like Figure 13 As shown, Figure 13 This is a visual illustration of login verification provided in an embodiment of this application. The visual interface for login verification may include interface 1, interface 2, interface 3, and interface 4. Interface 1 is the login verification interface in this embodiment of the application, which is an H5 page. This interface reminds the user that the terminal when logging into the first application A is a new device. To ensure account security, the user is asked to select a verification method to ensure that it is the user's own operation. The verification methods include login from other devices, real-name verification of accounts, and login verification for application B. Login from other devices refers to other devices that have already logged into the first application. The user can use this device to verify the terminal. Verification can be achieved by scanning a QR code. Real-name verification of accounts means that if the user has previously performed real-name authentication when using the first application, such as fingerprint recognition or facial recognition, the user can verify using this verification method. If a user loses their old device used to log in to the first application or has not previously used the first application for real-name authentication, the user can use application B for verification. Application B is an associated application of application A, meaning the user previously linked application B to application A. When the user clicks the "Verify with Application B" button, the interface redirects to interface 2 of application B. Interface 2 reminds the user that they are using application B to perform security verification for application A. To ensure account integrity, please confirm whether to allow verification for application A through application B. After the user clicks "Allow," the interface redirects to interface 3, which displays a successful verification message. Then, interface 3 automatically redirects back to the user interface 4 of the first application. Application A is an enterprise collaborative office device. Since users can have multiple identities within this application, all possible identities are displayed to the user upon entering application A for selection.

[0089] like Figure 14 As shown in the embodiments of this application, a login verification method executed by a first server of a first application is also provided, including: S1401, The receiving terminal sends a first login request through the client of the first application, the first login request including the first login account of the first application and the first terminal identifier of the terminal; S1402. If the first terminal identifier is different from the target terminal identifier, a verification instruction is sent to the client of the first application. The target terminal identifier is the terminal identifier stored in the first server that corresponds to the first login account. The verification instruction is used to trigger the client of the first application to display a login verification interface that includes login verification options. The login verification options include associated application verification options based on the associated applications of the first application. S1403. Receive the current login account of the associated application sent by the second server of the associated application. The current login account is sent by the second server to the first server after receiving an authorization verification request sent by the client of the associated application. The authorization verification request is sent by the client of the first application to the second server in response to receiving a selection operation for the verification option of the associated application. S1404. Login verification is performed based on the current login account and the target mapping relationship stored in the first server. The target mapping relationship is the correspondence between the first login account and the associated login account. The associated login account is the login account of the associated application used when binding the login operation of the associated application with the login operation of the first application.

[0090] In this embodiment of the application, the user can enter a first login account on the login interface of the first application. After the user has entered the account on the login interface of the first application, the user can click the login button on the login interface of the first application. The client of the first application responds to the user's click operation on the login button and sends a first login request to the first server of the first application.

[0091] As an optional embodiment, the first login request may also carry at least some of the following information: timestamp, terminal device type, geographical location information, network information, and application identifier, to enhance the security, reliability, and verifiability of the login request.

[0092] In this embodiment, the verification command is sent by the first server when it determines that the first terminal identifier and the target terminal identifier are different. The target terminal identifier is the terminal identifier stored in the first server corresponding to the first login account. The login verification interface displays login verification options, including an associated application verification option based on the associated applications of the first application.

[0093] In this embodiment of the application, after receiving the first login request, the first server obtains the first login account and the first terminal identifier, wherein the first terminal identifier is the unique identifier of the terminal that initiates the login request, and the target terminal identifier is the terminal identifier stored in the first server that is bound to the first login account.

[0094] When the first server detects that the current terminal's first terminal identifier does not match the stored target terminal identifier, it considers the current login abnormal or risky, triggers a security verification process, and sends a verification command to the first application's client. When user A logs into the first application using a new device, if the first server has not stored relevant information about that device, it considers that the device to be abnormal or risky, and in order to protect the user's first login account information in the first application, security verification is required.

[0095] In this embodiment, the login verification interface displayed on the terminal provides users with options to perform verification operations to complete the login verification process. The design of the login verification options can include multiple verification methods to meet the security verification needs in different scenarios. Among them, the login verification options include associated application verification options based on associated applications. Associated applications refer to other applications on the current terminal that are bound to or have a mapping relationship with the first application account. For example, an enterprise collaborative office application can be bound to an instant messaging application account, and a social media account can be bound to a payment application.

[0096] In this embodiment, when a user selects an associated application verification option, the client of the first application calls the client of the associated application and sends an authorization verification request to the second server of the associated application. The second server is the server corresponding to the associated application, used to manage user accounts and login status of the associated application. The client of the associated application is logged in on the terminal, meaning the terminal has passed trusted device verification to log in to the associated application. The associated application can be an application that has been pre-authenticated with real-name authentication. Therefore, the user can log in to the associated application on the terminal using real-name authentication methods such as fingerprint authentication or facial recognition. If the first application has not been pre-authenticated with real-name authentication, then the first application cannot perform security verification through fingerprint recognition or facial recognition. The security of the login process can be further enhanced by the fact that the associated application is already logged in on the terminal, preventing the first login account from being stolen or abused.

[0097] Therefore, based on the pre-established target mapping relationship, when the current login account of the associated application is consistent with the associated login account, it can be concluded that the first application and the associated login account belong to the same user. Therefore, when the terminal is a trusted device for the association that belongs to the same user, the terminal is also a trusted device for the first application.

[0098] Specifically, to enable the first server to obtain the currently logged-in account of the associated application, the client of the first application sends an authorization verification request through the client of the associated application. After receiving the authorization verification request, the second server sends the currently logged-in account of the associated application to the first server. The currently logged-in account of the associated application is the account the user is currently logged into in the associated application on the terminal. For example, if the user is already logged into account A in a payment application, then account A is the currently logged-in account for that payment application.

[0099] In this embodiment, after receiving the currently logged-in account of the associated application, the first server verifies it according to the stored target mapping relationship. This target mapping relationship refers to the binding relationship between the first login account and the login account of the associated application. The first server can perform login verification by comparing whether the current login account matches the associated login account stored in the target mapping relationship.

[0100] This application's embodiments implement a secure and convenient login verification method by verifying the terminal identifier and combining it with associated application verification options. When an abnormal login is detected, the server triggers a verification process, and the user can complete identity confirmation through the associated application, thereby preventing the account from being used by unauthorized devices and improving account security and user experience.

[0101] As an optional embodiment of this application, the login verification method performed by the first server further includes: The login verification result is sent to the client of the first application; wherein, the login verification result is the verification result of the first server based on the current login account and the associated login account. If the current login account and the associated login account are the same, the verification result is considered successful. If the login verification result is successful, the target terminal identifier is updated to the first terminal identifier; a second login request is received from the client of the first application, the second login request including the first login account and the first terminal identifier; The login verification of the first login account is performed based on the first terminal identifier and the updated target terminal identifier. If the first login account is the same as the updated target terminal identifier, the login success result is sent to the client of the first application.

[0102] The specific process for this section has been explained above. For detailed steps and procedures, please refer to the aforementioned description.

[0103] This application also provides a login verification method, including: The client of the first application running on the terminal sends a first login request to the first server of the first application. The first login request includes the first login account of the first application and the first terminal identifier of the terminal. The first server receives the first login request and, if the first terminal identifier is different from the target terminal identifier, sends a verification instruction to the client of the first application. The target terminal identifier is the terminal identifier stored in the first server that corresponds to the first login account. After receiving the verification command sent by the first server, the client of the first application displays a login verification interface, which displays login verification options, including associated application verification options based on the associated applications of the first application. After receiving the selection operation for the verification option of the associated application, the client of the first application sends an authorization verification request to the second server of the associated application through the client of the associated application running in the terminal. The second server receives the authorization verification request and sends the current login account of the associated application to the first server according to the authorization verification request; The first server receives the current login account sent by the second server and performs login verification based on the current login account and the associated login account in the target mapping relationship stored in the first server; The target mapping relationship is the correspondence between the first login account and the associated login account. The associated login account is the login account of the associated application used when binding the login operation of the associated application to the login operation of the first application.

[0104] The specific details of this section have been explained above. For detailed steps and operating procedures, please refer to the descriptions in the corresponding methods above.

[0105] For a detailed explanation of the login verification method provided in this application, please refer to [link / reference]. Figure 15 , Figure 15 A flowchart illustrating another login verification method provided in this application embodiment. Includes steps S1-S25: S1. The client of the first application sends a registration request to the first server, and will register the first application after verifying its identity. S2. The first server registers the first application based on the user's identity and gives the application login account of the first application to the client of the first application; S3. The first server establishes the correspondence between identity identifiers and application login accounts; S4. The client of the first application sends a first login binding request to the first server, which includes the user's login account in the second application. S5. The first server sends a binding verification request to the second server of the associated application, that is, the server of the second application. S6. The second server returns the result of agreeing to the binding to the first server; S7. The first server notifies the client of the first application that the binding is successful; S8. The first server establishes the correspondence between identity identifiers, application login accounts, and associated login accounts; S9. The client of the first application sends a first login request to the first server. The first login request includes a first login identifier and a first terminal identifier. The first login identifier is an identity identifier or the login account of the first application. S10. The first server compares the first terminal identifier with the target terminal identifier; S11. When it is determined that the first terminal identifier is not the target terminal identifier, a verification command is sent to the client of the first application; S12. The client of the first application instructs the front-end H5 to open the verification page, allowing the user to select a verification method; S13. The front-end H5 sends a verification message to the client of the first application, indicating that the user has selected the associated application. S14. The client of the first application sends an authorization verification request to the client of the associated application. S15. The client of the associated application sends an authorization verification request to the second server, which includes the currently logged-in account of the associated application. S16. The second server generates authorization verification information based on the currently logged-in account in the authorization verification request and returns the authorization verification information to the client of the associated application. S17. The client of the associated application sends authorization verification information to the client of the first application; S18. The client of the first application sends authorization verification information to the first server; S19. The first server sends authorization verification information to the second server; S20. The second server receives the authorization verification information and performs verification. S21. After the second server verifies the account, the currently logged-in account is returned to the first server. S22. The first server compares the currently logged-in account with the associated logged-in account; S23. The first server returns the verification result to the client of the first application; S24. When the client of the first application confirms successful verification, it sends a second login request to the first server. S25. The first server returns a successful login result to the client of the first application.

[0106] S7 and S8 can correspond to different terminals.

[0107] like Figure 16 As shown, Figure 16 This is an application scenario diagram of a login verification method provided in an embodiment of this application.

[0108] User C has two terminal devices, namely the first terminal and the second terminal shown in the diagram. The first terminal is User C's old device, and the second terminal is User C's new device. User C first registers a login account for application A on the old device (first terminal) and binds the login account for application A to the login account for application B through a binding server. Therefore, the relationship between the login accounts for application A and application B, and their identity identifiers, is stored in the target mapping relationship storage server. When application A and application B are bound, the first terminal can also send a binding verification request to the verification information management server. The verification information management server performs the binding verification, sends verification information to the first terminal, and after receiving the verification information again, allows application A and application B to bind. Afterwards, User C initiates a login request on the new device (second terminal). Upon receiving the request, the login verification server determines whether the second terminal is logging into application A for the first time.

[0109] If it is the first time, a verification command is sent to the second terminal. The second terminal obtains verification information from the verification information relationship server and sends the verification information to the login verification server. The login verification server obtains the binding relationship between application A and application B from the target mapping relationship storage server and verifies the user's current login account in application B.

[0110] The verification information management server assists in the transmission and management of verification information, ensuring its security and consistency. After successful verification, the login verification server returns the verification result to the second terminal, ultimately enabling the user to successfully log in on the new device. The registration server, binding server, target mapping relationship storage server, and login verification server can be considered as the server cluster corresponding to the first server. The verification information management server can be considered as a server within the server cluster corresponding to the second server. This server cluster also includes other servers such as the registration server, which are not shown in the diagram.

[0111] This application provides a login verification device, such as... Figure 17 As shown, the login verification device is applied to the client of a first application running on the terminal. The device may include: a module for sending a first login request 1701, a module for receiving verification instructions 1702, and a response selection operation module 1703, wherein... The module 1701 for sending a first login request is used to send a first login request to the first server of the first application. The first login request includes the first login account of the first application and the first terminal identifier of the terminal. The verification instruction receiving module 1702 is used to receive the verification instruction sent by the first server and display a login verification interface. The verification instruction is sent by the first server when it is determined that the first terminal identifier and the target terminal identifier are different. The target terminal identifier is the terminal identifier stored in the first server that corresponds to the first login account. The login verification interface displays login verification options, including associated application verification options based on the associated applications of the first application. The response selection operation module 1703 is used to respond to receiving a selection operation for the verification option of the associated application, and to send an authorization verification request to the second server of the associated application through the client of the associated application, so as to trigger the second server to send the current login account of the associated application to the first server, so that the first server can perform login verification based on the current login account and the associated login account in the target mapping relationship stored in the first server; wherein, the target mapping relationship is the correspondence between the first login account and the associated login account, and the associated login account is the login account of the associated application used when binding the login operation of the associated application to the first application.

[0112] As an optional embodiment of this application, when the response selection operation module sends an authorization verification request to the second server of the associated application through the client of the associated application, thereby triggering the second server to send the current login account of the associated application to the first server, it is specifically used for: The client of the associated application sends an authorization verification request to the second server; the authorization verification request includes the currently logged-in account of the associated application. The client of the associated application obtains the authorization verification information sent by the second server based on the currently logged-in account in the authorization verification request; The authorization verification information is sent from the first server to the second server so that the second server can verify the received authorization verification information and, after successful verification, send the current login account of the associated application to the first server.

[0113] As an optional embodiment of this application, the target mapping relationship is stored by the first server in the following manner before receiving the first login request: Receive a first login binding request for a first application, the first login binding request being used to bind the first login account of the first application to the login account of the second application; the first login binding request includes the login account of the second application; The second application is used as the associated application of the first application, and the login account of the second application is used as the associated login account of the first login account. The correspondence between the first login account and the associated login account is stored in the first server.

[0114] As an optional embodiment of this application, the first login account is created by the first server in the following way: Receive a registration request for the first application, the registration request including an object identifier for registration, which is either the identity identifier of the requesting object or the login account of the second application; In response to the registration request, create an application login account for the first application, and store the application login account as the first login account for the first application; Wherein, if the object identifier is the login account of the second application, the first login binding request is the registration request; if the object identifier is an identity identifier, the first login account is the identity identifier or the generated application login account.

[0115] As an optional embodiment of this application, when the object identifier is the login account of the second application, the mapping relationship between the first login account and the associated login account is stored in the first server, and then the method further includes: Receive a second login binding request for the first application, the second login binding request including an identity identifier, which is used to bind the identity identifier to the login account of the application; In response to the second login binding request, the identity identifier is bound and stored with the application login account, and the identity identifier is used as the first login account.

[0116] As an optional embodiment of this application, the authorization verification information is generated by the second server encrypting the current login account in the authorization verification request using a preset encryption algorithm; The second server verifies the received authorization verification information by including: The received authorization verification information is decrypted using the decryption algorithm corresponding to the encryption algorithm to obtain the decrypted login account. The decrypted login account is then compared with the current login account in the authorization verification request. If the comparison matches, the verification is confirmed to be successful.

[0117] As an optional embodiment of this application, the login verification device 170 further includes a login verification result receiving module, used to receive the login verification result sent by the first server; wherein, the login verification result is the verification result of the first server performing login verification based on the current login account and the associated login account, and if the current login account and the associated login account are the same, the verification result is considered successful, wherein, in the case of successful verification, the target terminal identifier stored in the first server is updated to the first terminal identifier in the first login request; The module for sending a second login request is used to send a second login request to the first server if the login verification result is successful. The second login request includes the first login account and the first terminal identifier, so that the first server can perform login verification of the first login account based on the first terminal identifier and the updated target terminal identifier, and send the login success result to the client of the first application if the first login account is the same as the updated target terminal identifier.

[0118] This application provides a login verification device 180, such as... Figure 18 As shown, the login verification device is applied to the first server of the first application. The device may include: a module 1801 for receiving a first login request, a module 1802 for sending verification instructions, a module 1803 for receiving login accounts, and a verification module 1804. The first login request receiving module 1801 is used to receive a first login request sent by the terminal through the client of the first application. The first login request includes the first login account of the first application and the first terminal identifier of the terminal. The verification instruction sending module 1802 is used to send a verification instruction to the client of the first application when the first terminal identifier is different from the target terminal identifier. The target terminal identifier is the terminal identifier stored in the first server that corresponds to the first login account. The verification instruction is used to trigger the client of the first application to display a login verification interface that includes login verification options. The login verification options include associated application verification options based on the associated applications of the first application. The login account receiving module 1803 is used to receive the current login account of the associated application sent by the second server of the associated application. The current login account is sent by the second server to the first server after receiving the authorization verification request sent by the client of the associated application. The authorization verification request is sent by the client of the first application to the second server in response to receiving the selection operation for the verification option of the associated application. The verification module 1804 is used to perform login verification based on the current login account and the target mapping relationship stored in the first server. The target mapping relationship is the correspondence between the first login account and the associated login account. The associated login account is the login account of the associated application used when binding the login operation of the associated application to the login operation of the first application.

[0119] As an optional embodiment of this application, the verification module 180 further includes a login verification result sending module, used to send the login verification result to the client of the first application; wherein, the login verification result is the verification result of the first server performing login verification based on the current login account and the associated login account, and if the current login account and the associated login account are the same, the verification result is considered successful; The module for receiving a second login request is configured to update the target terminal identifier to the first terminal identifier if the login verification result is successful; receive a second login request sent by the client of the first application, the second login request including the first login account and the first terminal identifier; perform login verification of the first login account based on the first terminal identifier and the updated target terminal identifier, and send a successful login result to the client of the first application if the first login account is the same as the updated target terminal identifier.

[0120] The apparatus in this application embodiment can execute the method provided in this application embodiment, and the implementation principle is similar. The actions performed by each module in the apparatus of each embodiment of this application correspond to the steps in the method of each embodiment of this application. For detailed functional descriptions of each module of the apparatus, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.

[0121] This application provides an electronic device, including a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of a login verification method. Compared with related technologies, this application provides the following: By establishing a correspondence between a first login account and an associated login account, when a user clicks the associated application verification option, the client of the first application sends an authorization verification request to the second server of the associated application through the client of the associated application. The second server then sends the current login account of the associated application to the client of the first application. The first server can then determine the current login account of the associated application to perform login verification. This application provides a new login verification scheme. By binding the first login account of the first application with the associated login account of the associated application, cross-application login verification is achieved when logging into the first application for the first time using a new device, avoiding the problem of login failure due to device changes.

[0122] In one alternative embodiment, an electronic device is provided, such as Figure 19 As shown, Figure 19 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of this application.

[0123] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0124] Bus 4002 may include a pathway for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 19 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0125] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0126] The memory 4003 stores computer programs that execute embodiments of this application, and its execution is controlled by the processor 4001. The processor 4001 executes the computer programs stored in the memory 4003 to implement the steps shown in the foregoing method embodiments.

[0127] Among them, electronic devices may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), and in-vehicle terminals (such as in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 19 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0128] This application provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program can implement the steps and corresponding content of the aforementioned method embodiments. Compared with the prior art, this application provides the following: By establishing a correspondence between a first login account and an associated login account, when a user clicks the associated application verification option, the client of the first application sends an authorization verification request to the second server of the associated application through the client of the associated application. The second server then sends the current login account of the associated application to the client of the first application, allowing the first server to determine the current login account of the associated application and perform login verification. This application provides a new login verification scheme that binds the first login account of the first application to the associated login account of the associated application, enabling cross-application login verification when logging into the first application for the first time on a new device, thus avoiding the problem of login failure due to device changes.

[0129] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium, a computer-readable medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, 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 device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0130] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments. Compared with the prior art, this application embodiment achieves the following: By establishing a correspondence between a first login account and an associated login account, when a user clicks the associated application verification option, the client of the first application sends an authorization verification request to the second server of the associated application through the client of the associated application. The second server then sends the current login account of the associated application to the client of the first application, allowing the first server to determine the current login account of the associated application and perform login verification. This application embodiment provides a new login verification scheme that, by binding the first login account of the first application with the associated login account of the associated application, enables cross-application login verification when logging into the first application for the first time using a new device, avoiding the problem of login failure due to device changes.

[0131] The terms "first," "second," "third," "fourth," "1," "2," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the illustrations or text descriptions.

[0132] It should be understood that although arrows indicate various operation steps in the flowcharts of this application's embodiments, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of this application's embodiments, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all steps in each flowchart, based on the actual implementation scenario, may include multiple sub-steps or multiple stages. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and this application's embodiments do not limit this.

[0133] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application without departing from the technical concept of this application also fall within the protection scope of the embodiments of this application.

Claims

1. A login authentication method characterized by, The method is executed by a client of a first application running in a terminal, and the method includes: Send a first login request to the first server of the first application, the first login request including the first login account of the first application and the first terminal identifier of the terminal; The system receives a verification command sent by the first server and displays a login verification interface. The verification command is sent by the first server when it determines that the first terminal identifier and the target terminal identifier are different. The target terminal identifier is a terminal identifier stored in the first server that corresponds to the first login account. The login verification interface displays login verification options, including associated application verification options based on the associated applications of the first application. In response to receiving a selection operation for the verification option of the associated application, an authorization verification request is sent from the client of the associated application to the second server of the associated application, so as to trigger the second server to send the current login account of the associated application to the first server, so that the first server can perform login verification based on the current login account and the associated login account in the target mapping relationship stored in the first server; The target mapping relationship is the correspondence between the first login account and the associated login account, and the associated login account is the login account of the associated application used when binding the login operation of the associated application with the first application.

2. The method of claim 1, wherein, The step of sending an authorization verification request from the client of the associated application to the second server of the associated application, thereby triggering the second server to send the current login account of the associated application to the first server, includes: The client of the associated application sends an authorization verification request to the second server; wherein the authorization verification request includes the currently logged-in account of the associated application; The client of the associated application obtains the authorization verification information sent by the second server based on the currently logged-in account in the authorization verification request; The authorization verification information is sent to the second server through the first server, so that the second server can verify the received authorization verification information and send the current login account of the associated application to the first server after the verification is successful.

3. The method according to claim 1 or 2, characterized in that, The target mapping relationship is stored by the first server in the following way before receiving the first login request: Receive a first login binding request for a first application, the first login binding request being used to bind the first login account of the first application to the login account of the second application; The first login binding request includes the login account of the second application; The second application is used as the associated application of the first application, the login account of the second application is used as the associated login account of the first login account, and the correspondence between the first login account and the associated login account is stored in the first server.

4. The method according to claim 3, characterized in that, The first login account was created by the first server in the following way: Receive a registration request for a first application, the registration request including an object identifier for registration, the object identifier being either the identity identifier of the requesting object or the login account of the second application; In response to the registration request, an application login account for the first application is created, and the application login account is used as the first login account for the first application and stored. Wherein, if the object identifier is the login account of the second application, the first login binding request is the registration request; if the object identifier is an identity identifier, the first login account is the identity identifier or the generated application login account.

5. The method according to claim 4, characterized in that, If the object identifier is the login account of the second application, the step of storing the correspondence between the first login account and the associated login account in the first server further includes: Receive a second login binding request for the first application, the second login binding request including an identity identifier, used to bind the identity identifier and the application login account; In response to the second login binding request, the identity identifier is bound and stored with the application login account, and the identity identifier is used as the first login account.

6. The method according to any one of claims 2-5, characterized in that, The authorization verification information is generated by the second server using a preset encryption algorithm to encrypt the currently logged-in account in the authorization verification request; The second server verifies the received authorization verification information by including: The received authorization verification information is decrypted using a decryption algorithm corresponding to the encryption algorithm to obtain the decrypted login account. The decrypted login account is then compared with the current login account in the authorization verification request. If the comparison matches, the verification is deemed successful.

7. The method according to any one of claims 1-2, characterized in that, The method further includes: Receive the login verification result sent by the first server; wherein the login verification result is the verification result of the first server performing login verification based on the current login account and the associated login account. If the current login account and the associated login account are the same, the verification result is considered successful. In the case that the verification result is successful, the target terminal identifier stored in the first server is updated to the first terminal identifier in the first login request. If the login verification result is successful, a second login request is sent to the first server. The second login request includes the first login account and the first terminal identifier, so that the first server can perform login verification of the first login account based on the first terminal identifier and the updated target terminal identifier. If the first login account is the same as the updated target terminal identifier, the login success result is sent to the client of the first application.

8. A login verification method, characterized in that, The method is executed by a first server of a first application, and the method includes: The receiving terminal sends a first login request through the client of the first application, the first login request including the first login account of the first application and the first terminal identifier of the terminal; If the first terminal identifier is different from the target terminal identifier, a verification instruction is sent to the client of the first application. The target terminal identifier is the terminal identifier stored in the first server that corresponds to the first login account. The verification instruction is used to trigger the client of the first application to display a login verification interface that includes login verification options. The login verification options include associated application verification options based on the associated applications of the first application. The system receives the current login account of the associated application from the second server of the associated application. The current login account is sent by the second server to the first server after receiving an authorization verification request from the client of the associated application. The authorization verification request is sent by the client of the first application to the second server in response to receiving a selection operation for the verification option of the associated application. Login verification is performed based on the current login account and the target mapping relationship stored in the first server. The target mapping relationship is the correspondence between the first login account and the associated login account. The associated login account is the login account of the associated application used when binding the login operation of the associated application with the login operation of the first application.

9. The method according to claim 8, characterized in that, The method further includes: The login verification result is sent to the client of the first application; wherein, the login verification result is the verification result of the first server based on the current login account and the associated login account. If the current login account and the associated login account are the same, the verification result is considered successful. If the login verification result is successful, the target terminal identifier is updated to the first terminal identifier; a second login request is received from the client of the first application, the second login request including the first login account and the first terminal identifier; The login verification of the first login account is performed based on the first terminal identifier and the updated target terminal identifier. If the first login account is the same as the updated target terminal identifier, the login success result is sent to the client of the first application.

10. A login verification method, characterized in that, include: The client of the first application running on the terminal sends a first login request to the first server of the first application. The first login request includes the first login account of the first application and the first terminal identifier of the terminal. The first server receives the first login request and, if the first terminal identifier is different from the target terminal identifier, sends a verification instruction to the client of the first application. The target terminal identifier is the terminal identifier stored in the first server that corresponds to the first login account. After receiving the verification instruction sent by the first server, the client of the first application displays a login verification interface, wherein the login verification interface displays login verification options, including associated application verification options based on the associated applications of the first application; After receiving the selection operation for the verification option of the associated application, the client of the first application sends an authorization verification request to the second server of the associated application through the client of the associated application running in the terminal; The second server receives the authorization verification request and sends the current login account of the associated application to the first server according to the authorization verification request; The first server receives the current login account sent by the second server and performs login verification based on the current login account and the associated login account in the target mapping relationship stored in the first server; The target mapping relationship is the correspondence between the first login account and the associated login account, and the associated login account is the login account of the associated application used when binding the login operation of the associated application with the first application.

11. A login verification device, characterized in that, A client for a first application running on a terminal, the device comprising: The module for sending a first login request is used to send a first login request to the first server of the first application. The first login request includes the first login account of the first application and the first terminal identifier of the terminal. The verification instruction receiving module is used to receive a verification instruction sent by the first server and display a login verification interface. The verification instruction is sent by the first server when it is determined that the first terminal identifier and the target terminal identifier are different. The target terminal identifier is a terminal identifier stored in the first server that corresponds to the first login account. The login verification interface displays login verification options, including associated application verification options based on the associated applications of the first application. The response selection operation module is used to respond to receiving a selection operation for the verification option of the associated application, and to send an authorization verification request to the second server of the associated application through the client of the associated application, so as to trigger the second server to send the current login account of the associated application to the first server, so that the first server can perform login verification based on the current login account and the associated login account in the target mapping relationship stored in the first server; wherein, the target mapping relationship is the correspondence between the first login account and the associated login account, and the associated login account is the login account of the associated application used when binding the login operation of the associated application with the first application.

12. A login verification device, characterized in that, The first server used for the first application includes: The module for receiving a first login request is configured to receive a first login request sent by the terminal through the client of the first application, wherein the first login request includes the first login account of the first application and the first terminal identifier of the terminal; The verification instruction sending module is used to send a verification instruction to the client of the first application when the first terminal identifier is different from the target terminal identifier. The target terminal identifier is a terminal identifier stored in the first server that corresponds to the first login account. The verification instruction is used to trigger the client of the first application to display a login verification interface that includes login verification options. The login verification options include associated application verification options based on the associated applications of the first application. The login account receiving module is used to receive the current login account of the associated application sent by the second server of the associated application. The current login account is sent by the second server to the first server after receiving an authorization verification request sent by the client of the associated application. The authorization verification request is sent by the client of the first application to the second server in response to receiving a selection operation for the verification option of the associated application. The verification module is used to perform login verification based on the current login account and the target mapping relationship stored in the first server. The target mapping relationship is the correspondence between the first login account and the associated login account. The associated login account is the login account of the associated application used when binding the login operation of the associated application with the login operation of the first application.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1-10.

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

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-10.

Images