Permission management method and apparatus, and device and storage medium

Abstract

The embodiments of the present disclosure relate to a permission management method and apparatus, and a device and a storage medium. The method disclosed herein comprises: receiving a use request for a target application in a platform, wherein the use request comprises token information; verifying the token information by using token management data, wherein the token management data is generated on the basis of a token creation request from a target user associated with the target application, and the token creation request at least indicates a specified permission of the target user for at least one working space in the platform; in response to the token information passing the verification, determining whether a use permission corresponding to the token information matches the use request; and in response to the use permission matching the use request, responding to the use request by using the target application. In this way, the embodiments of the present disclosure can improve the flexibility of permission management.

Description

Rights management method, device, equipment and storage medium

[0001] This application claims priority to the Chinese invention patent application entitled “Method, apparatus, device and storage medium for rights management” filed on March 29, 2024, with application number 202410382470.2, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] Example embodiments of the present disclosure generally relate to the field of computers, and more particularly, to a method, apparatus, device, and computer-readable storage medium for rights management. Background Art

[0003] With the advancement of computer technology, the technical barriers to application development and deployment are rapidly decreasing. Ordinary users can now build applications using low-code development platforms or other platforms. Some platforms allow users to open up their application interfaces, allowing more users or other applications to access services by calling these interfaces. Summary of the Invention

[0004] In a first aspect of the present disclosure, a method for rights management is provided. The method includes: receiving a usage request for a target application in a platform, the usage request including token information; verifying the token information using token management data, the token management data being generated based on a token creation request by a target user associated with the target application, the token creation request indicating at least a specified right regarding at least one workspace of the target user in the platform; in response to the token information passing the verification, determining whether the usage right corresponding to the token information matches the usage request; and in response to the usage right matching the usage request, responding to the usage request using the target application.

[0005] In a second aspect of the present disclosure, a device for permission management is provided. The device includes: a request receiving module configured to receive a use request for a target application in a platform, the use request including token information; a first authentication module configured to verify the token information using token management data, the token management data being generated based on a token creation request of a target user associated with the target application, the token creation request at least indicating a specified permission for at least one workspace of the target user in the platform; a second authentication module configured to determine whether the use permission corresponding to the token information matches the use request in response to the token information passing the verification; and a request response module configured to respond to the use request using the target application in response to the use permission matching the use request.

[0006] In a third aspect of the present disclosure, an electronic device is provided. The device includes at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit. When executed by the at least one processing unit, the instructions cause the device to perform the method of the first aspect.

[0007] In a fourth aspect of the present disclosure, a computer-readable storage medium is provided, wherein a computer program is stored on the computer-readable storage medium, and the computer program can be executed by a processor to implement the method of the first aspect.

[0008] It should be understood that the content described in this summary section is not intended to limit the key features or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. In the accompanying drawings, the same or similar reference numerals represent the same or similar elements, wherein:

[0010] FIG1 shows a schematic diagram of an example environment in which embodiments according to the present disclosure may be implemented;

[0011] FIG2 is a schematic diagram illustrating an example process of application rights management according to some embodiments of the present disclosure;

[0012] FIG3 illustrates an example interface according to some embodiments of the present disclosure;

[0013] FIG4 shows a flowchart of an example process of rights management according to some embodiments of the present disclosure;

[0014] FIG5 shows a schematic structural block diagram of an example apparatus for rights management according to some embodiments of the present disclosure; and

[0015] FIG6 illustrates a block diagram of an electronic device capable of implementing various embodiments of the present disclosure. DETAILED DESCRIPTION

[0016] The following describes embodiments of the present disclosure in more detail with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0017] It should be noted that the titles of any section / subsection provided herein are not limiting. Various embodiments are described throughout this document, and any type of embodiment may be included under any section / subsection. Furthermore, the embodiments described in any section / subsection may be combined in any manner with any other embodiments described in the same section / subsection and / or in different sections / subsections.

[0018] In the description of the embodiments of the present disclosure, the term "including" and similar terms should be understood as open inclusion, that is, "including but not limited to". The term "based on" should be understood as "based at least in part on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The term "some embodiments" should be understood as "at least some embodiments". Other explicit and implicit definitions may be included below. The terms "first", "second", etc. may refer to different or the same objects. Other explicit and implicit definitions may be included below.

[0019] The embodiments of the present disclosure may involve user data, data acquisition and / or use, etc. These aspects shall comply with the corresponding laws, regulations and relevant provisions. In the embodiments of the present disclosure, all data collection, acquisition, processing, processing, forwarding, use, etc. are carried out on the premise that the user is aware of and confirms them. Accordingly, when implementing the various embodiments of the present disclosure, the types, scope of use, and usage scenarios of the data or information that may be involved should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with the relevant laws and regulations. The specific notification and / or authorization method may vary according to the actual situation and application scenario, and the scope of the present disclosure is not limited in this respect.

[0020] If this specification and the solutions in the examples involve the processing of personal information, such processing will be done only with a legitimate basis (such as with the consent of the subject of personal information or as necessary for the performance of a contract) and only within the prescribed or agreed scope. A user's refusal to process personal information other than that required for basic functions will not affect the user's use of basic functions.

[0021] As mentioned above, some platforms allow users to open up the interfaces of their applications, allowing more users or other applications to access services by calling these interfaces. Therefore, how to effectively manage the permissions for calling these interfaces has become a key issue of concern.

[0022] Embodiments of the present disclosure propose a rights management scheme. According to the scheme, a use request for a target application in a platform is received, the use request including token information; the token information is verified using token management data, the token management data being generated based on a token creation request of a target user associated with the target application, the token creation request at least indicating a specified permission for at least one workspace of the target user in the platform; in response to the token information passing the verification, determining whether the use permission corresponding to the token information matches the use request; and in response to the use permission matching the use request, responding to the use request using the target application.

[0023] In this way, the embodiments of the present disclosure can call an interface by creating a token and including the token in a request, and can improve the reliability of authentication through secondary authentication, thereby improving the efficiency of application permission management.

[0024] Various example implementations of this solution are described in detail below in conjunction with the accompanying drawings.

[0025] Sample Environment

[0026] FIG1 shows a schematic diagram of an example environment 100 in which embodiments of the present disclosure can be implemented. As shown in FIG1 , the environment 100 may include a management system 110 .

[0027] 1 , such a management system 110 may be associated with an application platform 140. In some embodiments, such an application platform 140 may support developers 160 in creating and publishing corresponding applications 150.

[0028] As an example, such an application platform 140 may support users to create and manage different workspaces for developing or managing corresponding applications. In some examples, such an application 150 may include a bot based on a machine learning model.

[0029] In some embodiments, the developer 160 may, for example, open the application programming interface (API) of the application 150 through the application platform 140 to support other users or applications in invoking the application 150 to perform corresponding tasks by calling the interface.

[0030] As shown in FIG. 1 , the user 130 may, for example, call an API of the application 150 through the electronic device 120 or an application installed in the electronic device 120 to perform a corresponding task.

[0031] As will be described in detail below, to manage the efficiency and reliability of API calls, a request to call the API of application 150 may be sent to management system 110 , which determines whether the request is allowed based on token information in the request.

[0032] If the request is allowed, the request may be forwarded to the application 150, for example, so that the application 150 can respond to the request. The process of authentication based on token information will be described in detail below and will not be described in detail here.

[0033] It should be understood that the structure and function of the various elements in the environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of the present disclosure.

[0034] Some example embodiments of the present disclosure will be described below with continued reference to the accompanying drawings.

[0035] Example Permission Management

[0036] FIG2 shows a schematic diagram of a rights management process 200 according to some embodiments of the present disclosure.

[0037] As shown in FIG2 , at 205 , user 250 (eg, user 130 shown in FIG1 ) may utilize electronic device 120 shown in FIG1 to send a request for use of a target application (eg, application 150 shown in FIG1 ) to interface management module 260 .

[0038] In some embodiments, the usage request may be a call request corresponding to an application program interface developed by the application 150. Additionally, the electronic device 120 may also add token information to a header of the call request.

[0039] In some embodiments, the token information may be generated based on a token creation request by a target user (e.g., developer 160 or administrative user) associated with the application 150. In some embodiments, such a token creation request may indicate specified permissions for at least one workspace of the target user in the platform.

[0040] Figure 3 shows an example token creation interface 300 according to some embodiments of the present disclosure. As shown in Figure 3, the interface 300 may include a control 330 for selecting a workspace and a control 340 for selecting a permission type.

[0041] As an example, control 330 can list all workspaces of the target user in the platform and can accept the user's selection for the workspace.In some embodiments, a single workspace can correspond to a single application (e.g., bot), or can correspond to multiple applications.

[0042] For example, in the case where the target user selects “all workspaces” through the control 330 , the created token may indicate designated permissions for applications under all workspaces.

[0043] Additionally, control 340 may list the permission types that support accessing the application through API calls. For example, such permission types may include information about which types of APIs are allowed to be used, such as a chat API, or a query API, etc.

[0044] In some embodiments, such permission types may also include, for example, permissions related to the application's knowledge base, such as the permission to create knowledge, the permission to delete knowledge, etc. Alternatively or additionally, such permission types may also include management permissions for workspaces, such as the permission to obtain all applications under the workspace, the permission to create a workspace, the permission to delete a workspace, etc.

[0045] Additionally or alternatively, the interface 300 may also include a control 310 for inputting an identification of the token and a control 320 for inputting a validity period of the token.

[0046] Furthermore, after receiving the input information of the target user in the interface 300, the management system 110 may create a corresponding token based on the input information. In some embodiments, the plain text information of the token may be provided to the target user only when it is generated.

[0047] Additionally, the ciphertext version of the token (eg, the value after hashing) may be stored as token information for addition to a usage request by the electronic device 120 .

[0048] In some embodiments, the management system 110 may further perform encryption processing on the generated target token in response to receiving the token creation request, and store the encrypted data in the token management data for use in a subsequent verification process.

[0049] 2 , at 210 , the interface management module 260 may send the token information included in the use request to the first authentication module 270 . At 215 , the first authentication module 270 may verify the received token information using the token management data.

[0050] Specifically, the first authentication module 270 may, for example, perform corresponding encryption processing on the token information to determine whether the encrypted data matches the encrypted data in the token management data. If the two match, at 220, the first authentication module 270 may return identity information corresponding to the token information to the interface management module 260. As an example, such identity information may include an identity ticket used to indicate the identity.

[0051] On the contrary, if the first authentication module 270 determines that the token information authentication fails, the first authentication module 270 may send a message about the authentication failure to the interface management module 260, and the interface management module 260 may reject the received usage request accordingly.

[0052] Furthermore, the interface management module 260 can use the received identity information to determine whether the received use request matches the corresponding use permission. Specifically, as shown in FIG2 , at 225 , the interface management module 260 can send the identity information, the application identifier of the target application, and the target action corresponding to the use request to the second authentication module 280 (also referred to as the permission management module).

[0053] As an example, the usage request may be a call to a chat API of the bot. Accordingly, the interface management module 260 may send the identity ticket received from the first authentication module 270, the bot's identifier, and the target action (ie, chat) to the second authentication module 260.

[0054] At 230, the second authentication module 280 may determine the usage permissions corresponding to the identity information and determine whether the usage permissions match the application representation and the target action. For example, if the created token indicates permission to use the bot's chat API, the second authentication module 280 may determine that the usage permissions corresponding to the identity information include permission to use the bot's chat API and may determine that the usage permissions match the currently received usage request.

[0055] In contrast, if the usage request is a call regarding another type of API not included in the token, the second authentication module 280 may determine that its usage rights do not match the usage request.

[0056] As shown in Figure 2, at 235, the second authentication module 280 may send authentication information to the interface management module 260. The authentication information may, for example, indicate whether the usage permission determined based on the identity information matches the application identifier and the target action.

[0057] In some embodiments, if the authentication information indicates a match between the two, the interface management module 260 may respond to the use request using the target application. Specifically, as shown in FIG2 , at 240, the interface management module 260 may forward the use request or a portion of the use request to the request response module 290. Further, at 245, the request response module 290 may respond to the use request using the target application, for example, by sending a corresponding response message to the user 250.

[0058] Taking a chat scenario as an example, the application may generate a corresponding reply message based on the input message indicated in the usage request, and send the reply message to the user 250 as a response.

[0059] On the contrary, if the authentication information received from the second authentication module 280 indicates that the two do not match, the interface management module 260 may reject the use request accordingly.

[0060] Based on the process described above, the embodiments of the present disclosure can call the interface by creating a token and including the token in the request, and can improve the reliability of authentication through secondary authentication, thereby improving the efficiency of application permission management.

[0061] Example Process

[0062] FIG4 shows a flow chart of a process 400 of rights management according to some embodiments of the present disclosure. The process 400 may be implemented at the management system 110. The process 400 is described below with reference to FIG1.

[0063] As shown in FIG. 4 , in block 410 , the management system 110 receives a usage request for a target application in the platform, where the usage request includes token information.

[0064] At block 420 , the management system 110 verifies the token information using token management data generated based on a token creation request by a target user associated with a target application, the token creation request indicating at least specified permissions for at least one workspace of the target user in the platform.

[0065] At block 430 , the management system 110 determines whether the usage rights corresponding to the token information match the usage request in response to the token information passing verification; and

[0066] At block 440 , the management system 110 responds to the usage request using the target application in response to the usage rights being matched to the usage request.

[0067] In some embodiments, process 400 also includes: providing a token creation interface to the target user, the token creation interface including a first control for selecting a workspace and a second control for selecting a permission type; and obtaining a token creation request based on input information received by the token creation interface.

[0068] In some embodiments, the token creation interface further includes: a third control for inputting a token identification; and / or a fourth control for specifying a validity period of the token.

[0069] In some embodiments, the process 400 further includes: in response to receiving the token creation request, performing cryptographic processing on the target token generated based on the token creation request to update the token management data.

[0070] In some embodiments, process 400 further includes providing target token information corresponding to the target token to the target user.

[0071] In some embodiments, in response to the token information passing verification, determining whether the usage permission corresponding to the token information matches the usage request includes: in response to the token information passing verification, obtaining identity information corresponding to the token information; and determining whether the usage permission corresponding to the identity information matches the usage request.

[0072] In some embodiments, determining whether the usage permission corresponding to the identity information matches the usage request includes: providing the identity information, the application identifier of the target application, and the target action corresponding to the usage request to the permission management module; and obtaining authentication information from the permission management module, the authentication information indicating whether the usage permission determined based on the identity information matches the application identifier and the target action.

[0073] In some embodiments, process 400 further includes: in response to the token information failing verification, denying the use request; or in response to the use rights not matching the use request, denying the use request.

[0074] In some embodiments, the target application is created by the target user using the target platform, and the target request is a call to a target interface of the target application, where the target interface is provided based on a configuration operation of the target user in the target platform.

[0075] In some embodiments, token information is included in the header of the usage request.

[0076] Example devices and equipment

[0077] Embodiments of the present disclosure also provide corresponding apparatuses for implementing the above-described methods or processes. FIG5 shows a schematic structural block diagram of an example apparatus 500 for rights management according to certain embodiments of the present disclosure. Apparatus 500 may be implemented as or included in management system 110. Each module / component in apparatus 500 may be implemented by hardware, software, firmware, or any combination thereof.

[0078] As shown in Figure 5, the device 500 includes a request receiving module 510, which is configured to receive a usage request for a target application in the platform, the usage request including token information; a first authentication module 520, which is configured to use token management data to verify the token information, the token management data is generated based on a token creation request of a target user associated with the target application, the token creation request at least indicates the specified permissions regarding at least one workspace of the target user in the platform; a second authentication module 530, which is configured to determine whether the usage permission corresponding to the token information matches the usage request in response to the token information passing the verification; and a request response module 540, which is configured to use the target application to respond to the usage request in response to the usage permission matching the usage request.

[0079] In some embodiments, the device 500 also includes a token creation module, which is configured to: provide a token creation interface to the target user, the token creation interface including a first control for selecting a workspace and a second control for selecting a permission type; and obtain a token creation request based on input information received by the token creation interface.

[0080] In some embodiments, the token creation interface further includes: a third control for inputting a token identification; and / or a fourth control for specifying a validity period of the token.

[0081] In some embodiments, the apparatus 500 further includes a data management module configured to: in response to receiving a token creation request, perform encryption processing on a target token generated based on the token creation request to update token management data.

[0082] In some embodiments, the data management module is further configured to provide the target user with target token information corresponding to the target token.

[0083] In some embodiments, the second authentication module 530 is further configured to: in response to the token information passing verification, obtain identity information corresponding to the token information; and determine whether the usage permission corresponding to the identity information matches the usage request.

[0084] In some embodiments, the second authentication module 530 is further configured to: provide identity information, application identification of the target application, and target action corresponding to the usage request to the permission management module; and obtain authentication information from the permission management module, the authentication information indicating whether the usage permission determined based on the identity information matches the application identification and the target action.

[0085] In some embodiments, the apparatus 500 further includes a request rejection module configured to: reject the use request in response to the token information failing verification; or reject the use request in response to the use permission not matching the use request.

[0086] In some embodiments, the target application is created by the target user using the target platform, and the target request is a call to a target interface of the target application, where the target interface is provided based on a configuration operation of the target user in the target platform.

[0087] In some embodiments, token information is included in the header of the usage request.

[0088] FIG6 shows a block diagram of an electronic device 600 in which one or more embodiments of the present disclosure may be implemented. It should be understood that the electronic device 600 shown in FIG6 is merely exemplary and should not be construed as limiting the functionality and scope of the embodiments described herein. The electronic device 600 shown in FIG6 can be used to implement the management system 110 of FIG1 .

[0089] As shown in FIG6 , electronic device 600 is a general-purpose electronic device. Components of electronic device 600 may include, but are not limited to, one or more processors or processing units 610, memory 620, storage device 630, one or more communication units 640, one or more input devices 650, and one or more output devices 660. Processing unit 610 may be a real or virtual processor and is capable of performing various processes according to programs stored in memory 620. In a multi-processor system, multiple processing units execute computer-executable instructions in parallel to enhance the parallel processing capabilities of electronic device 600.

[0090] The electronic device 600 typically includes a plurality of computer storage media. Such media can be any accessible media that can be obtained by the electronic device 600, including but not limited to volatile and non-volatile media, removable and non-removable media. The memory 620 can be a volatile memory (e.g., registers, cache, random access memory (RAM)), a non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. The storage device 630 can be a removable or non-removable medium and can include a machine-readable medium, such as a flash drive, a disk, or any other medium that can be used to store information and / or data and can be accessed within the electronic device 600.

[0091] The electronic device 600 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not shown in FIG6 , a disk drive for reading or writing from a removable, non-volatile disk (e.g., a “floppy disk”) and an optical drive for reading or writing from a removable, non-volatile optical disk may be provided. In these cases, each drive may be connected to a bus (not shown) by one or more data media interfaces. The memory 620 may include a computer program product 625 having one or more program modules configured to perform various methods or actions of various embodiments of the present disclosure.

[0092] The communication unit 640 enables communication with other electronic devices via a communication medium. Additionally, the functions of the components of the electronic device 600 can be implemented in a single computing cluster or multiple computing machines that can communicate via a communication connection. Thus, the electronic device 600 can operate in a networked environment using a logical connection with one or more other servers, a network personal computer (PC), or another network node.

[0093] The input device 650 may be one or more input devices, such as a mouse, keyboard, or trackball. The output device 660 may be one or more output devices, such as a display, a speaker, or a printer. The electronic device 600 may also communicate with one or more external devices (not shown) through the communication unit 640 as needed, such as a storage device, a display device, or the like, with one or more devices that allow a user to interact with the electronic device 600, or with any device that allows the electronic device 600 to communicate with one or more other electronic devices (e.g., a network card, a modem, etc.). Such communication may be performed via an input / output (I / O) interface (not shown).

[0094] According to an exemplary implementation of the present disclosure, a computer-readable storage medium is provided, on which computer-executable instructions are stored, wherein the computer-executable instructions are executed by a processor to implement the method described above. According to an exemplary implementation of the present disclosure, a computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, and the computer-executable instructions are executed by a processor to implement the method described above.

[0095] Various aspects of the present disclosure are described herein with reference to flowcharts and / or block diagrams of methods, apparatuses, devices, and computer program products implemented according to the present disclosure. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0096] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, such that when these instructions are executed by the processing unit of the computer or other programmable data processing device, a device is generated that implements the functions / actions specified in one or more blocks in the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, where these instructions cause the computer, programmable data processing device, and / or other device to operate in a specific manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in one or more blocks in the flowchart and / or block diagram.

[0097] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operational steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0098] The flow charts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the systems, methods and computer program products according to multiple implementations of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a part for a module, program segment or instruction, and a part for a module, program segment or instruction comprises one or more executable instructions for realizing the logical function of the specification. In some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two continuous boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be realized by a special hardware-based system that performs the function or action of the specification, or can be realized by a combination of special hardware and computer instructions.

[0099] While various implementations of the present disclosure have been described above, the foregoing description is intended to be illustrative, not exhaustive, and not limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is selected to best explain the principles of the implementations, their practical applications, or improvements to existing technologies, or to enable others skilled in the art to understand the various implementations disclosed herein.

Claims

1. A method for rights management, comprising: receiving a usage request for a target application in the platform, wherein the usage request includes token information; verifying the token information using token management data, the token management data being generated based on a token creation request of a target user associated with the target application, the token creation request indicating at least specified permissions for at least one workspace of the target user in the platform; In response to the token information passing the verification, determining whether the usage permission corresponding to the token information matches the usage request; and In response to the usage permission matching the usage request, the usage request is responded to using the target application.

2. The method according to claim 1, further comprising: Providing a token creation interface to the target user, wherein the token creation interface includes a first control for selecting a workspace and a second control for selecting a permission type; as well as The token creation request is obtained based on the input information received by the token creation interface.

3. The method according to claim 2, wherein the token creation interface further comprises: a third control for entering a token identification; and / or A fourth control is used to specify how long the token is valid for.

4. The method according to claim 1, further comprising: In response to receiving the token creation request, encryption processing is performed on a target token generated based on the token creation request to update the token management data.

5. The method according to claim 4, further comprising: Target token information corresponding to the target token is provided to the target user.

6. The method according to claim 1 , wherein determining whether the usage permission corresponding to the token information matches the usage request through verification in response to the token information comprises: In response to the token information passing the verification, obtaining identity information corresponding to the token information; as well as Determine whether the usage permission corresponding to the identity information matches the usage request.

7. The method according to claim 6, wherein determining whether the usage permission corresponding to the identity information matches the usage request comprises: Providing the identity information, the application identifier of the target application, and the target action corresponding to the use request to a rights management module; as well as Authentication information is obtained from the authority management module, where the authentication information indicates whether the usage authority determined based on the identity information matches the application identifier and the target action.

8. The method according to claim 1, further comprising: In response to the token information failing the verification, rejecting the use request; or In response to the usage rights not matching the usage request, denying the usage request.

9. The method according to claim 1, wherein the target application is created by the target user using the target platform, and the target request is a call to a target interface of the target application, wherein the target interface is provided based on a configuration operation of the target user in the target platform.

10. The method of claim 1, wherein the token information is included in a header of the usage request.

11. A device for rights management, comprising: a request receiving module configured to receive a usage request for a target application in the platform, wherein the usage request includes token information; a first authentication module configured to verify the token information using token management data, the token management data being generated based on a token creation request of a target user associated with the target application, the token creation request at least indicating designated permissions regarding at least one workspace of the target user in the platform; a second authentication module configured to, in response to the token information passing verification, determine whether the usage permission corresponding to the token information matches the usage request; as well as The request response module is configured to respond to the use request by using the target application in response to the use permission matching the use request.

12. An electronic device comprising: at least one processing unit; as well as At least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the electronic device to perform the method according to any one of claims 1 to 10 when executed by the at least one processing unit.

13. A computer-readable storage medium having a computer program stored thereon, wherein the computer program can be executed by a processor to implement the method according to any one of claims 1 to 10.

Images