Permission management method and apparatus, and device and storage medium
By generating access tokens based on the OAuth protocol and determining permission matching, the security and applicability of cross-platform resource sharing are solved, secure resource access across trust domains is achieved, and resource access flexibility and security of OAuth protocol in federated identity scenarios are improved.
Patent Information
- Application Number
- PCT/CN2024/094310
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-05-20
- Publication Date
- 2025-07-24
AI Technical Summary
The existing identity authentication and authorization technologies have problems of insufficient universality and security in cross-platform and cross-system resource sharing and management. Especially when dealing with the identification and resource sharing of user identities between different organizations or services, the OAuth protocol has obvious restrictions in the federal identity scenario.
By receiving application requests from the proxy service, generating and sending access tokens, determining that the access request matches the permission information and authorizing the target application to access resources, the extension scheme based on the OAuth protocol is adopted to support flexible settings of policy and condition information to achieve secure resource access across trust domains.
It improves the security and flexibility of resource access, allows three-party platforms to achieve secure resource access across trust domains without registering an identity on one platform, and enhances the applicability of the OAuth protocol in the federated identity scenario.
Smart Images

Figure CN2024094310_24072025_PF_FP_ABST
Abstract
Description
A method, device, equipment and storage medium for rights management Technical Field
[0001] 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
[0002] In the modern information technology sector, with the increasing diversification and complexity of network services, the demand for secure and efficient user authentication and resource access authorization is growing. While existing authentication and authorization technologies have met these needs to a certain extent, they still present numerous challenges in cross-platform and cross-system resource sharing and management. In particular, the universality and security of existing solutions remain to be improved when it comes to user identity identification and resource sharing across different organizations or services.
[0003] Summary of the Invention
[0004] In a first aspect of the present disclosure, a method for permissions management is provided. The method includes: receiving an application request from a proxy service, the application request indicating permission information of a target application with respect to a set of resources; sending an access token corresponding to the permission information to the proxy service; receiving an access request for a target resource from a target application, the access request including the access token; determining whether the access request matches the permission information corresponding to the access token; and, in response to the access request matching the permission information, authorizing the target application to access the target resource.
[0005] In a second aspect of the present disclosure, a device for permission management is provided. The device includes: a first receiving module configured to receive an application request from a proxy service, the application request indicating permission information of a target application regarding a set of resources; a token sending module configured to send an access token corresponding to the permission information to the proxy service; a second receiving module configured to receive an access request for a target resource from a target application, the access request including the access token; a permission verification module configured to determine whether the access request matches the permission information corresponding to the access token; and an access control module configured to authorize the target application to access the target resource in response to a match between the access request and the permission information.
[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] In a fifth aspect of the present disclosure, a computer program product is provided, which includes computer-executable instructions, which, when executed by a processor, implement the method according to the first aspect of the present disclosure.
[0009] 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
[0010] 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:
[0011] FIG1 illustrates the architecture of an example system capable of implementing some embodiments of the present disclosure;
[0012] FIG2 shows a flowchart of a rights management process according to some embodiments of the present disclosure;
[0013] FIG3 shows a schematic structural block diagram of an example apparatus for rights management according to some embodiments of the present disclosure; and
[0014] FIG4 illustrates a block diagram of an electronic device capable of implementing various embodiments of the present disclosure. DETAILED DESCRIPTION
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] Any solutions in this specification and the embodiments that involve personal rights management will be processed only with a legitimate basis (such as obtaining the consent of the personal information subject 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.
[0020] With the rapid development of information technology, identity authentication and access control play an increasingly important role in protecting network resources. Among the numerous identity authentication and access control mechanisms, the OAuth (Open Authorization) protocol has become a key technical standard due to its flexibility and wide application base.
[0021] The OAuth protocol is an industry-standard authorization protocol that allows users to grant third-party applications access to their private resources stored on another service without directly providing their username and password to the third-party application. This mechanism protects user privacy while enabling third-party applications to securely access the resources they need.
[0022] While OAuth and its extended protocols provide effective solutions in many scenarios, they still have some limitations when dealing with federated identity authentication and authorization. For example, JWT Flow requires applications to initiate resource access using their own identities, which may not be suitable for mobile or native applications, as these applications need to securely store their own credentials. PKCE Flow, while accessing resources on behalf of the user, requires the user to register their identity information in the same trust domain as the authentication server, which limits its applicability in broader federated identity scenarios.
[0023] Embodiments of the present disclosure provide a scheme for permission management. The scheme includes: receiving an application request from a proxy service, the application request indicating permission information of a target application with respect to a set of resources; sending an access token corresponding to the permission information to the proxy service; receiving an access request for a target resource from a target application, the access request including the access token; determining whether the access request matches the permission information corresponding to the access token; and, in response to the access request matching the permission information, authorizing the target application to access the target resource.
[0024] In this way, the embodiments of the present disclosure can improve the security and flexibility of resource access. Various example implementations of the solution are described in detail below in conjunction with the accompanying drawings.
[0025] Example System
[0026] FIG1 illustrates the architecture of an example system 100 according to some embodiments of the present disclosure. As shown in FIG1 , system 100 may include a first trust domain 110, which may include an authorization service 125 for managing access rights and protected resources 160. Additionally, system 100 may also include a second trust domain 105, which may include a proxy service 130 and an application 150.
[0027] In this disclosure, a trust domain refers to a set of entities or systems that trust each other in a specific context. Entities or systems within the trust domain can authenticate each other's identities through public or private protocols.
[0028] As an example, the resources 160 may include, for example, working controls, interfaces, agents, etc. provided in the application platform. The application 150 may, for example, provide corresponding services by accessing such resources 160 .
[0029] In some embodiments, as shown in FIG1 , at step 120 , the administrator 115 may register a third-party application (eg, application 150 ) with the authorization service 125 within the first trust domain 110 , declare the permissions required by the application, and upload information such as the application public key.
[0030] Furthermore, when application 150 needs to access resources 160 within first trust domain 110, proxy service 130 may apply for a corresponding federated identity for application 150. Specifically, in step 135, proxy server 135 may send an application request to authorization service 120, where the application request may indicate permission information of the target application regarding a set of resources.
[0031] In some embodiments, the permission information may include policy information to indicate an access control policy for a first resource in a group of resources. For example, such permission information may indicate resource-level authorization granularity to define a specific permission scope for each resource.
[0032] For example, such policy information can be an attribute-based access control (ABAC) authorization model. ABAC controls access to an operation object based on entity attributes, operation type, and related environment, providing a highly context-sensitive access control approach that enables fine-grained access control. For example, such policy information can indicate that a first type of access permission is granted to a first workspace, and a second type of access permission is granted to a second workspace.
[0033] In some embodiments, the permission information may further include condition information to indicate an access control condition associated with a second resource in the group of resources.
[0034] In some embodiments, such condition information may indicate, for example, a data transmission channel that is allowed to access the second resource. For example, the condition information may indicate that access to a specific resource is only allowed through a secure data transmission channel under a specific protocol.
[0035] Alternatively or additionally, such condition information may indicate a network address range that is allowed to access the second resource. For example, the condition information may indicate a range of IP addresses that are allowed to access a specific resource.
[0036] Alternatively or additionally, such condition information may indicate a client version that is allowed to access the second resource. For example, the condition information may indicate that only a specific client version (eg, a mobile client version) is allowed to access a specific resource.
[0037] Based on this approach, the embodiments of the present disclosure can support the setting of access control conditions, thereby improving the flexibility of authority management.
[0038] In some embodiments, the application request includes structured data indicating permission information. As an example, the proxy service 130 may encapsulate the structured data representing the permission information in the application request.
[0039] In some embodiments, such an application request is generated based on the OAuth protocol. For example, the application request can be constructed based on the OAuth JWT Flow (RFC7523). Additionally, such structured data can be included in the target field of the OAuth protocol. As an example, such a target field can include, but is not limited to, the scope defined by the OAuth protocol, other existing fields, or fields added in the future.
[0040] Furthermore, in step 140 , the authorization service 125 may generate a corresponding access token based on the received application request, and send the access token to the proxy service 130 .
[0041] At step 145 , the proxy service 130 establishes a secure transmission channel to distribute the received access token to the application 150 .
[0042] As shown in Figure 1, proxy service 130 and application 150 are within the same trust domain 105. The authentication scheme between entities within trust domain 105 depends on the design of the trust domain itself. Such schemes may include, but are not limited to, common authentication protocols: Kerberos v5 (RFC1510), OAuth2 / OIDC (RFC6749), FIDO (RFC8812), and LDAP (RFC4511). This disclosure is not intended to limit the authentication scheme within trust domain 105. As an example, the secure communication channel used for communication between proxy service 130 and application 150 can be constructed based on the TLS or DTLS algorithms mentioned in BCP 195 (RFC9325), but this disclosure is not intended to limit this.
[0043] Further, at step 155 , the application 150 may encapsulate the received access token in an access request, and may send the access request to the resource 160 .
[0044] Furthermore, the authentication service 130 or other appropriate authentication module (not shown in the figure) may determine whether the access request matches the permission information corresponding to the access token.
[0045] Specifically, attribute information of the access request may be determined. Such attribute information may include, for example, at least one of the following: a target resource to be accessed, an access type for the target resource, and application description information associated with the target application.
[0046] Furthermore, it can be determined whether the attribute information matches the permission information. For example, if the resource indicated by the attribute information is included in a group of resources indicated by the permission information, and the access type of the access request matches the permission range indicated by the permission information, then it can be determined that the attribute information matches the permission information.
[0047] As another example, when the permission information also indicates an access control policy, it can also be determined whether it matches the access control policy based on application description information associated with the target application (for example, the type of data transmission channel, the network address for sending the access request, or the version information of the application, etc.).
[0048] For example, if the application description information indicates a data transmission channel, a network address, and / or version information that is consistent with the access control policy, it can be determined that the access request matches the permission information.
[0049] Accordingly, if it is determined that the access request matches the permission information, the application 150 may be authorized to access the resource 160, for example, to provide the corresponding service using the resource 160. Conversely, in response to the access request not matching the permission information, the access request may be denied accordingly.
[0050] Based on this approach, the embodiments of the present disclosure address the challenges of OAuth services in federated identity scenarios, allowing identities on three platforms to securely access resources across trust domains without registering their identities on a single platform. Furthermore, by extending the OAuth protocol, the embodiments of the present disclosure enhance the security and flexibility of resource access.
[0051] Example Process
[0052] FIG2 shows a flowchart of an example process 200 for rights management according to some embodiments of the present disclosure. The process 200 shown in FIG2 will be described below with reference to FIG1 .
[0053] In block 210 , the system 100 receives an application request from a proxy service, the application request indicating permission information of a target application with respect to a set of resources.
[0054] In block 220 , the system 100 sends an access token corresponding to the permission information to the proxy service.
[0055] In block 230 , the system 100 receives an access request for a target resource from a target application, the access request including an access token.
[0056] At block 240 , the system 100 determines whether the access request matches the permission information corresponding to the access token.
[0057] At block 250 , in response to the access request matching the permission information, the system 100 authorizes the target application to access the target resource.
[0058] In some embodiments, the permission information includes policy information indicating an access control policy for a first resource in a group of resources.
[0059] In some embodiments, the permission information includes condition information indicating an access control condition associated with a second resource in the set of resources.
[0060] In some embodiments, the access control condition indicates at least one of the following: a data transmission channel for allowing access to the second resource; a network address range for allowing access to the second resource; and a client version for allowing access to the second resource.
[0061] In some embodiments, the application request includes structured data indicating permission information.
[0062] In some embodiments, the application request is generated based on the OAuth protocol, and the structured data is included in a target field in the OAuth protocol.
[0063] In some embodiments, the access token is sent from the proxy service to the target application via a secure communication channel.
[0064] In some embodiments, determining whether an access request matches permission information corresponding to an access token includes: determining attribute information of the access request, the attribute information including at least one of the following: a target resource, an access type for the target resource, and application description information associated with a target application; and determining whether the attribute information matches the permission information.
[0065] In some embodiments, process 200 further includes denying the access request in response to the access request not matching the permission information.
[0066] In some embodiments, the access token is generated by an authorization service, the authorization service and the target resource are in a first trust domain, and the proxy service and the target application are in a second trust domain.
[0067] Example devices and equipment
[0068] Embodiments of the present disclosure also provide corresponding apparatuses for implementing the above-described methods or processes. FIG3 shows a schematic structural block diagram of an example apparatus 300 for rights management according to certain embodiments of the present disclosure. Apparatus 300 may be implemented as or included in an electronic device. Each module / component in apparatus 300 may be implemented by hardware, software, firmware, or any combination thereof.
[0069] As shown in Figure 3, the device 300 includes a first receiving module 310, which is configured to receive an application request from a proxy service, the application request indicating the permission information of the target application regarding a set of resources; a token sending module 320, which is configured to send an access token corresponding to the permission information to the proxy service; a second receiving module 330, which is configured to receive an access request for the target resource from the target application, the access request including the access token; a permission verification module 340, which is configured to determine whether the access request matches the permission information corresponding to the access token; and an access control module 350, which is configured to authorize the target application to access the target resource in response to the access request matching the permission information.
[0070] In some embodiments, the permission information includes policy information indicating an access control policy for a first resource in a group of resources.
[0071] In some embodiments, the permission information includes condition information indicating an access control condition associated with a second resource in the set of resources.
[0072] In some embodiments, the access control condition indicates at least one of the following: a data transmission channel for allowing access to the second resource; a network address range for allowing access to the second resource; and a client version for allowing access to the second resource.
[0073] In some embodiments, the application request includes structured data indicating permission information.
[0074] In some embodiments, the application request is generated based on the OAuth protocol, and the structured data is included in a target field in the OAuth protocol.
[0075] In some embodiments, the access token is sent from the proxy service to the target application via a secure communication channel.
[0076] In some embodiments, the permission verification module 340 is further configured to: determine attribute information of the access request, the attribute information including at least one of the following: target resource, access type for the target resource, application description information associated with the target application; and determine whether the attribute information matches the permission information.
[0077] In some embodiments, the access control module 350 is further configured to deny the access request in response to the access request not matching the permission information.
[0078] In some embodiments, the access token is generated by an authorization service, the authorization service and the target resource are in a first trust domain, and the proxy service and the target application are in a second trust domain.
[0079] FIG4 shows a block diagram of an electronic device 400 in which one or more embodiments of the present disclosure may be implemented. It should be understood that the electronic device 400 shown in FIG4 is merely exemplary and should not be construed as limiting the functionality and scope of the embodiments described herein. The electronic device 400 shown in FIG4 can be used to implement the training system 100.
[0080] As shown in FIG4 , electronic device 400 is a general-purpose electronic device. Components of electronic device 400 may include, but are not limited to, one or more processors or processing units 410, memory 420, storage device 430, one or more communication units 440, one or more input devices 450, and one or more output devices 460. Processing unit 410 may be a real or virtual processor and is capable of performing various processes according to programs stored in memory 420. In a multi-processor system, multiple processing units execute computer-executable instructions in parallel to increase the parallel processing capabilities of electronic device 400.
[0081] The electronic device 400 typically includes a plurality of computer storage media. Such media can be any accessible media that can be obtained by the electronic device 400, including but not limited to volatile and non-volatile media, removable and non-removable media. The memory 420 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 430 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 400.
[0082] The electronic device 400 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not shown in FIG. 4 , a disk drive for reading from or writing to a removable, non-volatile disk (e.g., a “floppy disk”) and an optical drive for reading from or writing to 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 420 may include a computer program product 425 having one or more program modules configured to perform various methods or actions of various embodiments of the present disclosure.
[0083] The communication unit 440 enables communication with other electronic devices via a communication medium. Additionally, the functions of the components of the electronic device 400 can be implemented in a single computing cluster or multiple computing machines that can communicate via a communication connection. Thus, the electronic device 400 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.
[0084] Input device 450 may be one or more input devices, such as a mouse, keyboard, or trackball. Output device 460 may be one or more output devices, such as a display, a speaker, or a printer. Electronic device 400 may also communicate with one or more external devices (not shown) via communication unit 440 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 electronic device 400, or with any device that allows electronic device 400 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).
[0085] 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.
[0086] 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.
[0087] 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.
[0088] 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.
[0089] 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.
[0090] 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 permission management, comprising: Receiving an application request from a proxy service, the application request indicating permission information of a target application regarding a set of resources; Sending an access token corresponding to the permission information to the proxy service; Receiving an access request for a target resource from the target application, the access request including the access token; Determining whether the access request matches the permission information corresponding to the access token; And In response to the access request matching the permission information, authorizing the target application to access the target resource.
2. The method according to claim 1, wherein the permission information includes policy information, and the policy information indicates an access control policy for a first resource in the set of resources.
3. The method according to claim 1, wherein the permission information includes condition information, and the condition information indicates access control conditions associated with a second resource in the set of resources.
4. The method according to claim 3, wherein the access control conditions indicate at least one of the following: Allowing access to the data transmission channel of the second resource; Allowing access to the network address range of the second resource; Allowing access to the client version of the second resource.
5. The method according to claim 1, wherein the application request includes structured data indicating the permission information.
6. The method according to claim 5, wherein the application request is generated based on the OAuth protocol, and the structured data is included in a target field in the OAuth protocol.
7. The method according to claim 1, wherein the access token is sent from the proxy service to the target application via a secure communication channel.
8. The method according to claim 1, wherein determining whether the access request matches the permission information corresponding to the access token includes: Determining attribute information of the access request, the attribute information including at least one of the following: the target resource, the access type for the target resource, application description information associated with the target application; And Determining whether the attribute information matches the permission information.
9. The method according to claim 1, further comprising: In response to the access request not matching the permission information, rejecting the access request.
10. The method according to claim 1, wherein the access token is generated by an authorization service, the authorization service and the target resource are in a first trust domain, and the proxy service and the target application are in a second trust domain.
11. An apparatus for permission management, comprising: A first receiving module configured to receive an application request from a proxy service, the application request indicating permission information of a target application regarding a set of resources; A token sending module configured to send an access token corresponding to the permission information to the proxy service; A second receiving module configured to receive an access request for a target resource from the target application, the access request including the access token; A permission verification module configured to determine whether the access request matches the permission information corresponding to the access token; And An access control module, configured to authorize the target application to access the target resource in response to a match between the access request and the permission information.
12. An electronic device, comprising: At least one processing unit; And At least one memory, the at least one memory being coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions, when executed by the at least one processing unit, causing the electronic device to perform the method according to any one of claims 1 to 10.
13. A computer-readable storage medium having stored thereon a computer program, the computer program being executable by a processor to implement the method according to any one of claims 1 to 10.
14. A computer program product, comprising computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the method according to any one of claims 1 to 10.
Citation Information
Patent Citations
Token obtaining method and device
CN103780396A
Authentication reverse proxy method and system
CN112311783A
Client authentication and access token ownership validation
EP3879784A1
Method of token agency service in medical information solution system
KR101781125B1
Cited By
Software authorization control method and device and storage medium
CN120671113A
Method, device and equipment for identifying automatic access attack of firewall
CN120785627A
Access control method and device, equipment and storage medium
CN121278755A