Third-party account information management method and user authentication method

Abstract

The present invention discloses a third-party account information management method and a user authentication method. The method comprises: sending a session ID corresponding to the user identity identifier of the target user to the application front end corresponding to the target user; receiving a message to be bound sent by the application front end, wherein the message to be bound includes the session ID, the user identity identifier and the target platform; receiving account data sent by the application back end corresponding to the target platform, wherein the account data includes the third-party account information of the target user and the platform identity identifier of the target platform; binding and registering the user identity identifier, the third-party account information and the platform domain name of the target platform to obtain the platform account domain name of the target user; storing the platform account domain name in the registrar of the identity identifier domain. The present invention solves the technical problem that data such as user account information cannot be centrally managed due to the incompatibility between the application system and the distributed identity identification system in the related technology.

Description

Technical Field

[0001] The present invention relates to the technical field of information management, and in particular to a third-party account information management method and a user authentication method. Background Art

[0002] DID stands for Decentralized Identifiers. Users generate, manage, and control their own identities independently of institutions or governments. DIDs are globally unique, highly available, resolvable, and cryptographically verifiable. DIDs can be used to identify people, organizations, and things, and implement numerous security and privacy guarantees.

[0003] The user agent unit is an application that real users can use to identify their decentralized identities. Users can use it to generate DIDs, manage data and permissions, and issue / verify DID identity-related statements.

[0004] There are currently a large number of existing systems on the Internet, such as WeChat and Weibo. These systems use centralized user identity management and username / password verification methods. These systems are incompatible with distributed identity identification systems, and the cost of transformation is huge. Summary of the Invention

[0005] The embodiments of the present invention provide a third-party account information management method and a user authentication method to at least solve the technical problem that user account information and other data cannot be centrally managed due to the incompatibility between the application system and the distributed identity identification system in the related technology.

[0006] According to a first aspect of an embodiment of the present invention, a third-party account information management method is provided, which is applied to an identity identification domain, and the method includes: sending a session ID corresponding to the user identity of a target user to an application front-end corresponding to a target user; receiving a message to be bound sent by the application front-end, wherein the message to be bound includes the session ID, the user identity and the target platform; receiving account data sent by an application back-end corresponding to the target platform, wherein the account data includes the third-party account information of the target user and the platform identity of the target platform; binding and registering the user identity, the third-party account information and the platform domain name of the target platform to obtain the platform account domain name of the target user; and storing the platform account domain name in a registrar of the identity identification domain.

[0007] Furthermore, before receiving the binding message sent by the application front end, it also includes: encrypting the third-party account information according to the user private key of the target user through the application front end to obtain first encrypted data; and sending the first encrypted data and the session ID to the application back end through the application front end.

[0008] Furthermore, before receiving the account data sent by the application backend corresponding to the target platform, it also includes: decrypting the first encrypted data according to the user public key of the target user through the application backend to obtain the third-party account information; if the third-party account information matches the stored account information, encrypting the third-party account information and the platform domain name of the target platform according to the platform private key of the target platform through the application backend to obtain second encrypted data; and sending the second encrypted data and the session ID to the identity identification domain through the application backend.

[0009] Furthermore, the receiving the account data sent by the application backend corresponding to the target platform includes: decrypting the second encrypted data according to the platform public key of the target platform to obtain the account data.

[0010] Furthermore, storing the platform account domain name in the registrar of the identity identification domain includes: converting the platform account domain name into a hash value of a preset length; and storing the hash value in the registrar.

[0011] According to a second aspect of an embodiment of the present invention, a user authentication method is provided, which is applied to an application backend of a target platform, and the method comprises: sending a login request sent by an application frontend corresponding to a target user to a user identity service of an identity domain, wherein the login request carries a user identity corresponding to the target user; receiving an encrypted public key corresponding to the target user returned by the user identity service; authenticating the target user based on the encrypted public key; if the target user passes the verification, obtaining the target user's account information based on the user identity, and logging in the target user based on the account information.

[0012] Furthermore, before sending the login request sent by the application front end corresponding to the target user to the user identity identification service of the identity identification domain, it also includes: displaying the target login link and login ID of the target platform in the application interface corresponding to the application front end; receiving the login request, wherein the login request includes the user identity identification, the login ID and the target login link.

[0013] Furthermore, the receiving of the encryption public key corresponding to the target user returned by the user identity identification service includes: receiving the identity identification document corresponding to the target user returned by the user identity identification service, wherein the identity identification document is obtained after the user identity identification service parses the user identity; and obtaining the encryption public key from the identity identification document.

[0014] Furthermore, the identity authentication of the target user based on the encrypted public key includes: encrypting a preset verification code based on the encrypted public key to obtain an encrypted verification code; sending the encrypted verification code to a user identity identification platform so that the user identity identification platform decrypts the encrypted verification code to obtain a decrypted verification code; matching the decrypted verification code with the preset verification code, wherein the decrypted verification code is obtained by decrypting the encrypted verification code by the application front end.

[0015] Furthermore, if the target user passes the verification, the account information of the target user is obtained based on the user identity identifier, including: if the decrypted verification code matches the preset verification code, determining that the user identity identifier is a valid identity identifier; sending the user identity identifier to the identity identifier domain; receiving the platform account domain name returned by the identity identifier domain, wherein the platform account domain name includes the account information.

[0016] According to a third aspect of an embodiment of the present invention, a third-party account information management device is provided, which is applied to an identity identification domain, and the device includes: a sending module, which is used to send a session ID corresponding to the user identity of the target user to the application front end corresponding to the target user; a first receiving module, which is used to receive a message to be bound sent by the application front end, wherein the message to be bound includes the session ID, the user identity and the target platform; a second receiving module, which is used to receive account data sent by an application back end corresponding to the target platform, wherein the account data includes the third-party account information of the target user and the platform identity of the target platform; a processing module, which is used to bind and register the user identity, the third-party account information and the platform domain name of the target platform to obtain the platform account domain name of the target user; and a storage module, which is used to store the platform account domain name in the registrar of the identity identification domain.

[0017] According to the fourth aspect of an embodiment of the present invention, a user authentication device is provided, which is applied to an application backend of a target platform, and the device includes: a sending module, which is used to send a login request sent by an application frontend corresponding to a target user to a user identity service of an identity domain, wherein the login request carries a user identity corresponding to the target user; a receiving module, which is used to receive an encrypted public key corresponding to the target user returned by the user identity service; a verification module, which is used to authenticate the target user based on the encrypted public key; and an acquisition module, which is used to obtain the account information of the target user based on the user identity if the target user is verified, and log in the target user based on the account information.

[0018] According to the fifth aspect of an embodiment of the present invention, an electronic device is also provided, comprising a processor, a memory, and a program or instruction stored in the memory and executable on the processor. When the program or instruction is executed by the processor, the steps of the third-party account information management method described in the first aspect or the user authentication method described in the second aspect are implemented.

[0019] According to a sixth aspect of an embodiment of the present invention, a readable storage medium is further provided, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the third-party account information management method described in the first aspect or the user authentication method described in the second aspect are implemented.

[0020] In an embodiment of the present invention, a session ID corresponding to the target user's user identity is sent to the application front end corresponding to the target user; a pending binding message is received from the application front end, wherein the pending binding message includes the session ID, the user identity, and the target platform; account data is received from the application back end corresponding to the target platform, wherein the account data includes the target user's third-party account information and the platform identity of the target platform; the user identity, the third-party account information, and the platform domain name of the target platform are bound and registered to obtain the target user's platform account domain name; and the platform account domain name is stored in a register of the identity domain. Using the pending binding message sent by the application front end and the account data sent by the target platform, the user identity, the third-party account information, and the platform domain name are bound and registered to obtain the platform account domain name, and the platform account domain name is stored in a register of the identity domain. This method can manage and use the platform account domain name stored in the identity domain through the user identity, and manage the target user's third-party account information through the platform account domain name, thereby solving the technical problem in the related art where user account information and other data cannot be centrally managed due to incompatibility between the application system and the distributed identity system. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0022] Figure 1 is a schematic diagram of an optional application scenario according to an embodiment of the present invention;

[0023] Figure 2 is a flowchart of an optional third-party account information management method according to an embodiment of the present invention;

[0024] Figure 3 is a flow chart of an optional user authentication method according to an embodiment of the present invention;

[0025] Figure 4 is a flowchart of another optional user authentication method according to an embodiment of the present invention;

[0026] Figure 5 is a schematic diagram of a framework of an optional third-party account information management device according to an embodiment of the present invention;

[0027] Figure 6 2 is a schematic diagram of a framework of an optional user authentication device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0028] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0029] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0030] Example 1

[0031] Before introducing a third-party account information management method of this embodiment, the application scenario of the third-party account information management method of this embodiment is first described. Figure 1 FIG2 is a schematic diagram of an optional application scenario of a third-party account information management method according to this embodiment. The application scenario includes an application front-end 10, an application back-end 20, an identity domain DIDNS 30, an identity service DID service 40, and an identity application 50. The application scenario exists in a network including, but not limited to, a wide area network (WAN) or a local area network (LAN).

[0032] The application front-end 10 is a terminal device that includes applications for pre-defined services, such as mobile terminals, PCs, and microcomputers. The application back-end 20 is a server or cloud that supports the pre-defined services. The DIDNS 30 is used to store the platform account domain name corresponding to the target user's third-party account information; the DID service is used to manage and resolve the platform account domain name of the target user 40; and the identity application 50 is used to allocate and manage the corresponding identity identifiers (DIDs) for the target user and target platform.

[0033] In this embodiment, the identity identification domain DIDNS30 sends the session ID corresponding to the user identity of the target user to the application front end 10 corresponding to the target user; receives the message to be bound sent by the application front end 10, wherein the message to be bound includes the session ID, the user identity and the target platform; receives the account data sent by the application back end 20 corresponding to the target platform, wherein the account data includes the third-party account information of the target user and the platform identity of the target platform; binds and registers the user identity, the third-party account information and the platform domain name of the target platform to obtain the platform account domain name of the target user; and stores the platform account domain name in the registrar of the identity identification domain 30.

[0034] In the above embodiment, the user identity, third-party account information, and platform domain name are bound and registered using the binding message sent by the application front end and the account data sent by the target platform. This yields the platform account domain name, which is then stored in the registrar of the identity domain. This allows the platform account domain name stored in the identity domain to be managed and used using the user identity, allowing the target user's third-party account information to be managed using the platform account domain name.

[0035] According to an embodiment of the present invention, a third-party account information management method is provided, which is applied to the identity domain, such as Figure 2 As shown, the method specifically includes the following steps:

[0036] S202, sending the session ID corresponding to the user identity of the target user to the application front end corresponding to the target user;

[0037] S204, receiving a pending binding message sent by the application front end, wherein the pending binding message includes a session ID, a user identity identifier, and a target platform;

[0038] S206, receiving account data sent by the application backend corresponding to the target platform, wherein the account data includes the third-party account information of the target user and the platform identity of the target platform;

[0039] S208, binding and registering the user identity, third-party account information, and the platform domain name of the target platform to obtain the platform account domain name of the target user;

[0040] S210: Store the platform account domain name in the registrar of the identity domain.

[0041] In this embodiment, the application frontend includes, but is not limited to, user terminals such as mobile terminals, PCs, and microcomputers that have applications installed on them. The application backend is a server or cloud that supports the pre-defined service. The target platform is the platform corresponding to the pre-defined service, and the target platform is supported by the hardware of the application frontend and the application backend.

[0042] In addition, the identity domain in this embodiment is used to store the platform account domain name corresponding to the target user's third-party account information; the identity service (DID service) is used to manage, resolve and provide other services for the target user's platform account domain name; the identity application end is used to allocate and manage the corresponding identity DID for the target user and the target platform.

[0043] In this embodiment, the identity application includes, but is not limited to, a digital wallet application, which is used by target users, target platforms, and others to generate, manage, and control their own identity. The DID of the target user or platform is globally unique, resolvable, and cryptographically verifiable. DIDs are used to identify people, organizations, and things, providing security and privacy protection.

[0044] In this embodiment, the target user and the target platform each have a corresponding DID. Specifically, the target user has a corresponding user identity identifier, and the target platform has a corresponding identity identifier. In an application scenario of this embodiment, the user has a distributed identity identifier that can be mapped to a machine-readable identifier. The target user's user identity identifier is a string in a specific format that represents the digital identity of an entity.

[0045] For example, in the DID identifier “example:123456789abcdefghijk”, “example” is the identification method DID Method, and “123456789abcdefghijk” is the identification method special string DID Method Specific String.

[0046] Furthermore, platform account domain names are structured in a hierarchical domain name system, with dots separating domain names at different levels. Each level is called a domain, and the owner of a domain has full control over its subdomains. The top-level domain (.did) is owned by a smart contract called the "registrar," which specifies the rules governing the allocation of subdomains. Anyone can acquire ownership of a domain and use it for their own purposes, following the rules set out in these contracts. Subdomains within these domains represent organizations or platforms (such as IBM or WeChat). Users can configure subdomains for themselves or others as needed, such as "alice.weixin.did."

[0047] Specifically, the DIDNS architecture in this embodiment includes a registry and a resolver. The registry records each domain name's owner, the domain's resolver, and the TTL (the cached time-to-live) of all records associated with the domain. DIDNS maps domain names to the resolver responsible for resolving them. The resolver is responsible for converting domain names into DIDs. Both the DIDNS registry and resolver are standard blockchain smart contracts.

[0048] During the registration process for a target user's third-party account information on a target platform, the target user first initiates a session with the target platform, which includes a corresponding session ID. The identity domain is then bound to the target platform's domain name based on the session ID, user identity, platform identity, and corresponding account data, resulting in the target user's platform account domain name on the target platform.

[0049] For example, the DIDNS manager binds and registers "username.platform.did" with the DID to obtain the platform account domain name corresponding to the target user.

[0050] During this process, the manager in the identity domain generates a session ID for user authentication and returns it to the user. This session ID corresponds to the target user's user identity. The target user then sends their account data on the target platform to the target platform, and the session ID and the target platform's platform information are returned to the manager in the identity domain.

[0051] Next, the target platform verifies the target user's account data. Once the account data passes verification, it sends the target platform's platform domain name, account data, and session ID to the identity domain manager. Upon receiving the target platform's platform domain name, account data, and session ID, the identity domain manager binds the target user's account data and platform domain name to the user's identity, thus managing and registering the user's third-party account information based on the user's identity.

[0052] On the other hand, when the target platform verifies the target user's account data but the account data fails the verification, it does not send information to the manager of the identity domain or send a notification message of the account data verification failure, and the manager of the identity domain does not bind and register the target user's account data and the target platform.

[0053] In one example, taking target platform A as an example, the user identity b corresponding to target user B, the platform identity a of target platform A, and the account data C of target user B in target platform A, the above method may specifically include the following steps:

[0054] S21, the identity domain manager sends the session ID corresponding to the user identity b to the application front end corresponding to the target user B;

[0055] S22, target user B sends the account data and session ID for logging into target platform A to the target platform;

[0056] S23, target user A sends the session ID and platform information of the target platform to the manager of the identity domain;

[0057] S24, target platform B verifies target user A's account data;

[0058] S25, if the account data verification is successful, the platform domain name of the target platform A (network address information corresponding to the platform identity a), account data and session ID are sent to the manager of the identity domain;

[0059] S26, the manager of the identity domain binds and registers the platform domain name (network address information corresponding to the platform identity a), the account data, and the user identity b.

[0060] It should be noted that, through an embodiment of the present invention, a session ID corresponding to the target user's user identity is sent to the application front end corresponding to the target user; a pending binding message is received from the application front end, wherein the pending binding message includes the session ID, the user identity, and the target platform; account data is received from the application back end corresponding to the target platform, wherein the account data includes the target user's third-party account information and the platform identity of the target platform; the user identity, third-party account information, and the platform domain name of the target platform are bound and registered to obtain the target user's platform account domain name; and the platform account domain name is stored in the registrar of the identity domain. Through the pending binding message sent by the application front end and the account data sent by the target platform, the user identity, third-party account information, and platform domain name are bound and registered to obtain the platform account domain name, and the platform account domain name is stored in the registrar of the identity domain. This method can manage and use the platform account domain name stored in the identity domain through the user identity, and manage the target user's third-party account information through the platform account domain name, thereby solving the technical problem of the inability to centrally manage user account information and other data due to the incompatibility between the application system and the distributed identity system in the related art.

[0061] Optionally, in this embodiment, before receiving the binding message sent by the application front end, it also includes but is not limited to: encrypting the third-party account information according to the user private key of the target user through the application front end to obtain first encrypted data; sending the first encrypted data and session ID to the application back end through the application front end.

[0062] Specifically, in this embodiment, after the identity domain manager sends the session ID corresponding to the target user's identity to the application frontend, the application frontend encrypts the third-party account information, including but not limited to the target user's account name and password on the target platform, using the target user's private key. After encryption with the target user's DID private key, the encrypted data is generated as first encrypted data. The application frontend then sends the first encrypted data and the session ID to the application backend of the target platform.

[0063] Optionally, in this embodiment, before receiving the account data sent by the application backend corresponding to the target platform, it also includes but is not limited to: decrypting the first encrypted data according to the user public key of the target user through the application backend to obtain third-party account information; if the third-party account information matches the stored account information, encrypting the third-party account information and the platform domain name of the target platform according to the platform private key of the target platform through the application backend to obtain second encrypted data; and sending the second encrypted data and the session ID to the identity identification domain through the application backend.

[0064] Specifically, in this embodiment, after receiving the first encrypted data and session ID sent by the application front end, the application backend corresponding to the target platform decrypts the first encrypted data according to the user public key of the target user to obtain the third-party account information of the target user.

[0065] After obtaining the target user's third-party account information on the target platform's application backend, the third-party account information is verified. If the third-party account information matches the account information stored in the application backend, the third-party account information verification passes. The third-party account information and the target platform's platform domain name are encrypted using the target platform's platform private key to obtain second encrypted data. The target platform's platform domain name includes, but is not limited to, the target platform's name, platform ID, and network address.

[0066] Next, the application backend packages the second encrypted data and the session ID and sends them to the manager of the identity domain.

[0067] Furthermore, if the third-party account information does not match the account information stored in the application backend, the third-party account information verification fails and the third-party account information is not processed. In another example, if the third-party account information verification fails, a prompt indicating the failure and the session ID are sent to the manager of the identity domain.

[0068] It should be noted that, in this embodiment, the user public key of the target user is sent in advance to the application backend of the target platform and stored in the application backend, and the platform public key of the target platform is sent in advance to the manager of the identity domain and stored in the manager of the identity domain.

[0069] Through the above example, the target platform verifies the third-party account information of the target user.

[0070] Optionally, in this embodiment, receiving the account data sent by the application backend corresponding to the target platform includes but is not limited to: decrypting the second encrypted data according to the platform public key of the target platform to obtain the account data.

[0071] Specifically, after the manager of the identity domain receives the second encrypted data and session ID sent by the application backend, it obtains the platform public key corresponding to the target platform according to the session ID, and then connects the second encrypted data according to the platform public key to obtain the third-party account information corresponding to the target user.

[0072] Optionally, in this embodiment, storing the platform account domain name in the registrar of the identity domain includes but is not limited to: converting the platform account domain name into a hash value of a preset length; and storing the hash value in the registrar.

[0073] Specifically, in this embodiment, the platform account domain name can be stored in a hash value of a preset length, by converting the platform account domain name into a hash value of a preset length, and then storing the hash value in the registrar of the identity domain.

[0074] Through the above example, the storage space occupied by the platform account domain name can be reduced, the search speed of the registrar in the identity domain for the platform account domain name can be improved, and the system resources required to manage the platform account domain name can be reduced.

[0075] On the basis of the above-mentioned third-party account information management method, based on the same inventive concept and the same application scenario, this embodiment also proposes a user authentication method, which is applied to the application backend of the target platform, such as Figure 3 As shown, the method may specifically include the following steps:

[0076] S302: Send the login request sent by the application front end corresponding to the target user to the user identity service of the identity domain, wherein the login request carries the user identity corresponding to the target user;

[0077] S304, receiving the encrypted public key corresponding to the target user returned by the user identity identification service;

[0078] S306, authenticating the target user based on the encrypted public key;

[0079] S308: If the target user passes the verification, the target user's account information is obtained according to the user identity identifier, and the target user is logged in according to the account information.

[0080] Specifically, the application backend corresponding to the target platform receives the login request sent by the application frontend, and sends the login request to the user identity service corresponding to the identity domain. The parser in the user identity service parses the user identity and obtains the DID document corresponding to the user identity DID from the blockchain.

[0081] Next, the application backend obtains the encrypted public key in the DID document; then, the application backend initiates a challenge based on the decrypted public key to authenticate the target user; thus, the target user's account information is obtained based on the verification result of the target user's authentication.

[0082] Specifically, if the target user passes the verification, the application backend sends the user identity to the manager of the identity domain. The manager of the identity domain queries the user name matching the user identity DID and then returns the corresponding query result to the application backend.

[0083] On the other hand, the application front end polls the application back end for verification results at preset time intervals. If the query is successful, the application back end sends a session token to the application front end, indicating successful login; if the query fails, the application back end sends a prompt message indicating query failure to the application front end.

[0084] Optionally, in this embodiment, before sending the login request sent by the application front end corresponding to the target user to the user identity identification service of the identity identification domain, it also includes but is not limited to: displaying the target login link and login ID of the target platform in the application interface corresponding to the application front end; receiving the login request, wherein the login request includes the user identity identification, login ID and target login link.

[0085] For example, a QR code is displayed in the application interface corresponding to the application front-end. The QR code includes a target login link and a login ID for the target platform. A login request generated by the target user based on the target login link is received. For example, the target user scans the QR code to generate a login request.

[0086] In one example, the target user selects DID login authentication on the APP login interface on the front-end of the application, obtains the session identifier (loginID) and the APP back-end login address (LoginURL) from the APP back-end, and displays a QR code on the front-end of the APP. The QR code carries the loginID and LoginURL (or other forms of carrying the above information, such as the corresponding hexadecimal code). The APP front-end carries the loginID and initiates asynchronous polling to the application back-end at a preset frequency. The target user uses the digital wallet on the mobile terminal (the digital wallet acts as a user agent application to store and manage the DID) to identify the QR code, obtain the loginID and LoginURL (or obtain the above information through other forms), and authorize login.

[0087] Through the above example, the target login link and login ID of the target platform are displayed in the application interface corresponding to the application front end; after receiving the login request, the target user logs in to the target platform with the help of the user identity, making the login operation of the target user simple and secure.

[0088] Optionally, in this embodiment, receiving the encryption public key corresponding to the target user returned by the user identity identification service includes but is not limited to: receiving the identity identification document corresponding to the target user returned by the user identity identification service, wherein the identity identification document is obtained after the user identity identification service parses the user identity; obtaining the encryption public key from the identity identification document.

[0089] Specifically, in this embodiment, the mobile digital wallet APP front-end sends the loginID and DID to the LoginURL. After receiving the loginID and DID, the APP back-end sends the DID to the resolver of DIDNS in the DID service; then, based on the resolution result, the DID document corresponding to this DID is obtained from the blockchain (and the document integrity is checked by comparing the hash value); next, the APP back-end obtains the encrypted public key in the DID document.

[0090] Optionally, in this embodiment, the target user is authenticated based on the encrypted public key, including but not limited to: encrypting a preset verification code based on the encrypted public key to obtain an encrypted verification code; sending the encrypted verification code to the user identity identification platform so that the user identity identification platform decrypts the encrypted verification code to obtain a decrypted verification code; matching the decrypted verification code with the preset verification code, wherein the decrypted verification code is obtained by decrypting the encrypted verification code by the application front end.

[0091] Specifically, in this embodiment, the app backend uses this public key to initiate a challenge. For example, it uses the encryption public key to encrypt an initial random number (preset verification code). The resulting encrypted verification code is sent to the mobile digital wallet (user identity platform). The mobile digital wallet uses the encryption private key corresponding to the DID to decrypt the encrypted result to obtain the decrypted verification code of the aforementioned random number. The mobile digital wallet then sends the decrypted verification code and loginID to the app backend. The app backend then verifies the challenge result by comparing the received decrypted verification code with the initial random number (preset verification code).

[0092] Optionally, in this embodiment, if the target user passes the verification, the target user's account information is obtained based on the user identity identifier, including but not limited to: if the decrypted verification code matches the preset verification code, determining that the user identity identifier is a valid identity identifier; sending the user identity identifier to the identity identifier domain; receiving the platform account domain name returned by the identity identifier domain, wherein the platform account domain name includes account information.

[0093] Specifically, if the decrypted verification code and the initial random number (preset verification code) match, it means that the challenge response is successful, the DID is a valid identity identifier, and the identity authentication is successful; if the decrypted verification code and the initial random number (preset verification code) do not match, it means that the challenge response fails, the DID is an invalid identity identifier, and the identity authentication fails.

[0094] In this embodiment, after confirming that the user identity is valid, the user identity is sent to the identity domain, and the platform account domain name returned by the identity domain is received. Specifically, the app backend sends the DID to DIDNS, which queries the DIDNS for the user name that matches the DID and returns the query result to the app backend.

[0095] Through the above example, on the one hand, autonomous storage of the target user's identity information is achieved; on the other hand, the target user's identity authentication system application and verification component are separated, and the preset application can obtain user usage information but cannot obtain user identity information, thereby avoiding the preset application from collecting user identity information.

[0096] As a specific embodiment, Figure 4 As shown, the user authentication method may specifically include the following steps:

[0097] S401. The user selects DID login authentication on the APP login interface;

[0098] Specifically, the session identifier (loginID) and the login URL (LoginURL) are obtained from the APP backend, and a QR code is displayed on the APP frontend. The QR code carries the loginID and LoginURL (or other forms of the above information, such as the corresponding hexadecimal code). The APP frontend carries the loginID and initiates asynchronous polling to the APP backend at a preset frequency.

[0099] S402. Get loginID and LoginURL through the digital wallet;

[0100] Specifically, the user uses the digital wallet of the mobile terminal (the digital wallet serves as a user agent application for storing and managing the DID) to identify the QR code to obtain the loginID and LoginURL (or obtain the above information through other forms) and authorize the login.

[0101] S403. The mobile digital wallet sends the loginID and DID to the LoginURL;

[0102] S404. Send the DID to the DID service;

[0103] Specifically, after the APP backend receives the loginID and DID, it sends the DID to the DID resolver in the DID service.

[0104] S405. Get the DID document;

[0105] Specifically, based on the parsing results, the DID document corresponding to this DID is obtained from the blockchain (and the document integrity is checked by hash value comparison).

[0106] S406. The app backend obtains the public key in the document;

[0107] S407. Send the encrypted result to the digital wallet;

[0108] Specifically, the APP backend uses this public key to initiate a challenge, such as using the public key to encrypt a random number, and sends the encrypted result to the digital wallet.

[0109] S408. Decrypt the encrypted result;

[0110] Specifically, the mobile digital wallet uses the private key corresponding to the DID to decrypt the above encryption result to obtain the plaintext of the aforementioned random number;

[0111] S409. The digital wallet sends the plain text and loginID to the APP backend;

[0112] S410. APP backend performs identity authentication;

[0113] Specifically, the APP backend verifies the challenge result, that is, compares the received plaintext and the initial random number. If they are equal, it means that the challenge-response is successful, the DID is a valid identity identifier, and the identity authentication is successful.

[0114] S411. The app backend sends the DID to DIDNS;

[0115] S412. DIDNS queries the username that matches the DID;

[0116] S413. DIDNS returns the query result to the APP backend;

[0117] S414. The APP front-end polls the back-end to obtain the authentication result;

[0118] Specifically, if the query is successful, the APP backend sends a session token to the frontend, indicating that the login is successful; otherwise, if the query fails, it means that the login failed.

[0119] Through the above embodiment, the session ID corresponding to the user identity of the target user is sent to the application front end corresponding to the target user; the binding message sent by the application front end is received, wherein the binding message includes the session ID, the user identity and the target platform; the account data sent by the application back end corresponding to the target platform is received, wherein the account data includes the third-party account information of the target user and the platform identity of the target platform; the user identity, the third-party account information and the platform domain name of the target platform are bound and registered to obtain the platform account domain name of the target user; and the platform account domain name is stored in the registrar of the identity domain. Through the binding message sent by the application front end and the account data sent by the target platform, the user identity, the third-party account information and the platform domain name are bound and registered to obtain the platform account domain name, and the platform account domain name is stored in the registrar of the identity domain. It is possible to manage and use the platform account domain name stored in the identity domain through the user identity, and manage the third-party account information of the target user through the platform account domain name, thereby solving the technical problem that user account information and other data cannot be centrally managed due to the incompatibility between the application system and the distributed identity system in the related art.

[0120] It should be noted that for the aforementioned method embodiments, for simplicity of description, they are all expressed as a series of action combinations. However, those skilled in the art should be aware that the present invention is not limited by the order of the actions described, because according to the present invention, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present invention.

[0121] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present invention.

[0122] Example 2

[0123] According to an embodiment of the present invention, a third-party account information management device for implementing the third-party account information management method is also provided, which is applied to the identity identification domain, such as Figure 5 As shown, the device includes:

[0124] 1) A sending module 50 is configured to send a session ID corresponding to the user identity of the target user to the application front end corresponding to the target user;

[0125] 2) A first receiving module 52, configured to receive a to-be-bound message sent by the application front end, wherein the to-be-bound message includes the session ID, the user identity, and the target platform;

[0126] 3) A second receiving module 54, configured to receive account data sent by the application backend corresponding to the target platform, wherein the account data includes the third-party account information of the target user and the platform identity of the target platform;

[0127] 4) a processing module 56 for binding and registering the user identity, the third-party account information, and the platform domain name of the target platform to obtain the platform account domain name of the target user;

[0128] 5) A storage module 58, configured to store the platform account domain name in the registrar of the identity domain.

[0129] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiment 1, and this embodiment will not be repeated here.

[0130] According to an embodiment of the present invention, a user authentication device for implementing the above user authentication method is also provided, which is applied to the application backend of the target platform, such as Figure 6 As shown, the device includes:

[0131] The sending module 60 is used to send the login request sent by the application front end corresponding to the target user to the user identity service of the identity domain, wherein the login request carries the user identity corresponding to the target user;

[0132] A receiving module 62 is configured to receive the encrypted public key corresponding to the target user returned by the user identity service;

[0133] A verification module 64 is configured to authenticate the target user based on the encryption public key;

[0134] The acquisition module 66 is configured to acquire the target user's account information according to the user identity identifier if the target user passes the verification, and log in the target user according to the account information.

[0135] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiment 1, and this embodiment will not be repeated here.

[0136] Example 3

[0137] According to an embodiment of the present invention, an electronic device is also provided, including a processor, a memory, and a program or instruction stored in the memory and executable on the processor. When the program or instruction is executed by the processor, the steps of the third-party account information management method or user authentication method as described above are implemented.

[0138] Optionally, in this embodiment, the memory is configured to store program codes for executing the following steps:

[0139] S1, sending the session ID corresponding to the user identity of the target user to the application front end corresponding to the target user;

[0140] S2, receiving a message to be bound sent by the application front end, wherein the message to be bound includes the session ID, the user identity identifier, and the target platform;

[0141] S3, receiving account data sent by the application backend corresponding to the target platform, wherein the account data includes the third-party account information of the target user and the platform identity of the target platform;

[0142] S4, binding and registering the user identity, the third-party account information, and the platform domain name of the target platform to obtain the platform account domain name of the target user;

[0143] S5: Store the platform account domain name in the registrar of the identity domain.

[0144] Optionally, in this embodiment, the memory is configured to store program codes for executing the following steps:

[0145] S1, sending a login request sent by the application front end corresponding to the target user to the user identity service of the identity domain, wherein the login request carries the user identity corresponding to the target user;

[0146] S2, receiving the encryption public key corresponding to the target user returned by the user identity identification service;

[0147] S3, authenticating the target user according to the encrypted public key;

[0148] S4: If the target user passes the verification, the target user's account information is obtained according to the user identity identifier, and the target user is logged in according to the account information.

[0149] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiment 1, and this embodiment will not be described in detail here.

[0150] Example 4

[0151] An embodiment of the present invention further provides a readable storage medium storing a program or instruction. When the program or instruction is executed by a processor, the steps of the third-party account information management method or user authentication method described above are implemented.

[0152] Optionally, in this embodiment, the readable storage medium is configured to store program codes for executing the following steps:

[0153] S1, sending the session ID corresponding to the user identity of the target user to the application front end corresponding to the target user;

[0154] S2, receiving a message to be bound sent by the application front end, wherein the message to be bound includes the session ID, the user identity identifier, and the target platform;

[0155] S3, receiving account data sent by the application backend corresponding to the target platform, wherein the account data includes the third-party account information of the target user and the platform identity of the target platform;

[0156] S4, binding and registering the user identity, the third-party account information, and the platform domain name of the target platform to obtain the platform account domain name of the target user;

[0157] S5: Store the platform account domain name in the registrar of the identity domain.

[0158] Optionally, in this embodiment, the readable storage medium is configured to store program codes for executing the following steps:

[0159] S1, sending a login request sent by the application front end corresponding to the target user to the user identity service of the identity domain, wherein the login request carries the user identity corresponding to the target user;

[0160] S2, receiving the encryption public key corresponding to the target user returned by the user identity identification service;

[0161] S3, authenticating the target user according to the encrypted public key;

[0162] S4: If the target user passes the verification, the target user's account information is obtained according to the user identity identifier, and the target user is logged in according to the account information.

[0163] Optionally, the readable storage medium is further configured to store program codes for executing the steps included in the method in the above-mentioned embodiment 1, which will not be described in detail in this embodiment.

[0164] Optionally, in this embodiment, the above-mentioned readable storage medium may include but is not limited to: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and other media that can store program codes.

[0165] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiment 1, and this embodiment will not be described in detail here.

[0166] The serial numbers of the above embodiments of the present invention are for description only and do not represent the advantages or disadvantages of the embodiments.

[0167] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above-mentioned computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the existing technology, or all or part of the technical solution can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes a number of instructions for causing one or more computer devices (such as personal computers, servers, or network devices) to execute all or part of the steps of the methods described in various embodiments of the present invention.

[0168] In the above embodiments of the present invention, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0169] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. Among them, the device embodiments described above are merely illustrative. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, and can be electrical or other forms.

[0170] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0171] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0172] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. A third-party account information management method, characterized in that: Applied to the identity domain, the method includes: Send the session ID corresponding to the target user's user identity to the application front end corresponding to the target user; Encrypting the third-party account information according to the target user's private key through the application front end to obtain first encrypted data; Sending the first encrypted data and the session ID to the application backend via the application frontend; Receive a binding message sent by the application front end, wherein the binding message includes the session ID, the user identity identifier, and the target platform; Receiving account data sent by an application backend corresponding to the target platform, wherein the account data includes third-party account information of the target user and a platform identity identifier of the target platform; Binding and registering the user identity, the third-party account information, and the platform domain name of the target platform to obtain the platform account domain name of the target user; The platform account domain name is stored in the registrar of the identity domain.

2. The method according to claim 1, characterized in that Before receiving the account data sent by the application backend corresponding to the target platform, the method further includes: Decrypting the first encrypted data according to the public key of the target user through the application backend to obtain the third-party account information; If the third-party account information matches the storage account information, encrypting the third-party account information and the platform domain name of the target platform according to the platform private key of the target platform through the application backend to obtain second encrypted data; The second encrypted data and the session ID are sent to the identity identification domain through the application backend.

3. The method according to claim 2, characterized in that The receiving the account data sent by the application backend corresponding to the target platform includes: The second encrypted data is decrypted according to the platform public key of the target platform to obtain the account data.

4. The method according to claim 1, wherein Storing the platform account domain name in the registrar of the identity domain includes: Convert the platform account domain name into a hash value of a preset length; The hash value is stored in the register.

5. A user authentication method, characterized in that: Applied to the application backend of the target platform, the method includes: Sending the login request sent by the application front end corresponding to the target user to the user identity service of the identity domain, wherein the login request carries the user identity corresponding to the target user; Receive the encrypted public key corresponding to the target user returned by the user identity identification service; authenticating the target user according to the encrypted public key; If the target user passes the verification, the account information of the target user is obtained according to the user identity identifier, the user identity identifier is used to obtain the platform account domain name of the target user from the registrar of the identity identifier domain, the platform account domain name includes the account information, the platform account domain name includes the user identity identifier, third-party account information and the platform domain name of the target platform, the third-party account information is obtained based on the account data sent by the application backend corresponding to the target platform, the account data includes the platform identity identifier of the target platform, the platform domain name of the target platform is obtained based on the network address information corresponding to the platform identity identifier of the target platform, and the target user is logged in according to the account information; The step of authenticating the target user according to the encrypted public key includes: Encrypting the preset verification code according to the encryption public key to obtain an encrypted verification code; Sending the encrypted verification code to the user identity identification platform so that the user identity identification platform decrypts the encrypted verification code to obtain a decrypted verification code; The decrypted verification code is matched with the preset verification code, wherein the decrypted verification code is obtained by the application front end decrypting the encrypted verification code.

6. The method according to claim 5, characterized in that Before sending the login request sent by the application front end corresponding to the target user to the user identity service of the identity domain, the method further includes: In the application interface corresponding to the application front end, the target login link and login ID of the target platform are displayed; The login request is received, wherein the login request includes the user identity, the login ID, and the target login link.

7. The method according to claim 5, characterized in that The receiving the encryption public key corresponding to the target user returned by the user identity identification service includes: Receive an identity document corresponding to the target user returned by the user identity service, wherein the identity document is obtained by the user identity service after parsing the user identity; The encryption public key is obtained from the identity document.

8. The method according to claim 5, characterized in that If the target user passes the verification, obtaining the target user's account information according to the user identity identifier includes: If the decrypted verification code matches the preset verification code, determining that the user identity is a valid identity; Sending the user identity to the identity domain; Receive the platform account domain name returned by the identity domain, wherein the platform account domain name includes the account information.

9. A third-party account information management device, characterized in that: Applied to the identity identification domain, the device includes: A sending module is used to send the session ID corresponding to the user identity of the target user to the application front end corresponding to the target user; a first receiving module, configured to receive a to-be-bound message sent by the application front end, wherein the to-be-bound message includes the session ID, the user identity identifier, and the target platform; the application front end is configured to send first encrypted data and the session ID to an application back end corresponding to the target platform, where the first encrypted data is obtained by encrypting the third-party account information of the target user based on the user private key of the target user; A second receiving module is configured to receive account data sent by an application backend corresponding to the target platform, wherein the account data includes the third-party account information of the target user and the platform identity of the target platform; a processing module, configured to bind and register the user identity, the third-party account information, and the platform domain name of the target platform to obtain the platform account domain name of the target user; A storage module is used to store the platform account domain name in the registrar of the identity domain.

10. A user authentication device, characterized in that: The application backend applied to the target platform includes: A sending module, configured to send a login request sent by an application front end corresponding to a target user to a user identity service of an identity domain, wherein the login request carries a user identity corresponding to the target user; A receiving module, configured to receive the encrypted public key corresponding to the target user returned by the user identity identification service; A verification module is configured to authenticate the target user based on the encryption public key, wherein the application front end is configured to decrypt the encrypted verification code to obtain a decrypted verification code, wherein the decrypted verification code is obtained by decrypting the encrypted verification code based on the user identity identification platform, and the encrypted verification code is obtained by encrypting a preset verification code based on the encryption public key; An acquisition module is used to obtain the account information of the target user based on the user identity if the target user passes the verification. The user identity is used to obtain the platform account domain name of the target user from the registrar of the identity domain. The platform account domain name includes the account information. The platform account domain name includes the user identity, third-party account information and the platform domain name of the target platform. The third-party account information is obtained based on the account data sent by the application backend corresponding to the target platform. The account data includes the platform identity of the target platform. The platform domain name of the target platform is obtained based on the network address information corresponding to the platform identity of the target platform, and the target user is logged in according to the account information.

11. An electronic device, characterized in that: It includes a processor, a memory, and a program or instruction stored in the memory and executable on the processor, wherein when the program or instruction is executed by the processor, the steps of the third-party account information management method according to any one of claims 1 to 4 or the user authentication method according to any one of claims 5 to 8 are implemented.

12. A readable storage medium, characterized in that: The readable storage medium stores a program or instruction, and when the program or instruction is executed by the processor, the steps of the third-party account information management method according to any one of claims 1 to 4 or the user authentication method according to any one of claims 5 to 8 are implemented.

Images