Identity token management method, computer equipment and readable storage medium

Abstract

The invention relates to an identity token management method, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: sending a token acquisition request carrying an identity identifier to a server, and receiving a random number returned by the server; and signing the random number based on a locally generated private key, sending a digital signature to a server, sending the identity label, the random number and the digital signature to a block chain by the server, decrypting the digital signature based on a public key corresponding to the identity label by the block chain to obtain a decryption result, and when the decryption result is consistent with the random number, sending the digital signature to the server. And the encrypted permission configuration information corresponding to the identity identifier is returned to the server, the server constructs an identity token according to the decrypted permission configuration information, and the identity token is used for accessing a related service interface of the micro-service. Whether the user side applying for the token is legal or not can be verified through the interaction process between the server and the block chain, so that the possibility of privacy leakage can be reduced.

Description

Technical Field

[0001] The present application relates to the field of identity authentication technology, and in particular to an identity token management method, a computer device, a computer-readable storage medium, and a computer program product. Background Art

[0002] The transition from a monolithic architecture to a microservices architecture has brought many advantages to various types of digital transactions, including improved maintainability, scalability, and speed to market. However, in a microservices architecture, each microservice is responsible for implementing a specific function or business logic, so each request to access a microservice requires authentication and authorization approval. In related technologies, a centralized third party is required to store the user's identity authentication information, which makes privacy leaks more likely to occur. Summary of the invention

[0003] Based on this, it is necessary to provide an identity token management method, computer device, computer-readable storage medium and computer program product that can reduce the risk of privacy leakage in response to the above technical problems.

[0004] In a first aspect, the present application provides an identity token management method, comprising:

[0005] Based on the decentralized random number signature authentication protocol, a token acquisition request carrying an identity identifier is sent to the server, and the random number returned by the server is received;

[0006] The random number is signed based on the private key in a pair of public and private keys generated locally, and the digital signature is sent to the server to instruct the server to send the identity, random number and digital signature to the blockchain. The blockchain decrypts the digital signature based on the public key corresponding to the identity to obtain the decryption result. When the decryption result is consistent with the random number, the encrypted permission configuration information corresponding to the identity is returned to the server. The server constructs an identity token based on the decrypted permission configuration information, and sends the corresponding relationship between the identity token and the identity to the blockchain for storage; wherein the identity, the public key corresponding to the identity, and the encrypted permission configuration information stored in the blockchain are saved during the user identity registration process;

[0007] Receive the identity token returned by the server and access the relevant service interface of the microservice based on the identity token.

[0008] In one embodiment, the process of user identity registration includes:

[0009] Generate a pair of public and private keys and identity locally, and generate permission configuration information based on the current user permissions;

[0010] Call the registration interface of the server, and send an identity registration request to the server based on the permission configuration information, the locally generated public key and the identity identifier, to instruct the server to encrypt the permission configuration information based on the public key generated by itself, and send the identity identifier, the locally generated public key and the encrypted permission configuration information to the blockchain for storage.

[0011] In one embodiment, the method further comprises:

[0012] When identity revocation is required, an identity revocation request carrying an identity identifier is sent to the server to instruct the server to control the deletion of the associated data corresponding to the identity identifier in the blockchain when it is determined that the user end initiating the identity revocation request is the same as the user end using the identity identifier for identity registration;

[0013] When a token needs to be revoked, a token revocation request carrying the identity identifier and the identity token is sent to the server to instruct the server to control the blockchain to delete the identity token corresponding to the identity identifier;

[0014] When the token needs to be verified, a token verification request carrying the identity identifier and the identity token is sent to the server to instruct the server to control the blockchain to verify whether the identity identifier has been revoked and whether the identity token has been revoked.

[0015] In one of the embodiments, the token revocation request also carries a token validity period, which is used to instruct the blockchain to delete the expired identity token corresponding to the identity identifier.

[0016] In a second aspect, the present application provides an identity token management method, comprising:

[0017] Receive a token acquisition request sent by the user based on a decentralized random number signature authentication protocol, where the token acquisition request carries an identity identifier;

[0018] Sending a random number to the client to instruct the client to sign the random number based on a private key in a pair of public and private keys generated by the client;

[0019] Receive the digital signature returned by the user, send the identity, random number and digital signature to the blockchain, instruct the blockchain to decrypt the digital signature based on the public key corresponding to the identity, obtain the decryption result, and return the encrypted permission configuration information corresponding to the identity when the decryption result is consistent with the random number; wherein the identity, the public key corresponding to the identity, and the encrypted permission configuration information stored in the blockchain are saved during the user identity registration process;

[0020] Decrypt the encrypted permission configuration information, build an identity token based on the decrypted permission configuration information, send the correspondence between the identity token and the identity identifier to the blockchain for storage, and return the identity token to the user end to instruct the user end to access the relevant service interface of the microservice.

[0021] In one embodiment, the process of user identity registration includes:

[0022] Receive an identity registration request sent by a user, the identity registration request including permission configuration information generated by the user according to the current user permissions, a public key and an identity identifier generated locally by the user;

[0023] The permission configuration information is encrypted based on the locally generated public key, and the identity identifier, the public key generated locally by the user itself and the encrypted permission configuration information are sent to the blockchain for storage.

[0024] In one embodiment, the method further comprises:

[0025] When identity revocation is required, receiving an identity revocation request with an identity identifier from a user end, and controlling the deletion of associated data corresponding to the identity identifier in the blockchain if the user end initiating the identity revocation request is the same as the user end using the identity identifier for identity registration;

[0026] When a token needs to be revoked, a token revocation request carrying an identity identifier and an identity token is received from a user, and the blockchain is controlled to delete the identity token corresponding to the identity identifier;

[0027] When the token needs to be verified, a token verification request carrying the identity identifier and identity token sent by the user is received, and the blockchain is controlled to verify whether the identity identifier has been revoked and whether the identity token has been revoked.

[0028] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it implements the steps provided by various possible implementation methods of the first aspect or the second aspect mentioned above.

[0029] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps provided by various possible implementation methods of the first aspect or the second aspect mentioned above.

[0030] In a fifth aspect, the present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps provided by various possible implementation methods of the above-mentioned first aspect or second aspect.

[0031] The above-mentioned identity token management method, computer device, computer-readable storage medium and computer program product, since the issuance of identity tokens is no longer handled solely by a centralized third party, the identity identification, permission configuration information and the public key generated locally by the user end can be stored in the blockchain, and the legitimacy of the user end applying for the token can be verified through the interaction process between the server and the blockchain, thereby reducing the possibility of privacy leakage. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0033] FIG1 is a diagram of an application environment for identity authentication in one embodiment;

[0034] FIG2 is a schematic diagram of a flow chart of an identity token management method in one embodiment;

[0035] FIG3 is a schematic diagram of the relationship between the proxy Agent and the control Agent in one embodiment;

[0036] FIG4 is a schematic diagram of a flow chart of an identity token management method in one embodiment;

[0037] FIG5 is a simplified flowchart of an identity token management method according to an embodiment;

[0038] FIG6 is a schematic diagram of a detailed flow chart of an identity token management method in one embodiment;

[0039] FIG7 is a schematic diagram of interaction between a user terminal and a rights server in one embodiment;

[0040] FIG8 is a structural block diagram of a user terminal in one embodiment;

[0041] FIG9 is a block diagram of a server in one embodiment;

[0042] FIG. 10 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0043] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0044] Before explaining the embodiments of the present application, the concepts of terms that may be involved in the embodiments of the present application are now explained.

[0045] Blockchain: A decentralized distributed ledger organized in a chain data structure that contains multiple transaction blocks. Each block contains a batch of verified transactions and uses cryptography to ensure data security and tamper-proofing.

[0046] Smart Contract: A smart contract is a computer program deployed on a blockchain that is designed to automatically execute, manage, or enforce the terms and conditions of a contract. Smart contracts are usually written in code and deployed and executed on a blockchain network to enable various types of digital transactions and agreements in a decentralized manner.

[0047] User side: responsible for initiating requests to the microservice system and getting responses, allowing users to create multiple different identity accounts.

[0048] Authorization server: As a trusted third party, it is responsible for protocol interaction with users and issuing temporary identity tokens.

[0049] Blockchain: responsible for executing relevant smart contracts and storing important data.

[0050] Microservices: perform business logic processing and respond to user requests.

[0051] Currently, the transition from a monolithic architecture to a microservice architecture brings many advantages, including improved maintainability, scalability, and faster innovation and launch. However, in a microservice architecture, each microservice is responsible for implementing a specific function or business logic, so each request to access a microservice needs to be authenticated and authorized. This also leads to the following problems:

[0052] (1) Centralized dependency: Each microservice must manage authentication and authorization logic separately. Although the same code can be used in all microservices, this requires all microservices to support a specific language or framework.

[0053] (2) Microservices need to have multiple responsibilities: Microservices should only perform one function. Adding global authentication and authorization logic to microservices (as additional add-on features) will reduce their reliability and increase the difficulty of their management.

[0054] (3) Centralization risk: Many solutions choose to deploy a separate authentication service, which is responsible for unified authorization and identity authentication. However, this centralized storage structure makes user data vulnerable to single-point attacks, resulting in the risk of data tampering or data leakage.

[0055] In related technologies, a centralized third party is required to save the user's identity authentication information. Users cannot control their own identity authentication information, which makes privacy leaks prone to occur.

[0056] In view of the above problems, the embodiment of the present application provides an identity token management method, which can be applied in the application environment shown in FIG. 1. Among them, the user terminal 102, the server 104 and the blockchain 106 communicate with each other to manage the identity token. Among them, when the user terminal 102 needs to apply for an identity token, the server 104 can be specifically a permission server. When the user terminal needs to revoke the identity token, the server 104 can be specifically a business server. The blockchain 106 can be specifically composed of multiple blockchain devices, such as multiple servers, and the embodiment of the present application does not specifically limit this. The interaction process between the three can refer to the subsequent interaction diagram. Among them, the user terminal 102 can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, Internet of Things devices and portable wearable devices. The Internet of Things devices can be smart speakers, smart TVs, smart air conditioners, smart car devices, projection devices, etc. Portable wearable devices can be smart watches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality devices, smart glasses, etc. The server 104 may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services.

[0057] In an exemplary embodiment, as shown in FIG2 , an identity token management method is provided, which is described by taking the method applied to the user terminal in FIG1 as an example, and includes the following steps 202 to 206. Among them:

[0058] Step 202: Based on the decentralized random number signature authentication protocol, a token acquisition request carrying an identity identifier is sent to the server, and a random number returned by the server is received.

[0059] Among them, the decentralized random number signature authentication protocol (RSAP, Random-Code Sign Auth Protocol) mainly realizes the acquisition of tokens by signing and verifying random numbers. The identity identifier is the unique identifier of the user. After the server receives the token acquisition request, it can generate a random number and return the random number to the user.

[0060] Step 204, based on the private key in a pair of public and private keys generated locally, sign the random number, and send the digital signature to the server to instruct the server to send the identity, random number and digital signature to the blockchain. The blockchain decrypts the digital signature based on the public key corresponding to the identity to obtain the decryption result. When the decryption result is consistent with the random number, the encrypted permission configuration information corresponding to the identity is returned to the server. The server constructs an identity token based on the decrypted permission configuration information, and sends the corresponding relationship between the identity token and the identity to the blockchain for storage.

[0061] Among them, the locally generated public-private key pair refers to the public-private key generated by the user end itself. The user end can sign the random number based on the private key in the public-private key pair to obtain a digital signature. The user end sends the digital signature to the server, and the server can send the identity, random number and digital signature to the blockchain by calling the signature authentication method of the smart contract. Since the user end has forwarded the locally generated public key, its own identity and the permission configuration information used to represent its current permissions to the blockchain through the server when registering its identity, and the blockchain saves it, the blockchain can verify the digital signature based on the previously saved information.

[0062] Specifically, since the blockchain can store the user's identity and public key in correspondence during identity registration, when the blockchain receives the identity, random number and digital signature sent by the server, it can first use the identity to determine the corresponding public key. The blockchain uses the public key to decrypt the digital signature and obtain the decryption result. It can be understood that if the identity is correct and the digital signature has not been tampered with during the transmission process, the decryption result should be the same as the random number received by the blockchain. Otherwise, it can be said that the identity is illegal or the digital signature has been tampered with during the transmission process, making the transmission process not safe enough. At this time, the blockchain may not return the encrypted permission configuration information corresponding to the identity to the server, and return verification failure.

[0063] If the decryption result is consistent with the random number, the blockchain can return the encrypted permission configuration information corresponding to the identity identifier to the server. The server can decrypt accordingly to obtain the decrypted permission configuration information, and construct an identity token based on the decrypted permission configuration information. Among them, the encrypted permission configuration information stored in the blockchain is the permission configuration information sent by the user end during the identity registration process, which is encrypted by the server using the public key in a pair of public and private keys generated locally, and then sent to the blockchain for storage, so that the blockchain stores the encrypted permission configuration information. In this way, the security of the data stored in the blockchain can be improved. The server can use its own locally generated private key to decrypt the encrypted permission configuration information returned by the blockchain. In addition, the identity token can be used as an index to find the permission configuration of the user end.

[0064] Step 206: Receive the identity token returned by the server, and access the relevant service interface of the microservice based on the identity token.

[0065] After building the identity token, the server can return it to the client, who can use the identity token to access the relevant service interfaces of the microservice.

[0066] In the above-mentioned identity token management method, since the issuance of identity tokens is no longer handled solely by a centralized third party, the identity identification, permission configuration information and the public key generated locally by the user can be stored by the blockchain, and the legality of the user applying for the token can be verified through the interaction process between the server and the blockchain, thereby reducing the possibility of privacy leakage.

[0067] In an exemplary embodiment, the process of user identity registration includes:

[0068] Generate a pair of public and private keys and identity locally, and generate permission configuration information based on the current user permissions;

[0069] Call the registration interface of the server, and send an identity registration request to the server based on the permission configuration information, the locally generated public key and the identity identifier, to instruct the server to encrypt the permission configuration information based on the public key generated by itself, and send the identity identifier, the locally generated public key and the encrypted permission configuration information to the blockchain for storage.

[0070] Among them, the identity identifier can be randomly generated, and the permission configuration information can indicate which menu permissions or interface permissions the user has, etc., which is not specifically limited in the embodiments of the present application. After the user terminal sends an identity registration request to the server, the server can also generate a pair of public and private keys locally, and then use the public key to encrypt the permission configuration information sent by the user terminal. Finally, the server sends the encrypted permission configuration information, the identity identifier sent by the user terminal, and the public key generated locally by the user terminal to the blockchain, which is saved by the blockchain so that it can be used for subsequent token applications.

[0071] In this embodiment, since the issuance of identity tokens is no longer handled solely by a centralized third party, the identity identification, permission configuration information and the public key generated locally by the user can be stored by the blockchain, and the legality of the user applying for the token can be verified through the interaction process between the server and the blockchain, thereby reducing the possibility of privacy leakage.

[0072] In an exemplary embodiment, the method further comprises:

[0073] When identity revocation is required, an identity revocation request carrying an identity identifier is sent to the server to instruct the server to control the deletion of the associated data corresponding to the identity identifier in the blockchain when it is determined that the user end initiating the identity revocation request is the same as the user end using the identity identifier for identity registration;

[0074] When a token needs to be revoked, a token revocation request carrying the identity identifier and the identity token is sent to the server to instruct the server to control the blockchain to delete the identity token corresponding to the identity identifier;

[0075] When the token needs to be verified, a token verification request carrying the identity identifier and the identity token is sent to the server to instruct the server to control the blockchain to verify whether the identity identifier has been revoked and whether the identity token has been revoked.

[0076] The server mentioned here can be a business server, which can be specifically handled by the agent in the business server for implementing permission control. The control agent in the business server can be deployed separately to distribute blockchain configuration and verification rules to the agent. The agent and microservice can be deployed together in the same container in the business server to handle the specific logic related to identity authentication. The relationship between the control agent and the agent can be referred to in Figure 3.

[0077] In Figure 3, the control agent is responsible for issuing the identity token acquisition rules, parsing rules, and related blockchain configurations to the proxy agent. After the proxy agent receives the access request for the microservice sent by the user, it first extracts the identity token from the user request according to the acquisition rules. Then, the proxy agent uses the relevant configuration of the blockchain to call the pre-token check method of the smart contract to determine whether the identity token is valid. If the identity token is valid, it will be parsed according to the identity token parsing rules to determine whether the relevant information such as permissions is legal. In summary, the business logic related to permissions is only processed between the control agent and the proxy agent, and there is no strong coupling relationship with the specific microservices.

[0078] In the process of controlling permissions, there may be multiple requirements. One is the need to revoke the entire user identity, and the other is the need to revoke a certain identity token. In order to revoke the entire user identity, the user end can send an identity revocation request to the business server, and the identity revocation request can carry the user's identity. The agent in the business server can determine whether the user end that initiates the identity revocation request is consistent with the user end that uses the identity to register the identity. For example, it can determine whether the corresponding hardware addresses of the two processes are consistent. If they are consistent, the agent can call the smart contract-related methods to delete the associated data corresponding to the identity from the blockchain. For example, permission configuration information, public keys and other data can be deleted.

[0079] To revoke an identity token, the user can send a token revocation request with the identity identifier and the identity token to the business server. The agent in the business server can call the smart contract-related methods to delete the identity token corresponding to the identity identifier from the blockchain.

[0080] In addition to revoking the entire identity and a token under a certain identity, the identity token can also be verified. The user end can send a token verification request carrying the identity identifier and identity token to the business server. The agent in the business server can call the smart contract related methods to verify the identity token in the blockchain. Specifically, the token verification related method can be called first, which can first determine whether the identity identifier corresponding to the identity token has been revoked in the blockchain. If the identity identifier has been revoked, the result that the identity token is invalid can be returned. If the identity identifier has not been revoked, it can be further verified whether the identity token is revoked. If the identity token has been revoked, the result that the identity token is invalid can be returned.

[0081] In this embodiment, since the identity and token can be revoked through the relevant methods of the smart contract, the token can also be verified, so that instant revocation can be achieved, so as to effectively reduce the risk of leakage of user access tokens and improve the security of the system. In addition, since the verification can be performed through the control agent and the proxy agent in the server, the single point problem when logging in with a single account and password for identity authentication can be improved; because the control agent and the proxy agent are encapsulated in a container, they can support cross-platform or programming language reuse, thereby reducing code duplication.

[0082] In an exemplary embodiment, the token revocation request also carries a token validity period, which is used to instruct the blockchain to delete the expired identity token corresponding to the identity identifier.

[0083] In this embodiment, due to the timely cleaning of expired identity tokens, the risk of user access token leakage can be effectively reduced and the security of the system can be improved.

[0084] The above content mainly describes the scheme of the embodiment of the present application with the user end as the execution subject. With the server as the execution subject, as shown in FIG4, an identity token management method is provided, and the method is applied to the server in FIG1 as an example for description, including the following steps 402 to 408. Among them:

[0085] Step 402: Receive a token acquisition request sent by the user based on a decentralized random number signature authentication protocol, where the token acquisition request carries an identity identifier.

[0086] Step 404: Send the random number to the user terminal to instruct the user terminal to sign the random number based on the private key in the public-private key pair generated by the user terminal.

[0087] Step 406, receiving the digital signature returned by the user end, sending the identity identifier, random number and digital signature to the blockchain to instruct the blockchain to decrypt the digital signature based on the public key corresponding to the identity identifier to obtain the decryption result. When the decryption result is consistent with the random number, the encrypted permission configuration information corresponding to the identity identifier is returned.

[0088] Among them, the identity stored in the blockchain, the public key corresponding to the identity, and the encrypted permission configuration information are saved during the user identity registration process.

[0089] Step 408, decrypt the encrypted permission configuration information, construct an identity token based on the decrypted permission configuration information, send the correspondence between the identity token and the identity identifier to the blockchain for storage, and return the identity token to the user end to instruct the user end to access the relevant service interface of the microservice.

[0090] In the above-mentioned identity token management method, since the issuance of identity tokens is no longer handled solely by a centralized third party, the identity identification, permission configuration information and the public key generated locally by the user can be stored by the blockchain, and the legality of the user applying for the token can be verified through the interaction process between the server and the blockchain, thereby reducing the possibility of privacy leakage.

[0091] In an exemplary embodiment, the process of user identity registration includes:

[0092] Receive an identity registration request sent by a user, the identity registration request including permission configuration information generated by the user according to the current user permissions, a public key and an identity identifier generated locally by the user;

[0093] The permission configuration information is encrypted based on the locally generated public key, and the identity identifier, the public key generated locally by the user itself and the encrypted permission configuration information are sent to the blockchain for storage.

[0094] This process is the identity registration process. For details, please refer to the above explanation and will not be repeated here.

[0095] In this embodiment, since the issuance of identity tokens is no longer handled solely by a centralized third party, the identity identification, permission configuration information and the public key generated locally by the user can be stored by the blockchain, and the legality of the user applying for the token can be verified through the interaction process between the server and the blockchain, thereby reducing the possibility of privacy leakage.

[0096] In an exemplary embodiment, the method further comprises:

[0097] When identity revocation is required, receiving an identity revocation request with an identity identifier from a user end, and controlling the deletion of associated data corresponding to the identity identifier in the blockchain if the user end initiating the identity revocation request is the same as the user end using the identity identifier for identity registration;

[0098] When a token needs to be revoked, a token revocation request carrying an identity identifier and an identity token is received from a user, and the blockchain is controlled to delete the identity token corresponding to the identity identifier;

[0099] When the token needs to be verified, a token verification request carrying the identity identifier and identity token sent by the user is received, and the blockchain is controlled to verify whether the identity identifier has been revoked and whether the identity token has been revoked.

[0100] In this embodiment, since the identity and token can be revoked through the relevant methods of the smart contract, the token can also be verified, so that instant revocation can be achieved, so as to effectively reduce the risk of leakage of user access tokens and improve the security of the system. In addition, since the verification can be performed through the control agent and the proxy agent in the server, the single point problem when logging in with a single account and password for identity authentication can be improved; because the control agent and the proxy agent are encapsulated in a container, they can support cross-platform or programming language reuse, thereby reducing code duplication.

[0101] For ease of understanding, the complete method flow provided by the embodiment of the present application is now described. A simplified schematic diagram of the method flow can be referenced to FIG5, and a detailed schematic diagram of the method flow can be referenced to FIG6. For the process of identity registration and token application between the user terminal and the authority server, reference can be made to the schematic diagram in FIG7, and the specific process is as follows:

[0102] (1) The user generates a pair of public and private keys and an identity locally, and generates permission configuration information based on the current user permissions.

[0103] (2) The user client calls the server's registration interface and sends an identity registration request to the server based on the permission configuration information, the locally generated public key and identity identifier.

[0104] (3) The server encrypts the permission configuration information based on the public key generated by itself, and sends the identity identifier, the public key generated locally by the user, and the encrypted permission configuration information to the blockchain, which saves it.

[0105] (4) Based on the decentralized random number signature authentication protocol, the user sends a token acquisition request carrying an identity identifier to the server, and the server generates and returns a random number.

[0106] (5) The user signs the random number based on the private key in the locally generated public-private key pair and sends the digital signature to the server. The server sends the identity, random number and digital signature to the blockchain.

[0107] (6) The blockchain decrypts the digital signature based on the public key corresponding to the identity identifier to obtain the decryption result; when the decryption result is consistent with the random number, the encrypted permission configuration information corresponding to the identity identifier is returned to the server.

[0108] (7) The server decrypts the encrypted permission configuration information, constructs an identity token based on the decrypted permission configuration information, returns the identity token to the user, and sends the correspondence between the identity token and the identity identifier to the blockchain for storage.

[0109] Based on the same inventive concept, the embodiment of the present application also provides a user terminal for implementing the above-mentioned. The implementation scheme for solving the problem provided by the user terminal is similar to the implementation scheme recorded in the above-mentioned method, so the specific limitations in one or more user terminal embodiments provided below can refer to the limitations of the identity token management method above, and will not be repeated here.

[0110] In an exemplary embodiment, as shown in FIG8 , a user terminal is provided, including: a sending module 802, a verification module 804 and an access module 806, wherein:

[0111] The sending module 802 is used to send a token acquisition request carrying an identity identifier to the server based on a decentralized random number signature authentication protocol, and receive a random number returned by the server;

[0112] The verification module 804 is used to sign the random number based on the private key in a pair of public and private keys generated locally, and send the digital signature to the server to instruct the server to send the identity, random number and digital signature to the blockchain. The blockchain decrypts the digital signature based on the public key corresponding to the identity to obtain the decryption result. When the decryption result is consistent with the random number, the encrypted permission configuration information corresponding to the identity is returned to the server. The server constructs an identity token based on the decrypted permission configuration information, and sends the corresponding relationship between the identity token and the identity to the blockchain for storage; wherein the identity, the public key corresponding to the identity, and the encrypted permission configuration information stored in the blockchain are saved during the user identity registration process;

[0113] The access module 806 is used to receive the identity token returned by the server and access the relevant service interface of the microservice based on the identity token.

[0114] In an exemplary embodiment, the verification module 804 is also used to locally generate a pair of public and private keys and an identity, and generate permission configuration information according to the current user permissions; call the registration interface of the server, and based on the permission configuration information, the locally generated public key and the identity, send an identity registration request to the server to instruct the server to encrypt the permission configuration information based on the public key generated by itself, and send the identity, the locally generated public key and the encrypted permission configuration information to the blockchain for storage by the blockchain.

[0115] In an exemplary embodiment, the verification module 804 is further configured to, when identity revocation is required, send an identity revocation request carrying an identity identifier to the server, so as to instruct the server to control the deletion of associated data corresponding to the identity identifier in the blockchain when determining that the user terminal initiating the identity revocation request is consistent with the user terminal using the identity identifier for identity registration;

[0116] When a token needs to be revoked, a token revocation request carrying the identity identifier and the identity token is sent to the server to instruct the server to control the blockchain to delete the identity token corresponding to the identity identifier;

[0117] When the token needs to be verified, a token verification request carrying the identity identifier and the identity token is sent to the server to instruct the server to control the blockchain to verify whether the identity identifier has been revoked and whether the identity token has been revoked.

[0118] In an exemplary embodiment, the token revocation request also carries a token validity period, which is used to instruct the blockchain to delete the expired identity token corresponding to the identity identifier.

[0119] In an exemplary embodiment, as shown in FIG9 , a server is provided, including: a receiving module 902, a signing module 904, a verification module 906 and a construction module 908, wherein:

[0120] The receiving module 902 is used to receive a token acquisition request sent by the user end based on a decentralized random number signature authentication protocol, where the token acquisition request carries an identity identifier.

[0121] The signature module 904 is used to send a random number to the user terminal to instruct the user terminal to sign the random number based on the private key in a pair of public and private keys generated by the user terminal.

[0122] The verification module 906 is used to receive the digital signature returned by the user end, send the identity identifier, random number and digital signature to the blockchain, so as to instruct the blockchain to decrypt the digital signature based on the public key corresponding to the identity identifier to obtain the decryption result, and return the encrypted permission configuration information corresponding to the identity identifier when the decryption result is consistent with the random number; wherein, the identity identifier, the public key corresponding to the identity identifier, and the encrypted permission configuration information stored in the blockchain are saved during the user identity registration process.

[0123] The construction module 908 is used to decrypt the encrypted permission configuration information, construct an identity token according to the decrypted permission configuration information, send the correspondence between the identity token and the identity identifier to the blockchain for storage, and return the identity token to the user end to indicate the user end to access the relevant service interface of the microservice.

[0124] In an exemplary embodiment, the verification module 906 is also used to receive an identity registration request sent by the user terminal, which includes permission configuration information generated by the user terminal according to the current user permissions, a public key and an identity identifier generated locally by the user terminal itself; the permission configuration information is encrypted based on the locally generated public key, and the identity identifier, the public key generated locally by the user terminal itself and the encrypted permission configuration information are sent to the blockchain for storage by the blockchain.

[0125] In an exemplary embodiment, the verification module 906 is also used to receive an identity revocation request carrying an identity identifier sent by a user terminal when identity revocation is required, and control deletion of associated data corresponding to the identity identifier in the blockchain when the user terminal initiating the identity revocation request is consistent with the user terminal using the identity identifier for identity registration; when a token needs to be revoked, receive a token revocation request carrying an identity identifier and an identity token sent by a user terminal, and control the blockchain to delete the identity token corresponding to the identity identifier; when a token needs to be verified, receive a token verification request carrying an identity identifier and an identity token sent by a user terminal, and control the blockchain to verify whether the identity identifier is revoked and whether the identity token is revoked.

[0126] Each module in the above-mentioned client and server can be implemented in whole or in part by software, hardware or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute the operations corresponding to each module above.

[0127] In an exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be shown in FIG10. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. The processor, the memory and the input / output interface are connected via a system bus, and the communication interface is connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data related to identity authentication. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, an identity token management method is implemented.

[0128] Those skilled in the art will understand that the structure shown in FIG. 10 is merely a block diagram of a partial structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

[0129] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the method flow provided by the above-mentioned various method embodiments is implemented.

[0130] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the method flow provided by the above-mentioned various method embodiments is implemented.

[0131] In one embodiment, a computer program product is provided, including a computer program, which implements the method flow provided by the above-mentioned various method embodiments when executed by a processor.

[0132] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0133] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0134] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A method for managing identity tokens, characterized in that: Applied to a user terminal, the method includes: Based on the decentralized random number signature authentication protocol, a token acquisition request carrying an identity identifier is sent to the server, and a random number returned by the server is received; The random number is signed based on the private key in a pair of public and private keys generated locally, and the digital signature is sent to the server to instruct the server to send the identity identifier, the random number and the digital signature to the blockchain, and the blockchain decrypts the digital signature based on the public key corresponding to the identity identifier to obtain a decryption result. When the decryption result is consistent with the random number, the encrypted permission configuration information corresponding to the identity identifier is returned to the server, and the server constructs an identity token based on the decrypted permission configuration information, and sends the corresponding relationship between the identity token and the identity identifier to the blockchain for storage; wherein the identity identifier, the public key corresponding to the identity identifier, and the encrypted permission configuration information stored in the blockchain are saved during the user identity registration process; Receive the identity token returned by the server, and access the relevant service interface of the microservice based on the identity token.

2. The method according to claim 1, characterized in that The user identity registration process includes: Generate a pair of public and private keys and identity locally, and generate permission configuration information based on the current user permissions; The registration interface of the server is called, and based on the permission configuration information, the locally generated public key and the identity identifier, an identity registration request is sent to the server to instruct the server to encrypt the permission configuration information based on the public key generated by itself, and the identity identifier, the locally generated public key and the encrypted permission configuration information are sent to the blockchain for storage by the blockchain.

3. The method according to claim 1, characterized in that The method further comprises: When identity revocation is required, an identity revocation request carrying the identity identifier is sent to the server to instruct the server to control the deletion of the associated data corresponding to the identity identifier in the blockchain when it is determined that the user terminal initiating the identity revocation request is consistent with the user terminal using the identity identifier for identity registration; When a token needs to be revoked, a token revocation request carrying the identity identifier and the identity token is sent to the server to instruct the server to control the blockchain to delete the identity token corresponding to the identity identifier; When the token needs to be verified, a token verification request carrying the identity identifier and the identity token is sent to the server to instruct the server to control the blockchain to verify whether the identity identifier is revoked and whether the identity token is revoked.

4. The method according to claim 3, characterized in that The token revocation request also carries a token validity period, and the token validity period is used to instruct the blockchain to delete the expired identity token corresponding to the identity identifier.

5. A method for managing identity tokens, characterized in that: Applied to a server, the method comprises: Receiving a token acquisition request sent by a user based on a decentralized random number signature authentication protocol, wherein the token acquisition request carries an identity identifier; Sending a random number to the client to instruct the client to sign the random number based on a private key in a pair of public and private keys generated by the client; Receive the digital signature returned by the user terminal, send the identity identifier, the random number and the digital signature to the blockchain, instruct the blockchain to decrypt the digital signature based on the public key corresponding to the identity identifier to obtain a decryption result, and return the encrypted permission configuration information corresponding to the identity identifier when the decryption result is consistent with the random number; wherein the identity identifier, the public key corresponding to the identity identifier, and the encrypted permission configuration information stored in the blockchain are saved during the user identity registration process; The encrypted permission configuration information is decrypted, an identity token is constructed according to the decrypted permission configuration information, the correspondence between the identity token and the identity identifier is sent to the blockchain for storage, and the identity token is returned to the user end to instruct the user end to access the relevant service interface of the microservice.

6. The method according to claim 5, characterized in that The user identity registration process includes: Receiving an identity registration request sent by the user terminal, the identity registration request including permission configuration information generated by the user terminal according to current user permissions, a public key generated locally by the user terminal itself, and the identity identifier; The permission configuration information is encrypted based on a locally generated public key, and the identity identifier, the locally generated public key of the user terminal itself and the encrypted permission configuration information are sent to the blockchain for storage.

7. The method according to claim 5, characterized in that The method further comprises: In the case where identity revocation is required, receiving an identity revocation request sent by the user end and carrying the identity identifier, and controlling the deletion of associated data corresponding to the identity identifier in the blockchain when the user end initiating the identity revocation request is the same as the user end using the identity identifier for identity registration; In the case where a token needs to be revoked, receiving a token revocation request sent by the user terminal and carrying the identity identifier and the identity token, and controlling the blockchain to delete the identity token corresponding to the identity identifier; When the token needs to be verified, a token verification request carrying the identity identifier and the identity token sent by the user terminal is received, and the blockchain is controlled to verify whether the identity identifier is revoked and whether the identity token is revoked.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images