Identity authentication method and device and electronic equipment

Abstract

The invention discloses an identity authentication method and device and electronic equipment. The method comprises the following steps: a key identity management service obtains login request information of a target object in a business system; the key identity management service determines a target object identity identifier of the target object according to the business system identity identifier; the secret key identity management service performs digital signature on the login request information by using a private key associated with the target object identity identifier to obtain a login signature; and the key identity management service returns the login signature to the service system. According to the method and the device, the technical problems that the user needs to manage different keys among different enterprises, and the key management cost is high are solved.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and more specifically, to an identity authentication method, device, and electronic device. Background Art

[0002] In the user identity authentication methods adopted by related technologies, the private key generally comes from the enterprise side. For example, each bank issues digital certificates to its customers. The holder of the private key is not unique, and the keys of different enterprises are not interchangeable. Users need to manage different keys between different enterprises, and the key management cost is high.

[0003] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0004] The embodiments of the present application provide a method, device, and electronic device for identity authentication to at least solve the technical problem that users need to manage different keys between different enterprises and the key management cost is high.

[0005] According to one aspect of an embodiment of the present application, a method for identity authentication is provided, including: a key identity management service obtains login request information of a target object in a business system, wherein the login request information includes a business system identity identifier of the business system; the key identity management service determines a target object identity identifier of the target object based on the business system identity identifier, wherein the target object identity identifier is used by the business system to verify the authenticity of the target object; the key identity management service uses a private key associated with the target object identity identifier to perform a digital signature on the login request information to obtain a login signature, wherein the target object identity identifier corresponds to a set of private keys and public keys, and the public key is decoupled from the business system; the key identity management service returns the login signature to the business system, wherein the login signature is used by the business system to authenticate the target object using the public key obtained from the identity resolution service, and the identity resolution service is used to store the association between the target object identity identifier and the public key.

[0006] In some embodiments of the present application, before the key identity management service determines the target object identity identifier of the target object based on the business system identity identifier, the method also includes: determining whether the login request information includes the first target object identity identifier, and obtaining a judgment result; when the judgment result indicates that the login request information includes the first target object identity identifier, the key identity management service uses the private key associated with the first target object identity identifier to perform a digital signature on the login request information.

[0007] In some embodiments of the present application, when the key identity management service cannot determine the target object identity identifier of the target object based on the business system identity identifier, the method also includes: the key identity management service initiates user account registration to the business system, and binds the business system to the second target object identity identifier of the target object.

[0008] In some embodiments of the present application, before the key identity management service uses the private key associated with the target object identity identifier to perform a digital signature on the login request information, the method also includes: obtaining business information corresponding to the business system from the login request information, wherein the business information includes the business system identity identifier and the business signature, and the business signature is determined based on the private key of the business system; determining the first public key corresponding to the business system identity identifier in the identity resolution service; and verifying the business signature using the first public key to obtain a first verification result, wherein the first verification result is used by the key identity management service to verify the authenticity of the business system and indicate whether to continue the login.

[0009] In some embodiments of the present application, the key identity management service returns the login signature to the business system, including: obtaining a first callback address from the login request information, wherein the first callback address is the path used by the business system to receive the login signature; and using the first callback address to return the login signature to the business system.

[0010] In some embodiments of the present application, when the key identity management service verifies the authenticity of the business system, the key identity management service returns the login signature to the business system, including: determining the second callback address corresponding to the business system from the identity resolution service; and using the second callback address to return the login signature to the business system.

[0011] In some embodiments of the present application, the business system authenticates the target object in the following manner: the business system obtains the target object identity identifier from the login signature; the business system determines the second public key corresponding to the target object identity identifier in the identity resolution service; the business system uses the second public key to verify the login signature to obtain a second verification result, wherein the second verification result is used to indicate whether the target object has passed the identity authentication.

[0012] In some embodiments of the present application, the key identity management service is used for at least one of the following: managing the public-private key pair corresponding to the target object, the three-element relationship between the target object identity identifier and the public key and the identity resolution service access point, the registration relationship of the target object in multiple business systems, and the digital certificate of the target object issued by the third-party digital identity owner within the validity period.

[0013] In some embodiments of the present application, the target object corresponds to at least one target object identity identifier, wherein each target object identity identifier corresponds to a set of private keys and public keys, the correspondence between each target object identity identifier and the public key is registered to the identity resolution service, and each target object identity identifier corresponds to one or more business systems.

[0014] In some embodiments of the present application, the method further includes: updating the key corresponding to the target object identity identifier according to a preset period, obtaining an updated public key and an updated private key, and sending the updated public key to the identity resolution service.

[0015] According to another aspect of the embodiment of the present application, an identity authentication system is also provided, including a key identity management service, a business system, and an identity resolution service, wherein the key identity management service is connected to the identity resolution service and the business system, respectively, and is used to obtain the login request information of the target object in the business system, and digitally sign the login request information based on the private key associated with the target object identity identifier of the target object in the business system to obtain a login signature, and return the login signature to the business system, wherein the target object identity identifier corresponds to a set of private keys and public keys, and the public key is decoupled from the business system; the identity resolution service is connected to the key identity management service, and is used to store the association relationship between the target object identity identifier and the public key of the target object; the business system is connected to the key identity management service and the identity resolution service, respectively, and is used to receive the login signature, and use the public key and login signature obtained from the identity resolution service to authenticate the target object.

[0016] According to another aspect of the embodiment of the present application, an identity authentication device is also provided, including: an acquisition module, used by the key identity management service to obtain login request information of the target object in the business system, wherein the login request information includes the business system identity identifier of the business system; a determination module, used by the key identity management service to determine the target object identity identifier of the target object based on the business system identity identifier, wherein the target object identity identifier is used by the business system to verify the authenticity of the target object; a signature module, used by the key identity management service to digitally sign the login request information using the private key associated with the target object identity identifier to obtain a login signature, wherein the target object identity identifier corresponds to a set of private keys and public keys, and the public key is decoupled from the business system; a return module, used by the key identity management service to return the login signature to the business system, wherein the login signature is used by the business system to authenticate the target object using the public key obtained from the identity resolution service, and the identity resolution service is used to store the association relationship between the target object identity identifier and the public key.

[0017] According to another aspect of the embodiments of the present application, an electronic device is provided, including: a memory and a processor, the memory being used to store program instructions; the processor being connected to the memory and being used to execute the above-mentioned identity authentication method.

[0018] According to another aspect of the embodiments of the present application, a non-volatile storage medium is provided, which includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the above-mentioned identity authentication method by running the computer program.

[0019] According to another aspect of the embodiments of the present application, a computer program product is provided, including computer instructions, which implement the above-mentioned identity authentication method when executed by a processor.

[0020] In an embodiment of the present application, the key identity management service uses the digital identity of the target object to interact with the business system. The login request information is encrypted by using the private key corresponding to the target object identity identifier. The business system decrypts the public key obtained from the identity resolution service to authenticate the target object. This achieves the purpose of the business system not participating in the creation of private keys and the user not needing to remember and store the password of the business system, thereby realizing the technical effect of unified management of account passwords for multiple business systems by users, and further solving the technical problem that users need to manage different keys between different enterprises and the key management cost is high. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0022] Figure 1 This is a hardware structure block diagram of a computer terminal according to an identity authentication method according to an embodiment of the present application;

[0023] Figure 2 is a flow chart of an identity authentication method according to an embodiment of the present application;

[0024] Figure 3a This is a schematic diagram of a target object using the same identity identifier in multiple occasions according to an identity authentication method of an embodiment of the present application;

[0025] Figure 3b This is a schematic diagram of a target object using different identity identifiers in different situations according to an identity authentication method according to an embodiment of the present application;

[0026] Figure 4 This is a system architecture diagram of an identity authentication method according to an embodiment of the present application;

[0027] Figure 5 This is a KIMS architecture diagram of an identity authentication method according to an embodiment of the present application;

[0028] Figure 6 This is a business system architecture diagram of an identity authentication method according to an embodiment of the present application;

[0029] Figure 7 This is a system interaction diagram of an identity authentication method according to an embodiment of the present application;

[0030] Figure 8 This is a public device login flow chart of an identity authentication method according to an embodiment of the present application;

[0031] Figure 9 This is a dedicated device login flow chart of an identity authentication method according to an embodiment of the present application;

[0032] Figure 10 It is a structural diagram of an identity authentication device according to an embodiment of the present application. DETAILED DESCRIPTION

[0033] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in 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 this application.

[0034] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising 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.

[0035] In order to better understand the embodiments of the present application, the technical terms involved in the embodiments of the present application are explained as follows:

[0036] Keys & Identity Management System (KIMS): The user's personal end system mentioned in this application is independent of the business system and is used to manage the user's public and private keys and digital identity (digital identity naturally has a key pair). The KIMS system can be regarded as an individual's digital agent, responsible for creating, storing, changing and applying personal keys and digital identity, ensuring that users have full control over their digital identity and privacy.

[0037] Identity Keys Service (IKS): Also known as identity resolution service, it is a public service in this application. Similar to how DNS resolves the relationship between domain names and IP addresses, IKS resolves the relationship between digital identity identifiers and public keys. IKS enables other entities on the network to obtain the corresponding public key by querying the digital identity identifier, which is used for operations such as verifying digital signatures.

[0038] Due to the strengthening of internal control and other security checks, current IT systems are constantly strengthening user login security. The traditional user authentication method is password authentication, that is, username + password authentication, which is one of the most common authentication methods in information systems. This authentication method is a static password authentication technology. Users need to enter a username and password when logging in, and the legitimacy of the user is confirmed by matching the passwords. However, the disadvantage of this method is that if the user chooses a simple or easily guessed password, the security of the system will be reduced. In addition to password authentication, there are several other common identity authentication methods in related technologies:

[0039] (1) USB KEY + PIN code authentication: This authentication method uses the smart card chip built into the USB KEY to store the user's private key and digital certificate. The user needs to enter the correct PIN code to obtain the private key and certificate, and then the public key algorithm built into the USB KEY is used to authenticate the user. The USB KEY and PIN code are two necessary factors for authentication, and neither is indispensable. In this method, the USB KEY is provided by the enterprise, which increases costs. It is not universal across different enterprises and is not user-friendly.

[0040] (2) Biometric authentication: This is an authentication method based on the unique, reliable, and stable biometric features of the human body (such as fingerprints, irises, faces, palm prints, etc.). The most common biometric authentication method is fingerprint recognition. Users only need to enter fingerprint information to confirm their identity. This authentication method has high security, but due to its relatively high implementation cost, it is currently deployed in more important information systems. This method also faces some ethical and privacy challenges. For example, once the biometric feature is leaked, it cannot be changed, unlike the traditional password that can be reset. In terms of system architecture, it is similar to the password method, except that the password is replaced by a biometric feature. The enterprise needs to collect the user's biometric feature and implement security internal control measures for this sensitive information.

[0041] (3) Cryptography authentication / electronic certificate authentication: Identity authentication based on cryptography principles, such as digital signatures and encryption algorithms, is highly secure and difficult to crack, and is an important means to ensure network security. However, the cryptography authentication process is relatively complex and requires high user operation. Digital certificates are also based on cryptography principles. The difference is that they are issued by an authoritative third-party organization and contain important information such as the user's personal information and public key. Electronic certificates can be used in online transactions, electronic banking and other fields, and have high security and credibility. However, the application and management of electronic certificates require a certain cost and time, and the private key is issued by a third party. The holder of the private key is not unique. At the same time, the key needs to be changed periodically. This method is also not suitable for users to use one key / certificate across systems.

[0042] (4) FIDO authentication: It belongs to cryptographic authentication. The FIDO method includes two components: authenticator and relying party. The private key is created in the authenticator (dedicated software / hardware). Unlike CA certificates issued by third-party institutions, the FIDO method returns private information such as keys and biometrics to the control of the owner (authenticator) and supports cross-system use (relying party). However, the object managed by the FIDO authenticator is the key pair, and the life cycle of the key does not match the life cycle of the identity. When the key life cycle expires and needs to be changed, all servers associated with the public key need to be notified of the change.

[0043] In order to solve the above technical problems, the embodiments of the present application provide corresponding solutions, which are described in detail below.

[0044] The identity authentication method embodiment provided in the embodiment of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 FIG1 shows a hardware structure block diagram of a computer terminal for implementing an identity authentication method. Figure 1As shown, the computer terminal 10 may include one or more (illustrated by 102a, 102b, ..., 102n in the figure) processors (the processor may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission module 106 for communication functions connected via a wired and / or wireless network. In addition, it may also include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0045] It should be noted that the one or more processors and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry." The data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be incorporated in whole or in part into any of the other components of the computer terminal 10. As described in the embodiments of the present application, the data processing circuitry serves as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0046] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the identity authentication method in the embodiment of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, implementing the above-mentioned identity authentication method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely located relative to the processor, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0047] The transmission module 106 is configured to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by the communications provider of the computer terminal 10. In one embodiment, the transmission module 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, the transmission module 106 may be a radio frequency (RF) module, which is configured to communicate with the Internet wirelessly.

[0048] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 .

[0049] It should be noted that, in some optional embodiments, the above Figure 1 The computer terminal shown may include hardware elements (including circuits), software elements (including computer code stored on a computer-readable medium), or a combination of hardware elements and software elements. Figure 1 This is merely one example of a particular embodiment and is intended to illustrate the types of components that may be present in the computer terminal described above.

[0050] In the above-mentioned operating environment, an embodiment of the present application provides an embodiment of a method for identity authentication. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0051] Figure 2 This is a flow chart of an identity authentication method according to an embodiment of the present application. The execution subject of this method is a key identity management system (KIMS). Figure 2 As shown, the method includes the following steps:

[0052] Step S202: The key identity management service obtains login request information of the target object in the business system, wherein the login request information includes a business system identity identifier of the business system.

[0053] In the above step S202, the target object refers to the user who wishes to log in to the business system. The business system refers to a software application provided by an enterprise or organization to support various business activities, such as customer service, employee management, supply chain collaboration, etc. In some embodiments of the present application, the business system includes a front-end (client) and a back-end (server).

[0054] In some embodiments of the present application, the target object (such as a customer or employee) accesses the front end of the enterprise business system through various interfaces such as a browser, a dedicated APP or a mini-program, and initiates an access request to the back end of the business system.

[0055] After the business system receives the login request from the target object, it constructs a login event and communicates with the front-end and back-end of the business system. The back-end generates login request information based on the front-end information (IP, terminal, historical login users, etc.), back-end information (server information, URL, service provider identity information, timestamp, B-side public key, B-side signature, etc.), and business information (unique authentication transaction number, login random verification code, etc.), and sends the login request information to the front-end for display. For example, the login request information is converted into a QR code format. The QR code can contain the business system identity identifier, authentication transaction number, and server public key and signature of the business system. KIMS obtains the login request information by scanning the code.

[0056] A business system identifier is a label or code used to uniquely identify a specific business system or application environment. This identifier is also known as the business system identifier. When a target user (i.e., a user) attempts to log in to a business system, their login request can include this key information. This information is used to identify and distinguish between different business systems or applications, ensuring that subsequent login processes and identity authentication are performed for the correct business environment.

[0057] It should be noted that the login request information may also include a random code (login random verification code). When the business system determines that the login signature is legal, the business system uses the random code to locate the login signature to the target login request.

[0058] Before obtaining the login request information of the target object in the target business system, KIMS can also perform the following steps: in response to the creation instruction of the target object, generate an identity identifier corresponding to the target object and a set of private keys and public keys corresponding to the identity identifier; send the association relationship between the identity identifier and the public key to the identity resolution service, which is used to store the association relationship between the identity identifier and the public key.

[0059] In this application, each participant (target object) has an independent key identity manager (KIMS). The identity of each target object in the digital world is represented by a set of public / private keys. The private key represents the control of the identity. KIMS completes key creation, storage, change, encryption / decryption, signing and other tasks. After the target object creates an identity identifier, KIMS registers the association between the identity identifier and the public key to IKS. Registration is a one-time job. Subsequently, IKS is synchronized again only when the key is changed. At this time, the digital identity is anonymous. In some embodiments of the present application, the storage objects in IKS can be divided into multiple types. For example, when the storage object type is personal, the IKS stores the corresponding relationship between the personal identity identifier (i.e., the target object identity identifier) and the public key; when the storage object type is a business system, the IKS stores the corresponding relationship between the business system identity identifier, public key, and callback address.

[0060] When the target object logs into the business system for the first time, it needs to register the business system, that is, KIMS associates the target object identity identifier with the user account of a certain business system. Business system registration is a one-time job. For the target object, the same digital identity identifier (that is, the target object identity identifier) can be registered for multiple enterprise applications to achieve one identity pass.

[0061] After obtaining the login request information of the target object in the business system, the following steps can also be performed: determine whether the login request information belongs to the target login request information, the target login request information includes the information obtained by encrypting the initial login request information using the second public key of the target object, the second public key corresponds to the identity identifier, and each identity identifier corresponds to a public key; if the login request information belongs to the target login request information, use the private key of the target object to decrypt the login request information to obtain the initial login request information.

[0062] The target login request message is the login message generated by the business system and sent to the target object. This message is encrypted using the second public key corresponding to the target object's identity identifier. The second public key is the public key corresponding to the digital identity identifier associated with the target object. In this application, each identity identifier is associated with a public key, which enables the business system to encrypt information using that public key, ensuring that only the target object holding the correct private key can decrypt and access it.

[0063] In some embodiments of the present application, it is possible to determine whether the login request information belongs to the target login request information by checking the encryption identifier in the login request information; KIMS attempts to decrypt the login request information using the private key of the target object. If the decryption is successful, it means that the information is encrypted by the business system using the public key (second public key) corresponding to the private key.

[0064] It should be noted that not all login request information needs to be encrypted. Whether encryption is required can be determined through the following steps: the business system obtains the initial login request information corresponding to the target object, and the initial login request information includes the terminal information of the target terminal device. The target terminal device is the terminal device used by the target object to initiate a login request to the business system; the business system determines whether the target terminal device belongs to a terminal set based on the terminal information, and the terminal set includes a pre-set number of terminal devices; when the target terminal device belongs to the terminal set, the business system determines whether the target object belongs to the object set, and there is a binding relationship between the objects in the object set and the target terminal device; when the target object belongs to the object set, the business system uses the second public key to encrypt the initial login request information to obtain the target login request information.

[0065] In some embodiments of the present application, the business system may maintain a list of terminal collections, including information such as the MAC addresses and IP addresses of pre-set terminal devices. When a target terminal device initiates a login request, the business system compares the terminal information of the device with the list of terminal collections to confirm the device's credibility. If the target terminal device is confirmed to belong to the terminal collection, the business system will further check whether the target object is in the object collection to check whether the target object's identity identifier is bound to the terminal device. If both the target terminal device and the target object belong to the pre-set collection, the business system will obtain a second public key corresponding to the target object's identity identifier to encrypt the initial login request information.

[0066] Through the above steps, the business system can dynamically determine whether to encrypt login request information based on the trustworthiness of the target terminal device and target object, thereby protecting user privacy while increasing the security of the login process. For trusted terminal devices and objects, public-private key encryption is used to ensure secure information transmission. Even if the information is intercepted during transmission, it cannot be decrypted and exploited, thereby improving the security of the entire password-free login system and user experience.

[0067] Step S204: The key identity management service determines a target object identity identifier of the target object according to the business system identity identifier, wherein the target object identity identifier is used by the business system to verify the authenticity of the target object.

[0068] In the above step S204, the target object identity identifier is a unique identifier of a personal digital identity, registered in the IKS, and used for cross-system and cross-application identity authentication.

[0069] During the registration phase, the user selects a digital identity (target object identity identifier) to bind to the enterprise application, such as binding to the enterprise digital identity (business system identity identifier) of the enterprise application. In subsequent use, KIMS recognizes the enterprise application or enterprise digital identity and can automatically select the corresponding user digital identity for docking. When a user registers in an enterprise application, in addition to providing personal digital identity identifiers and key association information, the enterprise itself can also provide its own digital identity information (i.e., business system identity identifier). In the subsequent login or authentication process, when KIMS receives a login request from the enterprise application, it can identify the enterprise digital identity information and automatically select the personal digital identity bound to the enterprise for docking. This means that KIMS will select the correct one from the multiple user digital identities it manages (if any) based on the enterprise digital identity, and use the corresponding private key to sign to complete the login or authentication process.

[0070] It should be noted that before the key identity management service determines the target object identity identifier of the target object based on the business system identity identifier, the following steps can also be performed: determine whether the login request information includes the first target object identity identifier to obtain a judgment result; if the judgment result indicates that the login request information includes the first target object identity identifier, the key identity management service uses the private key associated with the first target object identity identifier to perform a digital signature on the login request information.

[0071] The first target object identity identifier refers to the digital identity identifier that is included in the login request information and is used to indicate a specific target object (user). In some scenarios, the business system already knows the identity identifier of the target object in advance and includes it in the login request information to limit the login process to only be completed by the specific target object. By including the first target object identity identifier in the login request information, the business system can ensure that only the specific user can complete the subsequent login process, thereby improving the security and pertinence of the system when processing sensitive data or performing high-level operations.

[0072] Specifically, after receiving the login request information, KIMS first parses the information and checks whether it contains the first target object identity identifier. If it is detected that the request contains the first target object identity identifier, KIMS will continue the processing flow and perform the digital signature operation; if not detected, KIMS needs to determine the target object identity identifier through subsequent steps.

[0073] When the key identity management service cannot determine the target object identity identifier of the target object based on the business system identity identifier, the following steps may also be performed: the key identity management service initiates user account registration to the business system and binds the business system to the second target object identity identifier of the target object.

[0074] When a new user first accesses a business system, the association between the identity identifier and the business system has not yet been established. In order to ensure that new users can also successfully log in to the system using a password-free authentication method based on a digital identity, when KIMS receives a login request but cannot identify the identity identifier of the target object based on the business system identity identifier, this means that the target object has not yet registered its digital identity in the business system. In this case, KIMS needs to guide the target object to perform the user account registration process. In some embodiments of the present application, KIMS, as a manager of personal digital identity, can proactively initiate a user account registration or binding request to the business system to create a new second target object identity identifier, which is used to represent the target object's digital identity under the business system. KIMS will use this identifier to communicate with the business system and request to establish a binding relationship between the identity identifier and the business system. After receiving this request, the business system will execute an internal account registration process, create a new internal account for the target object, and bind this account to the second target object identity identifier.

[0075] In step S206, the key identity management service digitally signs the login request information using the private key associated with the target object identity identifier to obtain a login signature, wherein the target object identity identifier corresponds to a set of private keys and public keys, and the public key is decoupled from the business system.

[0076] In step S206 above, a digital signature refers to the process of processing data using a private key through a specific cryptographic algorithm to generate a unique piece of information that can verify the integrity of the data and the authenticity of its source. In this embodiment of the application, the digital signature is primarily used to verify the identity of the target entity, ensuring that the login request information received by the business system is indeed from the target entity holding the corresponding private key.

[0077] When the target object uses KIMS to scan the login QR code of the business system and obtains the decrypted initial login request information, KIMS will select the corresponding private key from the private key set it manages based on the target object identity identifier in the information. It should be noted that in this application, the private key is managed within KIMS from creation to extinction and change, and is protected by the component. It will never leave the environment and is solely controlled by the owner (target object). There is no third party involved, such as CA (Certificate Authority), to reduce the possibility of third-party leakage.

[0078] Before using the private key to digitally sign the login request information, the following steps can also be performed: obtain business information corresponding to the business system from the login request information, wherein the business information includes the business system identity identifier and the business signature, and the business signature is determined based on the private key of the business system; determine the first public key corresponding to the business system identity identifier in the identity resolution service; use the first public key to verify the business signature to obtain a first verification result, wherein the first verification result is used by the key identity management service to verify the authenticity of the business system and indicate whether to continue the login.

[0079] Business information includes a business system identity identifier and a business signature that are unique to the business system. These are used to verify the legitimacy of the business system, ensuring that the target object can verify the credibility of the business system it is about to interact with during the login process, and avoiding the risk of potential man-in-the-middle attacks or phishing websites. The business system identity identifier is a unique identifier for the business system. It can be a URL, an enterprise digital identity identifier, or other information. It is used to query the public key corresponding to the business system in the IKS (Identity Resolution Service), i.e., the first public key. The business signature is the result of the business system using its own first private key to digitally sign the metadata of the login request information. The generation of the business signature verifies the legitimacy of the business system identity and ensures the integrity of the login request information and the authenticity of the source.

[0080] The first verification result is used directly by the login user (target object) to verify the authenticity of the login system (business system). If the verification result shows that the business signature is valid, it means that the business system has indeed used the first private key associated with its business system identity identifier to sign, thereby proving the identity of the business system and the authenticity of the request. It should be noted that in addition to the login user verifying the authenticity and identity of the business system, the business system also verifies the identity of the login user. That is, throughout the login process, both the business system and the login user are performing identity authentication, ensuring that both parties are legitimate entities and establishing a trust foundation for subsequent login and data exchange.

[0081] If the business signature verification passes, that is, the first verification result is legal, KIMS will allow the target object to continue the login process. Otherwise, if the verification fails, KIMS will terminate the login to prevent the target object from logging into an untrusted business system.

[0082] In step S208, the key identity management service returns the login signature to the business system, where the login signature is used by the business system to authenticate the target object using the public key obtained from the identity resolution service. The identity resolution service is used to store the association between the target object identity identifier and the public key.

[0083] In the above step S208, the login signature is the result generated after the target object uses its private key to digitally sign the login request information, which includes the target object identity identifier and digital signature. The login signature is sent to the business system for the business system to verify the identity of the target object.

[0084] In some embodiments of the present application, the login signature can be returned to the business system through the following steps: obtaining a first callback address from the login request information, wherein the first callback address is the path used by the business system to receive the login signature; and using the first callback address to return the login signature to the business system.

[0085] When the key identity management service verifies the authenticity of the business system, the key identity management service may further perform the following process: determining a second callback address corresponding to the business system from the identity resolution service; and returning the login signature to the business system using the second callback address.

[0086] The first callback address is the address or path pre-defined by the business system and notified to the Key Identity Management Service (KIMS) for receiving digitally signed login request feedback. The first callback address can be provided by the business system in the login request information, ensuring that the login signature can be returned to the business system correctly and securely.

[0087] The second callback address is obtained through the Identity Resolution Service (IKS) and is used to return the login signature to the business system after KIMS verifies the business system's authenticity. The existence of this second callback address strengthens the security of the login process, ensuring that the login signature cannot be intercepted or tampered with by middlemen.

[0088] In some embodiments of the present application, in order to prevent fake websites from impersonating enterprises to obtain personal signatures, the callback address may not be reflected in each login event. The login signature result can be returned from the API address registered during registration and binding. When the user registers or binds his or her digital identity to an enterprise application, a callback address (also called a signature return address) will be determined in advance with the enterprise. This address is the legal network endpoint used by the enterprise to receive the user's digital signature. This callback address will not be displayed or passed in plain text in the QR code or login request of each actual login event.

[0089] To improve the efficiency and security of identity authentication, the business system can authenticate the target object through the following methods: the business system obtains the target object's identity identifier from the login signature; the business system determines the second public key corresponding to the target object's identity identifier in the identity resolution service; the business system verifies the login signature using the second public key to obtain a second verification result, where the second verification result indicates whether the target object has passed identity authentication. After receiving the login signature returned by the target object, the business system first parses the login signature to extract the target object's identity identifier; uses the target object's identity identifier extracted from the login signature to initiate a query request to the IKS service to obtain the public key corresponding to the identifier; and verifies the login signature using the public key obtained from the IKS service.

[0090] In some embodiments of the present application, after the business system determines that the login signature is legal and the target object is logging into the business system for the first time, the business system may determine the target object's identity identifier as the target object's login account.

[0091] In this application, enterprise-side application accounts can be unbound from the user's periodically replaced public key and bound to a permanent digital identity, resolving the issue of inconsistency between key and account lifecycles. From a user's perspective, users no longer need to remember their enterprise application account, and the account becomes a unique internal identifier for the enterprise. Furthermore, since passwords are not used, compliance management issues such as password storage, password strength, and expiration dates are resolved from the enterprise's perspective, eliminating security risks associated with password leaks.

[0092] When registering an account, only the participant's identity identifier needs to be bound. During identity verification, the user's valid public key can be obtained through the IKS public service, and then the public key can be used to verify the other party's private key digital signature. As a result, the business system (application) does not need to store verification parameters such as passwords, and is not directly bound to the public key. Changes to the participant's key are decoupled from the enterprise application, and users do not need to remember the enterprise account. The enterprise account is reduced to an internal identifier. The complete chain of evidence for participating in identity authentication is as follows: participant --> account --> identity code --> public key --> signature verification. This collaborative model can cover all participants in the IT system, including enterprise employees, customers, and upstream and downstream partners.

[0093] In order to achieve unified management of the target object's keys across different business systems, the keys can be updated in the following ways: update the key corresponding to the identity identifier according to the preset period, obtain the updated public key and updated private key, and send the updated public key to the identity resolution service.

[0094] In related technologies, key change operations are complicated. For example, the object managed by the FIDO authenticator is the key pair, and the key life cycle does not match the identity life cycle. When the key life cycle expires and needs to be changed, the public keys associated with all accounts of the user on various enterprise servers will become invalid, causing cascading changes due to coupling. This application anchors the account to the identity code on the enterprise side, and then realizes the public key transformation through blockchain query (the identity code / public key relationship is similar to the domain name / IP relationship), thereby decoupling the account and the public key.

[0095] In some embodiments of the present application, when a user performs a key update operation in KIMS, the system will create a new public-private key pair to replace the original key pair. After generating the new updated public key, the KIMS software will send an update request to the IKS service, including the new updated public key information and the target object identity identifier, requesting to update the association between the public key and the identity identifier. After receiving the update request, the IKS service will check and verify the information in the request, such as confirming the legitimacy of the target object identity identifier and the validity of the updated public key. For example:

[0096] (1) Key update. When the preset period arrives, the user uses KIMS to perform a key pair update operation. KIMS generates a new updated public key and an updated private key to ensure that the security and strength of the new key pair meet the standards. In addition, the original key pair can be retained as a historical record for auditing and historical verification.

[0097] (2) Send an update request to IKS. KIMS constructs an update request message, which includes the personal digital identity identifier, the new updated public key, and a digital signature. The digital signature is obtained by signing the hash value of the identity identifier and the updated public key information using the user's private key (the original private key); KIMS sends an update request to the IKS public service, requesting to update the association between the personal digital identity identifier and the public key.

[0098] (3) IKS verification and evidence storage. After receiving the update request, IKS first verifies the legitimacy of the digital signature, uses the identity identifier to find the corresponding public key (i.e., the original public key), and verifies the signature. If the digital signature verification is successful, IKS will update its internal data structure and bind the identity identifier to the new updated public key. In addition, after the update, IKS can also add the updated information to the change chain, including the update timestamp, the updated public key, the hash value of the previous public key, etc., to form a "block". IKS can use blockchain technology to store this change information block to ensure the security and immutability of the change chain, providing a basis for future verification.

[0099] (4) Query and Verification. When other entities (such as enterprise application systems) need to verify their personal identity, they can query the IKS for the latest valid public key. The IKS returns the latest updated public key and, in addition, the change chain information, including the timestamp of the latest block and the hash value of the previous block. The verification entity can trace the change chain, verify the digital signature of each block, and the continuity between public keys to ensure that the obtained public key is legal and up-to-date.

[0100] It should be noted that the target object corresponds to at least one target object identity identifier, wherein each target object identity identifier corresponds to a set of private keys and public keys, the correspondence between each target object identity identifier and the public key is registered to the identity resolution service, and each target object identity identifier corresponds to one or more business systems.

[0101] In some embodiments of the present application, the target object can use the same target object identity identifier to bind multiple enterprise applications. For different enterprise applications / websites, the target object can use the same private key for signature authentication to achieve one-key access. Compared with traditional login, users in this application do not need to provide an account number or password. In fact, the account number is only degenerated into a unique identifier for the participant within the system, and the password is completely eliminated by design.

[0102] Users have the right to choose digital identities. A user can create multiple digital identities (i.e., target object identifiers), that is, users can use different digital identities in different situations. Figure 3a and Figure 3b This is a schematic diagram of an identity identifier application scenario of an identity authentication method according to an embodiment of the present application. Figure 3a This diagram shows how a target user can use a unified identity across multiple scenarios. This allows the target user to use the same digital identity (identity identifier) across multiple scenarios, enabling unified management of their personal identity. This includes both their identity as a customer accessing different enterprise applications and their work identity as an employee logging into their enterprise application. Figure 3b This is a schematic diagram of the target object selecting different identities in different occasions. The target object can use different digital identities in different occasions to prevent big data association between multiple B-ends. It should be noted that the choice of whether to use multiple identities in this application lies with the identity owner, rather than the original model where individual customers passively accept different identities assigned by different enterprise applications.

[0103] In some embodiments of the present application, the key identity management service is used for at least one of the following: managing the public-private key pair corresponding to the target object, the three-element relationship between the target object identity identifier and the public key and the identity resolution service access point, the registration relationship of the target object in multiple business systems, and the digital certificate of the target object issued by the third-party digital identity owner within the validity period.

[0104] Specifically: (1) It is used to manage the public-private key pair corresponding to the target object. As the key manager of the target object, KIMS can use asymmetric encryption and other algorithms to generate public-private key pairs, store the private key securely locally, and publish the public key to the IKS service so that other business systems can obtain it when needed. Users can update or revoke keys through this service to ensure that their keys are always under their control.

[0105] (2) It is used to manage the three-element relationship between the target object's identity identifier, the public key, and the identity resolution service access point. KIMS can maintain a database of three-element relationships, which contains the target object's identity identifier, the corresponding public key, and the access point to the IKS service. When a user creates or updates his or her digital identity, KIMS can record this information in the three-element relationship and synchronize it to the IKS service so that other systems can query and verify the user's identity.

[0106] (3) It is used to manage the registration relationships of target objects in multiple business systems. KIMS can track and manage the registration status of users in different business systems. For example, when a user registers or updates registration information in a new business system, KIMS can record this registration relationship and query or update data related to the business system through the Identity Resolution Service (IKS). This management of registration relationships allows users to view and manage their permission status in multiple systems in one place, improving user privacy and data controllability.

[0107] (4) It is used to manage the digital certificates issued by third-party digital identity owners within the validity period of the target object. KIMS supports users to obtain and store digital certificates from third-party certification agencies. Users can request these certificates, such as academic qualifications and age certificates, to be added to their identity documents and displayed to users through the KIMS management interface. When users need to display their specific identity attributes to the business system, KIMS can send the summary or link of these certificates to the business system, which will then verify the validity and authenticity of the certificates.

[0108] Through the above steps S202 to S208, the key identity management service adopts the digital identity of the target object to interact with the business system, and encrypts the login request information by using the private key corresponding to the target object identity identifier. The business system decrypts the information through the public key obtained from the identity resolution service to authenticate the target object, thereby achieving the purpose of the business system not participating in the creation of the private key and the user not needing to remember and store the password of the business system, thereby realizing the technical effect of the user's unified management of account passwords for multiple business systems, and thus solving the technical problem that users need to manage different keys between different enterprises and the key management cost is high.

[0109] According to another aspect of the embodiment of the present application, an identity authentication system is also provided, including a key identity management service, a business system, and an identity resolution service, wherein the key identity management service is connected to the identity resolution service and the business system, respectively, and is used to obtain the login request information of the target object in the business system, and digitally sign the login request information based on the private key associated with the target object identity identifier of the target object in the business system to obtain a login signature, and return the login signature to the business system, wherein the target object identity identifier corresponds to a set of private keys and public keys, and the public key is decoupled from the business system; the identity resolution service is connected to the key identity management service, and is used to store the association relationship between the target object identity identifier and the public key of the target object; the business system is connected to the key identity management service and the identity resolution service, respectively, and is used to receive the login signature, and use the public key and login signature obtained from the identity resolution service to authenticate the target object.

[0110] It should be noted that the identity authentication system is used to execute Figure 2 The authentication method shown is therefore Figure 2 The relevant explanations in the identity authentication method also apply to the identity authentication system and will not be repeated here.

[0111] Figure 4 This is a system architecture diagram of an identity authentication method according to an embodiment of the present application. Figure 4 As shown, this application is an application architecture that collaborates with multiple systems. In addition to the client (PC / mobile phone) and server (enterprise application backend) of traditional enterprise applications, it also introduces a personal key identity management module (KIMS) and a network public identity resolution service (IKS).

[0112] In some embodiments of this application, individuals own KIMS (not dependent on a specific enterprise, open source, transparent functions, and community sharing), and KIMS, as Party A (user), participates in business collaboration in the digital world on behalf of the identity owners it manages, such as Figure 5 As shown, KIMS includes the following modules:

[0113] (1) Key management template: Create public and private key pairs using mnemonics, external import, and layering, and manage the key lifecycle;

[0114] (2) Identity management module: including,

[0115] ① Use the public key to apply for a digital identity (such as the DID specification), and bind the identity identifier and public key and other publicly available identity information on the IKS (equivalent to the DID document on the blockchain);

[0116] ② Apply for a verifiable credential (VC) or a VP from a third-party issuer based on your needs; such as real-name verification, proof of employment / income, proof of age, etc.

[0117] ③ Change the identity key regularly or irregularly, and change the IKS information (DID document);

[0118] ④ When registering a user in an enterprise application, determine a digital identity code to bind to the enterprise user account, including the enterprise digital identity and enterprise API address;

[0119] ⑤ In some cases, when you have a dedicated device (similar to a smart card), you can bind an identity to the dedicated device;

[0120] (3) Identity signature module: Verify the digital identity of the enterprise logging into the system, register and bind the personal identity, use the corresponding private key to sign the login, and return the signature result from the API address registered during the registration and binding;

[0121] (4) Information encryption and decryption module: basic functions of key management;

[0122] (5) Signature verification module: basic functions of key management.

[0123] Figure 6 This is a schematic diagram of a business system architecture for an identity authentication method according to an embodiment of the present application. The enterprise business system (Party B) includes the following modules:

[0124] (1) Identity binding module: After the enterprise verifies the true identity of the system participant, it allocates a system personnel account and completes the association and binding between the account and the personnel digital identity code through scanning verification;

[0125] (2) Login preparation module: Based on the login request sent by the client, the login event information is constructed in combination with the server information, current time, etc., and a random code is generated as the event unique identifier. The login event information is signed and the login event information and signature are converted into a QR code for display, completing the login preparation;

[0126] (3) Signature verification module: ① Parse the signature information and extract the customer identity code; ② Query the valid public key on the Internet IKS; ③ Use the public key to parse and verify whether the signature is legal; ④ If the signature is legal, use the login random code to locate the login event saved by the server and compare the event status; if the event status is legal, determine the system account bound to the identity code; notify the front desk login authentication result initiated by the event.

[0127] Based on the above system architecture, Figure 7 It shows the interaction between the various modules of the system during the daily login process of a user to an application. Specifically:

[0128] Step 1: A user (individual) accesses an enterprise application (enterprise front-end) through a browser, dedicated app, or mini-program, and initiates an access request to the enterprise back-end;

[0129] Step 2: The enterprise application communicates with the front-end and back-end. The server generates a login QR code based on the front-end information (IP, terminal, historical login users, etc.), server information (server information, URL, server identity information, timestamp, B-side public key, B-side signature, etc.), and business information (unique authentication transaction number, login random verification code, etc.), and sends it to the front-end for display.

[0130] Step 3: The identity owner scans the QR code using KIMS;

[0131] Step 4: KIMS scans the code to obtain login information: If there is no designated person (corresponding to the process of determining whether the login request information belongs to the target login request information), the login information is not encrypted with the public key, and directly go to step 5; otherwise, if the login information specifies the login user, try to use the personal public key to decrypt the login information. If the decryption fails, the login is terminated. If the decryption is successful, proceed to the next step;

[0132] Step 5: KIMS parses the login information and obtains the enterprise application identity, enterprise signature, etc.

[0133] Step 6: KIMS initiates a query request to the network service IKS for the B-side identity to obtain the application public key, callback address and other information. It uses this public key to verify the enterprise signature, compares the enterprise callback address, and checks the legitimacy of the enterprise identity (website). If it is legal, it continues to step 7, otherwise the login is terminated;

[0134] Step 7: KIMS uses the private key to digitally sign the login information.

[0135] Step 8: KIMS returns the login signature to the identity consumer based on the callback address when verifying the server identity in step 6;

[0136] Step 9: The identity consumer (enterprise application server) parses the obtained login signature information;

[0137] Step 10: The application server queries the public key of the registrant from IKS based on the parsed identity code;

[0138] Step 11: The application server verifies the signature using the login user's public key;

[0139] Step 12: The application server notifies the application client of the verification result;

[0140] Step 13: The application client completes the login based on the verification result.

[0141] To facilitate understanding of the above identity authentication method, it is described below with reference to specific embodiments.

[0142] Specific embodiment 1: Figure 8 It shows the passwordless login process on public devices, that is, the identity consumer (business system) does not know the specific login person (target object), such as Figure 8 As shown, it includes the following processes:

[0143] Phase 1: Login preparation.

[0144] 1) A user accesses an enterprise application (front-end application) through a browser, dedicated app, or mini-program, and initiates an access request to the enterprise back-end. At this point, the business system collects client information and initiates a login request.

[0145] 2) For enterprise application front-end and back-end communication, the server generates a login QR code based on front-end information (IP, terminal, historical login users, etc.), server-side information (server information, URL, server identity information, timestamp, B-side public key, B-side signature, etc.), and business information (unique authentication transaction number, login random verification code, etc.), and sends it to the front-end for display;

[0146] 3) The identity owner scans the QR code using KIMS;

[0147] Phase 2: Identity provision.

[0148] 4) Scan the QR code in KIMS to obtain login information (login request information);

[0149] 5) KIMS parses login information (obtains system login authentication information);

[0150] 6) KIMS initiates a request to verify the B-side identity to the Internet Digital Identity Public Service (IKS) to verify the legitimacy of the B-side corporate identity (website). Specifically, it uses B's public key (first public key) to verify B's signature (business signature). Based on B's identity, it decides to use A's identity a and B's service URL (callback address) when binding.

[0151] 7) If the verification is successful, KIMS uses the private key to perform a digital signature on the login information, that is, it uses A's private key to sign B's authentication information (login request information), and together with identity a's identity identifier and public key, it forms the authentication confirmation information (login signature) and sends it back to B's service URL;

[0152] 8) KIMS returns the login signature to the identity consumer based on the callback address confirmed when verifying the server identity in step 6;

[0153] Phase 3: Identity verification.

[0154] 9) The identity consumer (enterprise application server, i.e., business system) parses the obtained login signature information and extracts the customer identity code a;

[0155] 10) The identity consumer queries the public key (IKS) of the registrant on the blockchain based on the parsed identity identification code a;

[0156] 11) The identity consumer uses the public key to parse and verify whether the signature is legitimate;

[0157] 12) The identity consumer notifies the application client of the verification result, uses the login random code to locate the login event saved by the server, and compares the event status;

[0158] 13) The application client completes the login based on the backend verification result. Specifically, it determines the system account bound to the identity code and notifies the front-end login authentication result of the event initiator.

[0159] Specific embodiment 2: Figure 9 It shows the password-free login process on a dedicated device, that is, the identity consumer can determine the specific login, such as Figure 9 As shown, in Figure 8 Based on the login process Figure 8 The login process shown has the following differences:

[0160] In step 2), the service end of the business system searches whether the login user is a fixed login user (account) bound to a dedicated device based on the front-end information (such as IP, terminal information, etc.). If the login user is a fixed login user, the dedicated login service will be used. It should be noted that, based on the preparation for ordinary login (see Specific Example 1), the login information is encrypted using the public key (second public key) of the fixed login user, a login QR code is generated, and sent to the front-end for display. Different from Specific Example 1, if the back-end of Enterprise B determines that it is a dedicated device, it will only accept pre-registered fixed login users.

[0161] In step 5), KIMS determines whether the user is a fixed user (corresponding to determining whether the login request information belongs to the target login request information). If so, it uses the private key to decrypt the login information and further parses the decrypted login information. Unlike in Specific Example 1, the login information on the dedicated device can only be decrypted and signed by the fixed user; other users cannot decrypt the login information.

[0162] The other steps of Specific Example 2 are the same as those of Specific Example 1 and will not be repeated here.

[0163] In the technical solution adopted in this application, KIMS is a personal digital agent that does not rely on any enterprise-side software. Individuals create digital identities and keys. Users use digital identities to interact with business systems through KIMS, which changes the mode of user-system interaction. At the same time, individuals use digital signatures with private keys to achieve secret-free authentication, eliminating the trouble of changing and remembering passwords. With the introduction of the IKS service, when users periodically update their keys, they only need to notify IKS to store the evidence, without the need to associate and notify numerous enterprise applications. In related technologies, the private key of the CA certificate comes from the enterprise side (the user is not the only holder), and the certificates of each company are not interchangeable. In this application, the private key is completely controlled by the customer, which meets the requirements of real identity control, that is, within the security range of the algorithm, each digital signature represents personal will and cannot be replaced or influenced by others.

[0164] Compared with FIDO authentication, this application introduces a public service module for network identity public key resolution (identity identifier and public key mapping). The business system account is bound to the identity identifier and the user public key is unbound. The corresponding public key and other public identity information are queried from the corresponding public blockchain each time it is used, eliminating the trouble of notifying all relevant enterprise applications of updates when the user periodically updates the key pair.

[0165] Compared to DID, the IKS of this application is equivalent to a DID document stored on a blockchain, but its form is not limited to blockchain. Based on efficiency considerations, it can be in the form of a centralized database. The private key management of DID is digital wallet software, while KIMS is a set of shared software or systems for personal use. The private key data it manages is inaccessible to other software on or off the device. From creation to destruction, the private key never leaves the protection scope of KIMS. In addition to managing private keys, KIMS also manages associated identity identification. Unlike DID, KIMS also manages the application registration management of digital identities in different enterprises. Moreover, in terms of private key management, KIMS supports the separation of private key data from KIMS and storage in independent smart hardware devices. In addition to the signature function being migrated to smart hardware, KIMS retains other identity management and identity application management.

[0166] Figure 10 is a structural diagram of an identity authentication device according to an embodiment of the present application, such as Figure 10 As shown, the device includes:

[0167] An acquisition module 1002 is configured to acquire, by the key identity management service, login request information of a target object in a business system, wherein the login request information includes a business system identity identifier of the business system;

[0168] Determination module 1004, configured for the key identity management service to determine a target object identity identifier of the target object according to the business system identity identifier, wherein the target object identity identifier is used by the business system to verify the authenticity of the target object;

[0169] Signature module 1006, used by the key identity management service to digitally sign the login request information using the private key associated with the target object identity identifier to obtain a login signature, wherein the target object identity identifier corresponds to a set of private keys and public keys, and the public key is decoupled from the business system;

[0170] Return module 1008 is used for the key identity management service to return the login signature to the business system, wherein the login signature is used by the business system to authenticate the target object using the public key obtained from the identity resolution service, and the identity resolution service is used to store the association between the target object identity identifier and the public key.

[0171] It should be noted that Figure 10 The identity authentication device shown is used to perform Figure 2 The authentication method shown is therefore Figure 2 The explanations of the authentication methods in the Figure 10 The identity authentication device shown is not described in detail here.

[0172] An embodiment of the present application also provides an electronic device, which includes a memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute the steps of the identity authentication method in each embodiment of the present application.

[0173] For example, the processor performs the following functions by executing program instructions stored in the memory: the key identity management service obtains login request information of the target object in the business system, wherein the login request information includes the business system identity identifier of the business system; the key identity management service determines the target object identity identifier of the target object based on the business system identity identifier, wherein the target object identity identifier is used by the business system to verify the authenticity of the target object; the key identity management service uses the private key associated with the target object identity identifier to perform a digital signature on the login request information to obtain a login signature, wherein the target object identity identifier corresponds to a set of private keys and public keys, and the public key is decoupled from the business system; the key identity management service returns the login signature to the business system, wherein the login signature is used by the business system to authenticate the target object using the public key obtained from the identity resolution service, and the identity resolution service is used to store the association between the target object identity identifier and the public key.

[0174] An embodiment of the present application further provides a non-volatile storage medium, which includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the steps of the identity authentication method in each embodiment of the present application by running the computer program.

[0175] An embodiment of the present application further provides a computer program product, including computer instructions, which, when executed by a processor, implement the steps of the identity authentication method in each embodiment of the present application.

[0176] The embodiments of the present application also provide a computer program, which, when executed by a processor, implements the steps of the identity authentication method in each embodiment of the present application.

[0177] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0178] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0179] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of the units can be 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. Another point is that 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, which can be electrical or other forms.

[0180] 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 units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0181] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or 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.

[0182] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as 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.

[0183] The above is only a preferred embodiment of the present application. 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 application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for identity authentication, characterized in that: include: The key identity management service obtains login request information of the target object in the business system, wherein the login request information includes a business system identity identifier of the business system; The key identity management service determines a target object identity identifier of the target object according to the business system identity identifier, wherein the target object identity identifier is used by the business system to verify the authenticity of the target object; The key identity management service digitally signs the login request information using a private key associated with the target object identity identifier to obtain a login signature, wherein the target object identity identifier corresponds to a set of private keys and public keys, and the public key is decoupled from the business system; The key identity management service returns the login signature to the business system, wherein the login signature is used by the business system to authenticate the target object using the public key obtained from the identity resolution service, and the identity resolution service is used to store the association between the target object identity identifier and the public key.

2. The method according to claim 1, characterized in that Before the key identity management service determines the target object identity identifier of the target object according to the business system identity identifier, the method further includes: Determining whether the login request information includes a first target object identity identifier, and obtaining a determination result; If the determination result indicates that the login request information includes the first target object identity identifier, the key identity management service digitally signs the login request information using a private key associated with the first target object identity identifier.

3. The method according to claim 1, characterized in that In the event that the key identity management service cannot determine the target object identity identifier of the target object based on the business system identity identifier, the method further includes: the key identity management service initiating user account registration to the business system to bind the business system to the second target object identity identifier of the target object.

4. The method according to claim 1, wherein Before the key identity management service digitally signs the login request information using the private key associated with the target object identity identifier, the method further includes: Acquire business information corresponding to the business system from the login request information, wherein the business information includes a business system identity identifier and a business signature, and the business signature is determined according to a private key of the business system; Determining a first public key corresponding to the business system identity identifier in the identity resolution service; The business signature is verified using the first public key to obtain a first verification result, wherein the first verification result is used by the key identity management service to verify the authenticity of the business system and indicate whether to continue logging in.

5. The method according to claim 1, wherein The key identity management service returns the login signature to the business system, including: Acquire a first callback address from the login request information, wherein the first callback address is a path used by the business system to receive the login signature; The login signature is returned to the business system using the first callback address.

6. The method according to claim 4, characterized in that When the key identity management service verifies the authenticity of the business system, the key identity management service returns the login signature to the business system, including: Determining a second callback address corresponding to the business system from the identity resolution service; The login signature is returned to the business system using the second callback address.

7. The method according to claim 1, characterized in that The business system authenticates the target object in the following ways: The business system obtains the target object identity identifier from the login signature; The business system determines, in the identity resolution service, a second public key corresponding to the target object identity identifier; The business system verifies the login signature using the second public key to obtain a second verification result, wherein the second verification result is used to indicate whether the target object has passed identity authentication.

8. The method according to claim 1, characterized in that The key identity management service is used for at least one of the following: managing the public-private key pair corresponding to the target object, the three-element relationship between the target object identity identifier and the public key and the identity resolution service access point, the registration relationship of the target object in multiple business systems, and the digital certificate of the target object issued by the third-party digital identity owner within the validity period.

9. The method according to claim 1, characterized in that The target object corresponds to at least one target object identity identifier, wherein each target object identity identifier corresponds to a set of private keys and public keys, the correspondence between each target object identity identifier and the public key is registered with the identity resolution service, and each target object identity identifier corresponds to one or more business systems.

10. The method according to claim 1, characterized in that The method further includes: updating a key corresponding to the target object identity identifier according to a preset period, obtaining an updated public key and an updated private key, and sending the updated public key to the identity resolution service.

11. An identity authentication system, characterized in that: Including key identity management services, business systems, and identity resolution services, among which, The key identity management service is connected to the identity resolution service and the business system respectively, and is used to obtain login request information of the target object in the business system, digitally sign the login request information based on the private key associated with the target object identity identifier of the target object in the business system to obtain a login signature, and return the login signature to the business system, wherein the target object identity identifier corresponds to a set of private keys and public keys, and the public key is decoupled from the business system; The identity resolution service is connected to the key identity management service and is used to store the association relationship between the target object identity identifier of the target object and the public key; The business system is connected to the key identity management service and the identity resolution service respectively, and is used to receive the login signature and perform identity authentication on the target object using the public key obtained from the identity resolution service and the login signature.

12. An identity authentication device, characterized in that: include: An acquisition module, configured to obtain, by a key identity management service, login request information of a target object in a business system, wherein the login request information includes a business system identity identifier of the business system; a determination module, configured for the key identity management service to determine a target object identity identifier of the target object according to the business system identity identifier, wherein the target object identity identifier is used by the business system to verify the authenticity of the target object; a signing module, configured for the key identity management service to digitally sign the login request information using a private key associated with the target object identity identifier to obtain a login signature, wherein the target object identity identifier corresponds to a set of private keys and public keys, and the public key is decoupled from the business system; A return module is used for the key identity management service to return the login signature to the business system, wherein the login signature is used by the business system to authenticate the target object using the public key obtained from the identity resolution service, and the identity resolution service is used to store the association between the target object identity identifier and the public key.

13. An electronic device, characterized in that: include: A memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute the identity authentication method described in any one of claims 1 to 10.

14. A non-volatile storage medium, characterized in that: The non-volatile storage medium includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the identity authentication method according to any one of claims 1 to 10 by running the computer program.

15. A computer program product comprising computer instructions, characterized in that When the computer instructions are executed by a processor, the identity authentication method described in any one of claims 1 to 10 is implemented.

Images