WO2024234192A1 - Authorization revocation method and apparatus - Google Patents

Abstract

Disclosed in embodiments of the present application are an authorization revocation method and an apparatus, which can be applied to a communication system. The method comprises: sending a first authorization revocation request to a first entity in a CAPIF, wherein the first authorization revocation request is used for indicating a refresh token related to a resource owner. In the technical solution, a second entity sends to a first entity an authorization revocation request for indicating a refresh token, to achieve the objective of revoking authorization, thereby deleting a large amount of security and authorization information stored in a CCF, reducing the burden of the CCF, improving the performance of the CAPIF, and thus improving the data processing speed and efficiency.

Description

A method and device for revoking authorization Technical Field

The present application relates to the field of communication technology, and in particular to an authorization revocation method and device thereof.

Background Art

In the scenario of subscriber-aware northbound API access (SNA), authorization can be obtained from the resource owner through the core function of the common API framework (CAPIF core function, CCF), and the target resource can be accessed according to the authorization information. In this process, CCF needs to store all security and authorization information related to the API caller and the resource owner. Since CCF cannot clear a large amount of security and authorization information, it occupies a large amount of memory, which brings a burden to CCF and affects the performance of the common API framework.

Summary of the invention

The embodiment of the present application provides an authorization revocation method and device, which can be applied in the communication field to solve the problem that CCF cannot clear a large amount of security and authorization information, reduce the burden of CCF, and improve the performance of the general API framework.

In a first aspect, an embodiment of the present application provides a method for revoking authorization, the method comprising:

A first authorization revocation request is sent to a first entity in a common application programming interface CAPIF framework, wherein the first authorization revocation request is used to indicate a refresh token related to a resource owner.

In this technical solution, the second entity sends an indicated refresh token authorization revocation request to the first entity to achieve the purpose of revoking authorization, thereby deleting a large amount of security and authorization information stored in the CCF, reducing the burden on the CCF, improving the performance of the CAPIF framework, and thereby improving the speed and efficiency of processing data.

In a second aspect, an embodiment of the present application provides another authorization revocation method, the method comprising:

A first authorization revocation request or a third authorization revocation request is received, wherein the first authorization revocation request or the second authorization revocation request is used to indicate a refresh token associated with a resource owner; and a revocation operation is performed on the refresh token based on the first authorization revocation request or the third authorization revocation request.

In a third aspect, an embodiment of the present application provides another authorization revocation method, the method comprising:

Send a second authorization revocation request to a second entity, wherein the second authorization revocation request is used to determine the first authorization revocation request sent to the first entity; or, send a third authorization revocation request to the first entity in the CAPIF framework; wherein the first authorization revocation request or the second authorization revocation or the third authorization revocation request is used to indicate a refresh token associated with a resource owner.

In a fourth aspect, an embodiment of the present application provides a communication device, which has the function of implementing some or all of the functions of the second entity in the method described in the first aspect above. For example, the functions of the communication device may have the functions of some or all of the embodiments in the present application, or may have the functions of implementing any one of the embodiments in the present application separately. The functions may be implemented by hardware, or may be implemented by hardware executing corresponding software. The hardware or software includes one or more units or modules corresponding to the above functions.

In one implementation, the structure of the communication device may include a transceiver module and a processing module, and the processing module is configured to support the communication device to perform the corresponding functions in the above method. The transceiver module is used to support communication between the communication device and other devices. The communication device may also include a storage module, which is used to couple with the transceiver module and the processing module, and store the computer programs and data necessary for the communication device.

As an example, the processing module may be a processor, the transceiver module may be a transceiver or a communication interface, and the storage module may be a memory.

In a fifth aspect, an embodiment of the present application provides another communication device, which has some or all of the functions of the first entity in the CAPIF framework in the method example described in the second aspect above. For example, the functions of the communication device may have the functions of some or all of the embodiments in the present application, or may have the functions of implementing any one of the embodiments in the present application separately. The functions may be implemented by hardware, or by executing corresponding software implementations through hardware. The hardware or software includes one or more units or modules corresponding to the above functions.

In one implementation, the structure of the communication device may include a transceiver module and a processing module, and the processing module is configured to support the communication device to perform the corresponding functions in the above method. The transceiver module is used to support communication between the communication device and other devices. The communication device may also include a storage module, which is used to couple with the transceiver module and the processing module, and store the computer programs and data necessary for the communication device.

As an example, the processing module may be a processor, the transceiver module may be a transceiver or a communication interface, and the storage module may be a memory.

In a sixth aspect, an embodiment of the present application provides another communication device, which has some or all of the functions of the resource owner client or terminal device in the method example described in the third aspect above. For example, the functions of the communication device may have some or all of the functions in the embodiments of the present application, or may have the functions of implementing any one of the embodiments of the present application alone. The functions may be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more units or modules corresponding to the above functions.

In one implementation, the structure of the communication device may include a transceiver module and a processing module, and the processing module is configured to support the communication device to perform the corresponding functions in the above method. The transceiver module is used to support communication between the communication device and other devices. The communication device may also include a storage module, which is used to couple with the transceiver module and the processing module, and store the computer programs and data necessary for the communication device.

As an example, the processing module may be a processor, the transceiver module may be a transceiver or a communication interface, and the storage module may be a memory.

In a seventh aspect, an embodiment of the present application provides a communication device, which includes a processor. When the processor calls a computer program in a memory, the method described in the first aspect is executed.

In an eighth aspect, an embodiment of the present application provides a communication device, which includes a processor. When the processor calls a computer program in a memory, the method described in the second aspect is executed.

In a ninth aspect, an embodiment of the present application provides a communication device, which includes a processor. When the processor calls a computer program in a memory, the method described in the third aspect is executed.

In a tenth aspect, an embodiment of the present application provides a communication device, the communication device comprising a processor and a memory, the memory storing a computer program; the processor executes the computer program stored in the memory to enable the communication device to The method described in the first aspect is executed.

In the eleventh aspect, an embodiment of the present application provides a communication device, which includes a processor and a memory, in which a computer program is stored; the processor executes the computer program stored in the memory so that the communication device executes the method described in the second aspect above.

In the twelfth aspect, an embodiment of the present application provides a communication device, which includes a processor and a memory, in which a computer program is stored; the processor executes the computer program stored in the memory so that the communication device executes the method described in the third aspect above.

In a thirteenth aspect, an embodiment of the present application provides a communication device, which includes a processor and an interface circuit, wherein the interface circuit is used to receive code instructions and transmit them to the processor, and the processor is used to run the code instructions to enable the device to execute the method described in the first aspect above.

In a fourteenth aspect, an embodiment of the present application provides a communication device, which includes a processor and an interface circuit, wherein the interface circuit is used to receive code instructions and transmit them to the processor, and the processor is used to run the code instructions to enable the device to execute the method described in the second aspect above.

In a fifteenth aspect, an embodiment of the present application provides a communication device, which includes a processor and an interface circuit, wherein the interface circuit is used to receive code instructions and transmit them to the processor, and the processor is used to run the code instructions to enable the device to execute the method described in the third aspect above.

In the sixteenth aspect, an embodiment of the present application provides an authorization revocation system, the system comprising the communication device described in the fourth aspect, the communication device described in the fifth aspect, and the communication device described in the sixth aspect, or the system comprising the communication device described in the seventh aspect, the communication device described in the eighth aspect, and the communication device described in the ninth aspect, or the system comprising the communication device described in the tenth aspect, the communication device described in the eleventh aspect, and the communication device described in the twelfth aspect, or the system comprising the communication device described in the thirteenth aspect, the communication device described in the fourteenth aspect, and the communication device described in the fifteenth aspect.

In a seventeenth aspect, an embodiment of the present invention provides a computer-readable storage medium for storing instructions for the second entity, and when the instructions are executed, the second entity executes the method described in the first aspect.

In an eighteenth aspect, an embodiment of the present invention provides a readable storage medium for storing instructions used by a first entity in the above-mentioned CAPIF framework. When the instructions are executed, the first entity in the CAPIF framework executes the method described in the above-mentioned second aspect.

In the nineteenth aspect, an embodiment of the present invention provides a readable storage medium for storing instructions used by the above-mentioned resource owner client or terminal device. When the instructions are executed, the resource owner client or terminal device executes the method described in the above-mentioned third aspect.

In the twentieth aspect, the present application also provides a computer program product comprising a computer program, which, when executed on a computer, enables the computer to execute the method described in the first aspect above.

In the twenty-first aspect, the present application also provides a computer program product comprising a computer program, which, when executed on a computer, enables the computer to execute the method described in the second aspect above.

In the twenty-second aspect, the present application also provides a computer program product comprising a computer program, which, when executed on a computer, enables the computer to execute the method described in the third aspect above.

In the twenty-third aspect, the present application provides a chip system, which includes at least one processor and an interface, for supporting the second entity to implement the functions involved in the first aspect, for example, determining or processing at least one of the data and information involved in the above method. In one possible design, the chip system also includes a memory, which is used to store computer programs and data necessary for the second entity. The chip system can be composed of chips, or it can include chips and other discrete devices.

In the twenty-fourth aspect, the present application provides a chip system, which includes at least one processor and an interface, for supporting the first entity in the CAPIF framework to implement the functions involved in the second aspect, for example, determining or processing at least one of the data and information involved in the above method. In one possible design, the chip system also includes a memory, which is used to store the necessary computer programs and data for the first entity in the CAPIF framework. The chip system can be composed of chips, or it can include chips and other discrete devices.

In the twenty-fifth aspect, the present application provides a chip system, which includes at least one processor and an interface, and is used to support the resource owner client or terminal device to implement the functions involved in the third aspect, for example, determining or processing at least one of the data and information involved in the above method. In one possible design, the chip system also includes a memory, which is used to store computer programs and data necessary for the resource owner client or terminal device. The chip system can be composed of a chip, or it can include a chip and other discrete devices.

In the twenty-sixth aspect, the present application provides a computer program which, when executed on a computer, enables the computer to execute the method described in the first aspect above.

In the twenty-seventh aspect, the present application provides a computer program which, when executed on a computer, enables the computer to execute the method described in the second aspect above.

In the twenty-eighth aspect, the present application provides a computer program which, when executed on a computer, enables the computer to execute the method described in the third aspect above.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions in the embodiments of the present application or the background technology, the drawings required for use in the embodiments of the present application or the background technology will be described below.

FIG1 is a schematic diagram of the architecture of a communication system provided in an embodiment of the present application;

FIG2 is a flow chart of an authorization revocation method provided in an embodiment of the present application;

FIG3 is a flow chart of another authorization revocation method provided in an embodiment of the present application;

FIG4 is a flow chart of another authorization revocation method provided in an embodiment of the present application;

FIG5 is a flow chart of another authorization revocation method provided in an embodiment of the present application;

FIG6 is a flow chart of another authorization revocation method provided in an embodiment of the present application;

FIG7 is a flow chart of another authorization revocation method provided in an embodiment of the present application;

FIG8 is a flow chart of another authorization revocation method provided in an embodiment of the present application;

FIG9 is a flow chart of another authorization revocation method provided in an embodiment of the present application;

FIG10 is a flow chart of another authorization revocation method provided in an embodiment of the present application;

FIG11 is a flow chart of another authorization revocation method provided in an embodiment of the present application;

FIG12 is an interactive schematic diagram of an authorization revocation method provided in an embodiment of the present application;

FIG13 is an interactive schematic diagram of another authorization revocation method provided in an embodiment of the present application;

FIG14 is a schematic diagram of the structure of a communication device provided in an embodiment of the present application;

FIG15 is a schematic diagram of the structure of another communication device provided in an embodiment of the present application;

FIG16 is a schematic diagram of the structure of a chip provided in an embodiment of the present application;

FIG17 is a communication system for authorization revocation provided in an embodiment of the present application;

FIG. 18 is another communication system for authorization revocation provided in an embodiment of the present application.

DETAILED DESCRIPTION

Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. Instead, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

The terms used in the disclosed embodiments are only for the purpose of describing specific embodiments and are not intended to limit the disclosed embodiments. The singular forms of "a", "an" and "the" used in the disclosed embodiments and the appended claims are also intended to include plural forms unless the context clearly indicates other meanings. It should also be understood that the term "and/or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

It should be understood that, although the terms first, second, third, etc. may be used to describe various information in the embodiments of the present disclosure, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the embodiments of the present disclosure, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining" for the purpose of brevity and ease of understanding, the terms used herein when characterizing the size relationship are "greater than" or "less than", "higher than" or "lower than". However, for those skilled in the art, it can be understood that the term "greater than" also covers the meaning of "greater than or equal to", and "less than" also covers the meaning of "less than or equal to"; the term "higher than" covers the meaning of "higher than or equal to", and "lower than" also covers the meaning of "lower than or equal to".

In order to better understand the authorization revocation method disclosed in the embodiment of the present application, the communication system to which the embodiment of the present application is applicable is first described below.

Please refer to Figure 1, which is a schematic diagram of the architecture of a communication system provided in an embodiment of the present application. The communication system may include, but is not limited to, a network device and a terminal device. The number and form of devices shown in Figure 1 are only used for example and do not constitute a limitation on the embodiment of the present application. In actual applications, two or more network devices and two or more terminal devices may be included. The communication system shown in Figure 1 includes a network device 101 and a terminal device 102 as an example.

It should be noted that the technical solutions of the embodiments of the present application can be applied to various communication systems. For example: the third generation (3G) universal mobile telecommunications system (UMTS) long term evolution (LTE) system, the fifth generation (5G) mobile communication system, the 5G new radio (NR) system, the sixth generation (6G) mobile communication system or other New mobile communication systems in the future, etc.

The network device 101 in the embodiment of the present application is an entity on the network side for transmitting or receiving signals. For example, the network device 101 may be an evolved NodeB (eNB), a transmission point (TRP), a next generation NodeB (gNB) in an NR system, a base station in other future mobile communication systems, or an access node in a wireless fidelity (WiFi) system. The embodiment of the present application does not limit the specific technology and specific device form adopted by the network device. The network device provided in the embodiment of the present application may be composed of a central unit (CU) and a distributed unit (DU), wherein the CU may also be referred to as a control unit. The CU-DU structure may be used to split the protocol layer of the network device, such as a base station, and the functions of some protocol layers are placed in the CU for centralized control, and the functions of the remaining part or all of the protocol layers are distributed in the DU, and the DU is centrally controlled by the CU.

The terminal device 102 in the embodiment of the present application is an entity for receiving or transmitting signals on the user side, such as a mobile phone. The terminal device may also be referred to as a terminal device (terminal), a user equipment (UE), a mobile station (MS), a mobile terminal device (MT), etc. The terminal device may be a car with communication function, a smart car, a mobile phone (mobile phone), a wearable device, a tablet computer (Pad), a computer with wireless transceiver function, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal device in industrial control (industrial control), a wireless terminal device in self-driving, a wireless terminal device in remote medical surgery, a wireless terminal device in smart grid (smart grid), a wireless terminal device in transportation safety (transportation safety), a wireless terminal device in a smart city (smart city), a wireless terminal device in a smart home (smart home), etc. The embodiments of the present application do not limit the specific technology and specific device form adopted by the terminal device.

It can be understood that the communication system described in the embodiment of the present application is for more clearly illustrating the technical solution of the embodiment of the present application, and does not constitute a limitation on the technical solution provided in the embodiment of the present application. Ordinary technicians in this field can know that with the evolution of the system architecture and the emergence of new business scenarios, the technical solution provided in the embodiment of the present application is also applicable to similar technical problems.

It should be noted that the authorization revocation method provided in any embodiment of the present application can be executed alone, or in combination with possible implementation methods in other embodiments, or in combination with any technical solution in the relevant technology.

The authorization revocation method and device provided by the present application are described in detail below in conjunction with the accompanying drawings.

Please refer to Figure 2, which is a flow chart of a method for revoking authorization provided in an embodiment of the present application. The method for revoking authorization may be performed by a second entity. As shown in Figure 2, the method may include but is not limited to the following steps:

S201: Send a first authorization revocation request to a first entity in a CAPIF framework, where the first authorization revocation request is used to indicate a refresh token related to a resource owner.

In some implementations, the second entity may be an API caller, and optionally, the API caller may be an application function or a client running on a terminal.

In some implementations, the first entity in the CAPIF framework may include a CAPIF core function (CCF) or an authorization function (Authorization It should be noted that the first entity is one of the CCF network element and the authorization function. The CCF network element or the authorization function will be integrated under certain conditions, that is, the CCF network element can also assume the responsibility of the authorization function at the same time.

In some implementations, the API caller can obtain a refresh token associated with the resource owner from the CCF or authorization function in CAPIF. In some implementations, the API caller can perform authorization interaction with the CCF or authorization function based on a network protocol to obtain a refresh token associated with the resource owner.

In some implementations, the refresh token associated with the resource owner is a refresh token that includes identification information of the resource owner. Optionally, the resource owner identifier can be a generic public subscription identifier (GPSI).

In some implementations, a refresh token associated with a resource owner can be used to generate an access token for a resource, so that an API caller can access the corresponding resource based on the access token.

In some implementations, the API caller may send a first authorization revocation request to the first entity, wherein the first authorization revocation request is used to indicate a refresh token associated with the resource owner.

In some implementations, if the first authorization revocation request includes a refresh token, the refresh token includes the resource owner identifier.

Optionally, the first authorization revocation request may explicitly indicate a refresh token associated with the resource owner. The API caller may directly send the refresh token associated with the resource owner to the first entity by carrying it in the first authorization revocation request.

Optionally, the first authorization revocation request may implicitly indicate a refresh token associated with the resource owner. The first authorization revocation request sent by the API caller may carry parameter information about the refresh token, and the first entity may indicate the refresh token according to the parameter information. For example, the first authorization revocation request includes at least one of the following information: a resource identifier of the authorized resource; an operation identifier of a semantic operation executable on the authorized resource; identification information of the second entity; and identification information of the resource owner.

In some implementations, the first authorization revocation request may include identification information of the resource owner. The first entity may determine the refresh token that needs to be revoked based on the identification information of the resource owner in the first revocation request, and revoke the refresh token.

In some implementations, the resource owner is an end user or a subscriber associated with an end user or a human being.

In some implementations, after obtaining the refresh token, the API caller (API invoker) can send an access token application request to the first entity. Accordingly, after receiving the access token application request, the first entity can generate an access token based on the refresh token. The API caller can receive the access token sent by the first entity and send the access token to the resource owner. Further, the API caller can access the corresponding resource based on the access token.

In some implementations, the API caller can send a refresh token and/or a token type of the refresh token to the first entity via the first authorization revocation request.

In an embodiment of the present application, the API caller sends an authorization revocation request indicating a refresh token to the first entity to achieve the purpose of revoking authorization, thereby deleting a large amount of security and authorization information stored in the CCF, reducing the burden on the CCF, improving the performance of the CAPIF framework, and thereby improving the speed and efficiency of processing data.

Please refer to Figure 3, which is a flowchart of a method for revoking authorization provided by an embodiment of the present application. The method may be performed by the second entity. As shown in FIG3 , the method may include but is not limited to the following steps:

S301, sending a first authorization revocation request to a first entity in the CAPIF framework.

In some implementations, the second entity may be an API caller, and optionally, the API caller may be an application function or a client running on a terminal.

In the embodiment of the present application, the implementation method of step S301 can be implemented by any method in the embodiments of the present application, which is not limited here and will not be repeated.

S302: Receive a revocation response message corresponding to a first authorization revocation request sent by a first entity.

In some implementations, after receiving the first authorization revocation request, the first entity can perform a revocation operation based on the refresh token indicated by the first authorization revocation request. After completing the revocation operation, the first entity can generate a revocation response message corresponding to the first authorization revocation request and feedback it to the API caller. The API caller can determine whether the refresh token is successfully revoked based on the revocation response message. If it is not successfully revoked, the refresh token can be sent again to revoke authorization.

Based on the above embodiment, the authorization revocation method may further include the following steps:

S303: Send a revocation response message to the terminal device or the resource owner client or the resource owner.

In some implementations, after receiving the revocation response message corresponding to the first authorization revocation request sent by the first entity, the API caller should also send a revocation response message to the terminal device or the resource owner client or the resource owner. The terminal device or the resource owner client or the resource owner can determine whether the refresh token is successfully revoked based on the revocation response message. If it is not successfully revoked, the refresh token can be revoked again.

In an embodiment of the present application, the API caller sends an authorization revocation request indicating a refresh token to the first entity. The API caller also needs to accept the revocation response message sent by the first entity and send a revocation response message to the terminal device or resource owner client or resource owner to achieve the purpose of revoking authorization. This deletes a large amount of security and authorization information stored in the CCF, reduces the burden on the CCF, improves the performance of the CAPIF framework, and improves the speed and efficiency of processing data. The API caller and the terminal device or resource owner client or resource owner receive the revocation response message sent by the first entity, and can promptly understand whether the revocation of authorization is successful, and then terminate the authorization in a timely manner.

Please refer to Figure 4, which is a flow chart of a method for revoking authorization provided in an embodiment of the present application. The method for revoking authorization may be performed by a second entity. As shown in Figure 4, the method may include but is not limited to the following steps:

S401: Receive a second authorization revocation request.

In some implementations, the second entity may be an API caller, and optionally, the API caller may be an application function or a client running on a terminal.

It should be noted that, in order to obtain a refresh token associated with a resource owner, the API caller (API invoker) can perform authorization interaction with the first entity through a network protocol to obtain a refresh token associated with the resource owner. Furthermore, the API caller can obtain an access token from the first entity based on the refresh token, so that the API caller can access the corresponding resource through the access token.

In some implementations, the API caller may receive a second authorization revocation request sent by the terminal device.

In some implementations, the API caller can receive a second authorization revocation request sent by a resource owner client running on a terminal device. In some implementations, the resource owner can send the second authorization revocation request to the API caller (APIinvoker) by controlling the terminal or the resource owner client. On the terminal device, the resource owner interacts with the server through the client on the terminal device. For example, the resource owner client is a browser, the API caller is the server accessed by the browser, and the resource owner interacts with the server through the browser.

In some implementations, the API caller may receive a second authorization revocation request sent by the end device or a resource owner client running on the end device or the resource owner.

Optionally, the second authorization revocation request includes at least one of the following information: a resource identifier of the authorized resource; an operation identifier of a semantic operation executable on the authorized resource; identification information of the second entity; and identification information of the resource owner. For example, the identification information of the resource owner may be GPSI.

S402: Generate a first authorization revocation request based on the second authorization revocation request, and send the first authorization revocation request to the first entity.

In some implementations, the first authorization revocation request is configured to indicate to the first entity a refresh token associated with the resource owner.

In some implementations, the API caller may receive the second authorization revocation request, and based on the second authorization revocation request, determine a refresh token associated with the resource owner, and generate a first authorization revocation request based on the refresh token. After generating the first authorization revocation request, the API caller sends the first authorization revocation request to the first entity.

In some implementations, the second authorization revocation request may include identification information of the resource owner. The API invoker may determine the refresh token that needs to be revoked based on the identification information of the resource owner in the second revocation request, and send the refresh token to the first entity through the first authorization revocation request, and the first entity revokes the refresh token.

In some implementations, the API caller receives a second authorization revocation request sent by a terminal device or a resource owner client or a resource owner running on the terminal device, and converts the resource identification information and semantic operation in the second authorization revocation request into information in the 3GPP field, thereby determining a refresh token based on the information in the 3GPP field, and sending the first authorization revocation request to the first entity based on the refresh token. In some implementations, the information in the 3GPP field can be a specific data type structure (specific data type), for example, it can be a monitoring event report (Monitoring Event Report), and attribute information (attribute information) in this data structure type, and the attribute information includes but is not limited to: API name (API name), monitoring type (monitoringType).

In some implementations, the first authorization revocation request may be the same as the second authorization revocation request. In the case where the first authorization revocation request is the same as the second authorization revocation request, the first entity may convert the resource identification information and semantic operation in the first authorization revocation request into information in the 3GPP domain, thereby determining the refresh token based on the information in the 3GPP domain, and further performing a revocation operation on the refresh token.

Based on the above embodiment, the authorization revocation method may further include the following steps:

S403: Receive a revocation response message corresponding to the first authorization revocation request sent by the first entity.

S404: Send a revocation response message to the terminal device or the resource owner client or the resource owner.

In the embodiment of the present application, the implementation method of steps S403 to S404 can be implemented by any method in the embodiments of the present application, which is not limited here and will not be repeated.

In the embodiment of the present application, the API caller performs authorization interaction with the first entity to obtain a refresh token. Further, the API caller accepts a second authorization revocation request sent by the resource owner's client or terminal, and according to the second authorization revocation request The refresh token is determined, thereby generating a first authorization revocation request, and sending the first authorization revocation request to the first entity to achieve the purpose of revoking authorization. In this way, a large amount of security and authorization information stored in the CCF is deleted, the burden of the CCF is reduced, the performance of the CAPIF framework is improved, and the speed and efficiency of processing data are improved.

Please refer to Figure 5, which is a flow chart of a method for revoking authorization provided in an embodiment of the present application. The method for revoking authorization may be performed by a second entity. As shown in Figure 5, the method may include but is not limited to the following steps:

S501: Receive a second authorization revocation request.

In some implementations, the second entity may be an API caller, and optionally, the API caller may be an application function or a client running on a terminal.

In the embodiment of the present application, the implementation method of step S501 can be implemented by any method in the embodiments of the present application, which is not limited here and will not be repeated.

S502: Determine a refresh token based on the second authorization revocation request.

In some implementations, the API caller can determine the refresh token based on the second authorization revocation request including parameter information related to the refresh token. Optionally, the second authorization request includes a resource identifier and/or a semantic operation identifier, and the API caller can determine the refresh token based on the resource identifier and/or the semantic operation identifier. In some implementations, the resource identifier and/or the operation identifier are converted to generate information in the 3GPP field, and the refresh token is determined based on the information in the 3GPP field.

In some implementations, the information in the 3GPP field can be a specific data type structure (specific data type), for example, it can be a monitoring event report (Monitoring Event Report), and attribute information (attribute information) in this data structure type, and the attribute information includes but is not limited to: API name (API name), monitoring type (monitoringType).

In some implementations, the second authorization revocation request may include identification information of the resource owner. The API invoker may determine the refresh token that needs to be revoked based on the identification information of the resource owner in the second revocation request, and send the refresh token to the first entity through the first authorization revocation request, and the first entity revokes the refresh token. S503: Send a first authorization revocation request to the first entity based on the refresh token.

In some implementations, the API caller may generate a first authorization revocation request based on a refresh token determined by the second authorization revocation request, and send the first authorization revocation request to the first entity.

In some implementations, the API caller may send the refresh token and/or the token type of the refresh token to the first entity.

Based on the above embodiment, the authorization revocation method may further include the following steps:

S504: Receive a revocation response message corresponding to the first authorization revocation request sent by the first entity.

S505: Send a revocation response message to the terminal device or the resource owner client or the resource owner.

In the embodiment of the present application, the implementation method of steps S504 to S505 can be implemented by any method in the embodiments of the present application, which is not limited here and will not be repeated.

In the embodiment of the present application, the API caller performs authorization interaction with the first entity to obtain a refresh token. Further, the API caller accepts the second authorization revocation request sent by the resource owner client or terminal, and determines the refresh token according to the second authorization revocation request, thereby generating a first authorization revocation request according to the refresh token, and sending the first authorization revocation request to the first entity to achieve the purpose of revoking authorization, thereby deleting a large amount of security and authorization information stored in the first entity, reducing the burden on CCF, improving the performance of the CAPIF framework, and improving the speed and efficiency of processing data.

Please refer to Figure 6, which is a flow chart of a method for revoking authorization provided by an embodiment of the present application. The method for revoking authorization can be executed by the first entity in the CAPIF framework. As shown in Figure 6, the method can include but is not limited to the following steps:

S601: Receive a first authorization revocation request or a third authorization revocation request, wherein the first authorization revocation request or the third authorization revocation request is used to indicate a refresh token related to a resource owner.

S602: Perform a revocation operation on the refresh token based on the first authorization revocation request or the third authorization revocation request.

It should be noted that the first authorization revocation request or the third authorization revocation request is used to indicate the refresh token related to the resource owner. The first entity needs to perform authorization interaction with the API caller through the network protocol and send the refresh token related to the resource owner to the API caller. Among them, the first entity is one of the CCF network element or the authorization function. And under certain conditions, the CCF network element and the authorization function will be integrated, that is, the CCF also assumes the responsibility of the authorization function.

In some implementations, a refresh token associated with a resource owner can be used to generate an access token for a resource, so that the resource owner can access the corresponding resource based on the access token.

In some implementations, the first entity may receive a first authorization revocation request sent by an API caller. Optionally, the first authorization revocation request may directly indicate a refresh token associated with the resource owner, or indirectly indicate a refresh token associated with the resource owner through parameter information.

In some implementations, the first entity may receive a third authorization revocation request sent by a terminal device or a resource owner client running on the terminal device or a resource owner. In some implementations, the resource owner may send the third authorization revocation request to the first entity in the CAPIF framework by manipulating the terminal or the resource owner client.

Optionally, the third authorization revocation request may directly include a refresh token related to the resource owner, or indirectly indicate the refresh token related to the resource owner through parameter information related to the refresh token.

In some implementations, if the first authorization revocation request or the third authorization revocation request includes a refresh token, the refresh token includes the resource owner identifier.

Optionally, the first authorization revocation request or the third authorization revocation request may implicitly indicate a refresh token to the first entity.

In some implementations, the first authorization revocation request or the third authorization revocation request includes at least one of the following information: a resource identifier of the authorized resource; an operation identifier of a semantic operation executable on the authorized resource; identification information of the second entity; and identification information of the resource owner.

In some implementations, the first entity may determine a refresh token based on at least one information in the first authorization revocation request or the third authorization revocation request, and perform a revocation operation on the refresh token.

Optionally, the first entity may determine the refresh token that needs to be revoked through the identification information of the resource owner in the first authorization revocation request or the third authorization revocation request, and perform a revocation operation on the refresh token.

Optionally, the first entity may convert the resource owner's identification information and the operation identifier of the semantic operation in the first authorization revocation request or the third authorization revocation request into information in the 3GPP field, and determine the refresh token based on the information in the 3GPP field. Further, after the refresh token needs to be revoked, the first entity may perform a revocation operation on the refresh token.

In some implementations, the 3GPP domain information may be a specific data type structure, for example, a Monitoring Event Report, and attribute information in this data structure type. (attribute information), the attribute information includes but is not limited to: API name (API name), monitoring type (monitoringType).

In some implementations, the content of the first authorization revocation request may be the same as the content of the third authorization revocation request. In the case where the content of the first authorization revocation request is the same as the content of the third authorization revocation request, optionally, both the first authorization revocation request and the third authorization revocation request include a refresh token to be revoked. Optionally, both the first authorization revocation request and the third authorization revocation request include parameter information related to the refresh token to be revoked. In the scenario of carrying parameter information related to the refresh token, the first entity can determine the refresh token based on at least one information in the received authorization revocation request, and revoke the refresh token.

Optionally, the revocation operation may include but is not limited to: deleting the refresh token, deleting information related to the refresh token, deleting an access token associated with the refresh token, etc. Optionally, the refresh token related information may be information such as the identifier of the resource owner, the identifier of the authorized resource, etc.

In some implementations, the access token can be determined based on the refresh token, and the first entity receives the access token application request sent by the API caller and generates a corresponding access token based on the refresh token. In the present application, after the first entity performs a revocation operation on the refresh token according to the first authorization revocation request or the third authorization revocation request, if the first entity receives the access token application request sent by the API caller, the first entity stops generating access tokens based on the refresh token, so that the refresh token can no longer be used to obtain a new access token, and accordingly the resource owner cannot obtain a new access token, and thus cannot access the resource, which can effectively stop the authorized access rights associated with the refresh token.

In the embodiment of the present application, the first entity can receive a first authorization revocation request sent by an API caller, or a third authorization revocation request sent by a terminal device or a resource owner client running on the terminal device or a resource owner, and the first entity determines the refresh token according to the first authorization revocation request or the third authorization revocation request to perform a revocation operation on the refresh token to achieve the purpose of revoking authorization. Thus, a large amount of security and authorization information stored in the CCF can be deleted, the burden of the CCF can be reduced, the performance of the CAPIF framework can be improved, and the speed and efficiency of processing data can be improved.

Please refer to Figure 7, which is a flow chart of a method for revoking authorization provided by an embodiment of the present application. The method for revoking authorization can be executed by the first entity in the CAPIF framework. As shown in Figure 7, the method can include but is not limited to the following steps:

S701, receiving a first authorization revocation request.

In some implementations, the first entity may receive a first authorization revocation request sent by the second entity. Optionally, the second entity may be an API caller (API invoker), and optionally, the API caller is an application function (application function) or a client (client) running on a terminal.

S702: Determine a refresh token based on the first authorization revocation request.

In some implementations, the first authorization revocation request may directly indicate or include a refresh token associated with the resource owner. Optionally, if the third authorization revocation request includes a refresh token, the refresh token includes resource owner identification information (eg, GPSI).

In some implementations, the first authorization revocation request may indirectly indicate the refresh token associated with the resource owner through parameter information associated with the refresh token. For example, the first authorization revocation request includes at least one of the following information: a resource identifier of the authorized resource; an operation identifier of the semantic operation that can be performed on the authorized resource; identification information of the second entity; The identification information of the source owner. The first entity may determine the refresh token based on the first authorization revocation request including the above information. The specific process of determining the refresh token based on the first authorization revocation request including the above information can refer to the relevant records in the above embodiment, which will not be repeated here.

S703: Perform a revocation operation on the refresh token.

In the embodiment of the present application, the implementation method of step S703 can be implemented by any method in the embodiments of the present application, which is not limited here and will not be repeated.

Based on the above embodiment, the authorization revocation method may further include the following steps:

S704: Send a revocation response message corresponding to the first authorization revocation request to the second entity.

In some implementations, the first entity receives a first deauthorization request sent by an API caller, determines the refresh token, performs a deauthorization operation on the refresh token, and generates a corresponding deauthorization response message. After performing the deauthorization operation, the first entity should also send a corresponding deauthorization response message to the API caller. The API caller can determine whether the refresh token is successfully deauthorized based on the deauthorization response message. If the deauthorization is not successfully deauthorized, the refresh token can be deauthorized again.

In an embodiment of the present application, the first entity can receive a first authorization revocation request sent by an API caller, and perform a revocation operation on the refresh token according to the first authorization revocation request to achieve the purpose of revoking authorization. Thus, a large amount of security and authorization information stored in the CCF can be deleted, reducing the burden on the CCF, improving the performance of the CAPIF framework, and thus improving the speed and efficiency of processing data. Furthermore, the response message corresponding to the authorization revocation request is sent to the API caller, so that the API caller can promptly understand whether the authorization revocation is successful, and then promptly revoke the authorization again if it is unsuccessful, so as to achieve the purpose of revoking authorization.

Please refer to Figure 8, which is a flowchart of a method for revoking authorization provided by an embodiment of the present application. The method for revoking authorization can be executed by the first entity in the CAPIF framework. As shown in Figure 8, the method can include but is not limited to the following steps:

S801, receiving a third authorization revocation request.

In some implementations, the first entity may receive a third authorization revocation request sent by the terminal device or a resource owner client running on the terminal device or a resource owner.

S802: Determine a refresh token based on the third authorization revocation request.

In some implementations, the third authorization revocation request may directly indicate or include a refresh token associated with the resource owner. Optionally, if the third authorization revocation request includes a refresh token, the refresh token includes resource owner identification information (GPSI).

In some implementations, the third authorization revocation request may indirectly indicate the refresh token associated with the resource owner through parameter information related to the refresh token. For example, the third authorization revocation request includes at least one of the following information: a resource identifier of the authorized resource; an operation identifier of the semantic operation that can be performed on the authorized resource; identification information of the second entity; identification information of the resource owner. The first entity may determine the refresh token based on the third authorization revocation request including the above information. The specific process of determining the refresh token based on the third authorization revocation request including the above information can refer to the relevant records in the above embodiments, which will not be repeated here.

S803: Perform a revocation operation on the refresh token.

In the embodiment of the present application, the implementation method of step S803 can adopt any one of the methods in the embodiments of the present application. The method is implemented in this way, and no limitation is made here and no further description is given.

Based on the above embodiment, the authorization revocation method may further include the following steps:

S804: Send a revocation response message corresponding to the third authorization revocation request to the terminal device or the resource owner client or the resource owner.

In some implementations, the first entity determines the refresh token by receiving the third authorization revocation request sent by the terminal device or the resource owner client or the resource owner, and performs a revocation operation on the refresh token to generate a corresponding revocation response message. After the first entity performs the revocation operation, it should also send a corresponding revocation response message to the terminal device or the resource owner client or the resource owner. The terminal device or the resource owner client or the resource owner can determine whether the refresh token is successfully revoked based on the revocation response message. If it is not successfully revoked, the refresh token can be revoked again.

In an embodiment of the present application, the first entity can receive a third authorization revocation request sent by a terminal device or a resource owner client or resource owner running on the terminal device. The first entity performs a revocation operation on the refresh token related to the resource owner according to the third authorization revocation request, thereby deleting a large amount of security and authorization information stored in the CCF, reducing the burden on the CCF, improving the performance of the CAPIF framework, and thus improving the speed and efficiency of processing data. Furthermore, the response message corresponding to the authorization revocation request is sent to the terminal device or the resource owner client or the resource owner, so that the terminal device or the resource owner client or the resource owner can timely understand whether the authorization revocation is successful, and then revoke the authorization again in time if it is unsuccessful, so as to achieve the purpose of authorization revocation.

Please refer to Figure 9, which is a flowchart of an authorization revocation method provided by an embodiment of the present application. The authorization revocation method can be executed by a resource owner client or a terminal device. As shown in Figure 9, the method may include but is not limited to the following steps:

S901, sending a second authorization revocation request to the second entity; or, sending a third authorization revocation request to the first entity in the CAPIF framework.

In some implementations, the second entity may be an API caller, and optionally, the API caller may be an application function or a client running on a terminal.

In some implementations, the first entity is one of a CCF network element or an authorization function.

In some implementations, the resource owner may send a second authorization revocation request to an API caller (APIinvoker) through a control terminal or a resource owner client, or send a third authorization revocation request to the first entity in the CAPIF framework.

In some implementations, the resource owner client or terminal device may send a second authorization revocation request to the API caller, wherein the second authorization revocation request is used to determine the first authorization revocation request sent to the first entity.

In some implementations, the resource owner client or terminal device may send a third authorization revocation request to the first entity in the CAPIF framework. The first authorization revocation request or the second authorization revocation request or the third authorization revocation request is used to indicate a refresh token associated with the resource owner. Optionally, the first authorization revocation request or the second authorization revocation request or the third authorization revocation request may directly indicate a refresh token associated with the resource owner, or indirectly indicate a refresh token associated with the resource owner through parameter information associated with the refresh token.

It is understandable that the resource owner is a terminal user or a subscriber or a human being associated with the terminal. The resource owner client runs on the terminal device, and the resource owner interacts with the server through the client on the terminal device. For example, the resource owner client is a browser, the API caller is the server accessed by the browser, and the resource owner interacts with the server through the browser.

Optionally, the second authorization revocation request or the third authorization revocation request includes at least one of the following information: a resource identifier of an authorized resource; an operation identifier of a semantic operation identifier executable on the authorized resource; identification information of the second entity; and identification information of the resource owner.

The first entity may determine the refresh token based on the above information included in the authorization revocation request, and perform a revocation operation on the refresh token.

In the embodiment of the present application, the resource owner client or terminal can generate a first authorization revocation request sent to the first entity by sending a second authorization revocation request to the API caller. A third authorization revocation request can also be sent directly to the first entity to achieve the purpose of revoking authorization. In this way, a large amount of security and authorization information stored in the CCF can be deleted, reducing the burden on the CCF, improving the performance of the CAPIF framework, and thus improving the speed and efficiency of processing data.

Please refer to Figure 10, which is a flowchart of an authorization revocation method provided in an embodiment of the present application. The authorization revocation method can be executed by a resource owner client or a terminal device. As shown in Figure 10, the method may include but is not limited to the following steps:

S1001: Send a second authorization revocation request to a second entity.

In some implementations, the second entity may be an API caller, and optionally, the API caller may be an application function or a client running on a terminal.

In some implementations, the resource owner may send a second authorization revocation request to the API caller by controlling a terminal or a resource owner client.

In some implementations, the resource owner client or terminal device may send a second authorization revocation request to the API caller, wherein the second authorization revocation request is used to determine the first authorization revocation request sent to the first entity.

S1002: Receive a revocation response message corresponding to the first authorization revocation request sent by the API caller.

In some implementations, the resource owner client or terminal may send a second authorization revocation request to the API caller, and the API caller generates a first authorization revocation request based on the second authorization revocation request. After receiving the first authorization revocation request, the first entity may perform a revocation operation on the refresh token based on the refresh token indicated by the first authorization revocation request. After completing the revocation operation, the first entity may generate a revocation response message corresponding to the first authorization revocation request and feedback it to the API caller, and the API caller feedbacks the revocation response message corresponding to the first authorization revocation request to the resource owner client or terminal device. The resource owner client or terminal device may determine whether the refresh token is successfully revoked based on the revocation response message, and if it is not successfully revoked, it may send the authorization revocation for the refresh token again. Optionally, the first entity is one of the CCF network elements or the authorization function.

Optionally, the second authorization revocation request includes at least one of the following information: a resource identifier of the authorized resource; an operation identifier of a semantic operation identifier executable on the authorized resource; identification information of the second entity and identification information of the resource owner.

In the embodiment of the present application, the first entity can delete a large amount of security and authorization information stored in the CCF or authorization function, reduce the burden on the CCF, improve the performance of the CAPIF framework, and improve the speed and efficiency of processing data. Further, a corresponding revocation response message is generated and fed back to the resource owner client or terminal device or resource owner, so that The terminal device or resource owner client or resource owner can promptly learn whether the revocation of authorization is successful, and then promptly revoke the authorization again if it is unsuccessful, so as to achieve the purpose of the authorization revocation response message.

Please refer to Figure 11, which is a flowchart of an authorization revocation method provided by an embodiment of the present application. The authorization revocation method can be executed by a resource owner client or a terminal device. As shown in Figure 11, the method may include but is not limited to the following steps:

S1101, sending a third authorization revocation request to the first entity.

In some implementations, the resource owner may send the third authorization revocation request to the first entity by controlling the terminal or the resource owner client.

S1102: Receive a revocation response message corresponding to the third authorization revocation request sent by the first entity.

In some implementations, the resource owner client or terminal device may send a third authorization revocation request to the first entity in the CAPIF framework. The third authorization revocation request is used to indicate a refresh token associated with the resource owner. Optionally, the third authorization revocation request may directly indicate or include a refresh token associated with the resource owner, or indirectly indicate a refresh token associated with the resource owner through parameter information associated with the refresh token. For example, the third authorization revocation request includes at least one of the following information: a resource identifier of an authorized resource; an operation identifier of a semantic operation identifier that can be executed on the authorized resource; identification information of the second entity and identification information of the resource owner.

In some implementations, the resource owner client or terminal device or resource owner may send a third authorization revocation request to the first entity. After receiving the third authorization revocation request, the first entity may perform a revocation operation on the refresh token based on the refresh token indicated by the third authorization revocation request.

After completing the revocation operation, the first entity may generate a revocation response message corresponding to the third authorization revocation request and feedback it to the resource owner client or terminal device or resource owner. The resource owner client or terminal device or resource owner may determine whether the refresh token is successfully revoked based on the revocation response message. If not, the refresh token may be resent again to revoke authorization.

In the embodiment of the present application, the first entity can delete a large amount of security and authorization information stored in the CCF or authorization function, reduce the burden on the CCF, improve the performance of the CAPIF framework, and improve the speed and efficiency of processing data. Further, a corresponding revocation response message is generated and fed back to the resource owner client or terminal device or resource owner, so that the terminal device or resource owner client or resource owner can promptly understand whether the revocation of authorization is successful, and then revoke the authorization again in time if it is unsuccessful, so as to achieve the purpose of revoking the authorization.

Please refer to Figure 12, which is an interactive schematic diagram of an authorization revocation method provided in an embodiment of the present application. As shown in Figure 12, the method may include but is not limited to the following steps:

S1201, the resource owner client or terminal device or resource owner sends a second authorization revocation request to a second entity.

In some implementations, the second entity may be an API caller, and optionally, the API caller may be an application function or a client running on a terminal.

S1202: The second entity sends a first authorization revocation request to the first entity. The first authorization revocation request may directly indicate or include a refresh token related to the resource owner.

S1203: The first entity revokes the refresh token related to the resource owner.

S1204: The first entity sends a revocation response message corresponding to the first authorization revocation request to the second entity.

S1205: The second entity sends a revocation response message to the resource owner client or terminal device or the resource owner.

In the embodiment of the present application, the first entity can delete a large amount of security and authorization information stored in the CCF or authorization function, reduce the burden on the CCF, improve the performance of the CAPIF framework, and improve the speed and efficiency of processing data. Further, a corresponding revocation response message is generated and fed back to the resource owner client or terminal device or resource owner, so that the terminal device or resource owner client or resource owner can promptly understand whether the revocation of authorization is successful, and then revoke the authorization again in time if it is unsuccessful, so as to achieve the purpose of revoking the authorization.

Please refer to Figure 13, which is an interactive schematic diagram of an authorization revocation method provided in an embodiment of the present application. As shown in Figure 13, the method may include but is not limited to the following steps:

S1301: The second entity sends a first authorization revocation request to the first entity.

S1302: The first entity revokes a refresh token related to the resource owner.

S1303: The first entity sends a revocation response message corresponding to the first authorization revocation request to the second entity.

In the embodiment of the present application, the first entity can delete a large amount of security and authorization information stored in the CCF or authorization function, reduce the burden on the CCF, improve the performance of the CAPIF framework, and improve the speed and efficiency of processing data. Further, a corresponding revocation response message is generated and fed back to the resource owner client or terminal device or resource owner, so that the terminal device or resource owner client or resource owner can promptly understand whether the revocation of authorization is successful, and then revoke the authorization again in time if it is unsuccessful, so as to achieve the purpose of revoking the authorization.

In the embodiments provided by the present application, the methods provided by the embodiments of the present application are introduced from the perspectives of network equipment and terminal equipment, respectively. In order to implement the functions in the methods provided by the embodiments of the present application, the network equipment and the terminal equipment may include hardware structures and software modules, and the functions are implemented in the form of hardware structures, software modules, or hardware structures plus software modules. A certain function in the functions may be executed in the form of hardware structures, software modules, or hardware structures plus software modules.

Please refer to Figure 14, which is a schematic diagram of the structure of a communication device 1400 provided in an embodiment of the present application. The communication device 1400 shown in Figure 14 may include a transceiver module 1401 and a processing module 1402. The transceiver module 1401 may include a sending module and/or a receiving module, the sending module is used to implement a sending function, the receiving module is used to implement a receiving function, and the transceiver module 1401 may implement a sending function and/or a receiving function.

The communication device 1400 may be a second entity, or a device in the second entity, or a device that can be used in combination with the second entity. Alternatively, the communication device 1400 may be a first entity in the CAPIF framework, or a device in the first entity in the CAPIF framework, or a device that can be used in combination with the first entity in the CAPIF framework. Alternatively, the communication device 1400 may be a resource owner client or terminal device, or a device in the resource owner client or terminal device, or a device that can be used in combination with the resource owner client or terminal device.

The communication device 1400 is a second entity:

The transceiver module 1401 is used to send a first authorization revocation request to a first entity in the CAPIF framework, wherein the first authorization revocation request is used to indicate a refresh token related to a resource owner.

In some implementations, the transceiver module 1401 is further configured to receive a second authorization revocation request; generate the first authorization revocation request based on the second authorization revocation request, and send the first authorization revocation request to the first entity.

In some implementations, the transceiver module 1401 is further configured to receive the first authorization revocation request sent by the first entity. Request the corresponding revocation response message.

In some implementations, the second authorization revocation request is sent by a terminal device or a resource owner client running on the terminal device or a resource owner.

In some implementations, the transceiver module 1401 is further configured to send the revocation response message to the terminal device or the resource owner client or the resource owner.

In some implementations, the second authorization revocation request includes at least one of the following information: a resource identifier of an authorized resource; an operation identifier of a semantic operation executable on the authorized resource; identification information of the second entity; and identification information of the resource owner.

In some implementations, the transceiver module 1401 is further configured to determine the refresh token based on the second authorization revocation request; and send the first authorization revocation request to the first entity based on the refresh token.

In some implementations, the processing module 1402 is further configured to convert the resource identifier and/or the operation identifier to generate information in the 3GPP domain; and determine the refresh token based on the information in the 3GPP domain.

In some implementations, the transceiver module 1401 is further configured to send the refresh token and/or the token type of the refresh token to the first entity via the first authorization revocation request.

In some implementations, before sending the first authorization revocation request, the transceiver module 1401 is further used to: perform authorization interaction with the first entity to obtain the refresh token related to the resource owner.

In some implementations, the first entity is a core function CCF or an authorization function in the CAPIF framework.

The communication device 1400 is the first entity in the CAPIF framework:

The transceiver module 1401 is configured to receive a first authorization revocation request or a third authorization revocation request, wherein the first authorization revocation request or the third authorization revocation request may indicate a refresh token associated with a resource owner;

The processing module 1402 is used to perform a revocation operation on the refresh token based on the first revocation authorization request or the third revocation authorization request.

In some implementations, the transceiver module 1401 is further configured to receive a first authorization revocation request sent by the second entity.

In some implementations, the transceiver module 1401 is further configured to receive the third authorization revocation request sent by a terminal device or a resource owner client running on the terminal device or a resource owner.

In some implementations, the transceiver module 1401 is further used to send a revocation response message corresponding to the first authorization revocation request to the second entity; or send a revocation response message corresponding to the third authorization revocation request to the terminal device or the resource owner client or the resource owner.

In some implementations, the third authorization revocation request includes at least one of the following information: a resource identifier of an authorized resource; an operation identifier of a semantic operation executable on the authorized resource; identification information of the second entity; and identification information of the resource owner.

In some implementations, the processing module 1402 is further configured to convert the resource identifier and/or the operation identifier to generate information in the 3GPP domain; and determine the refresh token based on the information in the 3GPP domain.

In some implementations, the transceiver module 1401 is further configured to perform authorization interaction with the second entity and send the refresh token associated with the resource owner to the second entity.

In some implementations, the processing module 1402 is further configured to: Request, determine the refresh token and/or the token type of the refresh token.

In some implementations, the first entity is one of the core function CCF network elements or the authorization functions in the CAPIF framework.

In some implementations, the transceiver module 1401 is further configured to stop generating an access token based on the refresh token upon receiving an access token application request sent by the second entity.

The communication device 1400 is a resource owner client or terminal device:

The transceiver module 1401 is used to send a second authorization revocation request to a second entity, wherein the second authorization revocation request is used to determine the first authorization revocation request sent to the first entity; or, to send a third authorization revocation request to the first entity in the CAPIF framework; wherein the second authorization revocation or the third authorization revocation request can indicate a refresh token associated with the resource owner.

In some implementations, the transceiver module 1401 is further configured to receive a revocation response message corresponding to the first authorization revocation request sent by the second entity; or receive a revocation response message corresponding to the third authorization revocation request sent by the first entity.

In some implementations, the second authorization revocation request or the third authorization revocation request includes at least one of the following information: a resource identifier of an authorized resource; an operation identifier of a semantic operation executable on the authorized resource; identification information of the second entity; and identification information of the resource owner.

In some implementations, the resource owner client runs on a terminal device.

In an embodiment of the present application, the second entity sends an authorization revocation request indicating a refresh token to the first entity to achieve the purpose of revoking authorization, thereby deleting a large amount of security and authorization information stored in the CCF, reducing the burden on the CCF, improving the performance of the CAPIF framework, and thereby improving the speed and efficiency of processing data.

Please refer to Figure 15, which is a schematic diagram of the structure of another communication device 1500 provided in an embodiment of the present application. The communication device 1500 can be a second entity, or a first entity in the CAPIF framework, or a resource owner client or terminal device, or a chip, chip system, or processor that supports the second entity to implement the above method, or a chip, chip system, or processor that supports the first entity in the CAPIF framework to implement the above method, or a chip, chip system, or processor that supports the resource owner client or terminal device to implement the above method. The device can be used to implement the method described in the above method embodiment, and the details can be referred to the description in the above method embodiment.

The communication device 1500 may include one or more processors 1501. The processor 1501 may be a general-purpose processor or a dedicated processor, etc. For example, it may be a baseband processor or a central processing unit. The baseband processor may be used to process the communication protocol and communication data, and the central processing unit may be used to control the communication device (such as a base station, a baseband chip, a terminal device, a terminal device chip, a DU or a CU, etc.), execute a computer program, and process the data of the computer program.

Optionally, the communication device 1500 may further include one or more memories 1502, on which a computer program 1504 may be stored, and the processor 1501 executes the computer program 1504 so that the communication device 1500 performs the method described in the above method embodiment. Optionally, data may also be stored in the memory 1502. The communication device 1500 and the memory 1502 may be provided separately or integrated together.

Optionally, the communication device 1500 may further include a transceiver 1505 and an antenna 1506. The transceiver 1505 may be referred to as a transceiver unit, a transceiver, or a transceiver circuit, etc., and is used to implement transceiver functions. The transceiver 1505 may include a receiver and a transmitter. A receiver can be called a receiver or a receiving circuit, etc., which is used to implement a receiving function; a transmitter can be called a transmitter or a transmitting circuit, etc., which is used to implement a transmitting function.

Optionally, the communication device 1500 may further include one or more interface circuits 1507. The interface circuit 1507 is used to receive code instructions and transmit them to the processor 1501. The processor 1501 runs the code instructions to enable the communication device 1500 to perform the method described in the above method embodiment.

In one implementation, the processor 1501 may include a transceiver for implementing the receiving and sending functions. For example, the transceiver may be a transceiver circuit, an interface, or an interface circuit. The transceiver circuit, interface, or interface circuit for implementing the receiving and sending functions may be separate or integrated. The above-mentioned transceiver circuit, interface, or interface circuit may be used for reading and writing code/data, or the above-mentioned transceiver circuit, interface, or interface circuit may be used for transmitting or delivering signals.

In one implementation, the processor 1501 may store a computer program 1503, which runs on the processor 1501 and enables the communication device 1500 to perform the method described in the above method embodiment. The computer program 1503 may be fixed in the processor 1501, in which case the processor 1501 may be implemented by hardware.

In one implementation, the communication device 1500 may include a circuit that can implement the functions of sending or receiving or communicating in the aforementioned method embodiments. The processor and transceiver described in the present application can be implemented in an integrated circuit (IC), an analog IC, a radio frequency integrated circuit RFIC, a mixed signal IC, an application specific integrated circuit (ASIC), a printed circuit board (PCB), an electronic device, etc. The processor and transceiver can also be manufactured using various IC process technologies, such as complementary metal oxide semiconductor (CMOS), N-type metal oxide semiconductor (NMOS), P-type metal oxide semiconductor (positive channel metal oxide semiconductor, PMOS), bipolar junction transistor (BJT), bipolar CMOS (BiCMOS), silicon germanium (SiGe), gallium arsenide (GaAs), etc.

The communication device described in the above embodiments may be the second entity or the first entity in the CAPIF framework or the resource owner client or terminal device, but the scope of the communication device described in this application is not limited thereto, and the structure of the communication device may not be limited by FIG. 14. The communication device may be an independent device or may be part of a larger device. For example, the communication device may be:

(1) Independent integrated circuit IC, or chip, or chip system or subsystem;

(2) having a set of one or more ICs, and optionally, the IC set may also include a storage component for storing data and computer programs;

(3) ASIC, such as modem;

(4) Modules that can be embedded in other devices;

(5) Receivers, terminal devices, intelligent terminal devices, cellular phones, wireless devices, handheld devices, mobile units, vehicle-mounted devices, network devices, cloud devices, artificial intelligence devices, etc.;

(6)Others

For the case where the communication device can be a chip or a chip system, please refer to the schematic diagram of the chip structure shown in Figure 16. The chip shown in Figure 16 includes a processor 1601 and an interface 1602. The number of processors 1601 can be one or more. Multiple, the number of interfaces 1602 can be multiple.

Optionally, the chip further includes a memory 1603, and the memory 1603 is used to store necessary computer programs and data.

In some implementations, the chip can be used to implement the functions of the second entity in the above-mentioned embodiments of the present application.

In some implementations, the chip can be used to implement the functions of the first entity in the CAPIF framework in the above-mentioned embodiments of the present application.

In some implementations, the chip can be used to implement the functions of the resource owner client or terminal device in the above-mentioned embodiments of the present application.

In the embodiment of the present application, the second entity first performs authorization interaction with the first entity to obtain a refresh token. Further, the second entity accepts the second authorization revocation request sent by the resource owner client or terminal, thereby generating a first authorization revocation request, and sends the first authorization revocation request to the first entity to achieve the purpose of revoking authorization, thereby reducing the burden of CCF, improving the performance of the CAPIF framework, and improving the speed and efficiency of processing data.

Those skilled in the art may also understand that the various illustrative logical blocks and steps listed in the embodiments of the present application may be implemented by electronic hardware, computer software, or a combination of the two. Whether such functions are implemented by hardware or software depends on the specific application and the design requirements of the entire system. Those skilled in the art may use various methods to implement the described functions for each specific application, but such implementation should not be understood as exceeding the scope of protection of the embodiments of the present application.

The embodiment of the present application also provides a communication system 1700 for authorization revocation, which includes a first entity 1701 and a second entity 1702 in a CAPIF framework.

The second entity 1702 is configured to send a first authorization revocation request to the first entity, wherein the first authorization revocation request is used to indicate a refresh token associated with a resource owner;

The first entity 1701 is configured to perform a revocation operation on the refresh token based on the first revocation authorization request.

In some implementations, the communication system further includes: a resource owner client or terminal device 1703, the resource owner client or terminal device, configured to send a second authorization revocation request to the second entity;

The second entity 1702 is configured to generate the first authorization revocation request based on the second authorization revocation request, and send the first authorization revocation request to the first entity.

The embodiment of the present application also provides a communication system 1800 for authorization revocation, which includes a first entity 1801 in a CAPIF framework and a resource owner client or terminal device 1802.

The resource owner client or terminal device 1802 is used to send a third authorization revocation request to the first entity in the CAPIF framework, wherein the third authorization revocation request is used to indicate a refresh token related to the resource owner;

The first entity 1801 is configured to perform a revocation operation on the refresh token based on the first revocation authorization request.

Optionally, the communication device in the aforementioned embodiment of Figure 14 can be used as a communication device of the second entity, as a communication device of the first entity in the CAPIF framework, and as a communication device of the resource owner client or terminal device, or the communication device in the aforementioned embodiment of Figure 15 can be used as a communication device of the second entity, as a communication device of the first entity in the CAPIF framework, and as a communication device of the resource owner client or terminal device.

The present application also provides a readable storage medium having instructions stored thereon, which implement the functions of any of the above method embodiments when executed by a computer.

The present application also provides a computer program product, which implements the functions of any of the above method embodiments when executed by a computer.

In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs. When the computer program is loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer program can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer program can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a high-density digital video disc (DVD)), or a semiconductor medium (e.g., a solid state disk (SSD)), etc.

A person skilled in the art may understand that the various numerical numbers such as first and second involved in the present application are only used for the convenience of description and are not used to limit the scope of the embodiments of the present application, and also indicate the order of precedence.

At least one in the present application can also be described as one or more, and a plurality can be two, three, four or more, which is not limited in the present application. In the embodiments of the present application, for a technical feature, the technical features in the technical feature are distinguished by "first", "second", "third", "A", "B", "C" and "D", etc., and there is no order of precedence or size between the technical features described by the "first", "second", "third", "A", "B", "C" and "D".

The corresponding relationships shown in each table in the present application can be configured or predefined. The values of the information in each table are only examples and can be configured as other values, which are not limited by the present application. When configuring the corresponding relationship between the information and each parameter, it is not necessarily required to configure all the corresponding relationships illustrated in each table. For example, in the table in the present application, the corresponding relationships shown in some rows may not be configured. For another example, appropriate deformation adjustments can be made based on the above table, such as splitting, merging, etc. The names of the parameters shown in the titles of the above tables can also use other names that can be understood by the communication device, and the values or representations of the parameters can also be other values or representations that can be understood by the communication device. When implementing the above tables, other data structures can also be used, such as arrays, queues, containers, stacks, linear lists, pointers, linked lists, trees, graphs, structures, classes, heaps, hash tables or hash tables.

The predefined in the present application may be understood as defined, predefined, stored, pre-stored, pre-negotiated, pre-configured, solidified, or pre-burned.

Those skilled in the art will appreciate that the units and algorithm steps of each example described in the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Different methods may be used to implement the described functionality for each specific application, but such implementation should not be considered beyond the scope of the present application.

Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims (40)

A method for revoking authorization, characterized in that it is performed by a second entity, and the method comprises: A first authorization revocation request is sent to a first entity in a common application programming interface CAPIF framework, wherein the first authorization revocation request is used to indicate a refresh token related to a resource owner. The method according to claim 1, characterized in that the sending of the first authorization revocation request to the first entity in the common application programming interface CAPIF framework comprises: receiving a second authorization revocation request; The first authorization revocation request is generated based on the second authorization revocation request, and the first authorization revocation request is sent to the first entity. The method according to claim 1 or 2, characterized in that after sending the first authorization revocation request to the first entity, it also includes: Receive a revocation response message corresponding to the first authorization revocation request sent by the first entity. The method according to claim 2 or 3 is characterized in that the second authorization revocation request is sent by a terminal device or a resource owner client or a resource owner running on the terminal device. The method according to claim 4, characterized in that after receiving the revocation response message corresponding to the first authorization revocation request sent by the first entity, it also includes: The revocation response message is sent to the terminal device or the resource owner client or the resource owner. The method according to any one of claims 2 to 5, characterized in that the second authorization revocation request includes at least one of the following information: The resource identifier of the authorized resource; An operation identifier of a semantic operation executable on the authorized resource; identification information of the second entity; The identification information of the resource owner. The method according to any one of claims 2 to 6, characterized in that the sending a first authorization revocation request to the first entity in the CAPIF framework based on the second authorization revocation request comprises: determining the refresh token based on the second authorization revocation request; The first authorization revocation request is sent to the first entity based on the refresh token. The method according to claim 7, characterized in that the determining the refresh token based on the second authorization revocation request comprises: Convert the resource identifier and/or the operation identifier to generate 3GPP domain information; The refresh token is determined based on the information of the 3GPP domain. The method according to any one of claims 1 to 8, characterized in that the method further comprises: The refresh token and/or the token type of the refresh token is sent to the first entity through the first authorization revocation request. The method according to any one of claims 1 to 8, characterized in that before sending the first authorization revocation request, it also includes: Perform an authorization interaction with the first entity to obtain the refresh token associated with the resource owner. The method according to any one of claims 1 to 10 is characterized in that the first entity is a core function CCF or an authorization function in the CAPIF framework. A method for revoking authorization, characterized in that it is performed by a first entity in a CAPIF framework, and the method comprises: receiving a first authorization revocation request or a third authorization revocation request, wherein the first authorization revocation request or the third authorization revocation request may indicate a refresh token associated with a resource owner; Based on the first revocation authorization request or the third revocation authorization request, a revocation operation is performed on the refresh token. The method according to claim 12, wherein receiving the first authorization revocation request comprises: A first authorization revocation request sent by a second entity is received. The method according to claim 12, wherein receiving the third authorization revocation request comprises: The third authorization revocation request sent by the terminal device or the resource owner client running on the terminal device or the resource owner is received. The method according to any one of claims 12 to 14, characterized in that after performing a revocation operation on the refresh token based on the first revocation authorization request or the third revocation authorization request, the method further comprises: Sending a revocation response message corresponding to the first authorization revocation request to the second entity; or, Send a revocation response message corresponding to the third authorization revocation request to the terminal device or the resource owner client or the resource owner. The method according to any one of claims 12 to 15, characterized in that the third authorization revocation request includes at least one of the following information: The resource identifier of the authorized resource; An operation identifier of a semantic operation executable on the authorized resource; identification information of the second entity; The identification information of the resource owner. The method according to claim 16, before performing a revocation operation on the refresh token based on the third revocation authorization request, further comprises: Convert the resource identifier and/or the operation identifier to generate 3GPP domain information; The refresh token is determined based on the information of the 3GPP domain. The method according to any one of claims 12 to 16, characterized in that before receiving the first authorization revocation request or the third authorization revocation request, it also includes: An authorization interaction is performed with the second entity, and the refresh token associated with the resource owner is sent to the second entity. The method according to any one of claims 12 to 18, characterized in that the method further comprises: Based on the first authorization revocation request or the third authorization revocation request, the refresh token and/or a token type of the refresh token is determined. The method according to any one of claims 12-19 is characterized in that the first entity is one of the core function CCF network elements or authorization functions in the CAPIF framework. The method according to any one of claims 12 to 20, characterized in that after the revoking operation is performed on the refresh token based on the first authorization revocation request or the third authorization revocation request, the method comprises: When receiving the access token application request sent by the second entity, stop generating the access token based on the refresh token. A method for revoking authorization in a CAPIF framework, characterized in that it is executed by a resource owner client or a terminal device, and the method comprises: Sending a second authorization revocation request to a second entity, wherein the second authorization revocation request is used to determine the first authorization revocation request sent to the first entity in the CAPIF framework; or, A third authorization revocation request is sent to the first entity in the CAPIF framework; wherein the second authorization revocation or the third authorization revocation request is used to indicate a refresh token associated with a resource owner. The method according to claim 22, characterized in that the method further comprises: receiving a revocation response message corresponding to the first authorization revocation request sent by the second entity; or, Receive a revocation response message corresponding to the third authorization revocation request sent by the first entity. The method according to claim 22 or 23, characterized in that the second authorization revocation request or the third authorization revocation request includes at least one of the following information: The resource identifier of the authorized resource; An operation identifier of a semantic operation identifier executable on the authorized resource; identification information of the second entity; The identification information of the resource owner. The method according to any one of claims 22-24 is characterized in that the resource owner client runs on a terminal device. A communication system, characterized by comprising: a first entity and a second entity in a CAPIF framework; The second entity is configured to send a first authorization revocation request to the first entity, wherein the first authorization revocation request is used to indicate a refresh token associated with a resource owner; The first entity is configured to perform a revocation operation on the refresh token based on the first revocation authorization request. The communication system according to claim 26, characterized in that it further comprises: a resource owner client or terminal device, wherein the resource owner client or terminal device is used to send a second authorization revocation request to the second entity; The second entity is configured to generate the first authorization revocation request based on the second authorization revocation request, and send the first authorization revocation request to the first entity. A communication system, characterized in that it comprises: a first entity in a CAPIF framework and a resource owner client or terminal device; The resource owner client or terminal device is used to send a third authorization revocation request to the first entity in the CAPIF framework, wherein the third authorization revocation request is used to indicate a refresh token related to the resource owner; The first entity is configured to perform a revocation operation on the refresh token based on the first revocation authorization request. A communication device, comprising: The processing module is used to send a first authorization revocation request to a first entity in a common application programming interface CAPIF framework, wherein the first authorization revocation request is used to indicate a refresh token related to a resource owner. A communication device, comprising: a transceiver module, configured to receive a first authorization revocation request or a third authorization revocation request, wherein the first authorization revocation request or the second authorization revocation request may indicate a refresh token associated with a resource owner; A processing module is used to perform a revocation operation on the refresh token based on the first revocation authorization request or the third revocation authorization request. A communication device, comprising: A transceiver module is used to send a second authorization revocation request to a second entity, wherein the second authorization revocation request is used to determine the first authorization revocation request sent to the first entity; or, to send a third authorization revocation request to the first entity in the CAPIF framework; wherein the second authorization revocation or the third authorization revocation request is used to indicate a refresh token associated with a resource owner. A communication device, characterized in that the device comprises a processor and a memory, the memory stores a computer program, and the processor executes the computer program stored in the memory so that the device performs the method according to any one of claims 1 to 11. A communication device, characterized in that the device comprises a processor and a memory, the memory stores a computer program, and the processor executes the computer program stored in the memory so that the device performs the method as claimed in any one of claims 12 to 21. A communication device, characterized in that the device comprises a processor and a memory, the memory stores a computer program, and the processor executes the computer program stored in the memory so that the device performs the method as described in any one of claims 22 to 25. A communication device, characterized in that it comprises: a processor and an interface circuit; The interface circuit is used to receive code instructions and transmit them to the processor; The processor is configured to run the code instructions to execute the method according to any one of claims 1 to 11. A communication device, characterized in that it comprises: a processor and an interface circuit; The interface circuit is used to receive code instructions and transmit them to the processor; The processor is configured to run the code instructions to execute the method according to any one of claims 12 to 21. A communication device, characterized in that it comprises: a processor and an interface circuit; The interface circuit is used to receive code instructions and transmit them to the processor; The processor is configured to run the code instructions to execute the method according to any one of claims 22 to 25. A computer-readable storage medium is used to store instructions, and when the instructions are executed, the method according to any one of claims 1 to 11 is implemented. A computer-readable storage medium is used to store instructions, and when the instructions are executed, the method according to any one of claims 12 to 21 is implemented. A computer-readable storage medium is used to store instructions, and when the instructions are executed, the method according to any one of claims 22 to 25 is implemented.