User authorization method and apparatus

Abstract

The application discloses a user authorization method and device, wherein the method comprises: when a user logs in an account of a target application, generating a first NFT asset based on target user information to be authorized and submitting the first NFT asset to a blockchain; the target user information is specified by the user in user information of the account; when a third-party application client needs to apply for authorization of the first NFT asset, triggering a smart contract of the target application in the blockchain to generate a second NFT asset based on authorization information of the first NFT asset and transfer the second NFT asset to the third-party application client, so that a resource end in the blockchain knows that the third-party application client has obtained authorization of the first NFT asset. By using the application, the delay of resource acquisition can be effectively reduced, and the load of an authorization server can be avoided from being too high.

Description

Technical Field

[0001] This invention relates to computer application technology, and in particular to a user authorization method and apparatus. Background Technology

[0002] Open Authorization (OAuth) is an open web standard for authorization that allows users to authorize third-party applications to access information they store on other service providers without having to provide their usernames and passwords to the third-party mobile applications or share all of their data. OAuth is widely used worldwide, and the current version is 2.0.

[0003] Figure 1 The OAuth 2.0 protocol flow is given, such as... Figure 1 As shown, the protocol process mainly includes the following steps:

[0004] Step A: The client requests authorization from the user.

[0005] Step B: The client receives an authorization grant, indicating that the client has been authorized.

[0006] Step C: The client uses the authorization grant to request an access token from the authorization server.

[0007] Step D: After the authorization server authenticates the client's identity and grants the authorization grant, it issues an access token to the client.

[0008] Step E: The client uses an access token to request protected resources from the resource server.

[0009] Step F: The resource server verifies the access token. If valid, it sends the requested protected resource.

[0010] In the process of developing this invention, the inventors discovered that the above-mentioned user authorization agreement has problems such as high load on the authorization server and large delay in resource requests. Summary of the Invention

[0011] In view of this, the main objective of the present invention is to provide a user authorization method and apparatus that can effectively reduce the latency of resource acquisition and avoid excessive load on the authorization server.

[0012] To achieve the above objectives, the technical solution proposed in this embodiment of the invention is as follows:

[0013] A user authorization method, comprising:

[0014] After a user logs into the target application's account, a first non-fungible token (NFT) asset is generated based on the target user information to be authorized, and submitted to the blockchain; the target user information is specified by the user in the user information of the account.

[0015] When a third-party application client needs to apply for authorization of the first NFT asset, the smart contract of the target application in the blockchain is triggered to generate a second NFT asset based on the authorization information of the first NFT asset and transfer it to the third-party application client, so that the resource end in the blockchain knows that the third-party application client has obtained authorization of the first NFT asset.

[0016] This invention also proposes a user authorization device, comprising:

[0017] The first NFT asset generation unit is used to generate a first non-fungible token NFT asset based on the target user information to be authorized after a user logs into the target application's account, and submit it on the blockchain; the target user information is specified by the user in the user information of the account.

[0018] The second NFT asset generation unit is used to trigger the smart contract of the target application in the blockchain to generate a second NFT asset based on the authorization information of the first NFT asset when a third-party application client needs to apply for authorization of the first NFT asset, and then transfer it to the third-party application client, so that the resource end in the blockchain knows that the third-party application client has obtained authorization for the first NFT asset.

[0019] This invention also provides an electronic device, including a processor and a memory;

[0020] The memory stores an application program that can be executed by the processor, which causes the processor to perform the user authorization method as described above.

[0021] This invention also proposes a computer-readable storage medium storing computer-readable instructions for executing the user authorization method described above.

[0022] This invention also proposes a computer program product, including a computer program / instruction, characterized in that, when the computer program / instruction is executed by a processor, it implements the steps of the user authorization method described above.

[0023] In summary, the user authorization scheme proposed in this embodiment of the invention converts the user information requiring authorization into NFT assets (i.e., the first NFT asset). When a third-party application client needs authorization to access the corresponding account, authorization is triggered based on the NFT asset, and an authorized digital asset (i.e., the second NFT asset) is generated based on the corresponding authorization information. At this time, the resource end in the blockchain will also know that the authorized digital asset is real and reliable. In this way, when the resource end in the blockchain receives the resource request from the third-party application client, it does not need to trigger the smart contract for authorization to perform additional authentication on the third-party application client. Thus, while ensuring authorization security by leveraging the technical advantages of NFTs, the problem of excessive load on the authorization server is avoided, and the latency of resource request processing is effectively reduced. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating the existing OAuth 2.0 protocol.

[0025] Figure 2 This is a diagram illustrating how to request authorization and obtain resources based on the existing OAuth2.0 protocol.

[0026] Figure 3 This is a schematic diagram of the method flow according to an embodiment of the present invention;

[0027] Figures 4-9 This is a schematic diagram illustrating the application of an embodiment of the present invention in a specific scenario;

[0028] Figure 10 This is a schematic diagram of the device structure according to an embodiment of the present invention. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0030] The inventors discovered through research the specific reasons why existing licensing schemes suffer from problems such as high license server load and large resource request latency, as follows:

[0031] The existing authorization scheme uses a centralized authorization implementation, where the resource end (i.e., the resource server) does not participate in the token issuance process. Therefore, upon receiving a resource request, it is necessary to additionally verify the validity of the token, such as... Figure 2 As shown, every time a client requests a protected resource, the resource server needs to send a token authentication request to the authorization server. This will result in a high load on the authorization server and a high latency when the client requests the resource due to the need for token authentication.

[0032] To address the aforementioned issues, this application provides a decentralized user authorization scheme based on NFT technology. Users first store their information on a blockchain in the form of digital assets. As participants in the blockchain, the client and resource providers are involved. When a client requests authorization, the blockchain generates a digital asset containing authorization information and transfers it to the client. Simultaneously, the resource provider verifies the authenticity and reliability of this authorized digital asset. Thus, when a client subsequently requests resources from the resource provider, the resource provider does not need to perform additional authentication, thereby increasing authorization security, reducing resource acquisition latency, and avoiding the problem of excessive load on the authorization server.

[0033] Figure 3 This is a schematic diagram of the method flow of an embodiment of the present invention, such as... Figure 3 As shown, the user authorization implemented in this embodiment mainly includes the following steps:

[0034] Step 301: After a user logs into the target application's account, a first NFT asset is generated based on the target user information to be authorized, and submitted to the blockchain; the target user information is specified by the user in the user information of the account.

[0035] This step is used to convert user information that needs to be authorized to other application clients into NFT assets, and store the user information in the form of digital assets on the blockchain, so that authorization processing can be carried out based on the NFT assets in subsequent steps.

[0036] It's important to note that NFTs are applications based on blockchain technology. This technology ensures that NFT ownership remains intact. NFTs are transferable, meaning they can be traded on specific trading platforms, much like art markets. Blockchain technology makes every transaction completely transparent and traceable. Furthermore, due to the inherent advantages of blockchain, NFTs naturally have an advantage against counterfeiting. NFTs are issued by smart contracts and have a unique identifier (contract address + token ID). Based on the ERC-721 open protocol, information about the digital content itself and its creation is extracted and recorded. This information can include: content encoding, description (including user information), NFT creation time, NFT creator, and NFT ownership holder.

[0037] In this step, to ensure the security of the NFT asset generation operation, the NFT asset corresponding to the user information is generated only after the user successfully logs into the target application's account.

[0038] Specifically, after a user logs into the target application's account, they can select all or part of the user information from that account as the target user information to be authorized (such as account information, payment information, etc.) according to authorization requirements.

[0039] The specific methods for generating NFT assets can be implemented using existing technologies, and will not be elaborated here.

[0040] In one implementation, the following method can be used to generate a first NFT asset based on the target user information to be authorized, and submit it to the blockchain:

[0041] After the user logs into the target application's account through the first device, when the first device detects that the user has specified the target user information as the information to be authorized, it retrieves the target user information from the local machine or the target application's server, triggers the target application's smart contract to generate a first NFT asset based on the target user information, and transfers the first NFT asset to the user's blockchain account.

[0042] Step 302: When a third-party application client needs to apply for authorization of the first NFT asset, the smart contract of the target application in the blockchain is triggered to generate a second NFT asset based on the authorization information of the first NFT asset and transfer it to the third-party application client, so that the resource end in the blockchain knows that the third-party application client has obtained authorization of the first NFT asset.

[0043] In this step, when a third-party application client needs to obtain authorization for the user information to be authorized, it needs to trigger the blockchain to generate a digital asset (i.e., a second NFT asset) based on the authorization information of the corresponding NFT asset (i.e., the first NFT asset). In this way, the resource end in the blockchain will know that the corresponding authorization is genuine and reliable based on the generation of the second NFT asset. This means that when the third-party application client obtains resources based on the authorized account, it is not necessary to trigger the smart contract for authorization to perform additional authentication on the third-party application client. This can ensure the security of authorization, avoid the problem of excessive load on the authorization server, and effectively reduce the latency of resource request processing.

[0044] In practical applications, third-party application clients can be installed on the user device used when creating the first NFT asset, or on other user devices.

[0045] In one implementation, the target application's smart contract can be triggered to generate a second NFT asset based on the authorization information of the first NFT asset using the following method:

[0046] The third-party application client requests authorization for the first NFT asset from the smart contract, so that the smart contract, based on the request, notifies the user to confirm whether they agree to the third-party application client obtaining the authorization, and generates the second NFT asset based on the corresponding authorization information when the user confirms their agreement.

[0047] Specifically, when the smart contract receives a message from a third-party application client requesting authorization for the first NFT asset, it can notify the user to confirm whether they agree to the third-party application client obtaining authorization for the first NFT asset by creating the user device of the first NFT asset (i.e., the aforementioned first device).

[0048] Using steps 301 and 302 above, secure authorization for a third-party application client to obtain specified user information can be achieved. In one embodiment, steps x1 to x2 can be further used to enable the third-party application client to request resources from the resource provider based on the obtained NFT asset authorization:

[0049] Step x1: When the third-party application client needs to request the resource terminal in the blockchain to use the account to obtain resource services, it sends the corresponding resource request to the resource terminal.

[0050] Specifically, the resource request will carry the account's identification information to notify the resource provider to request resource services based on the corresponding account.

[0051] Step x2: Based on the resource request, the resource terminal queries the historical authorization records of the blockchain to determine whether the third-party application client has obtained authorization for the first NFT asset and whether the authorization is valid. If so, the corresponding resource service operation is executed based on the account indicated by the resource request.

[0052] Here, when the resource end receives the resource request, it can query the historical authorization records of the blockchain based on the identification information carried in the resource request to find out whether the third-party application client has obtained valid authorization for the first NFT asset. In this way, it is not necessary to trigger the smart contract for authorization to perform additional authentication on the third-party application client.

[0053] In one implementation, to improve the flexibility of NFT asset licensing management, the above method embodiments can further utilize the following method to allow users to revoke the licenses of generated NFT assets:

[0054] Based on the user's instruction to revoke the authorization, a request is made to the smart contract to revoke the authorization, so that the smart contract generates a third NFT asset based on the corresponding revocation authorization information and transfers the third NFT asset to the third-party application client, wherein the token type of the third NFT asset is revocation.

[0055] Specifically, after logging into the target application's account, the user can initiate an instruction to revoke the authorization.

[0056] In one implementation, in the above method embodiment, the third-party application client can further utilize the following steps y1~y2 to automatically extend the validity period of the generated NFT asset authorization:

[0057] Step y1: When the third-party application client detects that the interval between the current time and the expiration time of the second NFT asset is less than a preset duration, it requests the smart contract to extend the authorization validity period of the first NFT asset.

[0058] It should be noted that when generating the second NFT asset, the validity period of the asset can be set. In this step, when the third-party application client detects that the validity period of the current second NFT asset is about to expire, it automatically requests an extension from the smart contract to ensure the validity of the authorized digital asset.

[0059] Step y2: The smart contract generates a new second NFT asset based on the request and corresponding authorization information, and transfers the new second NFT asset to the third-party application client; the token validity period of the new second NFT asset is the validity period set according to the preset extension time.

[0060] Step y2 allows for the extension of the validity period of the second NFT asset.

[0061] The extended time is used to limit the duration of the validity period extension. The specific duration can be set by those skilled in the art or by the user according to actual needs, and will not be elaborated here.

[0062] As can be seen from the above technical solution, this method provides a decentralized user authorization method. This method allows authorized clients to request resources from resource providers without requiring additional authentication, thereby increasing authorization security and reducing resource acquisition latency. The following uses a television as an example of an application scenario. Figures 4-9 The specific implementation of the above method embodiments is illustrated by example:

[0063] 1. For example Figure 4 As shown, the generation process of the first NFT asset includes the following steps:

[0064] Step 1: On the TV, the user selects all or part of their user information to generate NFT assets.

[0065] Step 2: The TV and the TV service provider's server exchange user information.

[0066] Here, when the TV discovers that the user information selected by the user in step 1 is not saved locally, it needs to interact with the server to obtain the corresponding user information.

[0067] Step 3: The TV uses the smart contract of the TV service provider in the blockchain to generate NFT assets containing user information.

[0068] Step 4: The TV service provider's smart contract will transfer the generated NFT assets to the user's blockchain account.

[0069] 2. For example Figure 5 As shown, the generation process of the second NFT asset includes the following steps:

[0070] Step 1: The client requests authorization from the smart contract of the TV service provider in the blockchain.

[0071] Step 2: The TV service provider's smart contract triggers the user's confirmation via the TV to agree to the client's authorization request, and obtains the user's confirmation.

[0072] Step 3: The TV service provider's smart contract generates an NFT asset containing authorization information (i.e., the second NFT asset) and transfers it to the client. Simultaneously, the resource end in the blockchain can verify the authenticity of the authorization obtained by the client. During the generation of the second NFT asset, the smart contract needs to interact with the TV service provider's server.

[0073] 3. For example Figure 6 As shown, the process of a client requesting a resource includes the following steps:

[0074] First, through Figure 5 In step 3, the client obtains an NFT asset containing authorization information. At the same time, the resource side in the blockchain also confirms that the authorization obtained by the client is genuine and reliable.

[0075] Then, through step 4, the client requests resources from the resource provider, which returns the resources directly without requiring additional verification.

[0076] 4. An implementation example of how the third-party application client obtains payment authorization and requests payment when it is a third-party wallet. For example... Figure 7 As shown, this example includes the following steps:

[0077] Step 1: The third-party wallet requests payment authorization for a specific TV account s from the TV service provider's smart contract.

[0078] Step 2: The TV service provider's smart contract obtains the user's consent and authorization confirmation through the TV.

[0079] Step 3: The TV service provider's smart contract generates an NFT asset containing authorization information (i.e., the second NFT asset), sets the token type to payment, and transfers it to a third-party wallet. Simultaneously, marketplace A (the resource side) in the blockchain confirms that the payment authorization obtained by the third-party wallet is genuine and credible.

[0080] Step 4: The third-party wallet requests payment from Mall A, and the request carries account information indicating which account to deduct the money from.

[0081] Step 5: Mall A accepts the payment request and completes the payment without requiring additional verification.

[0082] 5. For example Figure 8 As shown, the process for a user to revoke authorization includes the following steps:

[0083] Step 1: The user initiates the revocation of authorization on the TV.

[0084] Step 2: The TV service provider's smart contract generates an NFT asset containing revocation authorization information, sets the token type to revocation, and transfers it to the client. Simultaneously, the resource side in the blockchain confirms that the authorization previously obtained by the client has been revoked.

[0085] Step 3: The client requests resources from the resource provider, but the resource provider rejects the request.

[0086] 6. For example Figure 9 As shown, the process for automatically updating the license validity period includes the following steps:

[0087] Step 1: The NFT asset containing authorization information obtained by the client is about to expire, so apply for renewal.

[0088] Step 2: The TV service provider's smart contract generates an NFT asset containing authorization information, sets a new token validity period, and transfers it to the client's account. At the same time, the resource side in the blockchain confirms that the newly acquired NFT asset containing authorization information is authentic and trustworthy.

[0089] Step 3: The client requests resources from the resource provider. The resource provider does not require additional verification and directly returns the resources.

[0090] Based on the above method embodiments, this invention also proposes a user authorization device, such as... Figure 10 As shown, it includes:

[0091] The first NFT asset generation unit 1001 is used to generate a first non-fungible token NFT asset based on the target user information to be authorized after a user logs into the target application's account, and submit it on the blockchain; the target user information is specified by the user in the user information of the account.

[0092] The second NFT asset generation unit 1002 is used to trigger the smart contract of the target application in the blockchain to generate a second NFT asset based on the authorization information of the first NFT asset when a third-party application client needs to apply for authorization of the first NFT asset, and transfer it to the third-party application client, so that the resource end in the blockchain knows that the third-party application client has obtained authorization of the first NFT asset.

[0093] It should be noted that the above methods and apparatus are based on the same inventive concept. Since the methods and apparatus solve problems in similar ways, the implementation of the apparatus and methods can refer to each other, and the repeated parts will not be described again.

[0094] Based on the above method embodiments, this invention also proposes an electronic device, including a processor and a memory; the memory stores an application program executable by the processor, used to cause the processor to execute the user authorization method as described above. Specifically, a system or device equipped with a storage medium can be provided, on which software program code implementing the functions of any of the above embodiments is stored, and the computer (or CPU or MPU) of the system or device can read and execute the program code stored in the storage medium. Furthermore, the operating system or other devices operating on the computer can perform some or all of the actual operations through instructions based on the program code. The program code read from the storage medium can also be written to a memory located in an expansion board inserted into the computer or to a memory located in an expansion unit connected to the computer, and then, based on the instructions of the program code, a CPU or other device installed on the expansion board or expansion unit can execute some or all of the actual operations, thereby realizing the functions of any of the above user authorization method embodiments.

[0095] Specifically, the memory can be implemented as various storage media such as electrically erasable programmable read-only memory (EEPROM), flash memory, and programmable programmable read-only memory (PROM). The processor can be implemented as one or more central processing units (CPUs) or one or more field-programmable gate arrays (FPGAs), wherein the FPGA integrates one or more CPU cores. Specifically, the CPU or CPU core can be implemented as a CPU or an MCU.

[0096] This application embodiment implements a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the user authorization method described above.

[0097] It should be noted that not all steps and modules in the above processes and structural diagrams are mandatory; some steps or modules can be omitted as needed. The execution order of the steps is not fixed and can be adjusted as required. The division of modules is merely for the convenience of description and functional division. In actual implementation, a module can be implemented by multiple modules, and the functions of multiple modules can also be implemented by the same module. These modules can be located in the same device or in different devices.

[0098] The hardware modules in each embodiment can be implemented mechanically or electronically. For example, a hardware module may include specially designed permanent circuitry or logic devices (such as dedicated processors, such as FPGAs or ASICs) to perform specific operations. A hardware module may also include programmable logic devices or circuitry (such as general-purpose processors or other programmable processors) temporarily configured by software to perform specific operations. The choice between mechanical implementation, dedicated permanent circuitry, or temporarily configured circuitry (such as software-configured circuitry) for the hardware module can be made based on cost and time considerations.

[0099] In this document, "illustrative" means "serving as an example, illustration, or description," and any illustration or embodiment described herein as "illustrative" should not be construed as a preferred or more advantageous technical solution. For the sake of brevity, the figures only schematically represent the parts relevant to the invention and do not represent their actual structure as a product. Furthermore, for the sake of clarity and ease of understanding, in some figures, components with the same structure or function are only schematically depicted, or only one is labeled. In this document, "a" does not mean that the number of relevant parts of the invention is limited to "only one," and "a" does not exclude the possibility that the number of relevant parts of the invention is "more than one." In this document, terms such as "upper," "lower," "front," "rear," "left," "right," "inner," and "outer" are used only to indicate the relative positional relationship between relevant parts, and not to limit the absolute position of these relevant parts.

[0100] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A user authorization method, characterized by, The method comprises: After a user logs in an account of a target application, a first NFT asset is generated based on target user information to be authorized, and the first NFT asset is submitted to a blockchain for uploading; The target user information is specified by the user in user information of the account; When a third-party application client needs to apply for authorization of the first NFT asset, a smart contract of the target application in the blockchain generates a second NFT asset based on authorization information of the first NFT asset and transfers the second NFT asset to the third-party application client, so that a resource end in the blockchain knows that the third-party application client has obtained authorization of the first NFT asset; When the third-party application client needs to request a resource end in the blockchain for resource services obtained by using the account, a corresponding resource request is sent to the resource end; The resource end queries historical authorization records of the blockchain based on the resource request, judges whether the third-party application client has obtained authorization of the first NFT asset and whether the authorization is in a valid state, and if so, performs a corresponding resource service operation based on the account indicated by the resource request.

2. The method of claim 1, wherein, The method further comprises: After the user logs in an account of a target application through a first device, when the first device detects that the user specifies the target user information as to-be-authorized information, the target user information is obtained from a local device or a server of the target application, and a smart contract of the target application generates a first NFT asset based on the target user information and transfers the first NFT asset to a blockchain account of the user.

3. The method of claim 1, wherein, The method further comprises: The third-party application client requests the smart contract to obtain authorization of the first NFT asset, so that the smart contract notifies the user to confirm whether to agree that the third-party application client obtains the authorization based on the request, and generates a second NFT asset based on corresponding authorization information when the user confirms to agree.

4. The method of claim 1, wherein, The method further comprises: Based on an instruction of the user to revoke the authorization, a request is sent to the smart contract to revoke the authorization, so that the smart contract generates a third NFT asset based on corresponding revocation authorization information and transfers the third NFT asset to the third-party application client, wherein a token type of the third NFT asset is revocation.

5. The method of claim 1, wherein, The method further comprises: When the third-party application client detects that an interval between a current time and an expiration time of the second NFT asset is less than a preset time length, a request is sent to the smart contract to extend a valid period of the authorization of the first NFT asset; The smart contract generates a new second NFT asset based on corresponding authorization information according to the request and transfers the new second NFT asset to the third-party application client; a token valid period of the new second NFT asset is a valid period set according to a preset extension time.

6. A user authorization device, characterized by The method comprises: The first NFT asset generation unit is configured to generate a first non-fungible token (NFT) asset based on target user information to be authorized after a user logs in an account of a target application, and submit the first NFT asset to a blockchain; The target user information is specified by the user in user information of the account; The second NFT asset generation unit is configured to trigger a smart contract of the target application in the blockchain to generate a second NFT asset based on authorization information of the first NFT asset and transfer the second NFT asset to a third-party application client when the third-party application client needs to apply for authorization of the first NFT asset, so that a resource end in the blockchain knows that the third-party application client has obtained authorization of the first NFT asset; and when the third-party application client needs to request a resource service from the resource end in the blockchain using the account, send a corresponding resource request to the resource end; and the resource end queries a historical authorization record of the blockchain based on the resource request, judges whether the third-party application client has obtained authorization of the first NFT asset and whether the authorization is in a valid state, and if so, performs a corresponding resource service operation based on the account indicated by the resource request.

7. An electronic device, comprising: comprises a processor and a memory; The memory stores an application program executable by the processor, so as to enable the processor to execute the user authorization method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer readable instructions are stored in the memory and used to execute the user authorization method according to any one of claims 1 to 5.

9. A computer program product comprising computer programs / instructions, characterized in that, The computer program / instructions are executed by the processor to implement the steps of the user authorization method according to any one of claims 1 to 5.

Images