Identity token management method, computer device and readable storage medium

Abstract

The application 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, receiving a random number returned by the server; signing the random number based on a locally generated private key, sending the digital signature to the server, sending the identity identifier, the random number and the digital signature to the block chain, decrypting the digital signature based on the public key corresponding to the identity identifier by the block chain to obtain a decryption result, returning the encrypted permission configuration information corresponding to the identity identifier to the server in the case that the decryption result is consistent with the random number, constructing an identity token according to the decrypted permission configuration information by the server, and the identity token is used for accessing related service interfaces of micro services. Since the legality of the user end applying for the token can be verified through the interaction process between the server and the block chain, the possibility of privacy leakage can be reduced.

Description

Technical Field

[0001] This application relates to the field of identity verification technology, and in particular to an identity token management method, computer device, computer-readable storage medium, and computer program product. Background Technology

[0002] The shift from monolithic to microservice architectures has brought numerous advantages to various types of digital transactions, including improved maintainability, scalability, and speed of deployment. However, in a microservice architecture, each microservice is responsible for implementing specific functions or business logic, requiring authentication and authorization for each request to access a microservice. In related technologies, this often involves a centralized third party storing user authentication information, which can easily lead to privacy breaches. Summary of the Invention

[0003] Therefore, 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-mentioned technical problems.

[0004] Firstly, this application provides an identity token management method, including:

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

[0006] Based on the private key of a locally generated public-private key pair, a random number is signed. The digital signature is sent to the server, instructing the server to send the identity identifier, random number, and digital signature to the blockchain. The blockchain decrypts the digital signature based on the public key corresponding to the identity identifier, obtaining the decryption result. If the decryption result matches the random number, the encrypted permission configuration information corresponding to the identity identifier is returned to the server. The server constructs an identity token based on the decrypted permission configuration information and sends the correspondence between the identity token and the identity identifier to the blockchain for storage. 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.

[0007] Receive the identity token returned by the server, and use the identity token to access the relevant service interfaces of the microservice.

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

[0009] Generate a public / private key pair and an identity identifier locally, and generate permission configuration information based on the current user's permissions;

[0010] The system calls the server's registration interface, sends an identity registration request to the server based on the permission configuration information, the locally generated public key, and the identity identifier, instructing the server to encrypt the permission configuration information based on its own generated public key, and then sends 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 includes:

[0012] In cases where identity revocation is required, an identity revocation request carrying an identity identifier is sent to the server. This instructs the server to determine if the user initiating the identity revocation request is the same user who registered using the identity identifier, and then to control the deletion of the associated data corresponding to the identity identifier in the blockchain.

[0013] In cases where token revocation is required, 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 token verification is required, a token verification request carrying the identity identifier and 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 embodiment, the token revocation request also carries a token expiration date, which is used to instruct the blockchain to delete the expired identity token corresponding to the identity identifier.

[0016] Secondly, this application provides an identity token management method, including:

[0017] Receive token acquisition requests sent by the user client based on a decentralized random number signature authentication protocol. The token acquisition request carries an identity identifier.

[0018] 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 public-private key pair generated by the user terminal.

[0019] The system receives the digital signature returned by the user, sends the identity identifier, random number, and digital signature to the blockchain, and instructs the blockchain to decrypt the digital signature based on the public key corresponding to the identity identifier. If the decryption result matches the random number, the system returns the encrypted permission configuration information corresponding to the identity identifier. 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.

[0020] The encrypted permission configuration information is decrypted, an identity token is constructed based on 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 terminal to instruct the user terminal to access the relevant service interface of the microservice.

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

[0022] Receive an identity registration request sent by the user client. The identity registration request includes permission configuration information generated by the user client based on the current user permissions, and the public key and identity identifier generated locally by the user client.

[0023] The permission configuration information is encrypted using a locally generated public key. The identity identifier, the user's locally generated public key, and the encrypted permission configuration information are then sent to the blockchain for storage.

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

[0025] In cases where identity revocation is required, the system receives identity revocation requests sent by user clients, which carry identity identifiers. If the user client initiating the identity revocation request is the same as the user client that registered with the identity identifier, the system controls the deletion of the associated data corresponding to the identity identifier in the blockchain.

[0026] In cases where token revocation is required, the system receives a token revocation request from the user client, which carries the identity identifier and the identity token, and controls the blockchain to delete the identity token corresponding to the identity identifier.

[0027] When token verification is required, the system receives a token verification request from the user client, which carries the identity identifier and the identity token. It then controls the blockchain to verify whether the identity identifier and the identity token have been revoked.

[0028] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps provided by the various possible implementations of the first or second aspect described above.

[0029] Fourthly, this application also 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 implementations of the first or second aspect.

[0030] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps provided by various possible implementations of the first or second aspect described above.

[0031] The aforementioned identity token management methods, computer devices, computer-readable storage media, and computer program products reduce the possibility of privacy leaks because the issuance of identity tokens is no longer handled solely by a centralized third party. Instead, identity identifiers, permission configuration information, and locally generated public keys on the user's end are stored on the blockchain. The legitimacy of the user applying for the token is verified through the interaction between the server and the blockchain. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This is a diagram illustrating the application environment for authentication in one embodiment;

[0034] Figure 2 This is a flowchart illustrating an identity token management method in one embodiment;

[0035] Figure 3 This is a schematic diagram illustrating the relationship between the Agent and the Control Agent in one embodiment;

[0036] Figure 4 This is a flowchart illustrating an identity token management method in one embodiment;

[0037] Figure 5 This is a simplified flowchart illustrating an identity token management method in one embodiment;

[0038] Figure 6 This is a detailed flowchart of an identity token management method in one embodiment;

[0039] Figure 7 This is a schematic diagram illustrating the interaction between the user client and the authorization server in one embodiment.

[0040] Figure 8 Here is a block diagram of the user terminal in one embodiment;

[0041] Figure 9 This is a structural block diagram of a server in one embodiment;

[0042] Figure 10 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0044] Before explaining the embodiments of this application, the terms and concepts that may be involved in the embodiments of this application will be explained.

[0045] Blockchain: A decentralized distributed ledger organized in a chain-like data structure, containing multiple blocks of transactions. Each block contains a batch of verified transactions and uses cryptographic techniques to ensure data security and tamper-proofness.

[0046] Smart contracts: 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 typically written in code and deployed and executed on a blockchain network, enabling various types of digital transactions and agreements in a decentralized manner.

[0047] The user side is responsible for initiating requests to the microservice system and receiving responses, allowing users to create multiple different identity accounts.

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

[0049] Blockchain: Responsible for executing related smart contracts and storing important data.

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

[0051] Currently, the shift from monolithic architecture to microservice architecture offers numerous advantages, including improved maintainability, scalability, and faster innovation and deployment. However, in a microservice architecture, each microservice is responsible for implementing specific functionalities or business logic, meaning that every request to access a microservice requires authentication and authorization. This 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 should not have multiple responsibilities: A microservice should only perform one function. Adding global authentication and authorization logic to a microservice (as an additional feature) will reduce its reliability and increase the difficulty of its management.

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

[0055] In related technologies, a centralized third party is needed to store users' identity authentication information. Users have no control over their own identity authentication information, which can easily lead to privacy leaks.

[0056] To address the aforementioned issues, this application provides an identity token management method that can be applied to, for example... Figure 1 In the application environment shown, the user terminal 102, server 104, and blockchain 106 communicate with each other to manage identity tokens. When the user terminal 102 needs to request an identity token, server 104 can specifically be a permission server. When the user terminal needs to revoke an identity token, server 104 can specifically be a business server. Blockchain 106 can be composed of multiple blockchain devices, such as multiple servers; this embodiment does not specifically limit this. The interaction process between the three can be referred to in the following interaction diagram. The user terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality devices, smart glasses, etc. Server 104 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0057] In one exemplary embodiment, such as Figure 2 As shown, an identity token management method is provided, which can be applied to... Figure 1 Taking the user client as an example, the explanation includes the following steps 202 to 206. Wherein:

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

[0059] The decentralized random number signature authentication protocol (RSAP) primarily achieves token acquisition by verifying the signature of a random number. The identity identifier is the unique identifier for the user. After receiving a token acquisition request, the server generates a random number and returns it to the user.

[0060] Step 204: Based on the private key of the locally generated public-private key pair, sign the random number and send the digital signature to the server to instruct the server to send the identity identifier, random number, and digital signature to the blockchain. The blockchain decrypts the digital signature based on the public key corresponding to the identity identifier to obtain the decryption result. If the decryption result matches the random number, return the encrypted permission configuration information corresponding to the identity identifier to the server. The server constructs an identity token based on the decrypted permission configuration information and sends the correspondence between the identity token and the identity identifier to the blockchain for storage.

[0061] The locally generated public-private key pair refers to the public and private keys generated by the user client. The user client can use the private key in this pair to sign a random number, obtaining a digital signature. The user client sends the digital signature to the server, which can then send the identity identifier, random number, and digital signature to the blockchain by calling the smart contract's signature authentication method. Since the user client has already forwarded its locally generated public key, its own identity identifier, and permission configuration information representing its current permissions to the blockchain during identity registration, and the blockchain stores this information, it can verify the digital signature based on this previously saved information.

[0062] Specifically, during identity registration, the blockchain can store the user's identity identifier along with their public key. Therefore, when the blockchain receives the identity identifier, random number, and digital signature from the server, it can first use the identity identifier to determine the corresponding public key. The blockchain then uses this public key to decrypt the digital signature, obtaining the decryption result. Understandably, if the identity identifier is correct and the digital signature has not been tampered with during transmission, the decryption result should be the same as the random number received by the blockchain. Otherwise, it indicates that the identity is illegitimate or the digital signature has been tampered with during transmission, making the transmission process insecure. In this case, the blockchain may not return the encrypted permission configuration information corresponding to the identity identifier to the server and instead return a verification failure message.

[0063] If the decryption result matches the random number, the blockchain can return the encrypted permission configuration information corresponding to that identity to the server. The server can then decrypt the information to obtain the decrypted permission configuration information and construct an identity token based on it. The encrypted permission configuration information stored on the blockchain is generated during identity registration. The server uses the public key of a locally generated public-private key pair to encrypt the permission configuration information sent by the user before sending it to the blockchain for storage. This ensures that the blockchain stores encrypted permission configuration information, thus improving the security of the data stored on the blockchain. The server can decrypt the encrypted permission configuration information returned by the blockchain using its locally generated private key. Furthermore, the identity token can serve as an index to locate the user's permission configuration.

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

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

[0066] In the aforementioned identity token management method, since the issuance of identity tokens is no longer handled solely by a centralized third party, but rather the identity identifier, permission configuration information, and locally generated public key on the user's end can be stored on the blockchain, and the legitimacy of the user applying for the token can be verified through the interaction between the server and the blockchain, thereby reducing the possibility of privacy leaks.

[0067] In one exemplary embodiment, the user registration process includes:

[0068] Generate a public / private key pair and an identity identifier locally, and generate permission configuration information based on the current user's permissions;

[0069] The system calls the server's registration interface, sends an identity registration request to the server based on the permission configuration information, the locally generated public key, and the identity identifier, instructing the server to encrypt the permission configuration information based on its own generated public key, and then sends the identity identifier, the locally generated public key, and the encrypted permission configuration information to the blockchain for storage.

[0070] The identity identifier can be randomly generated, and the permission configuration information can represent the user's menu permissions or interface permissions, etc., which are not specifically limited in this embodiment. After the user sends an identity registration request to the server, the server can also generate a public-private key pair locally, and then use the public key to encrypt the permission configuration information sent by the user. Finally, the server sends the encrypted permission configuration information, the identity identifier sent by the user, and the public key generated locally by the user to the blockchain, where it is stored and 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 identifier, permission configuration information, and public key generated locally on the user's end can be stored on the blockchain. The legitimacy of the user applying for the token is verified through the interaction between the server and the blockchain, thereby reducing the possibility of privacy leaks.

[0072] In one exemplary embodiment, the method further includes:

[0073] In cases where identity revocation is required, an identity revocation request carrying an identity identifier is sent to the server. This instructs the server to determine if the user initiating the identity revocation request is the same user who registered using the identity identifier, and then to control the deletion of the associated data corresponding to the identity identifier in the blockchain.

[0074] In cases where token revocation is required, 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 token verification is required, a token verification request carrying the identity identifier and 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] Here, the server mentioned can be a business server, specifically handled by a proxy agent within that business server used for access control. The control agent within the business server can be deployed separately to distribute blockchain configuration and verification rules to the proxy agent. The proxy agent and microservices can be deployed together in the same container within the business server, handling the specific logic related to authentication. The relationship between the control agent and the proxy agent can be found in [reference needed]. Figure 3 .

[0077] exist Figure 3In this architecture, the control agent is responsible for issuing the rules for acquiring and parsing identity tokens, as well as the relevant blockchain configurations, to the proxy agent. Upon receiving an access request for a microservice from the user, the proxy agent first extracts the identity token from the request according to the acquisition rules. Next, the proxy agent uses the relevant blockchain configurations to call the smart contract's pre-authentication token check method to determine the validity of the identity token. If the identity token is valid, it is parsed according to the parsing rules to determine the legality of permissions and other related information. In summary, permission-related business logic is processed only between the control agent and the proxy agent, and is not tightly coupled with the specific microservice.

[0078] In the process of controlling permissions, various needs may arise. One is the need to revoke the entire user identity, and another is the need to revoke a specific identity token. For the revocation of the entire user identity, the client can send an identity revocation request to the business server, which can carry the user's identity identifier. The agent in the business server can then determine whether the client initiating the identity revocation request is the same client that registered using the identity identifier. For example, it can check whether the corresponding hardware addresses in the two processes are the same. If they are the same, the agent can invoke smart contract methods to delete the associated data corresponding to that identity identifier from the blockchain. For example, it can delete permission configuration information, public keys, and other data.

[0079] To revoke an identity token, the client can send a token revocation request carrying both the identity identifier and the identity token to the business server. The agent on the business server can then invoke smart contract methods to delete the identity token corresponding to that identity identifier from the blockchain.

[0080] Besides revoking an entire identity and a specific token under a specific identity, identity tokens can also be verified. The client can send a token verification request carrying the identity identifier and the identity token to the business server. The agent in the business server can then call methods related to the smart contract to verify the identity token in the blockchain. Specifically, it can first call the token verification method, which determines whether the identity identifier corresponding to the identity token has been revoked in the blockchain. If the identity identifier has been revoked, it returns a result indicating the identity token is invalid. If the identity identifier has not been revoked, it can further verify whether the identity token has been revoked. If the identity token has been revoked, it returns a result indicating the identity token is invalid.

[0081] In this embodiment, since identity and tokens can be revoked and verified through smart contract methods, immediate revocation can be achieved, effectively reducing the risk of user access token leakage and improving system security. Furthermore, since verification can be performed through the control agent and proxy agent in the server, the single point of failure issue of relying solely on account and password login for authentication can be mitigated. Because the control agent and proxy agent are encapsulated in a container, they can be reused across platforms or programming languages, thereby reducing code duplication.

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

[0083] In this embodiment, by promptly clearing expired identity tokens, the risk of user access token leakage can be effectively reduced, thereby improving system security.

[0084] The above content mainly describes the scheme of the embodiments of this application with the user terminal as the execution subject. With the server as the execution subject, such as... Figure 4 As shown, an identity token management method is provided, which can be applied to... Figure 1 Taking the server in the example, the explanation includes steps 402 to 408. Wherein:

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

[0086] Step 404: Send a 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 itself.

[0087] Step 406: Receive the digital signature returned by the user terminal, send 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, obtain the decryption result, and return the encrypted permission configuration information corresponding to the identity identifier if the decryption result is consistent with the random number.

[0088] 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.

[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 terminal to instruct the user terminal to access the relevant service interfaces of the microservice.

[0090] In the aforementioned identity token management method, since the issuance of identity tokens is no longer handled solely by a centralized third party, but rather the identity identifier, permission configuration information, and locally generated public key on the user's end can be stored on the blockchain, and the legitimacy of the user applying for the token can be verified through the interaction between the server and the blockchain, thereby reducing the possibility of privacy leaks.

[0091] In one exemplary embodiment, the user registration process includes:

[0092] Receive an identity registration request sent by the user client. The identity registration request includes permission configuration information generated by the user client based on the current user permissions, and the public key and identity identifier generated locally by the user client.

[0093] The permission configuration information is encrypted using a locally generated public key. The identity identifier, the user's locally generated public key, and the encrypted permission configuration information are then sent to the blockchain for storage.

[0094] This process is the identity registration process, which can be found in the explanation above 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 identifier, permission configuration information, and public key generated locally on the user's end can be stored on the blockchain. The legitimacy of the user applying for the token is verified through the interaction between the server and the blockchain, thereby reducing the possibility of privacy leaks.

[0096] In one exemplary embodiment, the method further includes:

[0097] In cases where identity revocation is required, the system receives identity revocation requests sent by user clients, which carry identity identifiers. If the user client initiating the identity revocation request is the same as the user client that registered with the identity identifier, the system controls the deletion of the associated data corresponding to the identity identifier in the blockchain.

[0098] In cases where token revocation is required, the system receives a token revocation request from the user client, which carries the identity identifier and the identity token, and controls the blockchain to delete the identity token corresponding to the identity identifier.

[0099] When token verification is required, the system receives a token verification request from the user client, which carries the identity identifier and the identity token. It then controls the blockchain to verify whether the identity identifier and the identity token have been revoked.

[0100] In this embodiment, since identity and tokens can be revoked and verified through smart contract methods, immediate revocation can be achieved, effectively reducing the risk of user access token leakage and improving system security. Furthermore, since verification can be performed through the control agent and proxy agent in the server, the single point of failure issue of relying solely on account and password login for authentication can be mitigated. Because the control agent and proxy agent are encapsulated in a container, they can be reused across platforms or programming languages, thereby reducing code duplication.

[0101] For ease of understanding, the complete method flow provided in the embodiments of this application is now described. A simplified schematic diagram of the method flow can be found in the following figure. Figure 5 A detailed flowchart of this method can be found in section 6. For the process of identity registration and token request between the user client and the authorization server, please refer to... Figure 7 The diagram in the image shows the specific process as follows:

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

[0103] (2) The user 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 its own generated public key, and sends the identity identifier, the public key generated locally by the user terminal, and the encrypted permission configuration information to the blockchain for storage.

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

[0106] (5) The user signs the random number based on the private key in the public-private key pair generated locally, and sends the digital signature to the server. The server sends the identity identifier, 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; if the decryption result is consistent with the random number, it returns the encrypted permission configuration information corresponding to the identity identifier 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, this application also provides a user terminal for implementing the above-mentioned solution. The solution provided by this user terminal is similar to the solution described in the above method; therefore, the specific limitations in one or more user terminal embodiments provided below can be found in the limitations of the identity token management method described above, and will not be repeated here.

[0110] In one exemplary embodiment, such as Figure 8 As shown, a user terminal is provided, including: a sending module 802, an authentication 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 to receive a random number returned by the server.

[0112] The verification module 804 is used to sign a random number based on the private key of a locally generated public-private key pair, and send the digital signature to the server to instruct the server to send the identity identifier, random number, and digital signature to the blockchain. The blockchain decrypts the digital signature based on the public key corresponding to the identity identifier, and if the decryption result matches the random number, it returns the encrypted permission configuration information corresponding to the identity identifier to the server. The server constructs an identity token based on the decrypted permission configuration information and sends the correspondence between the identity token and the identity identifier to the blockchain for storage. 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.

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

[0114] In an exemplary embodiment, the verification module 804 is further configured to generate a pair of public and private keys and an identity identifier locally, generate permission configuration information based on the current user permissions, call the server's registration interface, and send an identity registration request to the server based on the permission configuration information, the locally generated public key and the identity identifier, so as to instruct the server to encrypt the permission configuration information based on its own generated public key, and send the identity identifier, the locally generated public key and the encrypted permission configuration information to the blockchain for storage.

[0115] In an exemplary embodiment, the verification module 804 is further configured to send an identity revocation request carrying an identity identifier to the server when it is necessary to revoke the identity, so as to instruct the server to control the deletion of the associated data corresponding to the identity identifier in the blockchain if it determines that the user terminal that initiates the identity revocation request is the same as the user terminal that registered the identity using the identity identifier.

[0116] In cases where token revocation is required, 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 token verification is required, a token verification request carrying the identity identifier and 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 one exemplary embodiment, the token revocation request also carries a token expiration date, which is used to instruct the blockchain to delete the expired identity token corresponding to the identity identifier.

[0119] In one exemplary embodiment, such as Figure 9 As shown, 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 terminal based on a decentralized random number signature authentication protocol. The token acquisition request carries an identity identifier.

[0121] The signature module 904 is used to send a random number to the user terminal, instructing the user terminal to sign the random number based on the private key in a public-private key pair generated by itself.

[0122] The verification module 906 is used to receive the digital signature returned by the user terminal, send 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, obtain the decryption result, and return the encrypted permission configuration information corresponding to the identity identifier if the decryption result matches 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] Module 908 is used to 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 terminal to instruct the user terminal to access the relevant service interfaces of the microservice.

[0124] In an exemplary embodiment, the verification module 906 is further configured to receive an identity registration request sent by the user terminal. The identity registration request includes permission configuration information generated by the user terminal based on the current user permissions, a public key generated locally by the user terminal, and an identity identifier. The user terminal encrypts the permission configuration information based on the locally generated public key and sends the identity identifier, the locally generated public key, and the encrypted permission configuration information to the blockchain for storage.

[0125] In an exemplary embodiment, the verification module 906 is further configured to: receive an identity revocation request carrying an identity identifier sent by a user terminal when identity revocation is required; and control the deletion of associated data corresponding to the identity identifier in the blockchain if the user terminal initiating the identity revocation request is the same as the user terminal that registered the identity using the identity identifier; receive a token revocation request carrying an identity identifier and an identity token sent by a user terminal when a token revocation is required, and control the blockchain to delete the identity token corresponding to the identity identifier; and receive a token verification request carrying an identity identifier and an identity token sent by a user terminal when token verification is required, and control the blockchain to verify whether the identity identifier and the identity token have been revoked.

[0126] The modules in the aforementioned client and server can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0127] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores authentication-related data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements an identity token management method.

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

[0129] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method flow provided in the various method embodiments described above.

[0130] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method flow provided in the various method embodiments described above.

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

[0132] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this 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. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0133] The technical features of the above embodiments can be combined in any way. For the sake of brevity, 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 embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for managing identity tokens, characterized in that, When applied to a user terminal, the method includes: Based on a decentralized random number signature authentication protocol, a token acquisition request carrying an identity identifier is sent to the server, and a random number is received from the server. Based on the private key of a locally generated public-private key pair, the random number is signed, 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. The blockchain decrypts the digital signature based on the public key corresponding to the identity identifier to obtain a decryption result. If the decryption result matches the random number, the encrypted permission configuration information corresponding to the identity identifier is returned to the server. The server constructs an identity token based on the decrypted permission configuration information and sends the correspondence between the identity token and the identity identifier to the blockchain for storage. 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 interfaces of the microservice based on the identity token; The user registration process includes: Generate a public / private key pair and an identity identifier locally, and generate permission configuration information based on the current user's permissions; The system 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 the identity identifier. This instructs the server to encrypt the permission configuration information using its own generated public key and then send the identity identifier, the locally generated public key, and the encrypted permission configuration information to the blockchain for storage. In cases where token revocation is required, 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. The control agent in the server is deployed separately and is used to distribute blockchain configuration and verification rules to the agent agents deployed in the containers of each microservice; the agent agent intercepts service interface access requests and calls the smart contract to check the validity of the identity token.

2. The method according to claim 1, characterized in that, The method further includes: In the event that an identity needs to be revoked, an identity revocation request carrying the identity identifier is sent to the server, instructing the server to control the deletion of the associated data corresponding to the identity identifier in the blockchain if it determines that the user terminal that initiated the identity revocation request is the same as the user terminal that registered the identity using the identity identifier. When a token verification is required, 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.

3. The method according to claim 2, characterized in that, 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.

4. A method for managing identity tokens, characterized in that, Applied to a server, the method includes: Receive a token acquisition request sent by the user client based on a decentralized random number signature authentication protocol, wherein the token acquisition request carries an identity identifier; 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 public-private key pair generated by itself; The system receives a digital signature returned by the user client, sends the identity identifier, the random number, and the digital signature to the blockchain, instructing the blockchain to decrypt the digital signature based on the public key corresponding to the identity identifier, obtains a decryption result, and returns the encrypted permission configuration information corresponding to the identity identifier if the decryption result matches 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 based on 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 terminal to instruct the user terminal to access the relevant service interface of the microservice. The user registration process includes: Receive an identity registration request sent by the user terminal, the identity registration request including permission configuration information generated by the user terminal based on the current user permissions, the public key generated locally by the user terminal, and the identity identifier; The permission configuration information is encrypted using a locally generated public key. The identity identifier, the user's locally generated public key, and the encrypted permission configuration information are then sent to the blockchain for storage. In the event that a token needs to be revoked, the system receives a token revocation request sent by the user client, which carries the identity identifier and the identity token, and controls the blockchain to delete the identity token corresponding to the identity identifier. The control agent in the server is deployed separately and is used to distribute blockchain configuration and verification rules to the agent agents deployed in the containers of each microservice; the agent agent intercepts service interface access requests and calls the smart contract to check the validity of the identity token.

5. The method according to claim 4, characterized in that, The method further includes: In the event that an identity needs to be revoked, the system receives an identity revocation request sent by the user terminal carrying the identity identifier. If the user terminal that initiates the identity revocation request is the same as the user terminal that registered the identity using the identity identifier, the system controls the deletion of the associated data corresponding to the identity identifier in the blockchain. When token verification is required, the system receives a token verification request sent by the user client, which carries the identity identifier and the identity token, and controls the blockchain to verify whether the identity identifier has been revoked and whether the identity token has been revoked.

6. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 5.

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

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

Images