WO2023221719A1 - 一种数据处理方法、装置、计算机设备以及可读存储介质 - Google Patents

一种数据处理方法、装置、计算机设备以及可读存储介质 Download PDF

Info

Publication number
WO2023221719A1
WO2023221719A1 PCT/CN2023/089109 CN2023089109W WO2023221719A1 WO 2023221719 A1 WO2023221719 A1 WO 2023221719A1 CN 2023089109 W CN2023089109 W CN 2023089109W WO 2023221719 A1 WO2023221719 A1 WO 2023221719A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
login
verified
target
node
Prior art date
Application number
PCT/CN2023/089109
Other languages
English (en)
French (fr)
Inventor
朱耿良
Original Assignee
腾讯科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Publication of WO2023221719A1 publication Critical patent/WO2023221719A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • This application relates to the field of blockchain technology, and in particular to a data processing method, device, computer equipment and readable storage medium.
  • the identity management system can store the identity management information used for login in a centralized server (ie, authorization server).
  • the identity management information stored in the authorization server is associated with all objects, that is, the authorization
  • the server stores the identity management information required for all objects to log in. Therefore, when all objects need to log in through the application client, they need to send a login request to the authorization server to implement the login operation of the application client.
  • the embodiment of this application provides a data processing method, which is executed by business nodes in the blockchain network.
  • the business nodes are used to provide object login services and token issuance services, including:
  • the business node receives the authorization request sent by the target object through the application client, calls the object login service based on the authorization request, and obtains the login information to be verified entered by the target object in the object login service;
  • the object login service matches the login information to be verified with the object credential information. If the login information to be verified matches the object credential information, the object authorization code for the target object is obtained and the object authorization code is returned to the application client; the object credential information It is obtained by the business node from the consensus node of the blockchain network;
  • the embodiment of the present application provides a data processing device, which is applied to a business node in a blockchain network.
  • the business node is used to provide object login services and token issuance services, including:
  • the first receiving module is used to receive the authorization request sent by the target object through the application client, call the object login service based on the authorization request, and obtain the login information to be verified input by the target object in the object login service;
  • the authorization code return module is used to match the login information to be verified with the object credential information through the object login service. If the login information to be verified matches the object credential information, the object authorization code for the target object is obtained and returned to the application client.
  • Object authorization code; object certificate information is obtained by the business node from the consensus node of the blockchain network;
  • the second receiving module is used to receive a token acquisition request sent by the application client based on the object authorization code, call the token issuance service based on the token acquisition request, obtain the object token for the target object through the token issuance service, and send the token to the application client.
  • the client returns an object token; the object token provides the application client with operation permissions for resource data within the authorization scope; operation permissions mean that the application client has the permission to operate resource data through business nodes.
  • An embodiment of the present application provides a computer device, including: a processor and a memory;
  • the processor is connected to a memory, where the memory is used to store a computer program.
  • the computer program is executed by the processor, the computer device executes the method provided by the embodiment of the present application.
  • Embodiments of the present application provide a computer-readable storage medium.
  • the computer-readable storage medium stores a computer program.
  • the computer program is adapted to be loaded and executed by a processor, so that a computer device having the processor executes the embodiment of the present application. provided method.
  • Embodiments of the present application also provide a computer program product or computer program.
  • the computer program product or computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium.
  • the processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method provided by the embodiment of the present application.
  • Figure 1 is a schematic diagram of a hierarchical structure of a blockchain network provided by an embodiment of the present application
  • Figure 2 is a schematic diagram of a data interaction scenario provided by an embodiment of the present application.
  • Figure 3 is a schematic flow chart of a data processing method provided by an embodiment of the present application.
  • Figure 4 is a schematic flowchart of applying for resources provided by an embodiment of the present application.
  • Figure 5 is a schematic diagram of a resource application scenario provided by an embodiment of the present application.
  • Figure 6 is a schematic flowchart of a data processing method provided by an embodiment of the present application.
  • Figure 7 is a system architecture diagram in a blockchain electronic bill scenario provided by the embodiment of this application.
  • Figure 8 is a schematic structural diagram of a data processing device provided by an embodiment of the present application.
  • Figure 9 is a schematic structural diagram of a computer device provided by an embodiment of the present application.
  • the authorization server When a user logs in through an application client, if there are a large number of application clients that send login requests to the authorization server at the same time, the authorization server cannot handle the large number of login requests in a timely manner, resulting in a queuing phenomenon among application clients, resulting in The application client cannot complete the login operation in time, which will reduce the efficiency of the application client's login. In addition, when the authorization server fails, the authorization server cannot successfully respond to the application client's login request, causing the application client to be unable to successfully complete the login operation, thereby reducing the stability of the application client's login.
  • Embodiments of the present application provide a data processing method, device, computer equipment and readable storage medium, which can improve the efficiency and stability of the target object's login application client.
  • Figure 1 is a schematic diagram of a hierarchical structure of a blockchain network provided by an embodiment of the present application.
  • the blockchain network hierarchical structure as shown in Figure 1 can be applied to a blockchain system.
  • the blockchain system can include an agent node (eg, agent node 100b), a first blockchain system, and a second blockchain. system to form the blockchain network 2000 shown in Figure 1.
  • agent node eg, agent node 100b
  • first blockchain system e.g, agent node 100b
  • second blockchain system to form the blockchain network 2000 shown in Figure 1.
  • both the first blockchain system and the second blockchain system may include one or more nodes, and there will be no limit on the number of nodes in the first blockchain system and the second blockchain system.
  • the first blockchain system may specifically include node 110a, node 110b, node 110c,..., and node 110n;
  • the second blockchain system may specifically include node 120a, node 120b, node 120c,..., and node 120n.
  • the blockchain network corresponding to the first blockchain system can be called the business network (ie, witness network) 100a, and the nodes in the business network 100a can be called business nodes.
  • the business nodes are mainly used to execute transaction services. , to obtain the transaction data associated with the transaction business. It is understandable that the business nodes here do not need to participate in the accounting consensus, but they can obtain block header data and partially authorized visible block data from the core consensus network through identity authentication.
  • the blockchain network corresponding to the second blockchain system can be called the core consensus network (i.e., consensus network) 100c, and the nodes in the core consensus network 100c can be called consensus nodes (i.e., accounting nodes).
  • the consensus node here can run a blockchain consensus protocol.
  • first blockchain system and the second blockchain system is not limited to the connection method, and can be directly or indirectly connected through wired communication, or directly or indirectly through wireless communication.
  • ground connection, and other connection methods which are not limited in this application.
  • the agent node 100b shown in Figure 1 can be used to isolate the business network 100a and the core consensus network 100c.
  • the agent node 100b can layer the peer-to-peer (Peer To Peer, P2P) network to form a network.
  • P2P peer To Peer
  • a hierarchical structure i.e., a double-layer chain structure
  • Business Network-Core Consensus Network can improve the confidentiality and security of data on the blockchain.
  • the agent node 100b, the business nodes in the business network 100a, and the consensus nodes in the core consensus network 100c can be collectively referred to as blockchain nodes in the blockchain network 2000.
  • the blockchain node can be a server connected to the blockchain network 2000 or a terminal device connected to the blockchain network 2000.
  • the specific form of the blockchain node does not matter here. Make limitations.
  • the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It can also provide cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, and cloud communications. , middleware services, domain name services, security services, CDN (Content Delivery Network, content distribution network), and cloud servers for basic cloud computing services such as big data and artificial intelligence platforms.
  • the terminal device can be a mobile phone, tablet computer, notebook computer, handheld computer, smart speaker, mobile Internet device (MID, mobile internet device), POS (Point Of Sales, point of sale) machine, wearable device (for example, smart watch , smart bracelets, etc.) etc.
  • nodes in the blockchain network 2000 shown in Figure 1 store a complete blockchain database.
  • Such nodes containing all transaction data can be called Full Nodes (Full Node, for example, as shown in Figure 1 Consensus node shown); other nodes store part of the blockchain database, generally only storing block headers and transaction data associated with their own nodes, rather than storing complete transaction data. They will pass "Simplified Payment Verification” Verification (referred to as SPV)" method to complete transaction verification.
  • SPV Simple Payment Verification
  • Such nodes can be called lightweight nodes (Lightweight Node) or SPV nodes (for example, the business node shown in Figure 1).
  • the business network 100a and the core consensus network 100c shown in Figure 1 can be in different network environments.
  • the business network 100a can be in a public network
  • the core consensus network 100c can be in a private network. Therefore, the business node is deployed in the business network 100a in the public network (ie, the public network), and the consensus node is deployed in the core consensus network 100c in the private network (ie, the private network). The two can interact through routing boundaries.
  • one service node can be selected as a target service node among multiple service nodes in the service network 110a shown in Figure 1.
  • the target service node has the function of sending a data synchronization request to the agent node 100b.
  • the node 110a shown in Figure 1 can be used as the target service node.
  • one consensus node can be selected as a target consensus node among multiple consensus nodes in the core consensus network 100c shown in Figure 1.
  • the target consensus node has the corresponding data synchronization request returned to the proxy node 100b.
  • the node 120a shown in Figure 1 can be used as the target consensus node.
  • the proxy node 100b can forward the data synchronization request sent by the target business node to the target consensus node, and the proxy node 100b can forward the synchronization data returned by the target consensus node to the target business node.
  • the core consensus network is in a relatively secure private cloud, its mutual access has a consensus mechanism to ensure security, and there is no need to add additional identity management and network control.
  • the target business node is in the public network and may be accessed by other uncertain network terminals. Therefore, the behavior of the target business node and other possible nodes accessing the core consensus network needs to be strictly controlled. In this way, the agent node and the target consensus node need to verify the target business node that sends the data synchronization request.
  • the agent node when it receives the data synchronization request sent by the target business node, it can perform authority verification on the target business node to obtain the authority verification result.
  • the authority verification here can include verifying whether the node identification of the target business node is The node ID that belongs to the illegal node list.
  • the illegal node list may refer to a blacklist stored by the agent node.
  • the illegal nodes corresponding to the illegal node identifiers in the illegal node list refer to detected malicious nodes and nodes reported by others. In a certain time period, Nodes that send transactions with abnormal frequency, etc.
  • the agent node can search for an illegal node identifier that is the same as the node identifier of the target service node in the illegal node list to obtain the authority verification result. If the permission verification result indicates that an illegal node ID that is the same as the node ID of the target node is found in the illegal node list, the agent node can determine that the permission verification result is an illegal verification result. At this time, the agent node can determine the target business node. is an illegal node, and there is no need to forward the data synchronization request to the target consensus node in the core consensus network.
  • the agent node may determine that the authority verification result belongs to a legal verification result. At this time, the The agent node can determine that the target business node is a legal node, and then forward the data synchronization request to the core consensus network The target consensus node.
  • the target business node can be used to provide object login service, token issuance service and object information operation service.
  • the object login service, token issuance service and object information operation service can be deployed on the server and specially provided for the application client (i.e. Third-party applications) server programs that provide remote network services.
  • application client i.e. Third-party applications
  • users who log in through third-party applications may be called target objects.
  • application clients may specifically include clients with data processing functions such as browsers, vehicle clients, smart home clients, entertainment clients, multimedia clients (for example, video clients), social clients, and information clients. end.
  • the vehicle-mounted client may be an application client on a vehicle-mounted terminal.
  • the business scenario to which the above hierarchical structure is applicable may be an application authorization scenario
  • the synchronization data in the application authorization scenario may include object management information and user management contracts (ie, object management contracts).
  • the object management information is distributed and stored in the blockchain maintained by the core consensus network.
  • the target business node can provide services to the application client after synchronously verifying the object management information.
  • the object management information may represent attribute information associated with the user (i.e., the object).
  • the object management information may specifically include object credential information and object resource information.
  • the object credential information may represent basic information for login (for example, account number, password), the object resource information may represent basic information associated with the user indicated by the object credential information.
  • the object management contract can be used to process object management information.
  • the object management contract is a blockchain smart contract that manages user information, user registration, freezing, permission design, etc.
  • the object management contract can be executed through blockchain transactions.
  • the target business node can authorize a third-party application to log in through the object credential information based on the object management contract, and authorize the logged-in third-party application to operate the object resource information.
  • the target business node can also provide functions owned by any other SPV node, such as verifying transactions, forwarding to the chain, querying status, querying blocks, etc.
  • Table 1 is a node identification list provided by the embodiment of the present application.
  • the node identifier list may store node identifiers and node names of nodes visible to a certain transaction data. As shown in Table 1:
  • the node identifier can be an IP (Internet Protocol, a protocol for interconnection between networks) address and any other information that can be used to identify the node.
  • IP Internet Protocol, a protocol for interconnection between networks
  • node 1 may be node 110a shown in FIG. 1
  • node 2 may send information (for example, a data synchronization request) to node 2 (for example, node 2 may be node 120a shown in FIG. 1) through the node identifier BBBBBB.
  • node 2 can determine that the information is sent by node 1 through the node identifier AAAAAA; node 2 can return information (for example, synchronization data) to node 1 through the node identifier AAAAAA, and node 1 can determine that the information is sent by node 1 through the node identifier BBBBBB.
  • the information is returned by node 2.
  • the agent node 100b can forward the data synchronization request sent by the node 1 to the node 2, and the agent node 100b can forward the synchronization data returned by the node 2 to the node 1.
  • the node 1 here can be the target business node, and the node 2 here can be the target. Consensus node.
  • the target consensus node in the core consensus network can obtain the encrypted data information sent by the proxy node 100b.
  • the encrypted data information can be obtained by the agent node 100b encrypting the data synchronization request and signature information through the system public key of the core consensus network
  • the signature information can be obtained by the target business node in the business network through the target business node.
  • the node private key is obtained after signing the data synchronization request.
  • the target consensus node can obtain the system private key of the core consensus network (that is, the system private key corresponding to the system public key of the core consensus network), and decrypt the encrypted data information through the system private key of the core consensus network to obtain data synchronization. Request and signature information.
  • the target consensus node can obtain the node public key of the target business node (that is, the node public key corresponding to the node private key of the target business node), verify the signature information based on the node public key of the target business node, and obtain the signature verification result. . Further, the target consensus node can receive the data synchronization request when the signature verification result indicates that the signature verification is successful. In some embodiments, the target consensus node may refuse to receive the data synchronization request when the signature verification result indicates that the signature verification failed.
  • the target business node can use a hash algorithm to perform hash calculation on the data synchronization request, so as to obtain the summary information h of the data synchronization request, and perform the hash calculation on the summary information h based on the node private key of the target business node.
  • Digital signature to obtain the signature information corresponding to the data synchronization request.
  • the target consensus node can verify the digital signature in the signature information based on the node public key of the target business node, obtain the summary information h of the data synchronization request, and verify the received data synchronization request based on the hash algorithm used by the target business node.
  • Hash calculation is performed to obtain the summary information H of the data synchronization request, and then the summary information h obtained by the signature verification and the summary information H obtained by the hash calculation can be compared to obtain the signature verification result.
  • the signature verification result indicates that the target consensus node has successfully verified the signature; when the summary information h is different from the summary information H, the signature verification result indicates that the target consensus node has failed the signature verification.
  • the agent node 100b when forwarding the encrypted data information, can also encrypt the encrypted data information through the node private key of the agent node 100b to obtain the encrypted encrypted data information, so as to The target consensus node is caused to decrypt the encrypted data information through the node public key of the proxy node 100b.
  • the target business node before sending the data synchronization request and signature information to the proxy node 100b, can encrypt the data synchronization request and signature information using the node public key of the proxy node 100b to obtain the encrypted request information, and then The encrypted request information is sent to the proxy node 100b. In this way, when the proxy node 100b receives the encrypted request information, it can decrypt the encrypted request information through the node private key of the proxy node 100b to obtain the data synchronization request and signature information.
  • the target business node receiving the synchronization data forwarded by the proxy node 100b please refer to the above description of the target consensus node receiving the data synchronization request forwarded by the proxy node 100b, which will not be described again here.
  • Figure 2 is a schematic diagram of a data interaction scenario provided by an embodiment of the present application.
  • the service node 20a shown in Figure 2 can be any node in the service network 100a in the embodiment corresponding to Figure 1
  • the agent node 20b shown in Figure 2 can be the agent node in the embodiment corresponding to Figure 1.
  • 100b the agent node 20b shown in Figure 2
  • the consensus node 20c shown in Figure 2 can be any node in the core consensus network 100c in the embodiment corresponding to Figure 1.
  • this embodiment of the present application takes the node 110a shown in Figure 1 as the business node 20a and the node 120a shown in Figure 1 as the consensus node 20c as an example to illustrate the business node 20a shown in Figure 2 , the specific process of data interaction between the agent node 20b and the consensus node 20c.
  • the business node 20a can send a data synchronization request to the agent node 20b, and the agent node 20b can forward the data synchronization request to the consensus node 20c.
  • the synchronization data can be returned to the agent node 20b, and the agent node 20b can forward the synchronization data to the service node 20a.
  • the object 21b shown in Figure 2 may be a target object
  • the terminal device corresponding to the object 21b may be a terminal device 21a
  • an application client may be installed in the terminal device 21a. Therefore, when the object 21b needs to log in to the application client in the terminal device 21a, the object 21b can send an authorization request to the service node 20a through the application client in the terminal device 21a.
  • the business node 20a can receive the authorization request sent by the object 21b through the application client, call the object login service based on the authorization request, and return the object authorization code to the terminal device 21a through the object login service.
  • the business node 20a can obtain the login information to be verified entered by the object 21b in the object login service, obtain the object credential information in the synchronization data, and match the login information to be verified and the object credential information through the object login service. If the login is to be verified, If the information matches the object credential information, the object authorization code for the object 20a is obtained, and then the object authorization code is returned to the terminal device 21a. In some embodiments, if the login information to be verified does not match the object credential information, the service node 20a does not need to return the object authorization code to the terminal device 21a.
  • the object 21b can send a token acquisition request to the service node 20a through the application client in the terminal device 21a, and the token acquisition request can carry the object authorization code. so.
  • the business node 20a can receive the token acquisition request sent by the object 21b through the application client, call the token issuance service based on the token acquisition request, and return the object token to the terminal device 21a through the token sending service.
  • the object token is a string of strings generated by the business node in response to the request sent by the application client so that the application client that owns the object token has corresponding operation permissions on the corresponding resource data.
  • Object tokens can be used in place of passwords.
  • Object tokens have the following characteristics: the token is short-term and will automatically expire when it expires; the object token can be revoked by the owner of the resource data, and will expire immediately after revocation; the object token has permission scope, such as objects with read-only permissions Tokens are more secure than object tokens with read and write permissions.
  • the business node 20a can verify the object authorization code through the token sending service. If the object authorization code is verified successfully, the object token for the object 21b is obtained, and then the object token is returned to the terminal device 21a. In some embodiments, if the object authorization code verification fails, the service node 20a does not need to return the object token to the terminal device 21a.
  • the object 21b can send a resource operation request to the business node 20a based on the object token.
  • the resource operation request is used to request the operation of resource data within the authorized scope by the business node 20a.
  • the resource data within the authorized scope can belong to objects in the synchronization data.
  • Resource information, resource data within the authorization scope may be object resource information belonging to object 21b in the object resource information.
  • the business node 20a can provide the application client with operation permissions for resource data within the authorization scope based on the object token. Therefore, the resource data within the authorization scope may be the object resource information belonging to the object 21b and having operation authority in the object resource information.
  • the business node 20a can also be used to provide object registration services.
  • the object 21b can send an object registration request to the business node 20a through the application client.
  • the business node 20a can receive the object registration request sent by the object 21b through the application client, call the object registration service based on the object registration request, and obtain the object registration of the object 21b.
  • the object registration information input in the service is then packaged through the consensus node 20c.
  • Register information on objects at consensus node 20c After the chain is successfully uploaded, the business node 20a can obtain the latest object certificate information from the blockchain maintained by the consensus node 20c.
  • the latest object credential information may include object registration information of object 21b, where the object registration information may include an object registration identifier and an object registration password.
  • the embodiment of the present application can use the business node in the blockchain network as an authorization server.
  • the authorization server can respond to the authorization request sent by the application client through the object login service and respond to the authorization request sent by the application client through the token sending service. Token acquisition request to implement the login operation of the application client.
  • the number of business nodes can be multiple, and multiple business nodes can respectively respond to the authorization request and token acquisition request sent by the application client, thereby improving the efficiency and stability of the target object logging in to the application client.
  • FIG. 3 is a schematic flowchart of a data processing method provided by an embodiment of the present application.
  • This method can be executed by a business node in the blockchain network.
  • the business node can be a server connected to the business network or a terminal device connected to the business network.
  • the specific form of the business node is not limited here.
  • the service node is used to provide object login services and token issuance services.
  • the service node can be any node in the service network 100a shown in Figure 1, for example, node 110a.
  • the data processing method may include the following steps:
  • Step S101 Receive the authorization request sent by the target object through the application client, call the object login service based on the authorization request, and obtain the login information to be verified input by the target object in the object login service;
  • the business node can receive the authorization request sent by the target object through the application client, call the object login front end based on the authorization request, and obtain the login information to be verified input by the target object in the object login front end.
  • the business node can display the object login front-end in the application client, so that the target object can input the login information to be verified in the object login front-end.
  • the object login service includes an object login front-end (ie, user login front-end) and an object login back-end.
  • the object login front-end can represent the front-end page of the object login service
  • the object login back-end can represent the back-end logic of the object login service.
  • the login information to be verified can be the login information of the target object in other application clients (for example, the target application client) other than the third-party application.
  • the object login front-end can represent the front-end page of the target application client
  • the object login backend can apply client-side backend logic to the target. Therefore, the business node can jump the third-party application to the object login front-end, and the target object interacts with the object login front-end, thereby realizing the login operation of the third-party application through the login information in the target application client.
  • the target object can directly input the login information to be verified in the object login front end, or can obtain the login information to be verified with authorization in the object login front end.
  • the login information to be verified and obtained with authorization can be the login information to be verified by the target object at the previous moment of the current moment. Enter the login information to be verified.
  • the business node can obtain object management information from the consensus node of the blockchain network, and the object management information can include object voucher information and object resource information; the business node can obtain the object management contract from the consensus node, and the object management contract can include But it is not limited to login judgment contract, authorization code verification contract and token verification contract.
  • the object credential information and login judgment contract can be used to execute step S102; the authorization code verification contract can be used to execute step S103, the token verification contract can be used to execute step S205, and the object resource information can be used to execute step S206.
  • the business node can build an object information database (ie, user login credentials DB (database, database)), and store the object management information in the object information database.
  • object information database ie, user login credentials DB (database, database)
  • the object information database can be used in step S102 Query the object credential information and query the object resource information in step S206.
  • the object management contract can be a blockchain smart contract stored in the business node.
  • the blockchain smart contract can be published in the consensus network and synchronized to the business node for execution.
  • the object management contract encapsulates the verification user Status, accept user login verification processing and other functions.
  • the object management contract can rely on the object management information in the object information database to function, that is, the object management contract can perform login verification based on the object credential information, and perform CURD of user information based on the object resource information (i.e., basic atomic operations for processing data, Create (i.e. C) creates, Update (i.e. U) updates, retrieve (i.e. R) reads, Delete (i.e. D) deletes).
  • object resource information i.e., basic atomic operations for processing data, Create (i.e. C) creates, Update (i.e. U) updates, retrieve (i.e. R) reads, Delete (i.e. D) deletes).
  • Step S102 Match the login information to be verified with the object credential information through the object login service. If the login information to be verified matches the object credential information, obtain the object authorization code for the target object and return the object authorization code to the application client;
  • the business node can call the login judgment contract through the object login backend, and match the login information to be verified with the object credential information through the login judgment contract.
  • the login judgment contract is obtained by the business node from the consensus node.
  • the business node can obtain the object authorization code for the target object and return the object authorization code to the application client.
  • the business node can reject the authorization request without returning the object authorization code to the application client.
  • the login information to be verified includes the object identification to be verified and the password of the object to be verified.
  • the business node can obtain the object credential information from the object information database through the login judgment contract.
  • the object certificate information is obtained from the consensus node by the business node.
  • the object credential information can include object identification credential information.
  • the business node can search for the object identification to be verified in the object identification credential information. If the object identification to be verified does not exist in the object identification credential information, it is determined that the login information to be verified does not match the object credential information. In some embodiments, if there is an object identification to be verified in the object identification credential information, the business node can determine the matching result between the login information to be verified and the object credential information based on the password of the object to be verified.
  • the object information database will not store plain text passwords, but the result of hashing the key after adding salt.
  • key salting refers to adding pre-generated characters or strings to random positions in the key.
  • a key is: 123456.
  • the system adds characters at random positions.
  • the result after addition is: 1a2b3c456abcd.
  • the result after addition is: 1a2b3c456abcd.
  • the object credential information also includes object password credential information (i.e., the result of hashing the key with salt) and string credential information (i.e., salt).
  • object identification credential information corresponds to one object password credential information and one string credential information. .
  • the business node determines the matching result between the login information to be verified and the object credential information based on the password of the object to be verified can be described as: the business node can correspond the password of the object to be verified and the object identification to be verified in the object credential information.
  • the string credential information is spliced to obtain the spliced login information to be verified (that is, the first spliced login information to be verified), that is, the password of the object to be verified and the above string credential information are spliced to obtain the spliced login information to be verified.
  • the business node can perform hash calculation on the spliced login information to be verified to obtain the hash login information to be verified (ie, the first hash login information to be verified). Further, the business node can compare the hash login information to be verified with the object password credential information corresponding to the object identification to be verified in the object credential information. If the hash login information to be verified and the object identification to be verified correspond to the object credential information, If the object password and credential information are the same, a matching result is generated to represent the match between the login information to be verified and the object credential information.
  • the business node can generate a message to represent the mismatch between the login information to be verified and the object credential information. Matching results.
  • the salt is a randomly generated string generated by a secure random function. Different object identification credential information corresponds to different salts. It should be understood that the embodiment of the present application does not limit the hash algorithm used for hash calculation.
  • the hash algorithm may be the MD5 Message-Digest Algorithm.
  • the service node can perform hash calculation on the password of the object to be verified to obtain the hashed password of the object to be verified. Further, the business node can splice the hash object password to be verified and the string credential information corresponding to the object identification to be verified in the object credential information to obtain the spliced login information to be verified (that is, the second spliced login information to be verified), also That is, the hash object password to be verified and the above string credential information are spliced to obtain the spliced login information to be verified.
  • the business node can perform hash calculation on the spliced login information to be verified to obtain the hash login information to be verified (ie, the second hash login information to be verified). In some embodiments, the business node can perform hash calculation on the password of the object to be verified to obtain the hash login information to be verified (ie, the third hash login information to be verified).
  • the object information database can also store plaintext passwords.
  • the object credential information also includes object password credential information (ie, plaintext password), and one object identification credential information corresponds to one object password credential information.
  • object password credential information ie, plaintext password
  • one object identification credential information corresponds to one object password credential information.
  • a matching result is generated to represent the match between the login information to be verified and the object credential information.
  • a matching result is generated to represent a mismatch between the login information to be verified and the object credential information.
  • the object management information in the object information database may include object status, and the object status may represent the frozen status or non-frozen status of the object.
  • the business node receives the authorization request sent by the application client, it can query the object status of the target object in the object information database through the object login service. If the object status of the target object is frozen, the authorization request will be rejected. In some embodiments, if the object status of the target object is an unfrozen state, the business node may return the object authorization code to the application client after obtaining the object authorization code for the target object.
  • Step S103 Receive a token acquisition request sent by the application client based on the object authorization code, call the token issuance service based on the token acquisition request, obtain the object token for the target object through the token issuance service, and return the object token to the application client. Card.
  • the business node can receive a token acquisition request sent by the application client based on the object authorization code, and call the token issuance service based on the token acquisition request. Further, the business node can call the authorization code verification contract through the token issuance service, and verify the object authorization code through the authorization code verification contract. Among them, the authorization code verification contract is obtained by the business node from the consensus node. Further, if the object authorization code verification passes, the business node can obtain the key authorization information associated with the target object, generate an object token for the target object based on the key authorization information, and return the object token to the application client. In some embodiments, if the object authorization code verification fails, the business node can reject the token acquisition request without returning the object token to the application client.
  • the object authorization code can be used to represent the authorization information corresponding to the target object, that is, the business node can obtain the authorization information selected by the target object in the object login service, and generate the object authorization code for the target object based on the authorization information.
  • the authorization information is the key authorization information of the target object, including at least one of aging information, operation authority and authorization scope; the aging information is used to characterize the life cycle of the object token. Therefore, the business node can parse the object authorization code and obtain the key authorization information associated with the target object.
  • the object authorization code does not need to represent the key authorization information associated with the target object.
  • the key authorization information associated with the target object can be obtained through the object authorization code, that is, the business node can obtain the target object in the object login service.
  • Select key authorization information includes at least one of aging information, operation authority and authorization scope; aging information is used to characterize the life cycle of the object token. Therefore, the business node can obtain key authorization information associated with the target object from the object login service through the token issuance service.
  • the object token can provide the application client with operation permissions for resource data within the authorization scope, that is, the object token can have operation permissions and authorization scopes.
  • the object token can also have timeliness information.
  • the resource data can also be called object resource information.
  • the aging information, operation permissions and authorization scope can be selected by the target object in the object login front end of the object login service; in some embodiments, the aging information, operation permissions and authorization scope can also be set by default by the business node. .
  • the target object can select any one or more of the aging information, operation permissions and authorization scope in the object login front-end, or does not need to select the aging information, operation permissions and authorization scope.
  • operation permission means that the application client has the permission to operate resource data through the business node.
  • the target object's operation permission for resource data can be read permission, write permission, read and write permission, delete permission, modify permission, read delete Permissions, etc., for example, read permission indicates that the target object can perform read operations on resource data; authorization scope may indicate resource data for which the target object has operation permissions.
  • the embodiment of this application does not limit the data types included in the authorization scope; aging information Used to characterize the life cycle of the object token. For example, the life cycle of the object token can be 1 day.
  • the business node in the blockchain network can receive the authorization request sent by the target object through the application client after obtaining the object credential information from the consensus node of the blockchain network, and obtain it through the object login service
  • the login information to be verified entered by the target object is then matched with the login information to be verified and the object credential information. If the login information to be verified matches the object credential information, the object authorization code for the target object is obtained and the object is returned to the application client.
  • Authorization code Further, the business node can receive a token acquisition request sent by the application client based on the object authorization code, obtain the object token for the target object through the token issuance service, and return the object token to the application client.
  • the business nodes in the blockchain network can serve as the authorization server in the identity management system.
  • the authorization server can obtain the distributed storage object certificate information from the consensus node of the blockchain network and respond to the application client based on the object certificate information.
  • Authorization request and token acquisition request sent by the client (authorization request and token acquisition request can be collectively referred to as login request).
  • login request Due to the decentralization and self-verification characteristics of the blockchain network, multiple business nodes can be deployed, and multiple application clients can send login requests to different business nodes respectively. Therefore, when multiple application clients send login requests at the same time, When making a login request, multiple business nodes can respond to multiple login requests at the same time, thereby improving the efficiency of the target object logging in to the application client.
  • the business node can provide the application client with operation permissions for resource data within the authorization scope based on the object token. This operation permission allows the application client to operate resource data through the business node. Therefore, the business node can use the object token to The token ensures that while the application client obtains operation permissions, it can control the object token at any time to ensure that the application client's operations on resource data will not endanger the security of resource data in the identity management system.
  • the third-party application when the third-party application receives the object token returned by the business node, it can indicate that the third-party application calls the business node to complete the object login managed on the chain and obtain the object identity indicated by the object credential information. Among them, the third-party application can perform its own business in subsequent steps after obtaining the object identity indicated by the object credential information.
  • the third-party application's own business represents the inherent functions of the third-party application, for example, through the object credential The identity of the object indicated by the information realizes the instant messaging function.
  • the object token indicates that the resource owner authorizes a third-party application to access its resource data stored on the authorization server without providing the account and password to the third-party application.
  • Step S41 to S46 can be executed linearly. Step S41 corresponds to step S101, step S42 corresponds to step S102, and step S43 to step S44 corresponds to step S103.
  • the third-party application i.e. client
  • the resource owner i.e. resource holder, Resource Owner
  • the resource owner may represent the object indicated by the object credential information
  • the resource owner here may represent the target object indicated by the login information to be verified.
  • the resource owner can match the login information to be verified with the object credential information. If the login information to be verified matches the object credential information, step S42 is executed, and a permission (ie, authorization code) is granted to the third-party application through step S42. , Authorization Grant).
  • the authorization code can also be called an object authorization code, and the object authorization code is used to identify the target object.
  • the third-party application can perform step S43, and through step S43, the permission (i.e., object authorization code) is given to the authorization server (i.e., authentication server, Authorization Server) for authentication (i.e., the target object sends a token through the application client) Get request).
  • the authorization server i.e., authentication server, Authorization Server
  • the authorization server here may be the service node in the embodiment of this application.
  • the authorization server can perform step S44 and return a token (ie Access Token) to the third-party application through step S44.
  • tokens can also be called object tokens.
  • Figure 5 is a schematic diagram of a resource application scenario provided by an embodiment of the present application.
  • the application authorization code shown in Figure 5 corresponds to step S41 in the embodiment corresponding to Figure 4.
  • the return authorization code shown in Figure 5 corresponds to step S42 in the embodiment corresponding to Figure 4.
  • the application token shown in FIG. 4 corresponds to step S43 in the above-mentioned embodiment corresponding to FIG. 4, and the return token shown in FIG. 5 corresponds to step S44 in the above-mentioned embodiment corresponding to FIG. 4.
  • permission verification contracts can be stored in the consensus nodes of the blockchain network, and the authority verification contracts can be smart contracts deployed on the consensus nodes.
  • Business nodes in the blockchain network can obtain authority verification from the consensus node of the blockchain network through the core network entrance (i.e., agent node) to verify the local contract (i.e., object management contract) and object management information, and then store the object management information.
  • the authority verification local contract may include but is not limited to the above-mentioned login judgment contract, authorization code verification contract and token verification contract
  • the object management information may include object credential information and object resource information.
  • the third-party application can apply for an authorization code (that is, send an authorization request) to the business node.
  • the business node can respond to the authorization request through the object login service, call the login judgment contract through the object login service, and use the login judgment contract and the object management information in the object login credential database, and returns the authorization code to the third-party application (that is, returns the object authorization code).
  • the third-party application can apply for a token from the business node (that is, send a token acquisition request).
  • the business node can respond to the token acquisition request through the token issuance service and call the authorization code through the token issuance service. Verify the contract, verify the object management information in the contract and object login credentials database through the authorization code, and return the token to the third-party application (that is, return the object token).
  • the blockchain network may include multiple consensus nodes, and the embodiments of this application do not limit the number of consensus nodes here; the blockchain network may include multiple business nodes, and the embodiments of this application do not limit the number of business nodes here. Quantity is limited. Since multiple business nodes and consensus nodes are deployed, the same business node can send data synchronization requests to different consensus nodes, and different application clients can send login requests (i.e. authorization requests and token acquisition requests) to different business nodes. ).
  • the two third-party applications may specifically be the third-party application X1 and the third-party application X2, and the multiple service nodes may specifically include the service node J1 and the service node J2.
  • the third-party application X1 can send a login request to the business node J1
  • the third-party application X2 can send a login request to the business node J2
  • the third-party application X1 can send a login request to the business node J2
  • the third-party application X2 can send a login request to the business node J1.
  • the business node when the business node receives the authorization request and token acquisition request sent by the application client, it can generate local information unrelated to the blockchain, and then store the local information in the object information database.
  • the local information can represent the information generated when the business node serves as the authorization server.
  • the local information can be the login time of the application client (that is, the time when the business node obtains the login information to be verified entered by the target object in the object login service).
  • the business nodes in the blockchain network can serve as the authorization server in the identity management system.
  • the authorization server can obtain the distributed storage object certificate information from the consensus node of the blockchain network and respond to the application client based on the object certificate information.
  • Authorization request and token acquisition request sent by the client (authorization request and token acquisition request can be collectively referred to as login request).
  • login request Due to the decentralization and self-verification characteristics of the blockchain network, multiple business nodes can be deployed, and multiple application clients can send login requests to different business nodes respectively. Therefore, when multiple application clients send login requests at the same time, When making a login request, multiple business nodes can respond to multiple login requests at the same time, thereby improving the efficiency of the target object logging in to the application client.
  • the business node can provide the application client with operation permissions for resource data within the authorization scope based on the object token. This operation permission allows the application client to operate resource data through the business node. Therefore, the business node can use the object token to The token ensures that while the application client obtains operation permissions, it can control the object token at any time to ensure that the application client's operations on resource data will not harm the resources in the identity management system. Data security.
  • FIG. 6 is a schematic flowchart of a data processing method provided by an embodiment of the present application.
  • This method can be executed by a business node in the blockchain network.
  • the business node can be a server connected to the business network or a terminal device connected to the business network.
  • the specific form of the business node is not limited here.
  • the service node is used to provide object login services, token issuance services and object information operation services.
  • the service node can be any node in the service network 100a shown in Figure 1, for example, node 110a.
  • the data processing method may include the following steps:
  • Step S201 Receive the authorization request sent by the target object through the application client, call the object login service based on the authorization request, and obtain the login information to be verified input by the target object in the object login service;
  • step S101 For the specific process of the business node obtaining the login information to be verified input by the target object in the object login service, please refer to the description of step S101 in the embodiment corresponding to Figure 3 above, and will not be described again here.
  • the application client can encrypt the authorization request through the node public key of the business node, obtain the encrypted authorization request, and send the encrypted authorization request to the business node.
  • the business node can receive the encrypted authorization request sent by the application client, decrypt the encrypted authorization request through the node private key of the business node, and obtain the authorization request.
  • Step S202 Match the login information to be verified with the object credential information through the object login service. If the login information to be verified matches the object credential information, obtain the object authorization code for the target object and return the object authorization code to the application client;
  • step S102 For the specific process of the service node obtaining the object authorization code for the target object, please refer to the description of step S102 in the embodiment corresponding to Figure 3 above, and will not be described again here.
  • the business node can encrypt the object authorization code through the node private key of the business node, obtain the encrypted object authorization code, and return the encrypted object authorization code to the application client.
  • the application client can receive the encrypted object authorization code returned by the business node, decrypt the encrypted object authorization code through the node public key of the business node, and obtain the object authorization code.
  • Step S203 Receive a token acquisition request sent by the application client based on the object authorization code, call the token issuance service based on the token acquisition request, obtain the object token for the target object through the token issuance service, and return the object token to the application client.
  • Card
  • step S103 For the specific process of the business node obtaining the object token for the target object, please refer to the description of step S103 in the embodiment corresponding to Figure 3 above, and will not be described again here.
  • the application client can determine the target business node for sending the authorization request and the token acquisition request from multiple business nodes based on the distance between the application client and the business node. For example, the application client can determine the target business node among the multiple business nodes. The nearest service node is used as the target service node. In some embodiments, the application client can also determine the target business node for sending the authorization request and the token acquisition request from multiple business nodes according to the node scheduling algorithm. For example, the application client can send the authorization request and the token acquisition request when needed.
  • a node scheduling request is sent to the scheduling server used for node scheduling, so that the scheduling service can schedule the target business node for the application client based on factors such as the real-time network quality of multiple business nodes, thereby improving business Node scheduling accuracy.
  • the business node may store object management information associated with all objects. In some embodiments, the business node may not need to store object management information associated with all objects. Similarly, the business node can store object credential information and object resource information associated with the target object at the same time. In some embodiments, the business node can also store object credential information or object resource information associated with the target object. Similarly, the service node can store all the object resource information associated with the target object. In some embodiments, the service node can also store part of the object resource information associated with the target object.
  • Step S204 Receive the resource operation request sent by the application client based on the object token, and call the object information operation service based on the resource operation request;
  • the method used in this application to send resource operation requests based on object tokens uses the OAuth 2.0 authorization mechanism, which can be used to authorize third-party applications (i.e., application clients) to operate resource data.
  • the resource owner of the resource data i.e., the target object
  • the business node generates an object token that allows the third-party application to enter the business node. This object token is used by third-party applications in place of the password.
  • the object token has the same function as the password, and both can enter the system, but there are three differences: (1) The object token is short-term. After the object token's life cycle expires, the object token will automatically expire. , the target object cannot modify the aging information of the object token; the password is generally valid for a long time, and if the target object does not modify the password, the password will not change. (2) The object token can be revoked by the resource owner at any time. If the object token is revoked by the resource owner, the object token will become invalid immediately; the password is generally not allowed to be revoked by others. (3) Object tokens have operation permissions. For network services, read-only tokens (i.e.
  • Like tokens are more secure than read-write tokens (that is, object tokens with read and write permissions).
  • read permissions allow third-party applications to read resource data but not write resource data; the password is generally Full permissions (i.e. password).
  • the object token has an authorization scope, and the object token has operation rights for the data types included in the authorization scope; the password has operation rights for all data types.
  • a third-party application can log in to the business system indicated by the business node through the object token (ie, a resource operation request sent to the business node based on the object token).
  • object token ie, a resource operation request sent to the business node based on the object token.
  • Business systems generally do not reconfirm the identity of third-party applications, so third-party applications must keep object tokens confidential.
  • the consequences of leaking object tokens are the same as leaking passwords. Therefore, in order to ensure the security of resource data in the business system, the business node can set the aging information of the object token to a shorter time, for example, 1 hour.
  • the resource operation request also carries the object identifier of the target object.
  • the object identifier of the target object enables the target object to operate its own corresponding resource data but not the resource data corresponding to other objects.
  • Step S205 call the token verification contract through the object information operation service, and verify the resource operation request and the object token through the token verification contract;
  • the business node can obtain the key authorization information associated with the object token through the token verification contract, and determine whether the resource operation request meets the key authorization information. Further, if the resource operation request meets the key authorization information, the business node can determine that the resource operation request and object token verification pass. In some embodiments, if the resource operation request does not satisfy key authorization information, the business node may determine that the resource operation request and object token verification fail.
  • the token verification contract can determine whether the resource operation request meets the aging information, operation permissions and authorization scope. If the resource operation requests all meet the aging information, operation permissions and authorization scope, the business node can determine that the resource operation request meets the key requirements. Authorization information. In some embodiments, if the resource operation request does not satisfy the aging information, operation authority or authorization scope, the service node may determine that the resource operation request does not satisfy the key authorization information.
  • the business node can determine that the resource operation request does not satisfy the operation permission; for another example, if the request time corresponding to the resource operation request exceeds the life of the object token period, the business node can determine that the resource operation request does not meet the timeliness information; for another example, if the data type of the requested operation in the resource operation request is different from the data type included in the authorization scope, the business node can determine that the resource operation request does not meet the authorization scope. .
  • the business node when receiving a resource operation request sent by an application client, the business node can query the object status of the target object in the object information database through the object information operation service. If the object status of the target object is in a frozen state, the resource operation request will be rejected. . In some embodiments, if the object status of the target object is an unfrozen state, the business node may perform step S206 or step S207 based on the resource operation request and the verification result of the object token.
  • the business node when the resource operation request and object token verification pass or fail, the business node can perform different steps. If the resource operation request and the object token verification pass, the business node can perform step S206; in some embodiments , if the resource operation request and object token verification fail, the business node can execute step S207.
  • Step S206 if the resource operation request and object token verification pass, respond to the resource operation request through the object information operation service;
  • the business node can obtain the target read data requested by the resource read operation request from the object information database through the object information operation service. Among them, the target read data belongs to resource data. Further, the business node can return the target read data to the application client.
  • the business node can obtain the target read data from the object information database through the object information operation service.
  • a data synchronization request for the target read data is sent to the consensus node through the object information operation service, and a data synchronization request for the target read data is sent from the consensus node based on the data synchronization request for the target read data.
  • Obtain the synchronized data from the node's on-chain data store the synchronized data in the object information database, and obtain the target read data from the object information database through the object information operation service.
  • the synchronization data includes target read data.
  • the business node can obtain the target write data requested to be written by the resource write operation request through the object information operation service. Among them, the target write data belongs to resource data. Further, if the target write data does not exist in the object information database, the business node can write the target write data to the object information database. In some embodiments, if the target write data exists in the object database, the service node does not need to respond to the resource access operation request.
  • the business node can forward the target write data to the consensus node, so that the consensus node packages the target write data and generates the target block. (i.e. the first target block), the target block is uploaded to the chain. Further, the business node can send a data synchronization request for the target write data to the consensus node, receive the target write data returned by the consensus node based on the data synchronization request for the target write data, and write the target write data to the object. information database. Among them, the target write data is obtained from the target block by the consensus node.
  • the business node can obtain the initial update data requested by the resource update operation request through the object information operation service. Further, if initial update data exists in the object information database, the business node can update the initial update data through the target update data in the resource update operation request. In some embodiments, if the initial update data does not exist in the object information database, the business node can write the target update data in the resource update operation request to the object information database. In some embodiments, if there is no initial update data in the object information database, the business node does not need to respond to the resource update operation request. Among them, both initial update data and target update data belong to resource data.
  • the business node can forward the target update data in the resource update operation request to the consensus node, so that the consensus node packages the target update data and generates the target block (i.e. the second target block), and upload the target block to the chain. Further, the business node can send a data synchronization request for the target update data to the consensus node, receive the target update data returned by the consensus node based on the data synchronization request for the target update data, and update the initial update in the object information database through the target update data. data.
  • the target update data is obtained from the target block by the consensus node.
  • the business node can obtain the target deletion data requested to be deleted by the resource deletion operation request through the object information operation service. Among them, the target deletion data belongs to resource data. Further, if the target deletion data exists in the object information database, the business node can delete the target deletion data from the object information database. In some embodiments, if the target deletion data does not exist in the object information database, the business node does not need to respond to the resource deletion operation request.
  • the business node can delete the target deletion data through the deletion function in the contract. If the deletion function in the contract is executed successfully (that is, the consensus node recognizes this Delete the contract task of the target deletion data), then receive the deletion instruction returned by the consensus node, and delete the target deletion data from the object information database based on the deletion instruction.
  • the resource operation request may include target write data, target delete data, or target update data.
  • the specific process of the business node returning the target read data can be found in the above description of returning the object authorization code, which will not be described again here.
  • the target read data obtained from the on-chain data of the consensus node, the target write data obtained from the first target block, and the target update data obtained from the second target block can all be called It is the synchronization data obtained by the business node from the consensus node.
  • the target read data can be obtained by the business node from the third target block stored by the consensus node, and the number of the first target block, the second target block and the third target block can be For one or more, that is, the business node can obtain the target write data from one or more first target blocks, the business node can obtain the target update data from one or more second target blocks, and the business node can obtain the target write data from one or more second target blocks.
  • the target write data, target update data and target read data may be packed into one or more target blocks respectively.
  • the embodiment of the present application takes as an example that the target write data, target update data and target read data are all packaged into a target block respectively.
  • the target write data is packaged into the target block Q as Example to illustrate.
  • the block information of the target block Q may include a block header (ie, block header information) and a block body (ie, block body, block body information).
  • the block header can include the parent block hash value of the target block Q (i.e., parent block hash), block height, version number, timestamp, difficulty value, random number, and Merkle tree root (i.e., district Block hash, block hash value) and other information
  • the block body can include the transaction data packaged to the target block Q and the Merkle path composed of the transaction hash value of the transaction data.
  • the 4 transaction data here can be transaction data 1, transaction data 2, transaction data 3 and transaction data 4.
  • the transaction hash value corresponding to the transaction data can be obtained by performing transaction hash conversion on these four transaction data.
  • the transaction hash value of transaction data 1 can be transaction hash value 1 (for example, Hash1)
  • transaction data 2 The transaction hash value of can be transaction hash value 2 (for example, Hash2)
  • the transaction hash value of transaction data 3 can be transaction hash value 3 (for example, Hash3)
  • the transaction hash value of transaction data 4 can be transaction Hash value 4 (for example, Hash4).
  • the target write data may be transaction data 3 and transaction data 4 in target block Q.
  • the consensus node can obtain the Merkel proof information corresponding to the target written data.
  • the Merkel proof information here can be composed of the transaction hash value in the Merkel path.
  • it can be composed of Hash12 (i.e. Based on Hash1 and Hash2
  • the generated hash value represents the hash value obtained by hashing the splicing result of Hash1 and Hash2) and Hash1234 (that is, the hash value generated based on Hash12 and Hash34, Hash34 is the hash value generated based on Hash3 and Hash4 hash value) as the path hash value to form the Merkle proof information based on the path hash value.
  • the consensus node can use the above target write data, Merkel proof information and the block header of the target block Q as synchronization data returned to the business node.
  • the business node can verify the synchronization data based on the target write data, Merkle proof information and the block header of the target block Q. Specifically, the business node can determine the tree root to be compared corresponding to the target block Q based on the transaction hash value corresponding to the target written data and the path hash value in the Merkel proof information. Further, the business node can obtain the verification result of the target block Q based on the tree root to be compared and the Merkle tree root in the block header of the target block Q. Among them, if the root of the tree to be compared is the same as the root of the Merkel tree, the verification result indicates that the verification is successful. Further, if the verification result indicates that the verification is successful, the business node can synchronize the block header of the target block Q to the block header chain of the business node, and write the target write data to the object information database.
  • Step S207 If the resource operation request and the object token verification fail, the resource operation request is rejected through the object information operation service.
  • the third-party application can perform step S45, and use the token (i.e., object token) to obtain the resource data corresponding to the token from the resource server (i.e., Resource Server) through step S45 (That is, protected resources (Protected Resource) (that is, the target object sends a resource operation request through the application client).
  • the resource server here may be the service node in the embodiment of this application.
  • the resource server may perform step S46, and return the protected resource (for example, target read information) to the third-party application through step S46.
  • the resource data is the resource owner's own resources, and the resource owner cannot obtain the resource data of other objects.
  • the service node can serve as the authorization server and the resource server.
  • the service node receives the authorization request and the token acquisition request
  • the service node can serve as the authorization server.
  • the service node receives the resource operation request
  • the service node can As a resource server.
  • the authorization server and resource server corresponding to the third-party application can be the same, that is, the third-party application can send authorization requests, token acquisition requests, and resource operation requests to the same business node; in some embodiments, the third-party application can send authorization requests, token acquisition requests, and resource operation requests to the same business node.
  • the authorization server and resource server corresponding to the application can be the same, that is, the third-party application can send authorization requests, token acquisition requests, and resource operation requests to different business nodes.
  • third-party applications can apply for resources (i.e., send resource operation requests) to the business node.
  • the business node can respond to the resource operation request through the user information reading service (i.e., the object information operation service).
  • the read service calls the token verification contract and returns resources to the third-party application (for example, returning target read information) through the token verification contract and the object management information in the object login credential database.
  • the business node when the resource operation request is a resource read operation request, the business node needs to return the resource to the third-party application; when the resource operation request is a resource write operation request, a resource update operation request, and a resource deletion operation request, the business node does not need to return the resource to the third-party application.
  • Third-party applications return resources.
  • Figure 7 is a system architecture diagram in a blockchain electronic bill scenario provided by an embodiment of the present application.
  • the business layer, routing agent layer and core consensus network layer in the embodiment of this application constitute the entire complete blockchain business system.
  • the routing agent layer serves to isolate the business layer and the core consensus network layer. effect.
  • the transaction service in the embodiment of this application can take the electronic bill transfer service as an example, which is not limited here.
  • the blockchain network can record the transaction information generated during the entire circulation process of electronic bills.
  • the circulation process of electronic bills can include the application of electronic bills, the issuance of electronic bills, the reimbursement of electronic bills, and the tax filing of electronic bills.
  • the business layer is in the witness network and can submit business operation interactions to the core consensus network layer.
  • the business nodes (for example, the first business node) in the business layer can include terminal equipment corresponding to the electronic tax bureau and terminal equipment corresponding to the enterprise. And the terminal equipment corresponding to the consumer user (i.e. consumer).
  • the electronic tax bureau can refer to the local tax bureau in the tax bureau's private network
  • the enterprise can be an invoicing service provider, reimbursement service provider or retail enterprise in the public cloud (for example, KA enterprise, that is, large retail customers and key retail customer enterprises) etc.
  • Consumer users can be payment service providers, circulation service providers or retail enterprises in the private cloud.
  • the bill transfer service performed by the first business node may be: transferring the electronic bill (for example, electronic bill X) obtained by the consumer user when purchasing equipment to the consumer user Terminal device B corresponding to the enterprise where you are located.
  • the service layer may also include a second service node.
  • two invoicers from two companies for example, employee 1 and employee 2 issue invoices on their respective terminal devices and generate some transaction data.
  • employee 1 can use the terminal device Device A1 performs transaction services to generate corresponding transaction data
  • employee 2 can use terminal device A2 to perform transaction services to generate corresponding transaction data.
  • the agent nodes in the routing agent layer can be used to isolate the business layer and the core consensus network layer.
  • the agent nodes can have point-to-point services (ie, P2P services), routing services, certificate caching, and authentication services. It can be understood that point-to-point services refer to services in the P2P network.
  • P2P services point-to-point services
  • routing services ie, certificate caching, and authentication services.
  • P2P services point-to-point services
  • routing services ie, P2P services
  • certificate caching ie.g., certificate caching, and authentication services.
  • authentication services ie, P2P services
  • P2P services point-to-point services
  • P2P services point-to-point services
  • the certificate is the identity certificate of the owner of the public key and is issued by an authoritative organization (Certificate Authority, CA). Based on the public key certificate system, asymmetric encryption and digital signature of information can be realized.
  • the public key certificate system here can include public and private key passwords, x509 certificates, CA certificate issuing centers, etc. Authentication services can be used to verify the transaction format, node legitimacy, etc. of the received information.
  • the proxy node can forward the data synchronization request sent by the business node in the business layer (ie, the target business node) to the consensus node in the core consensus network layer (ie, the target consensus node). ), and can also forward the synchronization data returned by the consensus nodes in the core consensus network layer to the business nodes in the business layer.
  • the agent node can encrypt the forwarded data.
  • the core consensus network layer may include multiple core chains, and each core chain may include one or more consensus nodes.
  • the core consensus network layer includes one as shown in Figure 7
  • the core chain is taken as an example to illustrate.
  • the consensus node (i.e., accounting node) in the core consensus network layer can be a trusted node (i.e., TrustSQL node) in the tax private network.
  • the consensus node can include permission contracts, caches (i.e. caches) and data blocks (i.e. blocks).
  • the permissions contract stores the circulation logic about the entire life cycle of electronic bills, such as the bill status and circulation process of electronic bills. , data access rights, electronic bill application conditions, electronic bill issuance conditions, etc.
  • Cache and data blocks can provide support for the uploading and query of transaction information.
  • each consensus node has the ability to package and produce blocks, that is, it can verify the transaction data forwarded by the agent node, and add it to the transaction pool of the consensus node (i.e., the cache shown in Figure 7) when the verification is successful. )middle. Furthermore, the consensus node can package the transaction data in its own transaction pool and produce blocks to successfully write it into the blockchain in the core consensus network layer. In addition, when the consensus node receives the data synchronization request forwarded by the agent node, it can determine the synchronization data on the blockchain for returning to the business node.
  • the embodiment of this application proposes a distributed identity management system based on blockchain.
  • the identity management system can expand the functions of business nodes in the blockchain network.
  • the business nodes can be based on the information obtained from the blockchain.
  • Object credential information and object resource information represent the blockchain as an authorization server and resource server for distributed object management, realizing distributed object login services, token issuance services and object information operation services, eliminating the need for centralized identity management. It solves the problem of untrustworthiness, improves the efficiency and stability of the target object logging in to the application client, and improves the efficiency and stability of the target object operating resource data through the application client.
  • the business node When the business node serves as the authorization server, the business node can receive the authorization request and token acquisition request sent by the application client, and return the object authorization code and object token for the target object to the application client; when the business node serves as the resource server, The business node can receive the resource operation request sent by the application client and respond to the resource operation request.
  • the embodiments of the present application can realize on-chain management of object credential information and object resource information, synchronize and verify on-chain data through business nodes, and ensure the accuracy of object credential information and object resource information synchronized from the chain. Real-time, accurate and non-tamperable, thereby ensuring the security of object management information.
  • FIG. 8 is a schematic structural diagram of a data processing device provided by an embodiment of the present application.
  • the data processing device 1 can be a computer program (including program code) running in a computer device.
  • the data processing device 1 is an application software; the data processing device 1 can be used to execute the method provided by the embodiment of the present application. corresponding steps in .
  • the data processing device 1 can be applied to a business node in the blockchain network.
  • the business node is used to provide object login services and token issuance services.
  • the business node can be the embodiment corresponding to Figure 2 above.
  • the data processing device 1 may include: a first receiving module 11, an authorization code return module 12, and a second receiving module 13; further, the data processing device 1 may also include: a third receiving module 14, a first response module 15, second response module 16;
  • the first receiving module 11 is used to receive the authorization request sent by the target object through the application client, call the object login service based on the authorization request, and obtain the login information to be verified input by the target object in the object login service;
  • the authorization code return module 12 is used to match the login information to be verified with the object credential information through the object login service. If the login information to be verified matches the object credential information, obtain the object authorization code for the target object and send it to the application client. Returns the object authorization code; the object certificate information is obtained by the business node from the consensus node of the blockchain network;
  • the object login service includes the object login front end and the object login back end;
  • the first receiving module 11 is specifically used to receive the authorization request sent by the target object through the application client, call the object login front-end based on the authorization request, and obtain the login information to be verified input by the target object in the object login front-end;
  • module 12 which is specifically used to call the login judgment contract through the object login backend, and match the login information to be verified with the object credential information through the login judgment contract; the login judgment contract is obtained by the business node from the consensus node of.
  • the login information to be verified includes the identification of the object to be verified and the password of the object to be verified;
  • Authorization code return module 12 is specifically used to obtain object voucher information from the object information database through the login judgment contract; the object voucher information is synchronized by the business node from the on-chain data of the consensus node; the object voucher information includes the object identification voucher information;
  • the authorization code return module 12 is specifically used to search for the object identification to be verified in the object identification credential information. If the object identification to be verified does not exist in the object identification credential information, it is determined that the login information to be verified does not match the object credential information;
  • the authorization code return module 12 is specifically used to determine the matching result between the login information to be verified and the object credential information based on the password of the object to be verified if there is an object identification to be verified in the object identification credential information.
  • the object credential information also includes object password credential information and string credential information; one object identification credential information corresponds to one object password credential information and one string credential information;
  • the authorization code return module 12 is specifically used to splice the string credential information corresponding to the password of the object to be verified and the object identification to be verified in the object credential information to obtain the spliced login information to be verified;
  • the authorization code return module 12 is specifically used to perform hash calculation on the spliced login information to be verified, and obtain the hashed login information to be verified;
  • the authorization code return module 12 is specifically used to compare the hash login information to be verified with the object password credential information corresponding to the object identification to be verified in the object credential information. If the hash login information to be verified and the object identification to be verified are in the object credential If the corresponding object password and credential information in the information are the same, a matching result is generated to represent the match between the login information to be verified and the object credential information;
  • the authorization code return module 12 is specifically used to generate, if the hash login information to be verified is different from the object password credential information corresponding to the object identification to be verified in the object credential information, to represent the mismatch between the login information to be verified and the object credential information. Matching results.
  • the second receiving module 13 is used to receive a token acquisition request sent by the application client based on the object authorization code, call the token issuance service based on the token acquisition request, obtain the object token for the target object through the token issuance service, and send the token to the application
  • the client returns an object token; the object token provides the application client with operation permissions for resource data within the authorization scope; operation permissions mean that the application client has the permission to operate resource data through business nodes.
  • the second receiving module 13 includes: an authorization code verification unit 131, a token return unit 132;
  • the authorization code verification unit 131 is used to call the authorization code verification contract through the token issuance service, and verify the object authorization code through the authorization code verification contract; the authorization code verification contract is obtained by the business node from the consensus node;
  • the token return unit 132 is used to obtain key authorization information associated with the target object if the object authorization code verification is passed, generate an object token for the target object based on the key authorization information, and return the object token to the application client.
  • the authorization code return module 12 is specifically used to obtain the key authorization information selected by the target object in the object login service, and generate the object authorization code for the target object based on the key authorization information;
  • the key authorization information includes aging information, operation permissions and authorization scope. At least one of; the aging information is used to characterize the life cycle of the object token;
  • the token return unit 132 is specifically used to parse the object authorization code to obtain key authorization information associated with the target object.
  • the second receiving module 13 is also specifically used to obtain the key authorization information selected by the target object in the object login service;
  • the key authorization information includes at least one of aging information, operation authority and authorization scope;
  • the aging information is used to characterize the object token.
  • the token return unit 132 is specifically configured to obtain key authorization information associated with the target object from the object login service through the token issuance service.
  • step S103 For the specific implementation of the authorization code verification unit 131 and the token return unit 132, please refer to the description of step S103 in the embodiment corresponding to Figure 3 above, and will not be described again here.
  • the business node is also used to provide object information operation services
  • the third receiving module 14 is used to receive the resource operation request sent by the application client based on the object token, and call the object information operation service based on the resource operation request;
  • the first response module 15 is used to call the token verification contract through the object information operation service, and verify the resource operation request and the object token through the token verification contract. If the resource operation request and the object token are verified through the object information, The operation service responds to resource operation requests;
  • the first response module 15 is specifically used to obtain key authorization information associated with the object token through the token verification contract, Determine whether the resource operation request meets key authorization information;
  • the first response module 15 is specifically configured to determine that the resource operation request and object token verification pass if the resource operation request meets the key authorization information
  • the first response module 15 is specifically configured to determine that the resource operation request and object token verification fail if the resource operation request does not meet the key authorization information.
  • the first response module 15 is specifically used to obtain the target read data requested by the resource read operation request from the object information database through the object information operation service if the resource operation request is a resource read operation request; target The read data belongs to resource data;
  • the first response module 15 is specifically used to return the target read data to the application client.
  • the first response module 15 is specifically used to obtain the target read data from the object information database through the object information operation service if the target read data requested by the resource read operation request exists in the object information database;
  • the first response module 15 is specifically used to send a data synchronization request for the target read data to the consensus node through the object information operation service if the target read data does not exist in the object information database, based on the data synchronization for the target read data.
  • Request to obtain synchronized data from the on-chain data of the consensus node store the synchronized data in the object information database, and obtain the target read data from the object information database through the object information operation service; the synchronized data includes the target read data.
  • the first response module 15 is specifically used to obtain the target write data requested by the resource write operation request through the object information operation service if the resource operation request is a resource write operation request; the target write data belongs to the resource data;
  • the first response module 15 is specifically configured to write the target write data to the object information database if the target write data does not exist in the object information database.
  • the first response module 15 is specifically used to forward the target write data to the consensus node if the target write data does not exist in the object information database, so that the consensus node packages the target write data and generates the target area.
  • Block upload the target block to the chain;
  • the first response module 15 is specifically configured to send a data synchronization request for the target write data to the consensus node, receive the target write data returned by the consensus node based on the data synchronization request for the target write data, and write the target write data. Enter the object information database.
  • the second response module 16 is used to reject the resource operation request through the object information operation service if the resource operation request and the object token verification fail.
  • the authorization code return module 12 and the second receiving module 13 please refer to the description of steps S101 to S103 in the embodiment corresponding to Figure 3 above, and will not be described again here.
  • the first response module 15 and the second response module 16 please refer to the description of steps S204 to S207 in the embodiment corresponding to FIG. 6, and will not be described again here.
  • the description of the beneficial effects of using the same method will not be described again.
  • FIG. 9 is a schematic structural diagram of a computer device provided by an embodiment of the present application.
  • the computer device 1000 may include a processor 1001 , a network interface 1004 and a memory 1005 .
  • the computer device 1000 may further include a user interface 1003 and at least one communication bus 1002 .
  • the communication bus 1002 is used to realize connection communication between these components.
  • the user interface 1003 may include a display screen (Display) and a keyboard (Keyboard), and the user interface 1003 may also include a standard wired interface and a wireless interface.
  • the network interface 1004 may include a standard wired interface or a wireless interface (such as a WI-FI interface).
  • the memory 1005 may be a high-speed RAM memory or a non-volatile memory, such as at least one disk memory.
  • the memory 1005 may also be at least one storage device located remotely from the aforementioned processor 1001.
  • memory 1005, which is a computer-readable storage medium may include an operating system, a network communication module, a user interface module, and a device control application program.
  • the network interface 1004 can provide network communication functions; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control stored in the memory 1005. application to achieve:
  • the object login service matches the login information to be verified with the object credential information. If the login information to be verified matches the object credential information, the object authorization code for the target object is obtained and the object authorization code is returned to the application client; the object credential information It is obtained by the business node from the consensus node of the blockchain network;
  • the computer device 1000 described in the embodiment of the present application can perform the data processing method described in the embodiment corresponding to FIG. 3 and FIG. 6, and can also perform the data processing device 1 in the embodiment corresponding to FIG. 8. The description will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be described again.
  • the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores the computer program executed by the aforementioned data processing device 1, and the computer program includes
  • the processor executes the program instructions, it can execute the description of the data processing method in the embodiments corresponding to FIG. 3 and FIG. 6. Therefore, the details will not be described again here.
  • the description of the beneficial effects of using the same method will not be described again.
  • embodiments of the present application also provide a computer program product or computer program.
  • the computer program product or computer program may include computer instructions, and the computer instructions may be stored in a computer-readable storage medium.
  • the processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor can execute the computer instructions, so that the computer device performs the description of the data processing method in the embodiments corresponding to Figures 3 and 6. Therefore, No further details will be given here. In addition, the description of the beneficial effects of using the same method will not be described again. For technical details not disclosed in the computer program products or computer program embodiments involved in this application, please refer to the description of the method embodiments in this application.
  • the computer program can be stored in a computer-readable storage medium, and the program can be executed when executed. When doing so, it may include the processes of the above method embodiments.
  • the storage medium can be a magnetic disk, an optical disk, a read-only memory (Read-Only Memory, ROM) or a random access memory (Random Access Memory, RAM), etc.

Abstract

本申请实施例提供了一种数据处理方法、装置、计算机设备以及可读存储介质，该方法包括：接收目标对象通过应用客户端发送的授权请求，基于授权请求调用对象登录服务，获取目标对象在对象登录服务中输入的待验证登录信息；通过对象登录服务将待验证登录信息与对象凭证信息进行匹配，若待验证登录信息与对象凭证信息相匹配，则获取针对目标对象的对象授权码，向应用客户端返回对象授权码；接收应用客户端基于对象授权码发送的令牌获取请求，基于令牌获取请求调用令牌发放服务，通过令牌发放服务获取针对目标对象的对象令牌，向应用客户端返回对象令牌。

Description

一种数据处理方法、装置、计算机设备以及可读存储介质
本申请要求于2022年05月17日提交中国专利局、申请号为202210536186.7名称为“一种数据处理方法、装置、计算机设备以及可读存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及区块链技术领域，尤其涉及一种数据处理方法、装置、计算机设备以及可读存储介质。
背景
相关技术中，身份管理系统可以将登录所使用的身份管理信息存储在一个中心化的服务器(即授权服务器)中，该授权服务器中所存储的身份管理信息与所有的对象相关联，即该授权服务器中存储了所有对象进行登录时所需要的身份管理信息。因此，所有对象在需要通过应用客户端进行登录时，均需要向该授权服务器发送登录请求，进而实现应用客户端的登录操作。
技术内容
本申请实施例提供了一种数据处理方法，方法由区块链网络中的业务节点执行，业务节点用于提供对象登录服务和令牌发放服务，包括：
业务节点接收目标对象通过应用客户端发送的授权请求，基于授权请求调用对象登录服务，获取目标对象在对象登录服务中输入的待验证登录信息；
通过对象登录服务将待验证登录信息与对象凭证信息进行匹配，若待验证登录信息与对象凭证信息相匹配，则获取针对目标对象的对象授权码，向应用客户端返回对象授权码；对象凭证信息是由业务节点从区块链网络的共识节点中所获取到的；
接收应用客户端基于对象授权码发送的令牌获取请求，基于令牌获取请求调用令牌发放服务，通过令牌发放服务获取针对目标对象的对象令牌，向应用客户端返回对象令牌；对象令牌为应用客户端提供针对授权范围内的资源数据的操作权限；操作权限是指应用客户端具有通过业务节点操作资源数据的权限。
本申请实施例提供了一种数据处理装置，装置应用于区块链网络中的业务节点，业务节点用于提供对象登录服务和令牌发放服务，包括：
第一接收模块，用于接收目标对象通过应用客户端发送的授权请求，基于授权请求调用对象登录服务，获取目标对象在对象登录服务中输入的待验证登录信息；
授权码返回模块，用于通过对象登录服务将待验证登录信息与对象凭证信息进行匹配，若待验证登录信息与对象凭证信息相匹配，则获取针对目标对象的对象授权码，向应用客户端返回对象授权码；对象凭证信息是由业务节点从区块链网络的共识节点中所获取到的；
第二接收模块，用于接收应用客户端基于对象授权码发送的令牌获取请求，基于令牌获取请求调用令牌发放服务，通过令牌发放服务获取针对目标对象的对象令牌，向应用客户端返回对象令牌；对象令牌为应用客户端提供针对授权范围内的资源数据的操作权限；操作权限是指应用客户端具有通过业务节点操作资源数据的权限。
本申请实施例提供了一种计算机设备，包括：处理器和存储器；
处理器与存储器相连，其中，存储器用于存储计算机程序，计算机程序被处理器执行时，使得该计算机设备执行本申请实施例提供的方法。
本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，该计算机程序适于由处理器加载并执行，以使得具有该处理器的计算机设备执行本申请实施例提供的方法。
本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例提供的方法。
附图说明
为了更清楚地说明本申请实施例或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种区块链网络分层结构的示意图；
图2是本申请实施例提供的一种进行数据交互的场景示意图；
图3是本申请实施例提供的一种数据处理方法的流程示意图；
图4是本申请实施例提供的一种申请资源的流程示意图；
图5是本申请实施例提供的一种申请资源的场景示意图；
图6是本申请实施例提供的一种数据处理方法的流程示意图；
图7是本申请实施例提供的一种区块链电子票据场景下的系统架构图；
图8是本申请实施例提供的一种数据处理装置的结构示意图；
图9是本申请实施例提供的一种计算机设备的结构示意图
实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
用户在通过应用客户端进行登录时，若在同一时间向授权服务器发送登录请求的应用客户端的数量很多，则授权服务器无法及时处理数量很多的登录请求，从而会出现应用客户端的排队等待现象，导致应用客户端无法及时完成登录操作，进而会降低应用客户端进行登录的效率。此外，在授权服务器出现故障时，授权服务器无法成功响应应用客户端的登录请求，导致应用客户端无法成功完成登录操作，从而会降低应用客户端进行登录的稳定性。
本申请实施例提供一种数据处理方法、装置、计算机设备以及可读存储介质，可以提高目标对象登录应用客户端的效率和稳定性。
请参见图1，图1是本申请实施例提供的一种区块链网络分层结构的示意图。如图1所示的区块链网络分层结构可以应用于区块链系统，该区块链系统可以包括代理节点(例如，代理节点100b)、第一区块链系统以及第二区块链系统，以构成图1所示的区块链网络2000。其中，第一区块链系统和第二区块链系统均可以包括一个或者多个节点，这里将不对第一区块链系统和第二区块链系统中节点的数量进行限制。如图1所示，第一区块链系统具体可以包括节点110a、节点110b、节点110c、…、和节点110n；第二区块链系统具体可以包括节点120a、节点120b、节点120c、…、和节点120n。
其中，第一区块链系统对应的区块链网络可以称之为业务网络(即见证网络)100a，处于业务网络100a中的节点可以称之为业务节点，该业务节点主要用于执行交易业务，以得到与该交易业务相关联的交易数据。可以理解的是，这里的业务节点不需要参与记账共识，但能够通过身份认证的方式从核心共识网络中获得区块头数据和部分授权可见的区块数据。其中，为了保证第一区块链系统内的信息互通，第一区块链系统中的每个节点之间可以存在信息连接，节点之间可以通过上述信息连接进行信息传输。
其中，第二区块链系统对应的区块链网络可以为称之为核心共识网络(即共识网络)100c，处于核心共识网络100c中的节点可以称之为共识节点(即记账节点)，这里的共识节点可以运行有区块链共识协议。其中，为了保证第二区块链系统内的信息互通，第二区块链系统中的每个节点之间可以存在信息连接，节点之间可以通过上述信息连接进行信息传输。
可以理解的是，上述第一区块链系统和第二区块链系统内的信息连接不限定连接方式，可以通过有线通信方式进行直接或间接地连接，也可以通过无线通信方式进行直接或间接地连接，还可以通过其他连接方式，本申请在此不做限制。
其中，图1所示的代理节点100b可以用于对该业务网络100a和核心共识网络100c进行网络隔离，该代理节点100b可以将点对点(Peer To Peer，简称P2P)网络进行网络分层，以形成“业务网络—核心共识网络”这样的分层结构(即双层链结构)，进而能够提高区块链上数据的保密性和安全性。
其中，可以理解的是，本申请实施例可以将代理节点100b、业务网络100a中的业务节点以及核心共识网络100c中的共识节点统称为区块链网络2000中的区块链节点。可以理解的是，该区块链节点可以为接入该区块链网络2000中的服务器，也可以为接入该区块链网络2000中的终端设备，这里对区块链节点的具体形式不做限定。
其中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。其中，终端设备可以是手机、平板电脑、笔记本电脑、掌上电脑、智能音响、移动互联网设备(MID，mobile internet device)、POS(Point Of Sales，销售点)机、可穿戴设备(例如，智能手表、智能手环等)等。
可以理解的是，图1所示的区块链网络2000中的一些节点存储了完整的区块链数据库，这样的包含所有交易数据的节点可以称为全量节点(Full Node，例如，图1所示的共识节点)；另外一些节点存储了部分的区块链数据库，一般只存储区块头和与自身节点相关联的交易数据，而不存储完整交易数据，它们会通过“简化交易验证(Simplified Payment Verification，简称SPV)”的方式完成交易校验，这样的节点可以称为轻量节点(Lightweight Node)或SPV节点(例如，图1所示的业务节点)。
可以理解的是，图1所示的业务网络100a和核心共识网络100c可以处于不同的网络环境，通常来说，业务网络100a可以处于公有网络中，核心共识网络100c可以处于私有网络中。因此，业务节点部署在处于公网(即公有网络)的业务网络100a中，共识节点部署在处于私网(即私有网络)的核心共识网络100c中，二者可以通过路由边界进行交互。
为便于理解，本申请实施例可以在图1所示的业务网络110a中的多个业务节点中选择一个业务节点作为目标业务节点，该目标业务节点具有向代理节点100b发送数据同步请求的功能，例如，本申请实施例可以将图1所示的节点110a作为目标业务节点。为便于理解，本申请实施例可以在图1所示的核心共识网络100c中的多个共识节点中选择一个共识节点作为目标共识节点，该目标共识节点具有向代理节点100b返回数据同步请求对应的同步数据的功能，例如，本申请实施例可以将图1所示的节点120a作为目标共识节点。其中，代理节点100b可以将目标业务节点发送的数据同步请求转发至目标共识节点，代理节点100b可以将目标共识节点返回的同步数据转发至目标业务节点。
由于核心共识网络处于相对安全的私有云中，其互相访问本就有共识机制保证安全，不需要额外加入身份管理和网络控制。而目标业务节点处于公共网络中，可能会被其他不确定的网络终端访问，因此，目标业务节点以及其他可能的节点接入核心共识网络中的行为需要被严格控制。这样，代理节点和目标共识节点需要对发送数据同步请求的目标业务节点进行验证。
可以理解的是，代理节点在接收到目标业务节点发送的数据同步请求时，可以对该目标业务节点进行权限验证，以得到权限验证结果，这里的权限验证可以包括验证目标业务节点的节点标识是否属于非法节点列表中的节点标识。其中，非法节点列表可以是指代理节点所存储的黑名单列表，该非法节点列表中的非法节点标识所对应的非法节点是指检测到的恶意节点、被他人举报的节点，在某一时间段发送交易频率异常的节点等。
其中，可以理解的是，代理节点可以在该非法节点列表中查找与该目标业务节点的节点标识相同的非法节点标识，以得到权限验证结果。若权限验证结果指示在非法节点列表中查找到与目标节点的节点标识相同的非法节点标识，则代理节点可以确定该权限验证结果属于非法验证结果，此时，该代理节点可以确定该目标业务节点为非法节点，进而无需将数据同步请求转发至核心共识网络中的目标共识节点。在一些实施例中，若权限验证结果指示在非法节点列表中未查找到与目标业务节点的节点标识相同的非法节点标识，则代理节点可以确定该权限验证结果属于合法验证结果，此时，该代理节点可以确定该目标业务节点为合法节点，进而可以将数据同步请求转发至核心共识网络中 的目标共识节点。
其中，目标业务节点可以用于提供对象登录服务、令牌发放服务和对象信息操作服务，对象登录服务、令牌发放服务和对象信息操作服务可以为部署在服务器上、专门为应用客户端(即第三方应用)提供远程网络服务的服务器程序。为便于理解，本申请实施例可以将通过第三方应用进行登录的用户称之为目标对象。其中，应用客户端具体可以包括浏览器、车载客户端、智能家居客户端、娱乐客户端、多媒体客户端(例如，视频客户端)、社交客户端以及资讯类客户端等具有数据处理功能的客户端。其中，车载客户端可以为车载终端上的应用客户端。
应当理解，上述分层结构所适用的业务场景可以为应用授权场景，应用授权场景下的同步数据可以包括对象管理信息和用户管理合约(即对象管理合约)。其中，对象管理信息分布式存储在核心共识网络所维护的区块链中，目标业务节点可以针对对象管理信息进行同步校验后，对应用客户端提供服务。
其中，对象管理信息可以表示与用户(即对象)相关联的属性信息，对象管理信息具体可以包括对象凭证信息和对象资源信息，对象凭证信息可以表示用于进行登录的基本信息(例如，账号、密码)，对象资源信息可以表示与对象凭证信息所指示的用户相关联的基本信息。其中，对象管理合约可以用于对对象管理信息进行处理。对象管理合约为管理着用户信息、用户的注册、冻结、权限设计等的区块链智能合约，通过区块链交易的方式可以执行对象管理合约。
其中，目标业务节点可以基于对象管理合约，通过对象凭证信息授权第三方应用进行登录，授权登录后的第三方应用操作对象资源信息。此外，目标业务节点还可以提供任何其他SPV节点拥有的功能，例如，验证交易，转发上链，查询状态，查询区块等。
为便于理解，请参见表1，表1是本申请实施例提供的一种节点标识列表。该节点标识列表中可以存储有对某一交易数据可见的节点的节点标识和节点名称。如表1所示：
表1
其中，节点标识可为IP(Internet Protocol，网络之间互联的协议)地址以及其他任一种能够用于标识该节点的信息。例如，节点1(例如，节点1可以为图1所示的节点110a)可以通过节点标识BBBBBB向节点2(例如，节点2可以为图1所示的节点120a)发送信息(例如，数据同步请求)，且节点2可以通过节点标识AAAAAA确定该信息是由节点1所发送的；节点2可以通过节点标识AAAAAA向节点1返回信息(例如，同步数据)，且节点1可以通过节点标识BBBBBB确定该信息是由节点2所返回的。其中，代理节点100b可以转发节点1向节点2发送的数据同步请求，代理节点100b可以转发节点2向节点1返回的同步数据，这里的节点1可以为目标业务节点，这里的节点2可以为目标共识节点。
其中，核心共识网络中的目标共识节点可以获取代理节点100b发送的加密数据信息。其中，加密数据信息可以为代理节点100b通过核心共识网络的系统公钥对数据同步请求和签名信息进行加密处理后所得到的，签名信息可以为业务网络中的目标业务节点通过该目标业务节点的节点私钥对数据同步请求进行签名后所得到的。进一步地，目标共识节点可以获取核心共识网络的系统私钥(即核心共识网络的系统公钥对应的系统私钥)，通过核心共识网络的系统私钥对加密数据信息进行解密处理，得到数据同步请求和签名信息。进一步地，目标共识节点可以获取目标业务节点的节点公钥(即目标业务节点的节点私钥对应的节点公钥)，基于目标业务节点的节点公钥对签名信息进行验签，得到验签结果。进一步地，目标共识节点可以在验签结果指示验签成功时，接收数据同步请求。在一些实施例中，目标共识节点可以在验签结果指示验签失败时，拒绝接收数据同步请求。
其中，可以理解的是，目标业务节点可以利用哈希算法对数据同步请求进行哈希计算，从而可以得到数据同步请求的摘要信息h，并基于目标业务节点的节点私钥对该摘要信息h进行数字签名，得到数据同步请求对应的签名信息。目标共识节点可以基于目标业务节点的节点公钥对签名信息中的数字签名进行验签，得到数据同步请求的摘要信息h，并基于目标业务节点所使用的哈希算法对接收到的数据同步请求进行哈希计算，从而可以得到数据同步请求的摘要信息H，进而可以将验签所得到的摘要信息h和哈希计算所得到的摘要信息H进行比较，得到验签结果。其中，在摘要信 息h与摘要信息H相同时，验签结果指示目标共识节点验签成功；在摘要信息h与摘要信息H不相同时，验签结果指示目标共识节点验签失败。
在一些实施例中，可以理解的是，代理节点100b在对加密数据信息进行转发时，还可以通过代理节点100b的节点私钥对加密数据信息进行加密处理，得到加密后的加密数据信息，以使目标共识节点通过代理节点100b的节点公钥对加密后的加密数据信息进行解密处理。在一些实施例中，目标业务节点在将数据同步请求和签名信息发送至代理节点100b之前，可以通过代理节点100b的节点公钥对数据同步请求和签名信息进行加密处理，得到加密请求信息，进而将该加密请求信息发送至代理节点100b。这样，代理节点100b在接收到加密请求信息时，可以通过该代理节点100b的节点私钥对加密请求信息进行解密处理，得到数据同步请求和签名信息。
同理，目标业务节点接收代理节点100b转发的同步数据的具体过程，可以参见上述目标共识节点接收代理节点100b转发的数据同步请求的描述，这里将不再进行赘述。
为便于理解，进一步地，请参见图2，图2是本申请实施例提供的一种进行数据交互的场景示意图。如图2所示的业务节点20a可以为上述图1所对应实施例的业务网络100a中的任意一个节点，如图2所示的代理节点20b可以为上述图1所对应实施例中的代理节点100b，如图2所示的共识节点20c可以为上述图1所对应实施例的核心共识网络100c中的任意一个节点。为便于理解，本申请实施例以上述图1所示的节点110a作为该业务节点20a、以上述图1所示的节点120a作为该共识节点20c为例，以阐述图2所示的业务节点20a、代理节点20b和共识节点20c之间进行数据交互的具体过程。
如图2所示，业务节点20a可以向代理节点20b发送数据同步请求，代理节点20b可以将数据同步请求转发至共识节点20c，这样，共识节点20c在获取到数据同步请求对应的同步数据之后，可以向代理节点20b返回同步数据，代理节点20b可以将同步数据转发至业务节点20a。
如图2所示的对象21b可以为目标对象，对象21b对应的终端设备可以为终端设备21a，终端设备21a中可以安装有应用客户端。因此，在对象21b需要登录终端设备21a中的应用客户端时，对象21b可以通过终端设备21a中的应用客户端向业务节点20a发送授权请求。这样，业务节点20a可以接收对象21b通过应用客户端发送的授权请求，基于授权请求调用对象登录服务，通过对象登录服务向终端设备21a返回对象授权码。
其中，业务节点20a可以获取对象21b在对象登录服务中输入的待验证登录信息，获取同步数据中的对象凭证信息，通过对象登录服务将待验证登录信息和对象凭证信息进行匹配，若待验证登录信息与对象凭证信息相匹配，则获取针对对象20a的对象授权码，进而向终端设备21a返回对象授权码。在一些实施例中，若待验证登录信息与对象凭证信息不匹配，则业务节点20a无需向终端设备21a返回对象授权码。
如图2所示，对象21b可以通过终端设备21a中的应用客户端向业务节点20a发送令牌获取请求，令牌获取请求可以携带有对象授权码。这样。业务节点20a可以接收对象21b通过应用客户端发送的令牌获取请求，基于令牌获取请求调用令牌发放服务，通过令牌发送服务向终端设备21a返回对象令牌。对象令牌是业务节点响应于应用客户端发送的请求而生成的一串字符串以使拥有该对象令牌的应用客户端对相应的资源数据具有对应的操作权限。对象令牌可以用来代替密码。对象令牌具有以下特点：令牌是短期的，到期会自动失效；对象令牌可以被资源数据的所有者撤销，撤销后会立即失效；对象令牌具有权限范围，例如只读权限的对象令牌就比读写权限的对象令牌更安全。
其中，业务节点20a可以通过令牌发送服务对对象授权码进行验证，若对象授权码验证通过，则获取针对对象21b的对象令牌，进而向终端设备21a返回对象令牌。在一些实施例中，若对象授权码验证不通过，则业务节点20a无需向终端设备21a返回对象令牌。
应当理解，对象21b可以基于对象令牌向业务节点20a发送资源操作请求，资源操作请求用于请求通过业务节点20a操作授权范围内的资源数据，授权范围内的资源数据可以属于同步数据中的对象资源信息，授权范围内的资源数据可以为对象资源信息中属于对象21b的对象资源信息。这样，业务节点20a可以基于对象令牌为应用客户端提供针对授权范围内的资源数据的操作权限。因此，授权范围内的资源数据可以为对象资源信息中属于对象21b、且具有操作权限的对象资源信息。
在一些实施例中，业务节点20a还可以用于提供对象注册服务。对象21b可以通过应用客户端向业务节点20a发送对象注册请求，这样，业务节点20a可以接收对象21b通过应用客户端发送的对象注册请求，基于对象注册请求调用对象注册服务，获取对象21b在对象注册服务中输入的对象注册信息，进而通过共识节点20c对对象注册信息进行打包处理。在共识节点20c对对象注册信息 上链成功后，业务节点20a可以从共识节点20c所维护的区块链上获取最新的对象凭证信息。其中，最新的对象凭证信息可以包括对象21b的对象注册信息，其中，对象注册信息可以包括对象注册标识和对象注册密码。
由此可见，本申请实施例可以将区块链网络中的业务节点作为授权服务器，该授权服务器可以通过对象登录服务响应应用客户端发送的授权请求，通过令牌发送服务响应应用客户端发送的令牌获取请求，从而实现应用客户端的登录操作。可以理解的是，业务节点的数量可以为多个，多个业务节点可以分别响应应用客户端发送的授权请求和令牌获取请求，从而可以提高目标对象登录应用客户端的效率和稳定性。
进一步地，请参见图3，图3是本申请实施例提供的一种数据处理方法的流程示意图。该方法可以由区块链网络中的业务节点执行，该业务节点可以为接入至业务网络中的服务器，也可以为接入至业务网络中的终端设备，这里不对业务节点的具体形式进行限定。该业务节点用于提供对象登录服务和令牌发放服务，该业务节点可以为上述图1所示的业务网络100a中的任意一个节点，例如，节点110a。其中，该数据处理方法可以包括以下步骤：
步骤S101，接收目标对象通过应用客户端发送的授权请求，基于授权请求调用对象登录服务，获取目标对象在对象登录服务中输入的待验证登录信息；
具体的，业务节点可以接收目标对象通过应用客户端发送的授权请求，基于授权请求调用对象登录前端，获取目标对象在对象登录前端中输入的待验证登录信息。其中，业务节点可以将对象登录前端显示在应用客户端中，以使目标对象在对象登录前端中输入待验证登录信息。其中，对象登录服务包括对象登录前端(即用户登录前端)和对象登录后端，对象登录前端可以表示对象登录服务的前端页面，对象登录后端可以表示对象登录服务的后端逻辑。
应当理解，待验证登录信息可以为目标对象在除第三方应用之外的其他应用客户端(例如，目标应用客户端)中的登录信息，这样，对象登录前端可以表示目标应用客户端的前端页面，对象登录后端可以为目标应用客户端的后端逻辑。因此，业务节点可以将第三方应用跳转到对象登录前端，由目标对象与对象登录前端进行交互，从而通过目标应用客户端中的登录信息实现第三方应用的登录操作。其中，目标对象可以在对象登录前端中直接输入待验证登录信息，也可以在对象登录前端中授权获取待验证登录信息，授权获取的待验证登录信息可以为目标对象在当前时刻的前一时刻所输入的待验证登录信息。
应当理解，业务节点可以从区块链网络的共识节点中获取对象管理信息，对象管理信息可以包括对象凭证信息和对象资源信息；业务节点可以从共识节点中获取对象管理合约，对象管理合约可以包括但不限于登录判断合约、授权码验证合约和令牌验证合约。其中，对象凭证信息和登录判断合约可以用于执行步骤S102；授权码验证合约可以用于执行步骤S103，令牌验证合约可以用于执行步骤S205，对象资源信息可以用于执行步骤S206。
其中，可以理解的是，业务节点可以构建对象信息数据库(即用户登录凭证DB(database，数据库))，将对象管理信息存储至对象信息数据库中，这样，对象信息数据库可以用于在步骤S102中查询对象凭证信息和在步骤S206中查询对象资源信息。
其中，可以理解的是，对象管理合约可以为存储在业务节点的区块链智能合约，区块链智能合约可以在共识网络中发布，并同步到业务节点中执行，对象管理合约封装了验证用户状态，接受用户登录验证处理等功能。对象管理合约可以依赖于对象信息数据库中的对象管理信息发挥作用，即对象管理合约可以基于对象凭证信息进行登录验证，基于对象资源信息进行用户信息的CURD(即用于处理数据的基本原子操作，Create(即C)创建、Update(即U)更新、Retrieve(即R)读取、Delete(即D)删除)。
步骤S102，通过对象登录服务将待验证登录信息与对象凭证信息进行匹配，若待验证登录信息与对象凭证信息相匹配，则获取针对目标对象的对象授权码，向应用客户端返回对象授权码；
具体的，业务节点可以通过对象登录后端调用登录判断合约，通过登录判断合约将待验证登录信息与对象凭证信息进行匹配。其中，登录判断合约是由业务节点从共识节点中所获取到的。进一步地，若待验证登录信息与对象凭证信息相匹配，则业务节点可以获取针对目标对象的对象授权码，向应用客户端返回对象授权码。在一些实施例中，若待验证登录信息与对象凭证信息不匹配，则业务节点可以拒绝授权请求，无需向应用客户端返回对象授权码。
其中，待验证登录信息包括待验证对象标识和待验证对象密码。应当理解，业务节点通过登录判断合约将待验证登录信息与对象凭证信息进行匹配的具体过程可以描述为：业务节点可以通过登录判断合约从对象信息数据库中获取对象凭证信息。其中，对象凭证信息是由业务节点从共识节点 的已上链数据中同步得到的，对象凭证信息可以包括对象标识凭证信息。进一步地，业务节点可以在对象标识凭证信息中查找待验证对象标识，若对象标识凭证信息中不存在待验证对象标识，则确定待验证登录信息与对象凭证信息不匹配。在一些实施例中，若对象标识凭证信息中存在待验证对象标识，则业务节点可以基于待验证对象密码，确定待验证登录信息与对象凭证信息之间的匹配结果。
其中，对象信息数据库中不会存储明文密码，而是存储密钥加盐后哈希的结果。其中，密钥加盐是指在密钥的随机的位置上添加预先生成的字符或字符串。例如一个密钥为：123456，系统在随机的位置上添加字符，添加后的结果为：1a2b3c456abcd添加后的结果为。这样，对象凭证信息还包括对象密码凭证信息(即密钥加盐后哈希的结果)和字符串凭证信息(即盐)，一个对象标识凭证信息对应一个对象密码凭证信息和一个字符串凭证信息。应当理解，业务节点基于待验证对象密码确定待验证登录信息与对象凭证信息之间的匹配结果的具体过程可以描述为：业务节点可以将待验证对象密码与待验证对象标识在对象凭证信息中对应的字符串凭证信息进行拼接，得到待验证拼接登录信息(即第一待验证拼接登录信息)，也即，将待验证对象密码和上述字符串凭证信息进行拼接，得到待验证拼接登录信息。进一步地，业务节点可以对待验证拼接登录信息进行哈希计算，得到待验证哈希登录信息(即第一待验证哈希登录信息)。进一步地，业务节点可以将待验证哈希登录信息与待验证对象标识在对象凭证信息中对应的对象密码凭证信息进行比较，若待验证哈希登录信息与待验证对象标识在对象凭证信息中对应的对象密码凭证信息相同，则生成用于表征待验证登录信息与对象凭证信息相匹配的匹配结果。在一些实施例中，若待验证哈希登录信息与待验证对象标识在对象凭证信息中对应的对象密码凭证信息不同，则业务节点可以生成用于表征待验证登录信息与对象凭证信息不匹配的匹配结果。
其中，盐是一个随机生成的字符串，是由安全的随机函数所生成的，不同的对象标识凭证信息对应于不同的盐。应当理解，本申请实施例不对哈希计算所使用的哈希算法进行限定，例如，哈希算法可以为MD5信息摘要算法(MD5Message-Digest Algorithm)。
其中，在一些实施例中，业务节点可以对待验证对象密码进行哈希计算，得到待验证哈希对象密码。进一步地，业务节点可以将待验证哈希对象密码与待验证对象标识在对象凭证信息中对应的字符串凭证信息进行拼接，得到待验证拼接登录信息(即第二待验证拼接登录信息)，也即将待验证哈希对象密码和上述字符串凭证信息进行拼接，得到待验证拼接登录信息。进一步地，业务节点可以对待验证拼接登录信息进行哈希计算，得到待验证哈希登录信息(即第二待验证哈希登录信息)。其中，在一些实施例中，业务节点可以对待验证对象密码进行哈希计算，得到待验证哈希登录信息(即第三待验证哈希登录信息)。
在一些实施例中，对象信息数据库中还可以存储明文密码，这样，对象凭证信息还包括对象密码凭证信息(即明文密码)，一个对象标识凭证信息对应一个对象密码凭证信息。应当理解，业务节点基于待验证对象密码确定待验证登录信息与对象凭证信息之间的匹配结果的具体过程可以描述为：业务节点可以将待验证对象密码与待验证对象标识在对象凭证信息中对应的对象密码凭证信息进行比较，若待验证对象密码与待验证对象标识在对象凭证信息中对应的对象密码凭证信息相同，则生成用于表征待验证登录信息与对象凭证信息相匹配的匹配结果。在一些实施例中，若待验证对象密码与待验证对象标识在对象凭证信息中对应的对象密码凭证信息不相同，则生成用于表征待验证登录信息与对象凭证信息不匹配的匹配结果。
应当理解，对象信息数据库中的对象管理信息可以包括对象状态，对象状态可以表示对象的冻结状态或非冻结状态。业务节点在接收应用客户端发送的授权请求时，可以通过对象登录服务在对象信息数据库中查询目标对象的对象状态，若目标对象的对象状态为冻结状态，则拒绝授权请求。在一些实施例中，若目标对象的对象状态为非冻结状态，则业务节点可以在获取到针对目标对象的对象授权码之后，向应用客户端返回对象授权码。
步骤S103，接收应用客户端基于对象授权码发送的令牌获取请求，基于令牌获取请求调用令牌发放服务，通过令牌发放服务获取针对目标对象的对象令牌，向应用客户端返回对象令牌。
具体的，业务节点可以接收应用客户端基于对象授权码发送的令牌获取请求，基于令牌获取请求调用令牌发放服务。进一步地，业务节点可以通过令牌发放服务调用授权码验证合约，通过授权码验证合约对对象授权码进行验证。其中，授权码验证合约是由业务节点从共识节点中所获取到的。进一步地，若对象授权码验证通过，则业务节点可以获取与目标对象相关联的关键授权信息，基于关键授权信息生成针对目标对象的对象令牌，向应用客户端返回对象令牌。在一些实施例中，若对象授权码验证不通过，则业务节点可以拒绝令牌获取请求，无需向应用客户端返回对象令牌。
可以理解的是，对象授权码可以用于表征与目标对象相对应的授权信息，即业务节点可以获取目标对象在对象登录服务中选择的授权信息，基于该授权信息生成针对目标对象的对象授权码。其中，授权信息为目标对象的关键授权信息，包括时效信息、操作权限和授权范围中的至少一个；时效信息用于表征对象令牌的生命周期。因此，业务节点可以对对象授权码进行解析，得到与目标对象相关联的关键授权信息。
在一些实施例中，对象授权码还可以无需表征与目标对象相关联的关键授权信息，通过对象授权码可以获取与目标对象相关联的关键授权信息，即业务节点可以获取目标对象在对象登录服务中选择的关键授权信息。其中，关键授权信息包括时效信息、操作权限和授权范围中的至少一个；时效信息用于表征对象令牌的生命周期。因此，业务节点可以通过令牌发放服务从对象登录服务中获取与目标对象相关联的关键授权信息。
可以理解的是，对象令牌可以为应用客户端提供针对授权范围内的资源数据的操作权限，即对象令牌可以具有操作权限和授权范围，此外，对象令牌还可以具有时效信息。其中，资源数据还可以称之为对象资源信息。
其中，时效信息、操作权限和授权范围可以是由目标对象在对象登录服务的对象登录前端中所选择的；在一些实施例中，时效信息、操作权限和授权范围也可以是业务节点默认设置的。目标对象可以在对象登录前端中选择时效信息、操作权限和授权范围中的任意一个或多个，也可以无需选择时效信息、操作权限和授权范围。
其中，操作权限是指应用客户端具有通过业务节点操作资源数据的权限，目标对象针对资源数据的操作权限可以为读取权限、写入权限、读写权限、删除权限、修改权限、读取删除权限等，例如，读取权限表示目标对象可以针对资源数据进行读取操作；授权范围可以表示目标对象具有操作权限的资源数据，本申请实施例不对授权范围所包含的数据类型进行限定；时效信息用于表征对象令牌的生命周期，例如，对象令牌的生命周期可以为1天。
在本申请实施例中，区块链网络中的业务节点可以在从区块链网络的共识节点中所获取对象凭证信息之后，接收目标对象通过应用客户端发送的授权请求，通过对象登录服务获取目标对象输入的待验证登录信息，进而将待验证登录信息与对象凭证信息进行匹配，若待验证登录信息与对象凭证信息相匹配，则获取针对目标对象的对象授权码，向应用客户端返回对象授权码。进一步地，业务节点可以接收应用客户端基于对象授权码发送的令牌获取请求，通过令牌发放服务获取针对目标对象的对象令牌，向应用客户端返回对象令牌。由此可见，区块链网络中的业务节点可以作为身份管理系统中的授权服务器，授权服务器可以从区块链网络的共识节点中获取分布式存储的对象凭证信息，基于对象凭证信息响应应用客户端所发送的授权请求和令牌获取请求(授权请求和令牌获取请求可以统称为登录请求)。由于区块链网络去中心化和自校验的特点，业务节点是可以部署多份的，多个应用客户端可以分别向不同的业务节点发送登录请求，因此，在多个应用客户端同时发送登录请求时，多个业务节点可以分别同时响应多个登录请求，从而提高目标对象登录应用客户端的效率。此外，由于业务节点的数量不止一个，在其中一个业务节点发生故障时，其他业务节点同样可以进行登录管理，不会对登录操作的业务逻辑产生影响，从而可以提高目标对象登录应用客户端的稳定性。与此同时，业务节点可以基于对象令牌为应用客户端提供针对授权范围内的资源数据的操作权限，该操作权限使得应用客户端可以通过业务节点操作资源数据，因此，业务节点可以通过对象令牌确保应用客户端获取操作权限的同时，随时对对象令牌进行控制，确保应用客户端的针对资源数据的操作不会危害身份管理系统中的资源数据的安全性。
可以理解的是，在本申请中，涉及到授权范围所包含的数据类型等相关的数据，当本申请以上实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守所在国家相关法律法规和国家标准。
可以理解的是，第三方应用在接收到业务节点返回的对象令牌时，可以表示第三方应用调用业务节点完成链上管理的对象登录，获取对象凭证信息所指示的对象身份。其中，第三方应用在获得对象凭证信息所指示的对象身份后，可以在后续步骤中进行自己的业务，第三方应用自己的业务表示的是第三方应用所具有的固有功能，例如，通过对象凭证信息所指示的对象身份实现即时通讯功能。此外，对象令牌表示资源拥有者授权第三方应用访问其存储在授权服务器上的资源数据，而不需要将账号和密码提供给第三方应用。
为便于理解，请参见图4，图4是本申请实施例提供的一种申请资源的流程示意图。如图4所示的流程示意图是一个线性的流程，步骤S41-步骤S46可以线性执行，步骤S41对应于步骤S101，步骤S42对应于步骤S102，步骤S43-步骤S44对应于步骤S103。
如图4所示，第三方应用(即client)可以执行步骤S41，通过步骤S41向资源拥有者(即资源持有者，Resource Owner)请求获取资源(即目标对象通过应用客户端(即第三方应用)发送授权请求，Authorization Request)。其中，资源拥有者可以表示对象凭证信息所指示的对象，这里的资源拥有者可以表示待验证登录信息所指示的目标对象。进一步地，资源拥有者可以将待验证登录信息与对象凭证信息进行匹配，若待验证登录信息与对象凭证信息相匹配，则执行步骤S42，通过步骤S42授权给予第三方应用一个许可(即授权码，Authorization Grant)。其中，授权码还可以称之为对象授权码，对象授权码用于辨别目标对象的身份。
如图4所示，第三方应用可以执行步骤S43，通过步骤S43将该许可(即对象授权码)给予授权服务器(即认证服务器，Authorization Server)进行认证(即目标对象通过应用客户端发送令牌获取请求)。其中，这里的授权服务器可以为本申请实施例中的业务节点。进一步地，若认证成功，则授权服务器可以执行步骤S44，通过步骤S44向第三方应用返回一个令牌(即Access Token)。其中，令牌还可以称之为对象令牌。
为便于理解，请参见图5，图5是本申请实施例提供的一种申请资源的场景示意图。如图5所示的申请授权码对应于上述图4所对应实施例中的步骤S41，如图5所示的返回授权码对应于上述图4所对应实施例中的步骤S42，如图5所示的申请令牌对应于上述图4所对应实施例中的步骤S43，如图5所示的返回令牌对应于上述图4所对应实施例中的步骤S44。
如图5所示，区块链网络的共识节点中可以存储有权限校验合约，权限校验合约可以为部署在共识节点上的智能合约。区块链网络中的业务节点可以通过核心网络入口(即代理节点)从区块链网络的共识节点中获取权限校验本地合约(即对象管理合约)和对象管理信息，进而将对象管理信息存储至对象登录凭证数据库(即对象信息数据库)。其中，权限校验本地合约可以包括但不限于上述登录判断合约、授权码验证合约和令牌验证合约，对象管理信息可以包括对象凭证信息和对象资源信息。
如图5所示，第三方应用可以向业务节点申请授权码(即发送授权请求)，这样，业务节点可以通过对象登录服务响应该授权请求，通过对象登录服务调用登录判断合约，通过登录判断合约和对象登录凭证数据库中的对象管理信息，向第三方应用返回授权码(即返回对象授权码)。
如图5所示，第三方应用可以向业务节点申请令牌(即发送令牌获取请求)，这样，业务节点可以通过令牌发放服务响应该令牌获取请求，通过令牌发放服务调用授权码验证合约，通过授权码验证合约和对象登录凭证数据库中的对象管理信息，向第三方应用返回令牌(即返回对象令牌)。
其中，区块链网络中可以包括多个共识节点，本申请实施例不对这里的共识节点的数量进行限定；区块链网络中可以包括多个业务节点，本申请实施例不对这里的业务节点的数量进行限定。由于业务节点和共识节点是部署多个的，同一个业务节点可以向不同的共识节点发送数据同步请求，不同的应用客户端可以向不同的业务节点发送登录请求(即授权请求和令牌获取请求)。
例如，在第三方应用的数量为两个时，两个第三方应用具体可以为第三方应用X1和第三方应用X2，多个业务节点具体可以包括业务节点J1和业务节点J2。这样，第三方应用X1可以向业务节点J1发送登录请求，第三方应用X2可以向业务节点J2发送登录请求；在一些实施例中，第三方应用X1可以向业务节点J2发送登录请求，第三方应用X2可以向业务节点J1发送登录请求。
可以理解的是，业务节点在接收到应用客户端发送的授权请求和令牌获取请求时，可以生成与区块链无关的本地信息，进而将本地信息存储至对象信息数据库中。其中，本地信息可以表示业务节点作为授权服务器时所生成的信息，例如，本地信息可以为应用客户端的登录时间(即业务节点获取目标对象在对象登录服务中输入的待验证登录信息的时间)。
由此可见，区块链网络中的业务节点可以作为身份管理系统中的授权服务器，授权服务器可以从区块链网络的共识节点中获取分布式存储的对象凭证信息，基于对象凭证信息响应应用客户端所发送的授权请求和令牌获取请求(授权请求和令牌获取请求可以统称为登录请求)。由于区块链网络去中心化和自校验的特点，业务节点是可以部署多份的，多个应用客户端可以分别向不同的业务节点发送登录请求，因此，在多个应用客户端同时发送登录请求时，多个业务节点可以分别同时响应多个登录请求，从而提高目标对象登录应用客户端的效率。此外，由于业务节点的数量不止一个，在其中一个业务节点发生故障时，其他业务节点同样可以进行登录管理，不会对登录操作的业务逻辑产生影响，从而可以提高目标对象登录应用客户端的稳定性。与此同时，业务节点可以基于对象令牌为应用客户端提供针对授权范围内的资源数据的操作权限，该操作权限使得应用客户端可以通过业务节点操作资源数据，因此，业务节点可以通过对象令牌确保应用客户端获取操作权限的同时，随时对对象令牌进行控制，确保应用客户端的针对资源数据的操作不会危害身份管理系统中的资源 数据的安全性。
进一步地，请参见图6，图6是本申请实施例提供的一种数据处理方法的流程示意图。该方法可以由区块链网络中的业务节点执行，该业务节点可以为接入至业务网络中的服务器，也可以为接入至业务网络中的终端设备，这里不对业务节点的具体形式进行限定。该业务节点用于提供对象登录服务、令牌发放服务和对象信息操作服务，该业务节点可以为上述图1所示的业务网络100a中的任意一个节点，例如，节点110a。其中，该数据处理方法可以包括以下步骤：
步骤S201，接收目标对象通过应用客户端发送的授权请求，基于授权请求调用对象登录服务，获取目标对象在对象登录服务中输入的待验证登录信息；
其中，业务节点获取目标对象在对象登录服务中输入的待验证登录信息的具体过程，可以参见上述图3所对应实施例中对步骤S101的描述，这里将不再进行赘述。
其中，应用客户端可以通过业务节点的节点公钥对授权请求进行加密处理，得到加密授权请求，将加密授权请求发送至业务节点。这样，业务节点可以接收应用客户端发送的加密授权请求，通过业务节点的节点私钥对加密授权请求进行解密处理，得到授权请求。
步骤S202，通过对象登录服务将待验证登录信息与对象凭证信息进行匹配，若待验证登录信息与对象凭证信息相匹配，则获取针对目标对象的对象授权码，向应用客户端返回对象授权码；
其中，业务节点获取针对目标对象的对象授权码的具体过程，可以参见上述图3所对应实施例中对步骤S102的描述，这里将不再进行赘述。
其中，业务节点可以通过业务节点的节点私钥对对象授权码进行加密处理，得到加密对象授权码，将加密对象授权码返回至应用客户端。这样，应用客户端可以接收业务节点返回的加密对象授权码，通过业务节点的节点公钥对加密对象授权码进行解密处理，得到对象授权码。
步骤S203，接收应用客户端基于对象授权码发送的令牌获取请求，基于令牌获取请求调用令牌发放服务，通过令牌发放服务获取针对目标对象的对象令牌，向应用客户端返回对象令牌；
其中，业务节点获取针对目标对象的对象令牌的具体过程，可以参见上述图3所对应实施例中对步骤S103的描述，这里将不再进行赘述。
其中，业务节点接收令牌获取请求的具体过程，可以参见上述接收授权请求的描述，这里将不再进行赘述；业务节点返回对象令牌的具体过程，可以参见上述返回对象授权码的描述，这里将不再进行赘述。
应当理解，不同的应用客户端可以向不同的业务节点发送授权请求和令牌获取请求。其中，应用客户端可以根据与业务节点之间的距离，从多个业务节点中确定用于发送授权请求和令牌获取请求的目标业务节点，例如，应用客户端可以将多个业务节点中的距离最近的业务节点作为目标业务节点。在一些实施例中，应用客户端还可以根据节点调度算法，从多个业务节点中确定用于发送授权请求和令牌获取请求的目标业务节点，例如，应用客户端可以在需要发送授权请求和令牌获取请求时，向用于进行节点调度的调度服务器发送节点调度请求，以使调度服务根据多个业务节点的实时网络质量等因素，为应用客户端实现目标业务节点的调度，从而提高业务节点的调度准确性。
因此，业务节点可以存储与所有对象相关联的对象管理信息，在一些实施例中，业务节点也可以无需存储与所有对象相关联的对象管理信息。同理，业务节点可以同时存储与目标对象相关联的对象凭证信息和对象资源信息，在一些实施例中，业务节点也可以存储与目标对象相关联的对象凭证信息或对象资源信息。同理，业务节点可以存储与目标对象相关联的全部对象资源信息，在一些实施例中，业务节点也可以存储与目标对象相关联的部分对象资源信息。
步骤S204，接收应用客户端基于对象令牌发送的资源操作请求，基于资源操作请求调用对象信息操作服务；
可以理解的是，本申请所使用的基于对象令牌发送资源操作请求的方式使用的是OAuth 2.0授权机制，该授权机制可以用于授权第三方应用(即应用客户端)对资源数据进行操作。资源数据的资源拥有者(即目标对象)告诉业务节点，同意授权第三方应用进入系统，获取该目标对象对应的资源数据，业务节点从而产生一个使得第三方应用可以进入业务节点的对象令牌，通过该对象令牌来代替密码供第三方应用使用。
其中，对象令牌与密码的作用是一样的，都可以进入系统，但是有三点差异：(1)对象令牌是短期的，在对象令牌的生命周期到期之后，对象令牌会自动失效，目标对象无法修改对象令牌的时效信息；密码一般长期有效，如果目标对象不修改密码，那么密码就不会发生变化。(2)对象令牌可以随时被资源拥有者撤销，若对象令牌被资源拥有者撤销，则对象令牌会立即失效；密码一般不允许被他人撤销。(3)对象令牌有操作权限，对于网络服务来说，只读令牌(即具有读取权限的对 象令牌)就比读写令牌(即具有读写权限的对象令牌)更安全，比如，读取权限使得第三方应用可以读取资源数据、而不可以写入资源数据；密码一般是完整权限(即密码)。(4)对象令牌由授权范围，对象令牌具有授权范围所包含的数据类型的操作权限；密码具有所有的数据类型的操作权限。
应当理解，第三方应用可以通过对象令牌登录业务节点所指示的业务系统(即基于对象令牌向业务节点发送的资源操作请求)。业务系统一般不会再次确认第三方应用的身份，所以第三方应用必须对对象令牌进行保密，泄漏对象令牌与泄漏密码的后果是一样的。因此，为保证业务系统中的资源数据的安全性，业务节点可以将对象令牌的时效信息设置为较短时间，例如，1小时。
可以理解的是，资源操作请求还携带有目标对象的对象标识，目标对象的对象标识使得目标对象可以操作自身对应的资源数据，而不可以操作其他对象对应的资源数据。
步骤S205，通过对象信息操作服务调用令牌验证合约，通过令牌验证合约对资源操作请求和对象令牌进行验证；
具体的，业务节点可以通过令牌验证合约获取与对象令牌相关联的关键授权信息，确定资源操作请求是否满足关键授权信息。进一步地，若资源操作请求满足关键授权信息，则业务节点可以确定资源操作请求和对象令牌验证通过。在一些实施例中，若资源操作请求不满足关键授权信息，则业务节点可以确定资源操作请求和对象令牌验证不通过。
可以理解的是，令牌验证合约可以确定资源操作请求是否满足时效信息、操作权限和授权范围，若资源操作请求均满足时效信息、操作权限和授权范围，则业务节点可以确定资源操作请求满足关键授权信息。在一些实施例中，若资源操作请求不满足时效信息、操作权限或授权范围，则业务节点可以确定资源操作请求不满足关键授权信息。比如，若资源操作请求为资源读取操作请求，操作权限为写入权限，则业务节点可以确定资源操作请求不满足操作权限；又比如，若资源操作请求对应的请求时间超出对象令牌的生命周期，则业务节点可以确定资源操作请求不满足时效信息；又比如，若资源操作请求所请求操作的数据类型与授权范围所包含的数据类型不同，则业务节点可以确定资源操作请求不满足授权范围。
应当理解，业务节点可以在接收应用客户端发送的资源操作请求时，通过对象信息操作服务在对象信息数据库中查询目标对象的对象状态，若目标对象的对象状态为冻结状态，则拒绝资源操作请求。在一些实施例中，若目标对象的对象状态为非冻结状态，则业务节点可以基于资源操作请求和对象令牌的验证结果执行步骤S206或步骤S207。
其中，在资源操作请求和对象令牌验证通过或验证不通过时，业务节点可以执行不同的步骤，若资源操作请求和对象令牌验证通过，则业务节点可以执行步骤S206；在一些实施例中，若资源操作请求和对象令牌验证不通过，则业务节点可以执行步骤S207。
步骤S206，若资源操作请求和对象令牌验证通过，则通过对象信息操作服务响应资源操作请求；
应当理解，若资源操作请求为资源读取操作请求，则业务节点可以通过对象信息操作服务从对象信息数据库中获取资源读取操作请求所请求读取的目标读取数据。其中，目标读取数据属于资源数据。进一步地，业务节点可以将目标读取数据返回应用客户端。
其中，可以理解的是，若对象信息数据库中存在资源读取操作请求所请求读取的目标读取数据，则业务节点可以通过对象信息操作服务从对象信息数据库中获取目标读取数据。在一些实施例中，若对象信息数据库中不存在目标读取数据，则通过对象信息操作服务向共识节点发送针对目标读取数据的数据同步请求，基于针对目标读取数据的数据同步请求从共识节点的已上链数据中获取同步数据，将同步数据存储至对象信息数据库，通过对象信息操作服务从对象信息数据库中获取目标读取数据。其中，同步数据包括目标读取数据。
在一些实施例中，应当理解，若资源操作请求为资源写入操作请求，则业务节点可以通过对象信息操作服务获取资源写入操作请求所请求写入的目标写入数据。其中，目标写入数据属于资源数据。进一步地，若对象信息数据库中不存在目标写入数据，则业务节点可以将目标写入数据写入至对象信息数据库。在一些实施例中，若对象数据库中存在目标写入数据，则业务节点可以无需响应资源接入操作请求。
其中，可以理解的是，若对象信息数据库中不存在目标写入数据，则业务节点可以将目标写入数据转发至共识节点，以使共识节点对目标写入数据进行打包处理，生成目标区块(即第一目标区块)，对目标区块进行上链处理。进一步地，业务节点可以向共识节点发送针对目标写入数据的数据同步请求，接收共识节点基于针对目标写入数据的数据同步请求所返回的目标写入数据，将目标写入数据写入至对象信息数据库。其中，目标写入数据是由共识节点从目标区块中获取到的。
在一些实施例中，应当理解，若资源操作请求为资源更新操作请求，则业务节点可以通过对象信息操作服务获取资源更新操作请求所请求更新的初始更新数据。进一步地，若对象信息数据库中存在初始更新数据，则业务节点可以通过资源更新操作请求中的目标更新数据更新初始更新数据。在一些实施例中，若对象信息数据库中不存在初始更新数据，则业务节点可以将资源更新操作请求中的目标更新数据写入至对象信息数据库。在一些实施例中，若对象信息数据库中不存在初始更新数据，则业务节点可以无需响应资源更新操作请求。其中，初始更新数据和目标更新数据均属于资源数据。
其中，可以理解的是，若对象信息数据库中存在初始更新数据，则业务节点可以将资源更新操作请求中的目标更新数据转发至共识节点，以使共识节点对目标更新数据进行打包处理，生成目标区块(即第二目标区块)，对目标区块进行上链处理。进一步地，业务节点可以向共识节点发送针对目标更新数据的数据同步请求，接收共识节点基于针对目标更新数据的数据同步请求所返回的目标更新数据，通过目标更新数据更新对象信息数据库中的初始更新数据。其中，目标更新数据是由共识节点从目标区块中获取到的。
其中，业务节点将资源更新操作请求中的目标更新数据写入至对象信息数据库的具体过程，可以参见上述将资源写入操作请求中的目标写入数据写入至对象信息数据库的描述，这里将不再进行赘述。
在一些实施例中，应当理解，若资源操作请求为资源删除操作请求，则业务节点可以通过对象信息操作服务获取资源删除操作请求所请求删除的目标删除数据。其中，目标删除数据属于资源数据。进一步地，若对象信息数据库中存在目标删除数据，则业务节点可以从对象信息数据库中删除目标删除数据。在一些实施例中，若对象信息数据库中不存在目标删除数据，则业务节点可以无需响应资源删除操作请求。
其中，可以理解的是，若对象信息数据库中存在目标删除数据，则业务节点可以通过合约中的删除函数来删除该目标删除数据，若通过合约中的删除函数执行成功(即说明共识节点认可此次删除该目标删除数据的合约任务)，则接收共识节点返回的删除指令，基于该删除指令从对象信息数据库中删除目标删除数据。
其中，业务节点接收资源操作请求的具体过程，可以参见上述接收授权请求的描述，这里将不再进行赘述；其中，资源操作请求中可以包括目标写入数据、目标删除数据或目标更新数据。其中，业务节点返回目标读取数据的具体过程，可以参见上述返回对象授权码的描述，这里将不再进行赘述。
应当理解，从共识节点的已上链数据中获取的目标读取数据、从第一目标区块中获取的目标写入数据、以及从第二目标区块中获取的目标更新数据，均可以称之为业务节点从共识节点上获取的同步数据。
其中，可以理解的是，目标读取数据可以为业务节点从共识节点所存储的第三目标区块中获取的，第一目标区块、第二目标区块和第三目标区块的数量可以为一个或多个，即业务节点可以从一个或多个第一目标区块中获取目标写入数据，业务节点可以从一个或多个第二目标区块中获取目标更新数据，业务节点可以从一个或多个第三目标区块中获取目标读取数据。换言之，目标写入数据、目标更新数据和目标读取数据均可以被分别打包至一个或多个目标区块中。
为便于理解，本申请实施例以目标写入数据、目标更新数据和目标读取数据均被分别打包至一个目标区块为例进行说明，这里以目标写入数据被打包至目标区块Q为例进行说明。目标区块Q的区块信息中可以包括区块头(即区块头信息)和区块体(即区块主体、区块体信息)。其中，区块头可以包括目标区块Q的父区块哈希值(即父区块哈希)、区块高度、版本号、时间戳、难度值、随机数以及默克尔树根(即区块哈希、区块哈希值)等信息，区块体可以包括打包至目标区块Q的交易数据以及由交易数据的交易哈希值所构成的默克尔路径。
为便于理解，这里以打包至目标区块Q中的交易数据的数量为4个为例进行说明，这里的4个交易数据可以为交易数据1、交易数据2、交易数据3和交易数据4。其中，对这4个交易数据进行交易哈希转换可以得到交易数据对应的交易哈希值，例如，交易数据1的交易哈希值可以为交易哈希值1(例如，Hash1)，交易数据2的交易哈希值可以为交易哈希值2(例如，Hash2)，交易数据3的交易哈希值可以为交易哈希值3(例如，Hash3)，交易数据4的交易哈希值可以为交易哈希值4(例如，Hash4)。例如，目标写入数据可以为目标区块Q中的交易数据3和交易数据4。
可以理解的是，共识节点可以获取目标写入数据对应的默克尔证明信息，这里的默克尔证明信息可以由默克尔路径中的交易哈希值构成，例如，这里可以由Hash12(即基于Hash1和Hash2所 生成的哈希值，表示对Hash1和Hash2的拼接结果进行哈希后所得到的哈希值)和Hash1234(即基于Hash12和Hash34所生成的哈希值，Hash34即基于Hash3和Hash4所生成的哈希值)作为路径哈希值，以根据路径哈希值构成默克尔证明信息。进一步地，共识节点可以将上述目标写入数据、默克尔证明信息和目标区块Q的区块头作为返回给业务节点的同步数据。
应当理解，业务节点在接收到同步数据之后，可以基于目标写入数据、默克尔证明信息和目标区块Q的区块头对同步数据进行验证。具体的，业务节点可以基于目标写入数据对应的交易哈希值以及默克尔证明信息中的路径哈希值，确定目标区块Q对应的待比较树根。进一步地，业务节点可以基于待比较树根和目标区块Q的区块头中的默克尔树根，得到目标区块Q的验证结果。其中，若待比较树根与默克尔树根相同，则验证结果指示验证成功。进一步地，若验证结果指示验证成功，则业务节点可以将目标区块Q的区块头同步至业务节点的区块头链，且将目标写入数据写入至对象信息数据库。
步骤S207，若资源操作请求和对象令牌验证不通过，则通过对象信息操作服务拒绝资源操作请求。
请再参见图4，如图4所示，第三方应用可以执行步骤S45，通过步骤S45使用令牌(即对象令牌)到资源服务器(即Resource Server)处获取该令牌对应的资源数据(即保护资源，Protected Resource)(即目标对象通过应用客户端发送资源操作请求)。其中，这里的资源服务器可以为本申请实施例中的业务节点。进一步地，资源服务器可以执行步骤S46，通过步骤S46向第三方应用返回保护资源(例如，目标读取信息)。其中，资源数据为资源拥有者自身的资源，资源拥有者不可以获取其他对象的资源数据。
应当理解，本申请实施例可以通过业务节点作为授权服务器和资源服务器，业务节点在接收授权请求和令牌获取请求时，业务节点可以作为授权服务器，业务节点在接收资源操作请求时，业务节点可以作为资源服务器。应当理解，第三方应用所对应的授权服务器和资源服务器可以是相同的，即第三方应用可以向同一个业务节点发送授权请求、令牌获取请求和资源操作请求；在一些实施例中，第三方应用所对应的授权服务器和资源服务器可以是相同的，即第三方应用可以向不同的业务节点发送授权请求、令牌获取请求和资源操作请求。
请再参见图5，如图5所示的申请资源对应于上述图4所对应实施例中的步骤S45，如图5所示的返回资源对应于上述图4所对应实施例中的步骤S46。如图5所示，第三方应用可以向业务节点申请资源(即发送资源操作请求)，这样，业务节点可以通过用户信息读取服务(即对象信息操作服务)响应该资源操作请求，通过用户信息读取服务调用令牌验证合约，通过令牌验证合约和对象登录凭证数据库中的对象管理信息，向第三方应用返回资源(例如，返回目标读取信息)。
其中，在资源操作请求为资源读取操作请求时，业务节点需要向第三方应用返回资源，在资源操作请求为资源写入操作请求、资源更新操作请求和资源删除操作请求时，业务节点无需向第三方应用返回资源。
为便于理解，请参见图7，图7是本申请实施例提供的一种区块链电子票据场景下的系统架构图。如图7所示，本申请实施例中的业务层、路由代理层以及核心共识网络层组成了整个完整区块链业务体系，其中，路由代理层起到对于业务层和核心共识网络层的隔离作用。为便于理解，本申请实施例中的交易业务可以以电子票据转移业务为例，在此不做限定。
可以理解的是，当区块链被用于税务系统或者其他场景中时，为了提高数据的保密性和安全性，在区块链体系中涉及个人隐私或者团队安全等相关数据时，可以采用本申请实施例中的“业务网络—核心共识网络”这一分层区块链结构。区块链网络可以为电子票据的整个流转过程中产生的交易信息进行记录，电子票据的流转过程可以包括电子票据的申领、电子票据的开具、电子票据的报销、电子票据的报税等过程。
其中，业务层处于见证网络中，可以向核心共识网络层提交业务操作交互，该业务层中的业务节点(例如，第一业务节点)可以包括电子税局对应的终端设备、企业对应的终端设备以及消费用户(即消费者)对应的终端设备。其中，电子税局可以是指税局专网中的地方税局，企业可以为公有云中的开票服务商、报销服务商或零售企业(例如，KA企业，即大型零售客户和重点零售客户企业)等，消费用户可以为私有云中的支付服务商、流转服务商或零售企业等。
例如，第一业务节点(例如，消费用户对应的终端设备A)所执行的票据转移业务可以为：将消费用户在购买器材时所获得的电子票据(例如，电子票据X)转移至该消费用户所在企业对应的终端设备B。当然，该业务层中还可以包括第二业务节点。例如，两个公司的两个开票员(例如，员工1和员工2)，在各自的终端设备上开票产生了一些交易数据。例如，员工1可以使用终端设 备A1执行交易业务，以生成对应的交易数据，员工2可以使用终端设备A2执行交易业务，以生成对应交易数据。
其中，路由代理层中的代理节点可以用于对业务层和核心共识网络层进行网络隔离，代理节点可以具有点对点服务(即P2P服务)、路由服务、证书缓存、认证服务。可以理解的是，点对点服务是指在P2P网络中的服务，基于一类特定的网络协议，P2P网络中的网络节点之间不需要一个中心节点来维护网络状态，而是每个节点通过和相邻节点的广播交互来维护全网的节点状态或者是其相邻节点连接状态。路由服务是节点具有的基本功能，可以用于节点之间的通信。证书缓存中的证书，可以指公钥证书体系(Public Key Infrastructure，简称PKI)，在证书体系中，证书是一个公钥拥有者的身份证明，由权威机构进行颁发(Certificate Authority，CA)。基于公钥证书体系可以实现非对称加密和对于信息的数字签名。这里的公钥证书体系可以包括公私钥密码，x509证书，CA证书签发中心等等。认证服务可以用于验证接收到的信息的交易格式、节点合法性等。
可以理解的是，在本申请实施例中，该代理节点可以将业务层中的业务节点(即目标业务节点)所发送的数据同步请求转发至核心共识网络层中的共识节点(即目标共识节点)，还可以将核心共识网络层中的共识节点所返回的同步数据转发至业务层中的业务节点。其中，在转发过程中，该代理节点可以对转发的数据进行加密处理。
可以理解的是，核心共识网络层中可以包括多个核心链，每个核心链可以包括一个或多个共识节点，为便于理解，本申请实施例以核心共识网络层包括图7所示的一个核心链为例进行说明。其中，核心共识网络层中的共识节点(即记账节点)可以为税务专网中的可信节点(即TrustSQL节点)。其中，共识节点可以包括权限合约、高速缓存(即缓存)和数据区块(即区块)，权限合约存储了关于电子票据的整个生命周期的流转逻辑，比如，电子票据的票据状态、流转流程、数据的访问权限、电子票据申领条件、电子票据开具条件等，高速缓存和数据区块可以为交易信息的上链与查询提供支持。
可以理解的是，每个共识节点均具有打包出块的能力，即可以对代理节点所转发的交易数据进行验证，并在验证成功时添加至共识节点的交易池(即图7所示的缓存)中。进一步地，该共识节点可以对自己交易池中的交易数据进行打包出块，以成功写入核心共识网络层中的区块链中。此外，共识节点在接收到由代理节点转发的数据同步请求时，可以在区块链上确定用于返回给业务节点的同步数据。
由此可见，本申请实施例提出了一种基于区块链的分布式身份管理系统，身份管理系统可以扩展区块链网络中的业务节点的功能，业务节点可以基于从区块链上获取的对象凭证信息和对象资源信息，代表区块链作为分布式对象管理的授权服务器和资源服务器，实现了分布式的对象登录服务、令牌发放服务和对象信息操作服务，去除了中心化身份管理带来的不可信问题，提高目标对象登录应用客户端的效率和稳定性，且提高目标对象通过应用客户端操作资源数据的效率和稳定性。在业务节点作为授权服务器时，业务节点可以接收应用客户端发送的授权请求和令牌获取请求，向应用客户端返回针对目标对象的对象授权码和对象令牌；在业务节点作为资源服务器时，业务节点可以接收应用客户端发送的资源操作请求，响应该资源操作请求。可以理解的是，本申请实施例可以实现对象凭证信息和对象资源信息的链上管理，通过业务节点对链上数据进行同步和校验，保证从链上同步的对象凭证信息和对象资源信息的实时性、准确性和不可篡改性，从而保证对象管理信息的安全性。
进一步地，请参见图8，图8是本申请实施例提供的一种数据处理装置的结构示意图。该数据处理装置1可以是运行于计算机设备中的一个计算机程序(包括程序代码)，例如，该数据处理装置1为一个应用软件；该数据处理装置1可以用于执行本申请实施例提供的方法中的相应步骤。如图8所示，该数据处理装置1可以应用于区块链网络中的业务节点，该业务节点用于提供对象登录服务和令牌发放服务，该业务节点可以为上述图2所对应实施例中的业务节点20a。该数据处理装置1可以包括：第一接收模块11，授权码返回模块12，第二接收模块13；进一步地，该数据处理装置1还可以包括：第三接收模块14，第一响应模块15，第二响应模块16；
第一接收模块11，用于接收目标对象通过应用客户端发送的授权请求，基于授权请求调用对象登录服务，获取目标对象在对象登录服务中输入的待验证登录信息；
授权码返回模块12，用于通过对象登录服务将待验证登录信息与对象凭证信息进行匹配，若待验证登录信息与对象凭证信息相匹配，则获取针对目标对象的对象授权码，向应用客户端返回对象授权码；对象凭证信息是由业务节点从区块链网络的共识节点中所获取到的；
其中，对象登录服务包括对象登录前端和对象登录后端；
第一接收模块11，具体用于接收目标对象通过应用客户端发送的授权请求，基于授权请求调用对象登录前端，获取目标对象在对象登录前端中输入的待验证登录信息；
则授权码返回模块12，具体用于通过对象登录后端调用登录判断合约，通过登录判断合约将待验证登录信息与对象凭证信息进行匹配；登录判断合约是由业务节点从共识节点中所获取到的。
其中，待验证登录信息包括待验证对象标识和待验证对象密码；
授权码返回模块12，具体用于通过登录判断合约从对象信息数据库中获取对象凭证信息；对象凭证信息是由业务节点从共识节点的已上链数据中同步得到的；对象凭证信息包括对象标识凭证信息；
授权码返回模块12，具体用于在对象标识凭证信息中查找待验证对象标识，若对象标识凭证信息中不存在待验证对象标识，则确定待验证登录信息与对象凭证信息不匹配；
授权码返回模块12，具体用于若对象标识凭证信息中存在待验证对象标识，则基于待验证对象密码，确定待验证登录信息与对象凭证信息之间的匹配结果。
其中，对象凭证信息还包括对象密码凭证信息和字符串凭证信息；一个对象标识凭证信息对应一个对象密码凭证信息和一个字符串凭证信息；
授权码返回模块12，具体用于对待验证对象密码和待验证对象标识在对象凭证信息中对应的字符串凭证信息进行拼接，得到待验证拼接登录信息；
授权码返回模块12，具体用于对待验证拼接登录信息进行哈希计算，得到待验证哈希登录信息；
授权码返回模块12，具体用于将待验证哈希登录信息与待验证对象标识在对象凭证信息中对应的对象密码凭证信息进行比较，若待验证哈希登录信息与待验证对象标识在对象凭证信息中对应的对象密码凭证信息相同，则生成用于表征待验证登录信息与对象凭证信息相匹配的匹配结果；
授权码返回模块12，具体用于若待验证哈希登录信息与待验证对象标识在对象凭证信息中对应的对象密码凭证信息不同，则生成用于表征待验证登录信息与对象凭证信息不匹配的匹配结果。
第二接收模块13，用于接收应用客户端基于对象授权码发送的令牌获取请求，基于令牌获取请求调用令牌发放服务，通过令牌发放服务获取针对目标对象的对象令牌，向应用客户端返回对象令牌；对象令牌为应用客户端提供针对授权范围内的资源数据的操作权限；操作权限是指应用客户端具有通过业务节点操作资源数据的权限。
其中，第二接收模块13包括：授权码验证单元131，令牌返回单元132；
授权码验证单元131，用于通过令牌发放服务调用授权码验证合约，通过授权码验证合约对对象授权码进行验证；授权码验证合约是由业务节点从共识节点中所获取到的；
令牌返回单元132，用于若对象授权码验证通过，则获取与目标对象相关联的关键授权信息，基于关键授权信息生成针对目标对象的对象令牌，向应用客户端返回对象令牌。
其中，授权码返回模块12，具体用于获取目标对象在对象登录服务中选择的关键授权信息，基于关键授权信息生成针对目标对象的对象授权码；关键授权信息包括时效信息、操作权限和授权范围中的至少一个；时效信息用于表征对象令牌的生命周期；
则令牌返回单元132，具体用于对对象授权码进行解析，得到与目标对象相关联的关键授权信息。
其中，第二接收模块13，还具体用于获取目标对象在对象登录服务中选择的关键授权信息；关键授权信息包括时效信息、操作权限和授权范围中的至少一个；时效信息用于表征对象令牌的生命周期；
则令牌返回单元132，具体用于通过令牌发放服务从对象登录服务中获取与目标对象相关联的关键授权信息。
其中，授权码验证单元131和令牌返回单元132的具体实现方式，可以参见上述图3所对应实施例中对步骤S103的描述，这里将不再进行赘述。
在一些实施例中，业务节点还用于提供对象信息操作服务；
第三接收模块14，用于接收应用客户端基于对象令牌发送的资源操作请求，基于资源操作请求调用对象信息操作服务；
第一响应模块15，用于通过对象信息操作服务调用令牌验证合约，通过令牌验证合约对资源操作请求和对象令牌进行验证，若资源操作请求和对象令牌验证通过，则通过对象信息操作服务响应资源操作请求；
其中，第一响应模块15，具体用于通过令牌验证合约获取与对象令牌相关联的关键授权信息， 确定资源操作请求是否满足关键授权信息；
第一响应模块15，具体用于若资源操作请求满足关键授权信息，则确定资源操作请求和对象令牌验证通过；
第一响应模块15，具体用于若资源操作请求不满足关键授权信息，则确定资源操作请求和对象令牌验证不通过。
其中，第一响应模块15，具体用于若资源操作请求为资源读取操作请求，则通过对象信息操作服务从对象信息数据库中获取资源读取操作请求所请求读取的目标读取数据；目标读取数据属于资源数据；
第一响应模块15，具体用于将目标读取数据返回应用客户端。
其中，第一响应模块15，具体用于若对象信息数据库中存在资源读取操作请求所请求读取的目标读取数据，则通过对象信息操作服务从对象信息数据库中获取目标读取数据；
第一响应模块15，具体用于若对象信息数据库中不存在目标读取数据，则通过对象信息操作服务向共识节点发送针对目标读取数据的数据同步请求，基于针对目标读取数据的数据同步请求从共识节点的已上链数据中获取同步数据，将同步数据存储至对象信息数据库，通过对象信息操作服务从对象信息数据库中获取目标读取数据；同步数据包括目标读取数据。
其中，第一响应模块15，具体用于若资源操作请求为资源写入操作请求，则通过对象信息操作服务获取资源写入操作请求所请求写入的目标写入数据；目标写入数据属于资源数据；
第一响应模块15，具体用于若对象信息数据库中不存在目标写入数据，则将目标写入数据写入至对象信息数据库。
其中，第一响应模块15，具体用于若对象信息数据库中不存在目标写入数据，则将目标写入数据转发至共识节点，以使共识节点对目标写入数据进行打包处理，生成目标区块，对目标区块进行上链处理；
第一响应模块15，具体用于向共识节点发送针对目标写入数据的数据同步请求，接收共识节点基于针对目标写入数据的数据同步请求所返回的目标写入数据，将目标写入数据写入至对象信息数据库。
第二响应模块16，用于若资源操作请求和对象令牌验证不通过，则通过对象信息操作服务拒绝资源操作请求。
其中，第一接收模块11，授权码返回模块12和第二接收模块13的具体实现方式，可以参见上述图3所对应实施例中对步骤S101-步骤S103的描述，这里将不再进行赘述。其中，第三接收模块14，第一响应模块15和第二响应模块16的具体实现方式，可以参见上述图6所对应实施例中对步骤S204-步骤S207的描述，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
进一步地，请参见图9，图9是本申请实施例提供的一种计算机设备的结构示意图。如图9所示，该计算机设备1000可以包括：处理器1001，网络接口1004和存储器1005，此外，上述计算机设备1000还可以包括：用户接口1003，和至少一个通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。其中，在一些实施例中，用户接口1003可以包括显示屏(Display)、键盘(Keyboard)，用户接口1003还可以包括标准的有线接口、无线接口。在一些实施例中，网络接口1004可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。在一些实施例中，存储器1005还可以是至少一个位于远离前述处理器1001的存储装置。如图9所示，作为一种计算机可读存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及设备控制应用程序。
在如图9所示的计算机设备1000中，网络接口1004可提供网络通讯功能；而用户接口1003主要用于为用户提供输入的接口；而处理器1001可以用于调用存储器1005中存储的设备控制应用程序，以实现：
接收目标对象通过应用客户端发送的授权请求，基于授权请求调用对象登录服务，获取目标对象在对象登录服务中输入的待验证登录信息；
通过对象登录服务将待验证登录信息与对象凭证信息进行匹配，若待验证登录信息与对象凭证信息相匹配，则获取针对目标对象的对象授权码，向应用客户端返回对象授权码；对象凭证信息是由业务节点从区块链网络的共识节点中所获取到的；
接收应用客户端基于对象授权码发送的令牌获取请求，基于令牌获取请求调用令牌发放服务， 通过令牌发放服务获取针对目标对象的对象令牌，向应用客户端返回对象令牌；对象令牌为应用客户端提供针对授权范围内的资源数据的操作权限；操作权限是指应用客户端具有通过业务节点操作资源数据的权限。
应当理解，本申请实施例中所描述的计算机设备1000可执行前文图3和图6所对应实施例中对数据处理方法的描述，也可执行前文图8所对应实施例中对数据处理装置1的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
此外，这里需要指出的是：本申请实施例还提供了一种计算机可读存储介质，且计算机可读存储介质中存储有前文提及的数据处理装置1所执行的计算机程序，且计算机程序包括程序指令，当处理器执行程序指令时，能够执行前文图3和图6所对应实施例中对数据处理方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机可读存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。
此外，需要说明的是：本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或者计算机程序可以包括计算机指令，该计算机指令可以存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器可以执行该计算机指令，使得该计算机设备执行前文图3和图6所对应实施例中对数据处理方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机程序产品或者计算机程序实施例中未披露的技术细节，请参照本申请方法实施例的描述。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。
以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (20)

  1. 一种数据处理方法，所述方法由区块链网络中的业务节点执行，所述业务节点用于提供对象登录服务和令牌发放服务，包括：
    所述业务节点接收目标对象通过应用客户端发送的授权请求，基于所述授权请求调用所述对象登录服务，获取所述目标对象在所述对象登录服务中输入的待验证登录信息；
    通过所述对象登录服务将所述待验证登录信息与对象凭证信息进行匹配，若所述待验证登录信息与所述对象凭证信息相匹配，则获取针对所述目标对象的对象授权码，向所述应用客户端返回所述对象授权码；所述对象凭证信息是由所述业务节点从所述区块链网络的共识节点中所获取到的；
    接收所述应用客户端基于所述对象授权码发送的令牌获取请求，基于所述令牌获取请求调用所述令牌发放服务，通过所述令牌发放服务获取针对所述目标对象的对象令牌，向所述应用客户端返回所述对象令牌；所述对象令牌为所述应用客户端提供针对授权范围内的资源数据的操作权限；所述操作权限是指所述应用客户端具有通过所述业务节点操作所述资源数据的权限。
  2. 根据权利要求1所述的方法，其中，所述对象登录服务包括对象登录前端和对象登录后端；
    所述业务节点接收目标对象通过应用客户端发送的授权请求，基于所述授权请求调用所述对象登录服务，获取所述目标对象在所述对象登录服务中输入的待验证登录信息，包括：
    所述业务节点接收目标对象通过应用客户端发送的授权请求，基于所述授权请求调用所述对象登录前端，获取所述目标对象在所述对象登录前端中输入的待验证登录信息；
    所述通过所述对象登录服务将所述待验证登录信息与对象凭证信息进行匹配，包括：
    通过所述对象登录后端调用登录判断合约，通过所述登录判断合约将所述待验证登录信息与对象凭证信息进行匹配；所述登录判断合约是由所述业务节点从所述共识节点中所获取到的。
  3. 根据权利要求2所述的方法，其中，所述待验证登录信息包括待验证对象标识和待验证对象密码；
    所述通过所述登录判断合约将所述待验证登录信息与对象凭证信息进行匹配，包括：
    通过所述登录判断合约从对象信息数据库中获取对象凭证信息；所述对象凭证信息是由所述业务节点从所述共识节点的已上链数据中同步得到的；所述对象凭证信息包括对象标识凭证信息；
    在所述对象标识凭证信息中查找所述待验证对象标识，若所述对象标识凭证信息中不存在所述待验证对象标识，则确定所述待验证登录信息与所述对象凭证信息不匹配；
    若所述对象标识凭证信息中存在所述待验证对象标识，则基于所述待验证对象密码，确定所述待验证登录信息与所述对象凭证信息之间的匹配结果。
  4. 根据权利要求3所述的方法，其中，所述对象凭证信息还包括对象密码凭证信息和字符串凭证信息；一个对象标识凭证信息对应一个对象密码凭证信息和一个字符串凭证信息；
    所述基于所述待验证对象密码，确定所述待验证登录信息与所述对象凭证信息之间的匹配结果，包括：
    将所述待验证对象密码与所述待验证对象标识在所述对象凭证信息中对应的字符串凭证信息进行拼接，得到待验证拼接登录信息；
    对所述待验证拼接登录信息进行哈希计算，得到待验证哈希登录信息；
    将所述待验证哈希登录信息与所述待验证对象标识在所述对象凭证信息中对应的对象密码凭证信息进行比较，若所述待验证哈希登录信息与所述待验证对象标识在所述对象凭证信息中对应的对象密码凭证信息相同，则生成用于表征所述待验证登录信息与所述对象凭证信息相匹配的匹配结果；
    若所述待验证哈希登录信息与所述待验证对象标识在所述对象凭证信息中对应的对象密码凭证信息不同，则生成用于表征所述待验证登录信息与所述对象凭证信息不匹配的匹配结果。
  5. 根据权利要求1所述的方法，其中，所述通过所述令牌发放服务获取针对所述目标对象的对象令牌，向所述应用客户端返回所述对象令牌，包括：
    通过所述令牌发放服务调用授权码验证合约，通过所述授权码验证合约对所述对象授权码进行验证；所述授权码验证合约是由所述业务节点从所述共识节点中所获取到的；
    若所述对象授权码验证通过，则获取与所述目标对象相关联的授权信息，基于所述授权信息生成针对所述目标对象的对象令牌，向所述应用客户端返回所述对象令牌。
  6. 根据权利要求5所述的方法，其中，所述获取针对所述目标对象的对象授权码，包括：
    获取所述目标对象在所述对象登录服务中选择的授权信息，基于所述授权信息生成针对所述目标对象的对象授权码；所述授权信息包括时效信息、所述操作权限和所述授权范围中的至少一个；所述时效信息用于表征所述对象令牌的生命周期；
    则所述获取与所述目标对象相关联的授权信息，包括：
    对所述对象授权码进行解析，得到与所述目标对象相关联的授权信息。
  7. 根据权利要求5所述的方法，其中，所述方法还包括：
    获取所述目标对象在所述对象登录服务中选择的授权信息；所述授权信息包括时效信息、所述操作权限和所述授权范围中的至少一个；所述时效信息用于表征所述对象令牌的生命周期；
    所述获取与所述目标对象相关联的授权信息，包括：
    通过所述令牌发放服务从所述对象登录服务中获取与所述目标对象相关联的授权信息。
  8. 根据权利要求1所述的方法，其中，所述业务节点还用于提供对象信息操作服务；
    所述方法还包括：
    接收所述应用客户端基于所述对象令牌发送的资源操作请求，基于所述资源操作请求调用所述对象信息操作服务；
    通过所述对象信息操作服务调用令牌验证合约，通过所述令牌验证合约对所述资源操作请求和所述对象令牌进行验证，若所述资源操作请求和所述对象令牌验证通过，则通过所述对象信息操作服务响应所述资源操作请求；
    若所述资源操作请求和所述对象令牌验证不通过，则通过所述对象信息操作服务拒绝所述资源操作请求。
  9. 根据权利要求8所述的方法，其中，所述通过所述令牌验证合约对所述资源操作请求和所述对象令牌进行验证，包括：
    通过所述令牌验证合约获取与所述对象令牌相关联的授权信息，确定所述资源操作请求是否满足所述授权信息；
    若所述资源操作请求满足所述授权信息，则确定所述资源操作请求和所述对象令牌验证通过；
    若所述资源操作请求不满足所述授权信息，则确定所述资源操作请求和所述对象令牌验证不通过。
  10. 根据权利要求8所述的方法，其中，所述通过所述对象信息操作服务响应所述资源操作请求，包括：
    若所述资源操作请求为资源读取操作请求，则通过所述对象信息操作服务从对象信息数据库中获取所述资源读取操作请求所请求读取的目标读取数据；所述目标读取数据属于所述资源数据；
    将所述目标读取数据返回所述应用客户端。
  11. 根据权利要求10所述的方法，其中，所述通过所述对象信息操作服务从对象信息数据库中获取所述资源读取操作请求所请求读取的目标读取数据，包括：
    若对象信息数据库中存在所述资源读取操作请求所请求读取的目标读取数据，则通过所述对象信息操作服务从所述对象信息数据库中获取所述目标读取数据；
    若所述对象信息数据库中不存在所述目标读取数据，则通过所述对象信息操作服务向所述共识节点发送针对所述目标读取数据的数据同步请求，基于针对所述目标读取数据的数据同步请求从所述共识节点的已上链数据中获取同步数据，将所述同步数据存储至所述对象信息数据库，通过所述对象信息操作服务从所述对象信息数据库中获取所述目标读取数据；所述同步数据包括所述目标读取数据。
  12. 根据权利要求8所述的方法，其中，所述通过所述对象信息操作服务响应所述资源操作请 求，包括：
    若所述资源操作请求为资源写入操作请求，则通过所述对象信息操作服务获取所述资源写入操作请求所请求写入的目标写入数据；所述目标写入数据属于所述资源数据；
    若对象信息数据库中不存在所述目标写入数据，则将所述目标写入数据写入至对象信息数据库。
  13. 根据权利要求12所述的方法，其中，所述若对象信息数据库中不存在所述目标写入数据，则将所述目标写入数据写入至对象信息数据库，包括：
    若对象信息数据库中不存在所述目标写入数据，则将所述目标写入数据转发至所述共识节点，以使所述共识节点对所述目标写入数据进行打包处理，生成目标区块，对所述目标区块进行上链处理；
    向所述共识节点发送针对所述目标写入数据的数据同步请求，接收所述共识节点基于针对所述目标写入数据的数据同步请求所返回的所述目标写入数据，将所述目标写入数据写入至所述对象信息数据库。
  14. 一种数据处理装置，所述装置应用于区块链网络中的业务节点，所述业务节点用于提供对象登录服务和令牌发放服务，包括：
    第一接收模块，用于接收目标对象通过应用客户端发送的授权请求，基于所述授权请求调用所述对象登录服务，获取所述目标对象在所述对象登录服务中输入的待验证登录信息；
    授权码返回模块，用于通过所述对象登录服务将所述待验证登录信息与对象凭证信息进行匹配，若所述待验证登录信息与所述对象凭证信息相匹配，则获取针对所述目标对象的对象授权码，向所述应用客户端返回所述对象授权码；所述对象凭证信息是由所述业务节点从所述区块链网络的共识节点中所获取到的；
    第二接收模块，用于接收所述应用客户端基于所述对象授权码发送的令牌获取请求，基于所述令牌获取请求调用所述令牌发放服务，通过所述令牌发放服务获取针对所述目标对象的对象令牌，向所述应用客户端返回所述对象令牌；所述对象令牌为所述应用客户端提供针对授权范围内的资源数据的操作权限；所述操作权限是指所述应用客户端具有通过所述业务节点操作所述资源数据的权限。
  15. 根据权利要求14所述的装置，其中，对象登录服务包括对象登录前端和对象登录后端；
    第一接收模块，用于接收目标对象通过应用客户端发送的授权请求，基于授权请求调用对象登录前端，获取目标对象在对象登录前端中输入的待验证登录信息；
    授权码返回模块，用于通过对象登录后端调用登录判断合约，通过登录判断合约将待验证登录信息与对象凭证信息进行匹配；登录判断合约是由业务节点从共识节点中所获取到的。
  16. 根据权利要求15所述的装置，其中，待验证登录信息包括待验证对象标识和待验证对象密码；
    授权码返回模块，用于通过登录判断合约从对象信息数据库中获取对象凭证信息；对象凭证信息是由业务节点从共识节点的已上链数据中同步得到的；对象凭证信息包括对象标识凭证信息；
    授权码返回模块，用于在对象标识凭证信息中查找待验证对象标识，若对象标识凭证信息中不存在待验证对象标识，则确定待验证登录信息与对象凭证信息不匹配；
    授权码返回模块，用于若对象标识凭证信息中存在待验证对象标识，则基于待验证对象密码，确定待验证登录信息与对象凭证信息之间的匹配结果。
  17. 根据权利要求16所述的装置，其中，对象凭证信息还包括对象密码凭证信息和字符串凭证信息；一个对象标识凭证信息对应一个对象密码凭证信息和一个字符串凭证信息；
    授权码返回模块，用于将待验证对象密码与待验证对象标识在对象凭证信息中对应的字符串凭证信息进行拼接，得到待验证拼接登录信息；
    授权码返回模块，用于对待验证拼接登录信息进行哈希计算，得到待验证哈希登录信息；
    授权码返回模块，用于将待验证哈希登录信息与待验证对象标识在对象凭证信息中对应的对象密码凭证信息进行比较，若待验证哈希登录信息与待验证对象标识在对象凭证信息中对应的对象密码凭证信息相同，则生成用于表征待验证登录信息与对象凭证信息相匹配的匹配结果；
    授权码返回模块，具体用于若待验证哈希登录信息与待验证对象标识在对象凭证信息中对应的对象密码凭证信息不同，则生成用于表征待验证登录信息与对象凭证信息不匹配的匹配结果。
  18. 一种计算机设备，包括：处理器和存储器；
    所述处理器与所述存储器相连，其中，所述存储器用于存储计算机程序，所述处理器用于调用所述计算机程序，以使得所述计算机设备执行权利要求1-13任一项所述的方法。
  19. 一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，该计算机程序适于由处理器加载并执行，以使得具有所述处理器的计算机设备执行权利要求1-13任一项所述的方法。
  20. 一种计算机程序产品，所述计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中，且适于由处理器读取并执行，以使得具有所述处理器的计算机设备执行权利要求1-13任一项所述的方法。
PCT/CN2023/089109 2022-05-17 2023-04-19 一种数据处理方法、装置、计算机设备以及可读存储介质 WO2023221719A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210536186.7 2022-05-17
CN202210536186.7A CN117118640A (zh) 2022-05-17 2022-05-17 一种数据处理方法、装置、计算机设备以及可读存储介质

Publications (1)

Publication Number Publication Date
WO2023221719A1 true WO2023221719A1 (zh) 2023-11-23

Family

ID=88793504

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/089109 WO2023221719A1 (zh) 2022-05-17 2023-04-19 一种数据处理方法、装置、计算机设备以及可读存储介质

Country Status (2)

Country Link
CN (1) CN117118640A (zh)
WO (1) WO2023221719A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117331964B (zh) * 2023-12-01 2024-02-27 成都明途科技有限公司 数据查询方法、装置、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108805573A (zh) * 2018-04-21 2018-11-13 深圳市元征科技股份有限公司 一种信息验证方法、服务器及存储介质
US20190342290A1 (en) * 2018-05-02 2019-11-07 Mastercard International Incorporated Method and system for enhanced login credential security via blockchain
US20190372958A1 (en) * 2018-06-05 2019-12-05 The Toronto-Dominion Bank Methods and systems for controlling access to a protected resource
CN112989426A (zh) * 2021-04-30 2021-06-18 腾讯科技（深圳）有限公司 授权认证方法及装置、资源访问令牌的获取方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108805573A (zh) * 2018-04-21 2018-11-13 深圳市元征科技股份有限公司 一种信息验证方法、服务器及存储介质
US20190342290A1 (en) * 2018-05-02 2019-11-07 Mastercard International Incorporated Method and system for enhanced login credential security via blockchain
US20190372958A1 (en) * 2018-06-05 2019-12-05 The Toronto-Dominion Bank Methods and systems for controlling access to a protected resource
CN112989426A (zh) * 2021-04-30 2021-06-18 腾讯科技（深圳）有限公司 授权认证方法及装置、资源访问令牌的获取方法

Also Published As

Publication number Publication date
CN117118640A (zh) 2023-11-24

Similar Documents

Publication Publication Date Title
US10708060B2 (en) System and method for blockchain-based notification
US11943224B2 (en) Blockchain-based admission processes for protected entities
US11038891B2 (en) Decentralized identity management system
US11762970B2 (en) Fine-grained structured data store access using federated identity management
US20210051025A1 (en) System and method for blockchain-based cross-entity authentication
CN109327481B (zh) 一种基于区块链的全网统一在线认证方法及系统
CN109829326B (zh) 基于区块链的跨域认证与公平审计去重云存储系统
WO2022193985A1 (zh) 一种数据处理方法、装置、设备及存储介质
US10554406B1 (en) Authorized data sharing using smart contracts
US11829502B2 (en) Data sharing via distributed ledgers
WO2023024742A1 (zh) 一种数据处理方法、装置、计算机设备及存储介质
JP7169462B2 (ja) ブロックチェーンネットワークにおいてアイデンティティ証明書を取り換える方法、装置、記憶媒体及びコンピュータ機器
CN113271311B (zh) 一种跨链网络中的数字身份管理方法及系统
US11240027B2 (en) Synchronizing radius server databases using distributed ledger network
CN112149105A (zh) 数据处理系统、方法、相关设备及存储介质
US20180196948A1 (en) Distributed and decentralized clound storage system and method thereof
JP2023542681A (ja) ブロックチェーンの許可フレームワークへのデバイスアイデンティティの統合
CN114547636A (zh) 分布式账本系统
WO2023221719A1 (zh) 一种数据处理方法、装置、计算机设备以及可读存储介质
US11640475B1 (en) Systems and processes for providing secure client controlled and managed exchange of data between parties
US20230246822A1 (en) Systems and methods for providing secure, encrypted communications across distributed computer networks by coordinating cryptography-based digital repositories in order to perform blockchain operations in decentralized applications
US20230245111A1 (en) Systems and methods for requesting secure, encrypted communications across distributed computer networks for authorizing use of cryptography-based digital repositories in order to perform blockchain operations in decentralized applications
Ramesh et al. Public auditing for shared data with efficient user revocation in the cloud
Zhang et al. Decentralized authorization and authentication based on consortium blockchain
Yao et al. CD-BCM: Cross-Domain Batch Certificates Management Based On Blockchain

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23806672

Country of ref document: EP

Kind code of ref document: A1