Communication method and apparatus

Abstract

A communication method and an apparatus. The method comprises: a terminal sending a first request, the first request being used for requesting to revoke a first token, wherein the first request comprises first information, the first information is used for determining the first token, and the first token is a token for authorizing a first service to a first user. By means of the method, a user can control a terminal to initiate the procedure of revoking a first token, such that the authorization of a first service corresponding to the first token can be revoked.

Description

Communication method and device

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of the People's Republic of China on August 4, 2023, with application number 202310986490.6 and application name "A Communication Method and Device", the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of communication technology, and in particular to a communication method and device. Background Art

[0004] The capability open architecture of the 3rd Generation Partnership Project (3GPP) network provides a way for the 3GPP network to provide services to the outside world. Under this architecture, the application function (AF) can use the capabilities provided by the 3GPP network to process and / or obtain 3GPP-related data information, which may include processing and / or obtaining 3GPP network data, as well as processing and / or obtaining 3GPP network user-related data. When processing and / or obtaining user-related data, the AF must obtain the user's authorization. For example, the AF can request the 3GPP network to send the user's location information to the outside world. If the user's authorization is not obtained, the user's privacy information may be exposed. For another example, the AF can request the 3GPP network to change the user's network service quality (QoS). If the user's authorization is not obtained, the user experience will be inconsistent with the expected value, and the user may also be charged additional fees.

[0005] After a user authorizes a service, the authorization may be revoked. How to design the service revocation process requires further research.

[0006] Summary of the Invention

[0007] The present application provides a communication method and apparatus for revoking authorization for a service.

[0008] In a first aspect, an embodiment of the present application provides a communication method, which can be applied to a terminal, or to a module in a terminal, such as a chip, a chip system, or a processor, or a logical node, a logical module, or software that can implement all or part of the terminal functions. The following is an illustration of the application of this method to a terminal. The method includes: the terminal can determine first information, and the first information is used to determine a first token, and the first token is a token that authorizes a first service for a first user. The terminal sends a first request, and the first request includes first information, and the first request is used to request the revocation of the first token.

[0009] Through this method, the terminal can initiate the process of revoking the first token by including the first information in the first request. In this way, the user can initiate the process of revoking the first token by controlling the terminal, thereby revoking the authorization of the first service corresponding to the first token.

[0010] In one possible design, the first information includes a random number, which is used to identify the first token. With this design, the terminal can initiate a process to revoke the first token by including the random number in the first request. In this way, the user can initiate the process to revoke the first token by controlling the terminal, thereby revoking authorization for the first service corresponding to the first token.

[0011] In one possible design, the random number can be used to determine the second information through a one-way function, and the second information is used to determine the first token. In this design, the random number can be protected by the one-way function. This prevents other applications on the terminal or AF, other than the user agent, from obtaining information related to the random number and, therefore, from initiating the revocation process for the first token, thereby improving terminal communication security.

[0012] In one possible design, the terminal may also receive a first response. The first response indicates one of the following: successful revocation of the first token, triggering of the revocation process for the first token, or receipt of the first request. The first response includes a random number or second information derived from a one-way function and the random number. With this design, the terminal can promptly receive one of the following: successful revocation of the first token, triggering of the revocation process for the first token, or receipt of the first request.

[0013] In one possible design, the terminal can generate a random number and second information, where the second information is obtained based on a one-way function and the random number. The terminal can then send the second information to the authorization function network element, where the second information corresponds to the first token. Through this design, the random number used to initiate the revocation process of the first token is generated by the terminal and can be protected by a one-way function. In this way, other applications on the terminal or AF other than the user agent cannot obtain information related to the random number and thus cannot initiate the revocation process for the first token, thereby improving the communication security of the terminal.

[0014] In one possible design, before the terminal generates the random number and the second information, the terminal may detect a first operation by the first user, where the first operation indicates that the first user agrees to authorize the first service for the first user. With this design, the terminal generates the random number and the second information only after detecting the first operation. This eliminates the need to generate random numbers for tokens that the user has not agreed to, thereby reducing terminal energy consumption.

[0015] In one possible design, the first information includes auxiliary information for identifying the first token. With this design, the terminal can initiate the first token revocation process by including the auxiliary information in the first request. In this way, the user can initiate the first token revocation process by controlling the terminal, thereby revoking authorization for the first service corresponding to the first token.

[0016] Optionally, the auxiliary information includes at least one of the following:

[0017] information for identifying the authorization scope of the first token;

[0018] Information for identifying a service application programming interface (API) corresponding to the first token;

[0019] Information used to identify the AzF corresponding to the first token;

[0020] information used to identify the first user;

[0021] Information used to identify the API open function corresponding to the first token;

[0022] Information for identifying the validity period of the first token;

[0023] Information for identifying the issuance time of the first token.

[0024] In one possible design, the terminal can detect a first operation by a first user, indicating that the first user consents to authorizing the first service for the first user. The terminal then retrieves and stores the auxiliary information. With this design, the terminal retrieves and stores the auxiliary information only after detecting the first operation. This eliminates the need to retrieve and store auxiliary information for tokens that the user has not consented to, thereby reducing terminal energy consumption and conserving terminal storage resources.

[0025] In one possible design, the terminal may receive an authorization code corresponding to the first token, which is used to determine that the first token corresponding to the auxiliary information is a token authorized by the authorization function network element. Thus, after receiving the authorization code, the terminal may determine that the first token corresponding to the auxiliary information is a token authorized by the authorization function network element, and may thereby initiate a token revocation process based on the auxiliary information.

[0026] In one possible design, the first information includes an authorization code corresponding to the first token. With this design, the terminal can initiate a process to revoke the first token by including the authorization code in the first request. In this way, the user can initiate the process to revoke the first token by controlling the terminal, thereby revoking authorization for the first service corresponding to the first token.

[0027] In one possible design, the terminal may receive an authorization code corresponding to the first token from the authorization function network element. In this way, the terminal may obtain the authorization code corresponding to the first token in a timely manner.

[0028] In one possible design, the first request also includes: indication information of the first user, and the indication information of the first user and the first information are used to determine the first token. The indication information of the first user can be used to quickly narrow the range of tokens to be determined, thereby increasing the speed of determining the first token. For example, the first device saves tokens of multiple users. The first device can select the token of the first user from the tokens of the multiple users based on the indication information of the first user, and select the first token from the tokens of the first user based on the first information. Since the first device can use the user's indication information as an index of the tokens of multiple users, the first device can quickly exclude tokens of users other than the first user, narrow the range of tokens to be determined, and increase the speed of determining the first token.

[0029] In one possible design, the terminal sends the first request to AzF based on the address information of AzF; or, the terminal sends the first request to AzF through an API caller. With this design, the terminal can flexibly send the first request to AzF.

[0030] On the second aspect, an embodiment of the present application provides a communication method, which can be applied to a first device. The first device can be an API caller, a device including an API caller (for example, a terminal or AF) or an AzF, or a module applied to an API caller, a device including an API caller or an AzF, such as a chip, a chip system, or a processor, or a logical node, a logical module or software that can implement all or part of the functions of an API caller, a device including an API caller or an AzF. The method includes: the first device can receive a first request from a terminal, the first request is used to request the revocation of a first token, the first request includes first information, the first information is used to determine the first token, and the first token is a token that authorizes the first service to the first user. The first device can determine the first token based on the first request.

[0031] Through this method, the terminal can initiate the process of revoking the first token by including the first information in the first request. In this way, the user can initiate the process of revoking the first token by controlling the terminal, thereby revoking the authorization of the first service corresponding to the first token.

[0032] In one possible design, the first information includes a random number, which is used to identify the first token. With this design, the terminal can initiate the first token revocation process by including the random number in the first request. In this way, the user can initiate the first token revocation process by controlling the terminal, thereby revoking authorization for the first service corresponding to the first token.

[0033] In one possible design, the random number is used to determine the second information through a one-way function, and the second information is used to determine the first token. In this design, the random number can be protected by the one-way function. This prevents other applications on the terminal or AF, other than the user agent, from obtaining information related to the random number and, therefore, from initiating the revocation process for the first token, thereby improving terminal communication security.

[0034] In one possible design, the first device may further send a first response to the terminal. This first response is used to indicate one of the following: successful revocation of the first token, triggering of the first token revocation process, or receipt of the first request. The first response includes a random number or second information, where the second information is derived from a one-way function and the random number. With this design, the terminal can promptly obtain one of the following: successful revocation of the first token, triggering of the first token revocation process, or receipt of the first request.

[0035] In one possible design, the first device may receive second information from the terminal, where the second information is derived using a one-way function and a random number. The first device may then associate the second information with the first token. With this design, the first device can quickly determine the corresponding first token based on the second information.

[0036] In one possible design, the first device may send a notification message to the API caller. The notification message may be used to indicate one of the following: successful revocation of the first token, triggering of the revocation process for the first token, or receipt of the first request. The notification message includes information indicating the first token. With this design, the API caller can promptly be notified of one of the following: successful revocation of the first token, triggering of the revocation process for the first token, or receipt of the first request.

[0037] In one possible design, the first information includes auxiliary information for identifying the first token. With this design, the terminal can initiate the first token revocation process by including the auxiliary information in the first request. In this way, the user can initiate the first token revocation process by controlling the terminal, thereby revoking authorization for the first service corresponding to the first token.

[0038] Optionally, the auxiliary information includes at least one of the following:

[0039] information for identifying the authorization scope of the first token;

[0040] Information used to identify the service API corresponding to the first token;

[0041] Information used to identify the AzF corresponding to the first token;

[0042] information used to identify the first user;

[0043] Information used to identify the API open function corresponding to the first token;

[0044] Information for identifying the validity period of the first token;

[0045] Information for identifying the issuance time of the first token.

[0046] In one possible design, the first information includes an authorization code corresponding to the first token. With this design, the terminal can initiate a process to revoke the first token by including the authorization code in the first request. In this way, the user can initiate the process to revoke the first token by controlling the terminal, thereby revoking authorization for the first service corresponding to the first token.

[0047] In one possible design, the first device may send an authorization code corresponding to the first token to the terminal. In this way, the terminal may obtain the authorization code corresponding to the first token in a timely manner.

[0048] In one possible design, the first request also includes: indication information of the first user, and the indication information of the first user and the first information are used to determine the first token. The indication information of the first user can be used to quickly narrow the range of tokens to be determined, thereby increasing the speed of determining the first token. For example, the first device saves tokens of multiple users. The first device can select the token of the first user from the tokens of the multiple users based on the indication information of the first user, and select the first token from the tokens of the first user based on the first information. Since the first device can use the user's indication information as an index of the tokens of multiple users, the first device can quickly exclude tokens of users other than the first user, narrow the range of tokens to be determined, and increase the speed of determining the first token.

[0049] In one possible design, the first device may revoke the first token; or the first device may send a second request to the AzF, wherein the second request is used to request the revocation of the first token. With this design, the first device may revoke the first token or request the AzF to revoke the first token.

[0050] In one possible design, the first device may receive the first request sent by the terminal based on the address information of the AzF network element; or the first device may receive the first request from the terminal through an API caller. With this design, the first device can flexibly receive the first request from the terminal.

[0051] In a third aspect, an embodiment of the present application provides a communication method, which can be applied to a terminal, or to a module in a terminal, such as a chip, a chip system, or a processor, or a logical node, a logical module, or software that can implement all or part of the terminal functions. The following is an illustration of the application of this method to a terminal. The method includes: the terminal can receive third information, and the third information is used to indicate that the authorization to be revoked is a first authorization that allows the first user to use the first service. After detecting the second operation of the first user, the terminal can send a fourth information, and the second operation is used to indicate that the first user agrees to revoke the first authorization, and the fourth information is used to trigger the revocation of the first authorization.

[0052] Through this method, after detecting the second operation of the first user, the terminal sends the fourth information for triggering the revocation of the first authorization, that is, triggering the token process of the token, thereby avoiding the interruption of the service expected by the user due to the revocation of authorization, that is, avoiding the user from being denied service.

[0053] In one possible design, before receiving the third information, the terminal sends a third request, where the third request includes indication information of the first service. With this design, the terminal can trigger the revocation of the first authorization by including the indication information of the first service in the third request.

[0054] In a fourth aspect, an embodiment of the present application provides a communication method, which can be applied to a third device. The third device can be AzF, or a module applied to AzF, such as a chip, a chip system, or a processor. It can also be a logical node, a logical module, or software that can implement all or part of the AzF functions. The method includes: the third device sends a third message to the terminal, and the third message is used to indicate that the authorization to be revoked is the first authorization that allows the first user to use the first service. The third device can receive a fourth message sent by the terminal based on the second operation of the first user, the second operation is used to indicate that the first user agrees to revoke the first authorization, and the fourth message is used to trigger the revocation of the first authorization.

[0055] Through this method, after detecting the second operation of the first user, the terminal sends the fourth information for triggering the revocation of the first authorization, that is, triggering the token process of the token, thereby avoiding the interruption of the service expected by the user due to the revocation of authorization, that is, avoiding the user from being denied service.

[0056] In one possible design, before sending the third information, the third device may receive a third request from the terminal, where the third request includes indication information of the first service. With this design, the terminal can trigger the revocation of the first authorization by including the indication information of the first service in the third request.

[0057] In one possible design, the third device may send a fifth message to the API caller, and the fifth message is used to revoke the first authorization. Through this design, the API caller can obtain the fifth message of the user revoking the first authorization, and can use the fifth message to revoke the first authorization.

[0058] In one possible design, the fifth information is a second token. Optionally, the second token is a revocation token; or the value of the first field in the second token is a set value. This design provides multiple ways to use the second token to revoke the first authorization.

[0059] In a fifth aspect, the present application provides a communication device, which may be a terminal or a module in a terminal (such as a circuit or chip), or a logical node, a logical module, or software that can implement all or part of the terminal functions. The communication device has the function of implementing the first aspect above. For example, the communication device includes a module or unit or means corresponding to the operations involved in the first or third aspect above, and the module or unit or means may be implemented by software, or by hardware, or the corresponding software may be implemented by hardware.

[0060] In one possible design, the communication device includes a processing unit and an interface unit. The interface unit can be used to send and receive signals to enable communication between the communication device and other devices, and the processing unit can be used to perform certain internal operations of the communication device. The functions performed by the processing unit and the interface unit can correspond to the operations described in the first or third aspects above.

[0061] In one possible design, the communication device includes a processor, which can be coupled to a memory. The memory can store the necessary computer programs or instructions for implementing the functions of the first or third aspects described above. The processor can execute the computer programs or instructions stored in the memory. When the computer programs or instructions are executed, the communication device implements the method of any possible design of the first or third aspects described above.

[0062] In one possible design, the communication device includes a processor and a memory, and the memory may store the necessary computer programs or instructions for implementing the functions of the first or third aspect. The processor may execute the computer program or instructions stored in the memory. When the computer program or instructions are executed, the communication device implements the method of any possible design of the first or third aspect.

[0063] In one possible design, the communication device includes a processor and an interface circuit, wherein the processor is used to communicate with other devices through the interface circuit and execute the method in any possible design of the first aspect or the third aspect above.

[0064] In a sixth aspect, the present application provides a communication device, which may be an API caller, a device including an API caller (e.g., a terminal or AF) or an AzF, or an API caller, a device including an API caller or a module in an AzF (e.g., a circuit or chip), or a logical node, logical module or software that can implement all or part of the functions of an API caller, a device including an API caller or an AzF. The communication device has the function of implementing the second or fourth aspect mentioned above. For example, the communication device includes a module or unit or means corresponding to the operations involved in the second or fourth aspect mentioned above, and the module or unit or means may be implemented by software, or by hardware, or the corresponding software may be implemented by hardware.

[0065] In one possible design, the communication device includes a processing unit and an interface unit. The interface unit can be used to send and receive signals to enable communication between the communication device and other devices, and the processing unit can be used to perform certain internal operations of the communication device. The functions performed by the processing unit and the interface unit can correspond to the operations described in the second or fourth aspects above.

[0066] In one possible design, the communication device includes a processor, which can be coupled to a memory. The memory can store the necessary computer programs or instructions for implementing the functions of the second or fourth aspect. The processor can execute the computer programs or instructions stored in the memory. When the computer programs or instructions are executed, the communication device implements the method of any possible design of the second or fourth aspect.

[0067] In one possible design, the communication device includes a processor and a memory. The memory may store the necessary computer programs or instructions for implementing the functions of the second or fourth aspect. The processor may execute the computer program or instructions stored in the memory. When the computer program or instructions are executed, the communication device implements the method of any possible design of the second or fourth aspect.

[0068] In one possible design, the communication device includes a processor and an interface circuit, wherein the processor is used to communicate with other devices through the interface circuit and execute the method in any possible design of the second aspect or the fourth aspect above.

[0069] It can be understood that in the fifth aspect or the sixth aspect above, the processor can be implemented by hardware or by software. When implemented by hardware, the processor can be a logic circuit, an integrated circuit, etc.; when implemented by software, the processor can be a general-purpose processor, which is implemented by reading the software code stored in the memory. In addition, the above processors can be one or more, and the memories can be one or more. The memory can be integrated with the processor, or the memory and the processor can be set separately. In the specific implementation process, the memory can be integrated with the processor on the same chip, or can be set on different chips respectively. The embodiment of the present application does not limit the type of memory and the setting method of the memory and the processor.

[0070] In a seventh aspect, the present application provides a communication system, which may include the communication device described in the fifth aspect and the communication device described in the sixth aspect. Optionally, when the communication device described in the fifth aspect performs the method described in the first aspect, the communication device described in the sixth aspect performs the method described in the second aspect. When the communication device described in the fifth aspect performs the method described in the third aspect, the communication device described in the sixth aspect performs the method described in the fourth aspect.

[0071] In an eighth aspect, the present application provides a computer-readable storage medium, in which computer-readable instructions are stored. When a computer reads and executes the computer-readable instructions, the computer executes a method in any possible design of any aspect from the first to the fourth aspects mentioned above.

[0072] In a ninth aspect, the present application provides a computer program product, which, when read and executed by a computer, enables the computer to execute the method in any possible design of any aspect from the first to the fourth aspects above.

[0073] In a tenth aspect, the present application provides a chip, which is used to read a computer program stored in a memory to execute a method in any possible design of any aspect from the first to the fourth aspects above.

[0074] The technical effects that can be achieved in any of the fifth to tenth aspects mentioned above can refer to the description of the technical effects that can be achieved by any possible design in any of the first to fourth aspects mentioned above, and the repetitions will not be discussed. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0076] FIG2 is an architecture diagram of another communication system provided in an embodiment of the present application;

[0077] FIG3 is a flow chart of a first communication method provided in an embodiment of the present application;

[0078] FIG4 is a flow chart of a first method for applying for a token provided in an embodiment of the present application;

[0079] FIG5 is a flowchart of a first method for revoking a token provided in an embodiment of the present application;

[0080] FIG6 is a flow chart of a second method for applying for a token provided in an embodiment of the present application;

[0081] FIG7 is a flow chart of a second token revocation method provided in an embodiment of the present application;

[0082] FIG8 is a flowchart of a third method for applying for a token provided in an embodiment of the present application;

[0083] FIG9 is a flowchart of a third token revocation method provided in an embodiment of the present application;

[0084] FIG10 is a flow chart of a second communication method provided in an embodiment of the present application;

[0085] FIG11 is a flow chart of a third communication method provided in an embodiment of the present application;

[0086] FIG12 is a structural diagram of a communication device provided in an embodiment of the present application;

[0087] FIG13 is a structural diagram of another communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0088] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the accompanying drawings.

[0089] The following describes the architecture of the communication system to which the method provided in this application is applied.

[0090] FIG1 shows an architecture diagram of a communication system applicable to an embodiment of the present application, wherein the fifth generation (the5 th The 5G network architecture is a 5G network architecture. As shown in Figure 1, the communication system consists of three parts: the terminal part, the operator network part, and the data network (DN). The functions of some of these network elements are described below.

[0091] A terminal, also known as a terminal device or user equipment (UE), is a device with wireless transceiver capabilities. It can be deployed on land, indoors or outdoors, handheld or vehicle-mounted; on water (such as ships); or in the air (such as airplanes, balloons, and satellites). A terminal can be a mobile phone, tablet computer, computer with wireless transceiver capabilities, virtual reality (VR) terminal, augmented reality (AR) terminal, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, etc.

[0092] The above-mentioned terminal can establish a connection with the operator network through the interface provided by the operator network (such as N1, etc.), and use the data and / or voice services provided by the operator network. The terminal can also access the DN through the operator network, use the operator services deployed on the DN, and / or services provided by a third party. Among them, the above-mentioned third party may be a service provider other than the operator network and the terminal, and can provide data and / or voice services to the terminal. Among them, the specific form of the above-mentioned third party can be determined according to the actual application scenario and is not limited here.

[0093] The carrier network can be a network deployed by the carrier and can include access network equipment and core network equipment. In one possible implementation method, the carrier network also includes an AF network element. Alternatively, the AF network element may not belong to the carrier network but to a third party.

[0094] Access network equipment is a device in a wireless network, such as a radio access network (RAN) node or a radio access network device that connects a terminal to a wireless network. Currently, some examples of access network equipment include: next-generation base stations (gNodeB, gNB) in 5G, transmission reception points (TRP), evolved Node B (eNB), radio network controller (RNC), Node B (NB), base station controller (BSC), base transceiver station (BTS), home base station (e.g., home evolved NodeB, or home Node B, HNB), base band unit (BBU), wireless fidelity (Wifi) access point (AP), integrated access and backhaul (IAB), etc. In one implementation, the access network equipment may also be a future communication system (such as the 6th generation (the 6 th access network equipment in generation, 6G) communication system.

[0095] The core network device may include at least one of the following network elements: a mobility management network element, a session management network element, a user plane network element (e.g., a user plane function (UPF) network element), a data management network element (e.g., a unified data management (UDM) network element), a unified data repository (UDR) network element, a network exposure network element (e.g., a network exposure function (NEF) network element), a policy control network element (e.g., a policy control function (PCF) network element), or an authentication function network element (e.g., an authentication server function (AUSF) network element). Some of these network elements are described below.

[0096] In this application, the mobility management network element is a control plane network element provided by the operator network, which is responsible for the access control and mobility management of the terminal accessing the operator network, such as including functions such as mobile state management, allocation of user temporary identity, authentication and authorization of users. In 5G, the mobility management network element can be an access and mobility management function (AMF) network element. In future communications such as 6G, the mobility management network element can still be an AMF network element, or have other names, which are not limited in this application.

[0097] In this application, the session management network element is a control plane network element provided by the operator network, which is responsible for managing the protocol data unit (PDU) session of the terminal. A PDU session is a channel for transmitting PDUs, and the terminal needs to transmit PDUs to each other with the DN through the PDU session. The SMF network element is responsible for establishing, maintaining and deleting the PDU session. The functions of the session management network element include: session management (such as session establishment, modification and release, including tunnel maintenance between the user plane network element and the access network equipment), selection and control of the user plane network element, service and session continuity (SSC) mode selection, roaming, etc. In 5G, the session management network element can be a session management function (SMF) network element. In future communications such as 6G, the session management network element can still be an SMF network element, or a network element with other names but with all or part of the functions of the session management network element. This application does not limit this.

[0098] In this application, the network open network element is a control plane network element provided by the operator. The network open network element opens the external interface of the operator network to the third party in a secure manner, and the interface is, for example, a service API. For example, when the session management network element needs to communicate with the network element of a third party, the network open network element can serve as a relay for the communication between the session management network element and the network element of the third party. When the network open network element acts as a relay, it can translate the identification information of the subscriber and the identification information of the third-party network element. For example, when the network open network element sends the subscriber's subscriber permanent identifier (SUPI) from the operator network to the third party, the SUPI can be translated into its corresponding external identity (ID). Conversely, when the network open network element sends the external ID (third-party network element ID) to the operator network, it can be translated into SUPI. In 5G, the network open network element can be a NEF network element. In future communications such as 6G, the network open network element can still be a NEF network element, or have other names, which are not limited in this application.

[0099] In the embodiments of the present application, the communication device for realizing the functions of the access network device, terminal or core network device can be the access network device, terminal or core network device itself, or can be a device capable of supporting the access network device, terminal or core network device to realize the functions, such as a chip system, which can be installed in the access network device, terminal or core network device. In the technical solutions provided in the embodiments of the present application, the technical solutions provided in the embodiments of the present application are described by taking the device for realizing the functions of the access network device as the access network device, the device for realizing the functions of the terminal as the terminal, and the device for realizing the functions of the core network device as the core network device as an example.

[0100] A DN is a network located outside of a carrier network. A carrier network can connect to multiple DNs, and a variety of services can be deployed on the DN, providing data and / or voice services to terminals. For example, a DN is the private network of a smart factory. Sensors installed in the workshop can be terminals, and the DN houses a control server for the sensors, which can provide services to the sensors. Sensors can communicate with the control server, receive instructions from the control server, and transmit collected sensor data to the control server based on the instructions. Another example is a DN that is a company's internal office network. An employee's mobile phone or computer can be a terminal, allowing them to access information and data resources on the company's internal office network.

[0101] In Figure 1, N1, N2, N3, and N4 are interface serial numbers. The meanings of these interface serial numbers can be found in the 3GPP standard protocol and are not limited here.

[0102] Figure 2 exemplarily shows an API system architecture that may be applicable to an embodiment of the present application, which architecture may be a common API framework (CAPIF) architecture. As shown in Figure 2, the CAPIF architecture may include: an API caller (API invoker), a CAPIF core function (CAPIF core function, CCF) network element, an authorization function (authorization function, AuF or AzF) network element, and an API exposing function (API exposing function, AEF) network element. Optionally, the CAPIF architecture may also include at least one of the following: an API publishing function (APF) network element, an API management function (API management function) network element, or a resource owner client (resource owner client(s), RO Client). The components of the CAPIF architecture are described below.

[0103] API callers are typically third-party applications that have signed service agreements with public land mobile network (PLMN) operators. These applications can run in either the terminal or the AF, so the API caller can be part of either the terminal or the AF. API callers can perform the following functions: provide API caller identity information and other information required for API caller authentication; support mutual authentication with the CCF; obtain authorization before accessing service APIs; discover service APIs; and search and call service APIs. The location of the API caller in the communication network can be seen in the AF network element or UE shown in Figure 1.

[0104] CCF may have the following functions: authenticate the API caller based on the API caller's identity information and other information required to authenticate the API caller; support mutual authentication with the API caller; provide authorization for the API caller before the API caller accesses the service API; publish and store service API information, and support discovery of service APIs; control access to service APIs according to policies configured by the PLMN operator; monitor service API calls; store logs of service API calls, and provide service API call logs to the authorization function network element; perform billing based on service API call logs; add new API callers and delete API callers; store CAPIF and service API-related policy configurations; support auditing based on access logs (for example, detecting whether there is abuse); support the use of another CAPIF core function to publish and / or discover service APIs in CAPIF docking. Optionally, CCF may be a device in the core network or a device in other networks, and this application does not limit this.

[0105] AzF is used to obtain user authorization. In this application, AuF and AzF can be used interchangeably. In addition, both AzF and CCF have authorization functions. AzF and CCF can be set in the same device or in different devices. The following example uses AzF and CCF set in the same device as an example. In this case, AzF and CCF are not distinguished. That is, AzF and CCF can be used interchangeably in the following, and can also be called authorization server.

[0106] The AEF is used to provide service APIs and serves as the entry point for API callers to invoke the service APIs. The AEF can perform the following functions: authenticate API callers based on the identity and other information required for API caller authentication provided by the CCF; verify authorization provided by the CCF; and record the number of times the service API is called on the CCF. For example, the AEF can be a NEF. The location of the AEF in the communication network can be seen in the NEF network element in Figure 1.

[0107] The API publishing function network element is a function network element that enables API providers to publish APIs. It can publish service API information to the CCF so that API callers can find the service API information in the CCF. It should be noted that the API publishing function network element and the NEF can be co-located.

[0108] The API management function network element performs management of the service API, such as monitoring the status of the service API, recording call information, etc. It should be noted that the API management function network element can be co-located with the NEF.

[0109] The RO Client is an application client used by users and can display an operation interface to users. The RO Client is, for example, an operating system or a browser. The RO Client can be an application on the UE in Figure 1. In this application, the RO client can also be called a user agent, and the two are used interchangeably.

[0110] In Figure 2, CAPIF-1, CAPIF-1e, CAPIF-2, CAPIF-2e, etc. are reference points. The meanings of these reference points can be found in the 3GPP standard protocol and are not limited here.

[0111] It should be noted that the communication systems shown in Figures 1 and 2 do not constitute a limitation on the communication systems to which the embodiments of the present application can be applied. Therefore, the communication method provided in the embodiments of the present application can also be applied to communication systems of various standards, such as: long term evolution (LTE) communication system, 5G communication system, 6G communication system and future communication system, vehicle to everything (V2X), long term evolution-vehicle network (LTE-vehicle, LTE-V), vehicle to vehicle (V2V), vehicle network, machine type communication (MTC), Internet of things (IoT), long term evolution-machine to machine (LTE-machine to machine, LTE-M), machine to machine (M2M), Internet of Things, etc. In addition, the communication system provided in the present application can be used in terrestrial network (TN) and / or non-terrestrial network (NTN) without limitation. In addition, it should be noted that the embodiments of the present application do not limit the names of the network elements in the communication system. For example, in communication systems of different standards, each network element may have other names; for example, when multiple network elements are integrated into the same physical device, the physical device may also have other names.

[0112] To facilitate understanding of this application, the terms used in this application are explained below.

[0113] 1) A token is a digital object, data field, or string that contains authorization or authentication information. For example, a token can be used to indicate authorization for one or more services or resources for one or more users.

[0114] Tokens can be classified into various types according to their purpose, such as access tokens (access_token), refresh tokens (refresh_token), identity tokens (ID token), etc. Among them, the access token is a credential used to access protected resources. For example, it can be used to authorize API callers to access the API service corresponding to the access token through AEF, such as QoS service. The refresh token is a credential used to obtain an access token. For example, it can be used to authorize API callers to request a new token from CCF when the current access token expires, that is, the refresh token can be used to update the usage time of the current token. In addition, the refresh token can also be used to shorten the validity period of the current access token or reduce the scope of the current access token.

[0115] A token may include a claim. This claim is a small piece of asserted information about the subject of the token and may include at least one of the following:

[0116] 1. Timeout: This field can be used to determine the timeout period of the token. For example, in the token declaration, "Timeout: {23-12-2}" means that the token will become invalid starting from December 2, 2023.

[0117] 2. API Invoker ID: This identifier indicates the API caller to which this token corresponds. For example, a token declaration may include API Invoker ID #1. If this token is an access token, it authorizes the API caller to access the API service to which this access token corresponds through the AEF. If this token is an update token, it authorizes the API caller to request an updated token from the CCF.

[0118] 3. AEF ID: This field indicates the AEF to which the token corresponds. For example, if the token declaration includes AEF ID #1, then if the token is an access token, it authorizes the API caller to access the API service associated with the access token through the AEF associated with AEF ID #1.

[0119] 4. Service indication: This indicates the service authorized by the token. This service indication can be an API service ID (also known as a service API ID or service ID). For example, a token declaration might include API service ID #1. If the token is an access token, it authorizes the API caller to access the API service corresponding to API service ID #1 through AEF.

[0120] 5. User indication information: used to indicate the user corresponding to the token. The user indication information can be the user ID or the ID of the terminal corresponding to the user.

[0121] 6. Scope: This is used to determine the scope of authorization for a token. For example, if the scope statement in a token includes AEF ID#1:API Service ID#1, API Service ID#2, it means that the API caller is authorized to access the API services corresponding to API Service ID#1 and API Service ID#2 through AEF#1.

[0122] Optionally, each piece of information in the above declarations can be a separate declaration. For example, the timeout period is one declaration, and the scope is another. It should be noted that the service indication information can be a separate declaration or included in the scope declaration. This application does not limit the declaration in which the service indication information is included.

[0123] It should be noted that tokens can also be classified according to whether they include information such as declarations. For example, a structured token includes one or more of the above-mentioned declaration information. The recipient or verifier of the token (such as AEF) can obtain the declaration information from the token. For another example, an opaque token does not include the above-mentioned declaration information. The recipient or verifier of the token (such as AEF) needs to request other network elements through other information in the token to indirectly obtain the declaration information or verify the declaration information. Optionally, the other information can be index information, and the index information is, for example, a token ID or a reference ID. Tokens can also be classified in other ways. For example, a bearer type token means that the owner of the token is authorized to use the resources or services corresponding to the token; a message authentication code (MAC) type token requires the owner of the token to further prove that he or she has the corresponding MAC key before being authorized to use the resources or services corresponding to the token. This application does not limit the classification method of tokens.

[0124] Optionally, the token may further include a signature, which may be a signature of the CCF's declaration of the token, and may be used to protect the integrity and / or confidentiality of the token.

[0125] In this application, the token can be encrypted or unencrypted. If the token is encrypted, the token holder (e.g., the API caller) needs to obtain the decryption key to read the claims in the token. This application does not restrict whether the token is encrypted.

[0126] 2) A user agent (also known as an RO Client) is an application program associated with a user that initiates various requests on their behalf. A user agent can include at least one of the following: a browser, a terminal application, a client, a command-line tool, or a web bot. The user agent can be installed on the terminal.

[0127] In this application, the communication channel between two network elements is protected by security, and this application does not limit the specific method of security protection. The two network elements are, for example: a user agent and an API caller, a user agent and an AZF, or an API caller and an AZF.

[0128] In the following text of this application, association can be replaced by binding.

[0129] In the following text of this application, "sending information to...(terminal)" can be understood as the destination of the information being the terminal, and can include sending information to the terminal directly or indirectly. "Receiving information from...(terminal)" can be understood as the source of the information being the terminal, and can include receiving information from the terminal directly or indirectly. The information may be processed as necessary between the source and destination of the information, such as format changes, but the destination can understand the valid information from the source. Similar expressions in this application can be understood similarly and will not be repeated here.

[0130] Currently, 3GPP networks can provide external services. For example, 3GPP networks provide external services such as user location information. After an API caller obtains authorization for user location information, they can obtain the user's location information through the 3GPP network. Another example of external services provided by the 3GPP network is QoS services. An API caller can request the 3GPP network to change the QoS service level of a user or terminal. After obtaining authorization for a certain level of QoS service, the API caller can establish or modify a PDU session corresponding to that level for the user or terminal through the 3GPP network, thereby ensuring that the user or terminal's communication quality meets the requirements of that level.

[0131] After the API caller obtains authorization, the authorization may be revoked. The Internet Engineering Task Force (IETF) standard supports a mechanism for revoking authorization (i.e., revoking tokens) initiated by the API caller (i.e., client). However, the token revocation process initiated by the API caller cannot guarantee that the token revocation process is authorized by the user. For example, when there are malicious applications in devices such as terminals or cloud platforms, the malicious applications may obtain the client's information and initiate a token revocation process, resulting in a service interruption for the user, i.e., the user is denied service (DoS). For example, for an update token, when a malicious application obtains the ID of the update token, the malicious application can initiate a revocation process for the update token. Therefore, how to design a service revocation authorized by the user, for example, how to design a token revocation process authorized by the user, requires further research.

[0132] In view of this, an embodiment of the present application provides a communication method. Figure 3 is a flow chart corresponding to the communication method provided in an embodiment of the present application. Figure 3 illustrates the method by taking the terminal and the first device as the execution subjects of the interaction diagram as an example, but the present application does not limit the execution subjects of the interaction diagram. Among them, the first device can be an API caller or AzF, or it can be a module applied to the API caller or AzF, such as a chip, a chip system or a processor, or it can be a logical node, a logical module or software that can realize all or part of the API caller or AzF functions. Optionally, the terminal in Figure 3 can be replaced by a user agent.

[0133] As shown in FIG3 , the method includes the following steps:

[0134] S301: The terminal determines first information, where the first information may be used to determine a first token. The first token may be a token that authorizes a first user to provide a first service.

[0135] The specific content of the first information will be described in the following methods a1, a2 and a3, and will not be expanded here.

[0136] S302: The terminal sends a first request; correspondingly, the first device receives the first request.

[0137] The first request may include first information, and the first request is used to request the revocation of the first token. Thus, based on the first information in the first request, the first device may determine that the first request is used to request the revocation of the first token. The first request may be an existing message (e.g., a revocation request) or a new message, and this application does not limit this.

[0138] In some examples, the terminal may send the first request directly to the first device. For example, the first device is an API caller, and the terminal may send the first request to the API caller based on the address information of the API caller. The address information of the API caller may be, for example, the Internet Protocol (IP) address and / or the Uniform Resource Locator (URL) address of the API caller. For another example, the first device is AzF, and the terminal may send the first request to AzF based on the address information of AzF. The address information of AzF may be, for example, the IP address and / or URL of AzF. The address information of AzF may be obtained by the terminal from the API caller.

[0139] In other examples, the terminal may send the first request to the first device via a second device. The second device may include one or more devices. For example, the first device is AzF and the second device is an API caller. The terminal may send the first request to AzF via the API caller.

[0140] Optionally, the first request also includes: information indicating the first user. The information indicating the first user may be, for example, the name or ID of the first user, or the ID of the terminal corresponding to the first user (e.g., SUPI or Generic Public Subscription Identifier (GPSI)). The information indicating the first user and the first information may be used to determine the first token. For example, the first device may store tokens for multiple users. Based on the information indicating the first user, the first device may select the token of the first user from the tokens of the multiple users, and select the first token from the tokens of the first user based on the first information. Because the first device may use the user's information as an index for the tokens of the multiple users, in this example, the first device may quickly exclude tokens of users other than the first user, narrowing the range of tokens to be determined and speeding up the determination of the first token. For another example, the first information may correspond to multiple tokens, and the token corresponding to the first user from the multiple tokens may be the first token. In this way, the first device may first locate the multiple tokens based on the first information, and then select the token corresponding to the first user from the multiple tokens as the first token based on the information indicating the first user. The multiple tokens may be tokens of multiple users, and the tokens of the multiple users may be stored by the first device.

[0141] S303: The first device determines the first token according to the first request.

[0142] The first device may determine the first token according to the first information in the first request. The specific content of the first device determining the first token will be described in the following methods a1, a2, and a3, which will not be expanded here.

[0143] In some possible implementations, the first device is an API caller. After determining the first token, the API caller may send a second request to AzF, which may include the first token or information indicating the first token (e.g., an ID), requesting the revocation of the first token. AzF may then revoke the first token. The specific process by which AzF revokes the first token is not limited in this application.

[0144] In some other possible embodiments, the first device is an AzF. After determining the first token, the AzF may revoke the first token. The specific process of the AzF revoking the first token is not limited in this application.

[0145] 3, the terminal can initiate the process of revoking the first token by including the first information in the first request. In this way, the user can initiate the process of revoking the first token by controlling the terminal, thereby revoking the authorization of the first service corresponding to the first token.

[0146] As mentioned above, the first information can be used to determine the first token. There are many ways to use the first information to determine the first token, for example, way a1, way a2 or way a3.

[0147] Mode a1: The first information includes a random number, which can be used to determine the first token.

[0148] There are multiple ways to use the random number to determine the first token, for example, way b1 or way b2.

[0149] Method b1: A correspondence #1 exists between the random number and the first token. The first device stores this correspondence #1. Thus, in S303, upon receiving the first request including the random number, the first device can determine the first token based on the random number and correspondence #1, and further determine that the first request is for revoking the first token.

[0150] Optionally, the first device may obtain the correspondence #1 through the following steps A1 to A3:

[0151] A1: The terminal generates the random number.

[0152] The random number may be generated by the terminal after detecting a first operation by the first user. The first operation may be used to indicate that the first user agrees to authorize the first service for the first user. For example, during the application process for the first token, the terminal displays pop-up window #1, which includes a display area for "Do you agree to authorize the first service for the first user?" and an operation area for "Yes" and "No." The first operation may include the first user touching the screen to select "Yes" in the operation area.

[0153] Optionally, after generating the random number, the terminal may save the random number.

[0154] In some possible ways, the terminal may save the correspondence between the random number and the first service and / or the first user, so that the terminal can determine the first token based on the correspondence. For example, the terminal may include the indication information of the first service corresponding to the random number, so that the terminal can determine the first service based on the random number. For another example, the terminal may save the indication information of the first user corresponding to the random number, so that the terminal can determine the first user based on the random number. For another example, the terminal may save the indication information of the first service corresponding to the random number and the indication information of the first user, so that the terminal can determine the first service of the first user based on the random number. Optionally, the terminal may also save the correspondence between the random number and the authorization information other than the indication information of the first service and the indication information of the first user, so as to more accurately determine the first token. For example, the authorization information may include but is not limited to at least one of the following: information on the scope of authorization, information on the service API, information on AzF, information on AEF, information on the validity period of authorization, or information on the time of authorization, etc.

[0155] A2: The terminal sends the random number; correspondingly, the first device receives the random number.

[0156] The manner in which the terminal sends the random number can refer to the manner in which the terminal sends the first request in S302, except that the first request is replaced by a random number, and will not be further described here. The random number can be included in an existing message or in a new message, and this application does not limit this. Optionally, the terminal can encrypt the random number before or when sending the random number; accordingly, the first device can decrypt the received message to obtain the random number. This application does not limit whether the random number is encrypted.

[0157] Optionally, the terminal may send a random number during the process of applying for the first token. Exemplarily, after detecting the first operation and generating the random number, the terminal may send the random number. The specific content of detecting the first operation can be referred to step A1 and will not be repeated here.

[0158] A3: The first device associates the random number with the first token or the authorization code corresponding to the first token to obtain correspondence #1. Correspondence #1 can be a direct correspondence between the random number and the first token, or a correspondence between the random number and the authorization code corresponding to the first token. Optionally, after obtaining correspondence #1, the first device can save it.

[0159] In some possible approaches, in approach b1, after S303, the method shown in FIG3 further includes step A4:

[0160] A4: The first device sends a first response; accordingly, the terminal receives the first response.

[0161] Among them, the first response can be used to indicate one of the following: the first token has been successfully revoked, the process of revoking the first token has been triggered, or the first request has been received. Optionally, the first response includes a random number. In this way, after receiving the first response, the terminal can determine one of the following based on the random number and the correspondence #1 between the random number and the first token: the first token has been successfully revoked, the process of revoking the first token has been triggered, or the first request has been received. The first response can be an existing message (for example, a revocation response) or a new message, and this application does not limit this.

[0162] In some examples, the first device may directly send the first response to the terminal. For example, if the first device is an AzF, the AzF may send the first response to the terminal based on the address information of the terminal. The address information of the terminal may be, for example, the IP address of the terminal.

[0163] In other examples, the first device may send the first response to the terminal via the second device. The second device may include one or more devices. For example, the first device is AzF and the second device is an API caller. AzF may send the first response to the terminal via the API caller.

[0164] In this way, the terminal can promptly learn that the first token has been successfully revoked, the process of revoking the first token has been triggered, or the first device has received the first request.

[0165] Method b2: The random number is used to determine the second information via a one-way function. In other words, a functional relationship exists between the random number and the second information, or the second information is determined based on the random number and the one-way function. The second information can be used to determine the first token. Exemplarily, the one-way function can be a hash function or a key derivation function (KDF). The following description uses a hash function as an example.

[0166] In some possible embodiments, there is a corresponding relationship #2 between the second information and the first token. The first device stores the corresponding relationship #2 and the hash function. Thus, in S303, after receiving the first request containing the random number, the first device can determine the second information based on the random number and the hash function, and determine the first token based on the second information and the corresponding relationship #2, and further determine that the first request is for requesting the revocation of the first token. For example, the random number is rand. After receiving the first request, the first device can calculate Utid = hash(rand), where Utid is the second information. Then, the first device can determine the first token corresponding to Utid based on Utid and the corresponding relationship #2. Optionally, when calculating Utid, the one-way function can also include other parameters in addition to the random number. For example, the one-way function can be expressed as: Utid = hash(rand, other parameters). Exemplarily, the other parameters can include at least one of the following: the ID of the terminal or the ID of the first device, etc. It should be noted that this application does not limit the number and values ​​of other parameters. The method by which the first device calculates the second information (for example, the one-way function) and the number and / or type of parameters required to calculate the second information may be pre-configured or determined by negotiation between the first device and the terminal, and this application does not limit this.

[0167] Optionally, the first device may obtain the corresponding relationship #2 through the following steps B1 to B3:

[0168] B1: The terminal generates the random number and the second information.

[0169] The specific details of how the terminal generates the random number can be found in step A1 and are not further described here. After generating the random number, the terminal can calculate the random number using a one-way function to obtain the second information. The method used by the terminal to calculate the second information is the same as the method used by the first device to calculate the second information. For details, see method b2, which describes how the first device can determine the second information based on the random number and a hash function. This description is not further described here.

[0170] Optionally, after generating the random number, the terminal may save the random number.

[0171] B2: The terminal sends the second information; accordingly, the first device receives the second information.

[0172] The manner in which the terminal sends the second information may refer to the manner in which the terminal sends the random number in step A2, except that the random number is replaced by the second information, which will not be described in detail here.

[0173] B3: The first device associates the second information with the first token to obtain correspondence #2. This correspondence #2 can be a direct correspondence between the second information and the first token, or a correspondence between the second information and the authorization code corresponding to the first token. When correspondence #2 is a direct correspondence between the second information and the first token, a one-to-one correspondence can exist between the second information and the first token, thereby improving the accuracy of determining the first token based on the second information. Optionally, after obtaining correspondence #2, the first device can save this correspondence #2.

[0174] In some possible approaches, in approach b2, after S303, the method shown in FIG3 further includes step B4:

[0175] B4: The first device sends a first response; accordingly, the terminal receives the first response.

[0176] Among them, the first response can be used to indicate one of the following: the first token is successfully revoked, the process of revoking the first token has been triggered, or the first request has been received. In some examples, the first response includes a random number. In this way, after receiving the first response, the terminal can determine the second information based on the random number and the hash function, and determine the first token based on the second information and the corresponding relationship #2, and then determine that the first response is used to indicate one of the following: the first token is successfully revoked, the process of revoking the first token has been triggered, or the first device has received the first request. In other examples, the first response includes the second information. In this way, after receiving the first response, the terminal can determine one of the following based on the second information and the corresponding relationship #2: the first token is successfully revoked, the process of revoking the first token has been triggered, or the first device has received the first request. The first response can be an existing message (for example, a revocation response) or a new message, and this application does not limit this.

[0177] The manner in which the first device sends the first response may refer to step A4 and will not be described in detail here.

[0178] In this way, the terminal can promptly be informed that the first token has been successfully revoked.

[0179] In some possible approaches, after S303, the method shown in FIG3 further includes step B5:

[0180] B5: The first device sends a notification message to the API caller; correspondingly, the API caller receives the notification message from the first device.

[0181] The notification message is used to indicate one of the following: successful revocation of the first token, triggering of the revocation process for the first token, or receipt of the first request. Exemplarily, the notification message may include information indicating the first token (e.g., a token ID). Thus, upon receiving the notification message, the API caller may determine one of the following: successful revocation of the first token, triggering of the revocation process for the first token, or receipt of the first request by the first device.

[0182] This application does not limit the execution order of step B4 and step B5.

[0183] Through this method a1, the terminal can initiate the revocation process of the first token based on the random number. In this way, the user can control the terminal to initiate the revocation process of the first token through the user agent on the terminal, ensuring that the revocation process is authorized by the user, thereby preventing the user's desired service from being interrupted due to the revocation of authorization, that is, preventing the user from being denied service.

[0184] Furthermore, in approach a1, the random number used to initiate the revocation process for the first token is generated by the terminal and protected by a one-way function. This prevents other applications on the terminal or AF, other than the user agent, from obtaining information related to the random number and, therefore, from initiating the revocation process for the first token, thereby improving terminal communication security.

[0185] Mode a2: The first information includes auxiliary information for identifying the first token. In this way, in S303, the first device can determine the first token according to the auxiliary information.

[0186] Exemplarily, the auxiliary information may include at least one of the following:

[0187] 1. Information for identifying the authorized scope of the first token (hereinafter referred to as information #1): For example, information #1 may indicate at least one of the following: an authorized service scope, an authorized permission scope (e.g., read or write), or a method for authenticating user information (e.g., an openID method). The authorized service scope may include the authorized service scope corresponding to each AEF. Optionally, information #1 may be used to determine the scope in the declaration of the first token.

[0188] 2. Information for identifying the service API corresponding to the first token (hereinafter referred to as information #2): For example, information #2 may indicate at least one of the following: QoS service, obtaining terminal location information, and a service subscribed by the first user. Optionally, information #2 may be used to determine the API service ID in the declaration of the first token.

[0189] 3. Information used to identify the AzF corresponding to the first token (hereinafter referred to as information #3): For example, this information #3 may include at least one of the following: the name, uniform resource locator (URL), or ID of the issuer of the first token. This information #3 may be used to determine the "iss" claim (or parameter) in the claim set of the first token. The "iss" claim is used to indicate the issuer of the first token. For example, the issuer of the first token may be the AzF corresponding to the first token.

[0190] 4. Information used to identify the user's indication information (hereinafter referred to as information #4): For example, this information #4 may include the first user's indication information. The specific content of the first user's indication information can be found in the description of the first user's indication information in S302 and will not be repeated here. This information #4 can be used to determine the "sub" claim in the first token's claim set. This claim indicates the subject of the first token, i.e., the authorized user of the first token. For example, the subject of the first token may be the first user or the terminal corresponding to the first user.

[0191] 5. Information for identifying the AEF network element corresponding to the first token (hereinafter referred to as information #5): For example, information #5 may include at least one of the following: the name, URL, or ID of the AEF network element corresponding to the first token. Information #5 may be used to determine the "aud" parameter in the declaration of the first token, which indicates the audience of the first token. The audience of the first token may include the AEF network element corresponding to the first token.

[0192] 6. Information for identifying the validity period of the first token (hereinafter referred to as information #6): Information #6 can be used to determine the "exp" parameter in the declaration of the first token, which is used to indicate the expiration time of the first token.

[0193] 7. Information used to identify the issuance time of the first token (hereinafter referred to as information #7): Information #7 can be used to determine the "iat" (i.e., issued at) statement or parameter in the statement set of the first token, which is used to indicate the issuance time of the first token.

[0194] It should be noted that the auxiliary information may also include other information in addition to the above 7 types of information. Optionally, the auxiliary information may include information corresponding to any statement in the first token and / or any information in the statement of the first token. The first device determines the first token by identifying the statement corresponding to the auxiliary information, or identifying the information in the statement corresponding to the auxiliary information. The auxiliary information helps to narrow the search scope for determining the first token in multiple tokens, so that the first token can be accurately determined. For example, if the declaration of the token includes an API caller identifier, the auxiliary information may include information for identifying the API caller identifier. The first device can identify the API caller identifier in the declaration based on the information for identifying the API caller identifier, thereby determining the first token including the API caller identifier.

[0195] Optionally, the auxiliary information and the information in the declaration of the first token may be different in format and / or accuracy, etc. For example, information #7 in the auxiliary information may include July 2023. The declaration "iat" of the first token may include July 27, 2023.

[0196] After receiving the auxiliary information, the first device may search for a first token that matches the auxiliary information from a token database based on the auxiliary information. The token database may be stored in the first device or in a device other than the first device, and this application does not limit this. Optionally, the first device may compare the auxiliary information with the declaration of the token in the token database, and select a token whose declaration is consistent with the auxiliary information as the first token. For example, in the auxiliary information, information #2 indicates QoS service, information #4 indicates user #1, information #5 indicates AEF network element #1, and information #6 indicates September 10, 2023. The token database includes token #1, and in the declaration of token #1, the API service ID indicates QoS service, the "sub" declaration indicates user #1, the "aud" declaration indicates AEF network element #1, and the "exp" declaration indicates September 10, 2023. The first device may determine token #1 as the first token.

[0197] In some possible approaches, the auxiliary information may be acquired and stored by the terminal after detecting the first operation of the first user. The specific content of the first operation detected by the terminal is referred to approach a1 and will not be repeated here.

[0198] Optionally, AzF may also send an authorization code corresponding to the first token; accordingly, the terminal receives the authorization code corresponding to the first token. Based on the authorization code, the terminal may determine that the first token corresponding to the auxiliary information is a token authorized by AzF; that is, the authorization code may be used to determine that the first token corresponding to the auxiliary information is a token authorized by AzF.

[0199] Through method a2, the terminal can initiate the revocation process of the first token based on the auxiliary information. In this way, the user can control the terminal to initiate the revocation process of the first token through the user agent on the terminal, ensuring that the revocation process is authorized by the user, thereby avoiding interruption of the user's desired service due to revocation of authorization, that is, avoiding denial of service to the user.

[0200] Mode a3: The first information includes an authorization code corresponding to the first token. In this way, in S303, the first device can determine the first token according to the authorization code.

[0201] The authorization code may be obtained by the terminal from AzF. For example, during the application process for the first token, AzF sends the authorization code to the terminal. The manner in which AzF sends the authorization code to the terminal can be similar to the manner in which the first device sends the first response in step A4, except that the first device is replaced by AzF and the first response is replaced by the authorization code. This description is omitted here.

[0202] Optionally, the terminal may save at least one of the following: a correspondence between the authorization code and the first service and / or the first user, or a correspondence between the authorization code and authorization information other than the indication information of the first service and the indication information of the first user, so that the terminal can determine the first token based on the correspondence. The manner in which the terminal saves the above-mentioned correspondences can refer to the description of the following content in step A1: the terminal saves the correspondence between the random number and the first service and / or the first user, and the terminal saves the correspondence between the random number and the authorization information other than the indication information of the first service and the indication information of the first user, except that the random number is replaced by the authorization code, which will not be repeated here.

[0203] It should be understood that the authorization code may correspond to one or more tokens, which include a first token. In some examples, the first device may determine the one or more tokens based on the authorization code, and trigger the revocation of each of the one or more tokens. The following takes the first token as an example to illustrate how the first device determines the one or more tokens. For example, the first device saves a correspondence #3 between the authorization code and the first token. After receiving the authorization code, the first device may determine the first token based on the authorization code and the correspondence #3. In other examples, the first request in S302 includes: an authorization code and indication information of the first service. The first device determines one or more tokens based on the authorization code; the first device selects the token corresponding to the indication information of the first service from the one or more tokens as the first token, and triggers the revocation of the first token.

[0204] Through method a3, the terminal can initiate the revocation process of the first token based on the authorization code. In this way, the user can control the terminal to initiate the revocation process of the first token through the user agent on the terminal, ensuring that the revocation process is authorized by the user, thereby preventing the user's desired service from being interrupted due to the revocation of authorization, that is, preventing the user from being denied service.

[0205] This embodiment of the present application provides another communication method, which is a possible example of the method shown in Figure 3. In this method, the first information is a random number, and the user agent can initiate the revocation process of the first token based on the random number. Referring to the flowcharts shown in Figures 4 and 5 below, the process of this method is specifically described, taking the first device as AzF and the second device as the API caller as an example.

[0206] FIG4 shows a method for applying for a first token, the method comprising:

[0207] S401: The API caller sends an authorization request to the user agent in the terminal.

[0208] The authorization request may be used to request authorization of the first service for the first user. Optionally, the authorization request may include at least one of the following: indication information of the API caller (e.g., the API caller's ID) or the scope of the requested authorization. The scope of the requested authorization may include indication information of the first service.

[0209] S402: The user agent sends the authorization request to the AzF.

[0210] S403: AzF sends message #a1 to the user agent.

[0211] The message #a1 is used to request confirmation of whether the first user agrees to authorize the first service for the first user. Optionally, the message #a1 may include a scope of the requested authorization.

[0212] S404: The user agent detects a first operation of the first user, where the first operation may be used to indicate that the first user agrees to authorize the first service for the first user.

[0213] The specific content of the first operation of the first user detected by the user agent can be referred to step A1, which will not be repeated here.

[0214] S405: The user agent generates a random number and second information.

[0215] The specific content of S405 may refer to step B1 and will not be repeated here.

[0216] S406: The user agent sends message #a2 to AzF.

[0217] The message #a2 is used to indicate that the first user agrees to authorize the first service to the first user. The message #a2 also includes second information.

[0218] S407: AzF associates the second information with the authorization code corresponding to the first token. Optionally, AzF may save the correspondence between the second information and the authorization code.

[0219] S408: AzF sends the authorization code corresponding to the first token to the user agent.

[0220] This application does not limit the execution order of S407 and S408.

[0221] S409: The user agent sends the authorization code to the API caller.

[0222] S410: The API caller sends a request #a1 to AzF.

[0223] The request #a1 includes an authorization code, which can be used to request the acquisition of the first token.

[0224] S411: AzF sends a first token to the API caller.

[0225] For the specific contents of S401 to S404, S406, and S408 to S411, please refer to the description of the token application process in the IETF standard.

[0226] S407 is an optional step. For example, after S410, the method shown in Figure 4 also includes S412: AzF associates the second information with the first token. Optionally, AzF may save the correspondence between the second information and the first token. This application does not limit the execution order of S411 and S412. When the method shown in Figure 4 includes S412, the method shown in Figure 4 may not include S407.

[0227] Through the method shown in FIG. 4 , the user agent may generate a random number and second information, and the AzF may associate the second information with the first token or the authorization code corresponding to the first token.

[0228] FIG5 shows a method for revoking a first token, the method comprising:

[0229] S501: The user agent saves the random number.

[0230] The random number may be generated by the user agent in S405.

[0231] Optionally, the user agent in the terminal may further store the instruction information of the first user. The specific content of the instruction information of the first user may refer to the description of the instruction information of the first user in S302, which will not be repeated here.

[0232] S502: After detecting an operation of the first user for running the user agent, the terminal starts the user agent.

[0233] S502 is an optional step. For example, when the user agent is already in the startup state, the method shown in FIG5 may not include S502.

[0234] S503: The user agent sends a revocation request #a1 including a random number to the AzF.

[0235] The cancellation request #a1 may be the first request in S302. Accordingly, S503 may refer to S302, and the repeated parts will not be repeated here.

[0236] S504: AzF determines a first token according to the random number.

[0237] The specific content of S504 can be referred to method b2 and will not be repeated here.

[0238] S505: AzF sends a revocation request #a2 to AEF, where the revocation request #a2 is used to request the release of resources corresponding to the first token.

[0239] In some examples, revocation request #a2 may include information in the first token. For example, revocation request #a2 may include at least one of the following information in the first token: service indication information, scope declaration information, and so on. Thus, after receiving revocation request #a2, the AEF may determine that revocation request #a2 is used to request the release of the resources corresponding to the first token.

[0240] In other examples, the revocation request #a2 may include: the first token and / or indication information of the first token (e.g., the ID of the first token). In this way, after receiving the revocation request #a2, the AEF may determine that the revocation request #a2 is used to request the release of the resources corresponding to the first token.

[0241] S506: The AEF triggers the release of resources corresponding to the first token.

[0242] This application does not limit the specific process of AEF triggering the release of resources corresponding to the first token.

[0243] S507: AEF sends a revocation response #a2 to AzF.

[0244] The revocation response #a2 is a response message to the revocation request #a2, and is used to indicate one of the following: the resource corresponding to the first token has been successfully released or has been triggered to be released, or the revocation request #a2 has been received.

[0245] S508: AzF sends a revocation notification to the API caller, where the revocation notification may be used to indicate one of the following: successful revocation of the first token, triggering of the process for revoking the first token, or receipt of the revocation request #a2.

[0246] The revocation notification may be the notification message in step B5. Accordingly, the specific content of S508 may refer to step B5 and will not be described in detail here.

[0247] Optionally, after receiving the revocation notification, the API caller may update the token database, for example, marking the first token as revoked in the token database.

[0248] S509: AzF sends a revocation response #a1 to the user agent.

[0249] The revocation response #a1 is a response message to the revocation request #a1, indicating one of the following: successful revocation of the first token, triggering of the revocation process for the first token, or receipt of the revocation request #a1. The revocation response #a1 may be the first response in step B4. The details of step S509 are described in step B4 and are not further detailed here.

[0250] This application does not limit the execution order of S508 and S509.

[0251] S509 is an optional step.

[0252] Through the method shown in Figures 4 and 5, the user agent can initiate the revocation process of the first token based on the random number, so that the revocation process is authorized by the user, and the AzF associates the second information with the first token or the authorization code corresponding to the first token, so that the first token can be accurately identified and the first token that the user wants to revoke can be revoked, thereby avoiding the interruption of the service that the user expects to obtain due to the revocation of authorization, that is, avoiding the user from being denied service. Moreover, in this method, the random number used to initiate the revocation process of the first token is generated by the terminal and can be protected by a one-way function. In this way, third-party applications on the terminal or AF cannot obtain information related to the random number, and thus cannot initiate the revocation process for the first token, thereby improving the security of the token revocation process.

[0253] An embodiment of the present application provides another communication method, which is another possible example of the method shown in Figure 3. In this method, the first information is auxiliary information, and the user agent can initiate the revocation process of the first token based on the auxiliary information. Referring to the flowcharts shown in Figures 6 and 7 below, the process of this method is specifically described, taking the first device as an AzF or API caller as an example.

[0254] FIG6 shows a method for applying for a first token, the method comprising:

[0255] S601: The API caller sends an authorization request to the user agent in the terminal.

[0256] S602: The user agent sends the authorization request to the AzF.

[0257] S603: AzF sends message #a1 to the user agent.

[0258] S604: The user agent detects a first operation of the first user, where the first operation may be used to indicate that the first user agrees to authorize the first service for the first user.

[0259] The specific contents of S601 to S604 can be referred to S401 to S404 and will not be repeated here.

[0260] S605: The user agent saves the auxiliary information used to identify the first token.

[0261] The specific content of the auxiliary information can be found in the description of the auxiliary information in method a2, and will not be repeated here.

[0262] This application does not limit the execution order of S605 and S604. For example, S605 can be executed before S604 (after receiving S603). It should be noted that the advantage of storing the auxiliary information after S605 is that the token corresponding to the auxiliary information has been authorized by the user. The auxiliary information stored before S604, and its corresponding token application has not yet been authorized by the user. Optionally, if after storing the auxiliary information, the user agent detects that the user does not agree to authorize the first service for the first user, the user agent may delete the stored auxiliary information.

[0263] S606: The user agent sends message #a2 to AzF.

[0264] The message #a2 is used to indicate that the first user agrees to authorize the first service for the first user.

[0265] S607: AzF sends the authorization code corresponding to the first token to the user agent.

[0266] S608: The user agent confirms the auxiliary information according to the authorization code.

[0267] Specifically, after receiving the authorization code corresponding to the first token, the user agent can confirm that the token request corresponding to the auxiliary information has successfully obtained the authorization code, and the auxiliary information saved in S605 can continue to be retained. Optionally, if the user agent does not receive the authorization code within a set time, the user agent can delete the auxiliary information saved in S605. The set time can be pre-set, determined by the user agent, or set by the network for the user agent, and this application does not limit this.

[0268] S608 is an optional step.

[0269] S609: The user agent sends the authorization code to the API caller.

[0270] This application does not limit the execution order of S608 and S609.

[0271] S610: The API caller sends a request #a1 to AzF.

[0272] The request #a1 includes an authorization code, which can be used to request the acquisition of the first token.

[0273] S611: AzF sends a first token to the API caller.

[0274] For the specific contents of S601 to S604, S606 to S607, and S609 to S611, please refer to the description of the token application process in the IETF standard.

[0275] Through the method shown in FIG6 , the user agent can save auxiliary information used to identify the first token.

[0276] FIG7 shows a method for revoking a first token, the method comprising:

[0277] S701: After detecting an operation of a first user for running a user agent, the terminal starts the user agent.

[0278] The specific content of S701 can be found in S502 and will not be repeated here.

[0279] S702: A secure channel is established between the user agent and the API caller.

[0280] For example, if the user agent is a web browser, a transport layer security (TLS) channel may be established between the user agent and the API caller. The TLS channel may be a Hypertext Transfer Protocol Secure (HTTPS) channel.

[0281] S702 is an optional step. For example, when the communication between the user agent and the API caller is secure or has been protected by other means, the method shown in FIG7 may not include S702.

[0282] S703: The user agent sends a cancellation request #b1 containing auxiliary information to the API caller.

[0283] The cancellation request #b1 may be the first request in S302. Accordingly, S703 may refer to S302 and will not be described in detail here.

[0284] In implementation a1, the first device may be an API caller. After S703, the method shown in FIG7 includes S704 to S705.

[0285] S704: The API caller determines the first token according to the auxiliary information.

[0286] The specific content of S704 can be referred to method a2 and will not be repeated here.

[0287] S705: The API caller sends a cancellation request #b2 to AzF.

[0288] The revocation request #b2 may include the first token and / or indication information of the first token, requesting the revocation of the first token. After receiving the revocation request #b2, the AzF may revoke the first token. This application does not limit the specific process by which the AzF revokes the first token.

[0289] In embodiment a2, the first device may be AzF. After S703, the method shown in FIG7 includes S706 to S707.

[0290] S706: The API caller sends a cancellation request #b1 containing auxiliary information to the AzF.

[0291] S707: AzF determines the first token according to the auxiliary information.

[0292] The specific content of S707 can be referred to method a2 and will not be repeated here.

[0293] After determining the first token, the AzF may revoke the first token. This application does not limit the specific process of the AzF revoking the first token.

[0294] After S705 or S707 , the method shown in FIG7 further includes S708 .

[0295] S708: AzF sends a revocation response #b1 to the API caller, which can be used to indicate one of the following: the first token is successfully revoked, the process of revoking the first token has been triggered, or a revocation request for requesting the revocation of the first token has been received (for example, revocation request #b2 in S705 or revocation request #b1 in S706).

[0296] Optionally, after receiving the revocation response #b1, the API caller may update the token database, for example, marking the first token as revoked in the token database.

[0297] In some possible approaches, the API caller may also forward the revocation response #b1 to the user agent.

[0298] Through the method shown in Figures 6 and 7, the user agent can initiate a revocation process for the first token based on the auxiliary information, so that the revocation process is authorized by the user, thereby avoiding the interruption of the service the user expects to obtain due to the revocation of authorization, that is, avoiding the user from being denied service.

[0299] The present application provides another communication method, which is another possible example of the method shown in Figure 3. In this method, the first information is an authorization code, and the user agent can initiate the revocation process of the first token based on the authorization code. Referring to the flowcharts shown in Figures 8 and 9 below, the process of this method is specifically described, taking the first device as an AzF or API caller as an example.

[0300] FIG8 shows a method for applying for a first token, the method comprising:

[0301] S801: The API caller sends an authorization request to the user agent in the terminal.

[0302] S802: The user agent sends the authorization request to the AzF.

[0303] S803: AzF sends message #a1 to the user agent.

[0304] S804: The user agent detects a first operation of the first user, where the first operation may be used to indicate that the first user agrees to authorize the first service for the first user.

[0305] S805: The user agent sends message #a2 to AzF.

[0306] S806: AzF sends the authorization code corresponding to the first token to the user agent.

[0307] The specific contents of S801 to S806 can be referred to S401 to S404 and S606 to S607, and will not be repeated here.

[0308] S807: The user agent saves the authorization code.

[0309] S808: The user agent sends the authorization code to the API caller.

[0310] This application does not limit the execution order of S807 and S808.

[0311] S809: The API caller sends a request #a1 to AzF.

[0312] S810: AzF sends a first token to the API caller.

[0313] The specific contents of S808 to S810 can be referred to S609 to S611 and will not be repeated here.

[0314] For the specific contents of S801 to S806 and S808 to S810, please refer to the description of the token application process in the IETF standard.

[0315] Through the method shown in FIG8 , the user agent can save the authorization code corresponding to the first token.

[0316] FIG9 shows a method for revoking a first token, the method comprising:

[0317] S901: After detecting an operation of a first user for running a user agent, the terminal starts the user agent.

[0318] The specific content of S901 can be referred to S502 and will not be repeated here.

[0319] Optionally, the user agent may further store the instruction information of the first user. The specific content of the instruction information of the first user may refer to the description of the instruction information of the first user in S302, which will not be repeated here.

[0320] S902: A secure channel is established between the user agent and the API caller.

[0321] The specific content of S902 can be referred to S702 and will not be repeated here.

[0322] S903: The user agent sends a revocation request #c1 including the authorization code to the API caller.

[0323] The cancellation request #c1 may be the first request in S302. Accordingly, S903 may refer to S302 and will not be described in detail here.

[0324] In implementation b1, the first device may be an API caller. After S903, the method shown in FIG9 includes S904 to S905.

[0325] S904: The API caller determines the first token according to the verification code.

[0326] The specific content of S904 can be referred to method a3 and will not be repeated here.

[0327] S905: The API caller sends a cancellation request #c2 to AzF.

[0328] The specific content of S905 can be found in S705 and will not be repeated here.

[0329] In embodiment b2, the first device may be AzF. After S903, the method shown in FIG9 includes S906 to S907.

[0330] S906: The API caller sends a revocation request #c1 including the authorization code to AzF.

[0331] S907: AzF determines the first token according to the authorization code.

[0332] The specific content of S907 can be referred to method a3 and will not be repeated here.

[0333] After determining the first token, the AzF may revoke the first token. This application does not limit the specific process of the AzF revoking the first token.

[0334] After S905 or S907 , the method shown in FIG9 further includes S908 .

[0335] S908: AzF sends a revocation response #c1 to the API caller, which can be used to indicate one of the following: the first token is successfully revoked, the process of revoking the first token has been triggered, or a revocation request for requesting the revocation of the first token has been received (for example, revocation request #c2 in S905 or revocation request #c1 in S906).

[0336] The specific content of S908 can refer to S708, except that the revocation response #b1 is replaced by the revocation response #c1, which will not be repeated here.

[0337] Through the method shown in Figures 8 and 9, the user agent can initiate a revocation process for the first token based on the authorization code, so that the revocation process is authorized by the user, thereby avoiding the interruption of the service the user expects to obtain due to the revocation of authorization, that is, avoiding the user from being denied service.

[0338] An embodiment of the present application provides another communication method. Figure 10 is a flow chart corresponding to the communication method provided in an embodiment of the present application. Figure 10 illustrates the method by taking the terminal and the third device as the execution subjects of the interaction diagram as an example, but the present application does not limit the execution subjects of the interaction diagram. Among them, the third device can be AzF, or it can be a module applied to AzF, such as a chip, a chip system or a processor, or it can be a logical node, a logical module or software that can realize all or part of the AzF functions. Optionally, the terminal in Figure 10 can be replaced by a user agent.

[0339] S1001: The terminal sends a third request; accordingly, the third device receives the third request.

[0340] The third request includes the instruction information of the first service, which can be used to request the revocation of the authorization of the first service. The specific content of the instruction information of the first service can be referred to the "instruction information of the service" in the above terminology description part, which will not be repeated here.

[0341] The way in which the terminal sends the third request can refer to the way in which the terminal sends the first request in S302, except that the first device is replaced by the third device and the first request is replaced by the third request, which will not be repeated here.

[0342] S1002: The third device sends third information; accordingly, the terminal receives the third information.

[0343] The third information may be used to indicate that the authorization to be revoked is the first authorization that allows the first user to use the first service. Exemplarily, the third information may include indication information of the first service, where the indication information of the first service is contained in a predetermined field or message. Thus, when the terminal parses the indication information of the first service in the predetermined field or message, the terminal may determine that the authorization to be revoked is the first authorization that allows the first user to use the first service.

[0344] The way in which the third device sends the third information can refer to the way in which the first device sends the first response in step A4, except that the first device is replaced by the third device and the first response is replaced by the third information, which will not be repeated here.

[0345] S1003: The terminal detects a second operation of the first user, where the second operation may be used to indicate that the first user agrees to revoke the first authorization.

[0346] After receiving the third message, the terminal may inquire whether the first user agrees to revoke the first authorization. For example, after receiving the third message, the terminal displays pop-up window #2, which includes a display area for "Do you agree to revoke the first user's authorization for the first service?" and an operation area for "Yes" and "No." The second operation may include the first user touching the screen in the operation area to select "Yes."

[0347] S1004: The terminal sends fourth information; accordingly, the third device receives the fourth information.

[0348] The fourth information may be sent by the terminal in response to the second operation, and may be used to trigger the revocation of the first authorization.

[0349] The way in which the terminal sends the fourth information can refer to the way in which the terminal sends the first request in S302, except that the first device is replaced by the third device and the first request is replaced by the fourth information, which will not be repeated here.

[0350] S1005: The third device sends the fifth information; accordingly, the API caller receives the fifth information.

[0351] The fifth information is information for revoking the first authorization. Optionally, the fifth information is the second token.

[0352] In some examples, the second token is a revocation token. Field #1 in the second token may be related to the first authorization. For example, the first token is a token that authorizes the first user to access the first service, and Field #1 of the second token contains information indicating the first token. Thus, after receiving the second token, the API caller can determine whether to revoke the first authorization based on the information indicated in Field #1 of the first token.

[0353] In other examples, the value of the first field in the second token is a set value. This set value can be, for example, a null value or other value. For example, the type of the second token is an access token. Field #1 in the second token is associated with the first authorization, and the value of the first field in the second token is the set value. Thus, after receiving the second token, the API caller can determine whether to revoke the first authorization based on Field #1 and the first field.

[0354] S1001 and S1005 are optional steps.

[0355] Through the method shown in Figure 10, after detecting the second operation of the first user, the terminal sends the fourth information for triggering the revocation of the first authorization, that is, triggering the token process of the token, thereby avoiding the interruption of the service expected by the user due to the revocation of authorization, that is, avoiding the user from being denied service.

[0356] The embodiment of the present application provides another communication method, which is a possible example of the method shown in Figure 10. Referring to the flowchart shown in Figure 11, the process of the method is specifically described by taking the first device as AzF as an example.

[0357] S1101: After detecting an operation of a first user for running a user agent, the terminal starts the user agent.

[0358] The specific content of S1101 can be referred to S502 and will not be repeated here.

[0359] S1102: The user agent sends a cancellation request #d1 to the API caller.

[0360] The revocation request #d1 includes indication information of the first service, and is used to request revocation of the first authorization for the first service.

[0361] S1103: The API caller sends a cancellation request #d2 to the user agent.

[0362] The revocation request #d2 includes indication information of the first service, and is used to request revocation of the first authorization for the first service.

[0363] S1104: The user agent sends a revocation request #d2 to the AzF.

[0364] The cancellation request #d2 may be the third request in S1001. Accordingly, the specific content of S1104 may refer to S1001 and will not be described in detail here.

[0365] S1105: AzF sends third information to the user agent.

[0366] The specific content of S1105 can be found in S1002 and will not be repeated here.

[0367] S1106: The user agent detects a second operation of the first user, where the second operation may be used to indicate that the first user agrees to revoke the first user's authorization for the first service.

[0368] S1107: The user agent sends the fourth information to the AzF.

[0369] The specific content of S1107 can be found in S1004 and will not be repeated here.

[0370] S1108: AzF sends the authorization code corresponding to the second token to the user agent.

[0371] Among them, the specific content of the second token can refer to the description of the second token in S1005, which will not be repeated here.

[0372] S1109: The user agent sends the authorization code corresponding to the second token to the API caller.

[0373] S1110: The API caller sends a request #d1 to the AzF, wherein the request #d1 includes an authorization code corresponding to the second token, which can be used to request the acquisition of the second token.

[0374] S1008 to S1110 are optional steps.

[0375] S1111: AzF sends the second token to the API caller.

[0376] S1112: The API caller sends a second token to the AEF.

[0377] S1113: The AEF revokes the first authorization according to the second token, and releases the resources corresponding to the first authorization.

[0378] Through the method shown in Figure 11, the user agent can initiate an authorization revocation process based on the second token, so that the revocation process is authorized by the user, thereby avoiding the interruption of the service the user expects due to the revocation of authorization, that is, avoiding the user being denied service.

[0379] Based on the same technical concept as the above-mentioned method embodiment, the embodiment of the present application provides a communication device through Figure 12, which can be used to perform the functions of the relevant steps in the above-mentioned method embodiment. The functions can be implemented by hardware, or by software or hardware executing the corresponding software implementation. The hardware or software includes one or more modules corresponding to the above-mentioned functions. The structure of the communication device is shown in Figure 12, including an interface unit 1201 and a processing unit 1202. The communication device 1200 can be a terminal, an API caller, a device including an API caller (for example, a terminal or AF) or an AzF, or it can be a module applied to a terminal, an API caller, a device including an API caller or an AzF, such as a chip, a chip system or a processor, or it can be a logical node, a logical module or software that can implement all or part of the terminal, API caller, a device including an API caller or an AzF function. In addition, the communication device 1200 can implement the communication method provided in the above-mentioned embodiments and examples of the present application. The functions of each unit in the communication device 1200 are introduced below.

[0380] The interface unit 1201 is used to input and / or output information. When outputting information, the interface unit 1201 can output information to other devices outside the communication device 1200, or can output information to other units in the communication device 1200. In some embodiments, the interface unit 1201 can be implemented by at least one of a physical interface, a communication module, a communication interface, and an input / output interface. In other embodiments, the interface unit 1201 can be implemented by an interface circuit, for example, a mobile communication module. The mobile communication module may include one or more of at least one antenna, at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc.

[0381] The processing unit 1202 can be used to support the communication device 1200 in performing the processing actions in the above method embodiment. The processing unit 1202 can be implemented by a processor. For example, the processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor can be a microprocessor or any conventional processor.

[0382] In one embodiment, the communication device 1200 is applied to the terminal in the embodiment of the present application shown in Figure 3. The specific functions of the processing unit 1202 in this embodiment are introduced below.

[0383] The processing unit 1202 is used to: determine first information, the first information is used to determine a first token, the first token is a token that authorizes a first service for a first user; send a first request through the interface unit 1201, the first request includes first information, and the first request is used to request the revocation of the first token.

[0384] In some possible embodiments, the processing unit 1202 is also used to: receive a first response through the interface unit 1201, the first response being used to indicate one of the following: successful revocation of the first token, triggering the process of revoking the first token, or receiving the first request, the first response including a random number or second information, the second information being obtained based on a one-way function and a random number.

[0385] In other possible methods, the processing unit 1202 is also used to: generate a random number and second information, the second information is obtained based on a one-way function and a random number; send the second information to the authorization function network element through the interface unit 1201, and the second information corresponds to the first token.

[0386] Optionally, the processing unit 1202 is further configured to: before generating the random number and the second information, detect a first operation of the first user, where the first operation is used to indicate that the first user agrees to authorize the first service to the first user.

[0387] In some examples, the processing unit 1202 is further used to: detect a first operation of the first user, where the first operation is used to indicate that the first user agrees to authorize the first service to the first user; and obtain and store auxiliary information.

[0388] In some possible embodiments, the processing unit 1202 is further configured to: receive an authorization code corresponding to the first token through the interface unit 1201, where the authorization code is used to determine that the first token corresponding to the auxiliary information is a token authorized by the authorization function network element.

[0389] In some other possible embodiments, the processing unit 1202 is further configured to: receive, through the interface unit 1201 , an authorization code corresponding to the first token from an authorization function network element.

[0390] Optionally, the processing unit 1202 is further used to: send a first request to the authorization function network element through the interface unit 1201 according to the address information of the authorization function network element; or send a first request to the authorization function network element through the application software programming interface caller.

[0391] In another embodiment, the communication device 1200 is applied to the first device in the embodiment of the present application shown in Figure 3. The specific functions of the processing unit 1202 in this embodiment are introduced below.

[0392] The processing unit 1202 is used to: receive a first request from the terminal through the interface unit 1201, the first request is used to request the revocation of the first token, the first request includes first information, the first information is used to determine the first token, the first token is a token that authorizes the first service for the first user; determine the first token according to the first request.

[0393] In some possible embodiments, the processing unit 1202 is also used to: send a first response to the terminal through the interface unit 1201, the first response is used to indicate one of the following: successful revocation of the first token, the process of revoking the first token has been triggered, or the first request has been received, the first response includes a random number or second information, and the second information is obtained based on a one-way function and a random number.

[0394] Optionally, the processing unit 1202 is further configured to: receive second information from the terminal through the interface unit 1201, where the second information is obtained based on a one-way function and a random number; and match the second information with the first token.

[0395] In some possible embodiments, the processing unit 1202 is also used to: send a notification message to the application software programming interface caller through the interface unit 1201, the notification message is used to indicate one of the following: successful revocation of the first token, the process of revoking the first token has been triggered, or the first request has been received, and the notification message includes indication information of the first token.

[0396] Optionally, the processing unit 1202 is further configured to: send an authorization code corresponding to the first token to the terminal through the interface unit 1201 .

[0397] Exemplarily, the processing unit 1202 is further used to: revoke the first token; or send a second request to the authorization function network element through the interface unit 1201, where the second request is used to request the revocation of the first token.

[0398] In some possible embodiments, the processing unit 1202 is further used to: receive, through the interface unit 1201, a first request sent by the terminal according to the address information of the authorized function network element; or, receive, through an application software programming interface caller, a first request from the terminal.

[0399] In yet another embodiment, the communication device 1200 is applied to the terminal in the embodiment of the present application shown in Figure 10. The specific functions of the processing unit 1202 in this embodiment are introduced below.

[0400] The processing unit 1202 is used to: receive third information through the interface unit 1201, the third information is used to indicate that the authorization to be revoked is the first authorization allowing the first user to use the first service; detect a second operation of the first user, the second operation is used to indicate that the first user agrees to revoke the first authorization; send fourth information through the interface unit 1201, the fourth information is used to trigger the revocation of the first authorization.

[0401] In some possible embodiments, the processing unit 1202 is further configured to: before receiving the third information, send a third request through the interface unit 1201, where the third request includes indication information of the first service.

[0402] In yet another embodiment, the communication device 1200 is applied to the third device in the embodiment of the present application shown in Figure 10. The specific functions of the processing unit 1202 in this embodiment are introduced below.

[0403] The processing unit 1202 is used to: send third information to the terminal through the interface unit 1201, the third information is used to indicate that the authorization to be revoked is the first authorization allowing the first user to use the first service; receive fourth information sent by the terminal based on the second operation of the first user through the interface unit 1201, the second operation is used to indicate that the first user agrees to revoke the first authorization, and the fourth information is used to trigger the revocation of the first authorization.

[0404] In some possible embodiments, the processing unit 1202 is further configured to: receive a third request from the terminal through the interface unit 1201 , where the third request includes indication information of the first service.

[0405] In some examples, the processing unit 1202 is further used to: send fifth information to the application software programming interface caller through the interface unit 1201, where the fifth information is used to revoke the first authorization.

[0406] A more detailed description of the processing unit 1202 and the interface unit 1201 can be directly obtained by referring to the relevant descriptions in the method embodiments shown in Figures 3 and 5, and will not be repeated here.

[0407] It should be noted that the module division in the above embodiments of the present application is illustrative and represents only one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional units in the various embodiments of the present application may be integrated into a single processing unit, may exist physically as separate units, or may be integrated into a single unit. The aforementioned integrated units may be implemented in either hardware or software functional units.

[0408] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0409] Based on the same technical concept, the embodiment of the present application provides a communication device as shown in Figure 13, which can be used to perform the relevant steps in the above method embodiment. The communication device can be a terminal, an API caller, a device including an API caller (for example, a terminal or AF) or an AzF, or it can be a module applied to a terminal, an API caller, a device including an API caller or an AzF, such as a chip, a chip system or a processor, or it can be a logical node, a logical module or software that can implement all or part of the functions of the terminal, the API caller, the device including the API caller or the AzF. In addition, the communication device can implement the communication method provided in the above embodiments and examples of the present application, and has the function of the communication device shown in Figure 12. Referring to Figure 13, the communication device 1300 includes: a processor 1302. Optionally, the communication device 1300 also includes: an interface circuit 1301 and a memory 1303. Among them, the interface circuit 1301, the processor 1302 and the memory 1303 are coupled to each other.

[0410] Optionally, the interface circuit 1301, the processor 1302, and the memory 1303 are coupled to each other via a bus 1304. The bus 1304 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be classified as an address bus, a data bus, a control bus, etc. For ease of illustration, FIG13 shows only one thick line, but this does not mean that there is only one bus or only one type of bus.

[0411] Interface circuit 1301 is configured to input and / or output information. When outputting information, interface circuit 1301 may output information to other devices outside of communication device 1300 or to other units within communication device 1300. Exemplarily, interface circuit 1301 may be implemented via at least one of a physical interface, a communication module, a communication interface, an input / output interface, and a mobile communication module. The mobile communication module may include one or more of at least one antenna, at least one filter, a switch, a power amplifier, and an LNA.

[0412] The processor 1302 may be configured to support the communication device 1300 in executing the processing actions in the above-described method embodiment. When the communication device 1300 is configured to implement the above-described method embodiment, the processor 1302 may also be configured to implement the functions of the processing unit 1202. The processor 1302 may be a CPU, other general-purpose processor, DSP, ASIC, FPGA, other programmable logic device, transistor logic device, hardware component, or any combination thereof. A general-purpose processor may be a microprocessor or any conventional processor.

[0413] In one embodiment, the communication device 1300 is applied to the terminal in the embodiment of the present application shown in Figure 3. The specific functions of the processor 1302 in this embodiment are introduced below.

[0414] The processor 1302 is used to: determine first information, the first information is used to determine a first token, the first token is a token that authorizes a first service for a first user; send a first request through the interface circuit 1301, the first request includes first information, and the first request is used to request the revocation of the first token.

[0415] In another embodiment, the communication device 1300 is applied to the first device in the embodiment of the present application shown in Figure 3. The specific functions of the processor 1302 in this embodiment are introduced below.

[0416] The processor 1302 is used to: receive a first request from the terminal through the interface circuit 1301, the first request is used to request the revocation of the first token, the first request includes first information, the first information is used to determine the first token, the first token is a token that authorizes the first service for the first user; determine the first token according to the first request.

[0417] In yet another embodiment, the communication device 1300 is applied to the terminal in the embodiment of the present application shown in Figure 10. The specific functions of the processor 1302 in this embodiment are described below.

[0418] The processor 1302 is used to: receive third information through the interface circuit 1301, where the third information is used to indicate that the authorization to be revoked is the first authorization allowing the first user to use the first service; detect a second operation of the first user, where the second operation is used to indicate that the first user agrees to revoke the first authorization; and send fourth information through the interface circuit 1301, where the fourth information is used to trigger the revocation of the first authorization.

[0419] In yet another embodiment, the communication device 1300 is applied to the third device in the embodiment of the present application shown in Figure 10. The specific functions of the processor 1302 in this embodiment are described below.

[0420] The processor 1302 is used to: send third information to the terminal through the interface circuit 1301, where the third information is used to indicate that the authorization to be revoked is the first authorization allowing the first user to use the first service; receive fourth information sent by the terminal based on the second operation of the first user through the interface circuit 1301, where the second operation is used to indicate that the first user agrees to revoke the first authorization, and the fourth information is used to trigger the revocation of the first authorization.

[0421] The specific functions of the processor 1302 can refer to the description of the communication method provided in the above embodiments and examples of the present application, as well as the specific functional description of the communication device 1200 in the embodiment of the present application shown in Figure 12, which will not be repeated here.

[0422] The memory 1303 is used to store program instructions and / or data, etc. Specifically, the program instructions may include program code, which includes computer operation instructions. The memory 1303 may include RAM, and may also include non-volatile memory (non-volatile memory), such as at least one disk storage. The processor 1302 executes the program instructions stored in the memory 1303, and uses the data stored in the memory 1303 to implement the above functions, thereby realizing the communication method provided in the above embodiment of the present application. The memory 1303 can be integrated with the processor 1302, or it can be a memory outside the communication device.

[0423] It is understood that the memory 1303 in FIG. 13 of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be ROM, programmable read-only memory (Programmable ROM, PROM), erasable programmable read-only memory (Erasable PROM, EPROM), electrically erasable programmable read-only memory (Electrically EPROM, EEPROM) or flash memory. The volatile memory may be RAM, which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct RAM bus random access memory (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0424] Based on the above embodiments, an embodiment of the present application further provides a computer program product including computer-executable instructions. When the computer program product is run, the method provided in the above embodiments is executed.

[0425] Based on the above embodiments, an embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a computer, the computer executes the method provided in the above embodiments.

[0426] The storage medium may be any available medium that can be accessed by a computer. By way of example and not limitation, computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer.

[0427] Based on the above embodiments, an embodiment of the present application further provides a chip, which is used to read a computer program stored in a memory to implement the method provided in the above embodiments.

[0428] Based on the above embodiments, embodiments of the present application provide a chip system, which includes a processor for supporting a computer device to implement the functions involved in each device in the above embodiments. In one possible design, the chip system also includes a memory for storing the necessary programs and data for the computer device. The chip system can be composed of a chip or can include a chip and other discrete devices.

[0429] In the various embodiments of the present application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0430] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0431] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each flow and / or box in the flow chart and / or block diagram, as well as the combination of the flow chart and / or box in the flow chart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more flow charts and / or one or more boxes in the block diagram.

[0432] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0433] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0434] In the various embodiments of the present application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0435] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. In the text description of this application, the character " / " generally indicates that the related objects are in an "or" relationship.

[0436] It is understood that the various numbers used in the embodiments of this application are merely for ease of description and are not intended to limit the scope of the embodiments of this application. The order of the sequence numbers of the above-mentioned processes does not necessarily imply a specific order of execution; the order of execution of the processes should be determined by their functions and inherent logic.

[0437] Obviously, those skilled in the art may make various changes and modifications to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include these modifications and variations.

Claims

1. A communication method, characterized in that: include: The terminal determines first information, where the first information is used to determine a first token, where the first token is a token for authorizing a first user to provide a first service; The terminal sends a first request, where the first request includes the first information, and the first request is used to request revocation of the first token.

2. The method according to claim 1, characterized in that The first information includes a random number, and the random number is used to determine the first token.

3. The method according to claim 2, characterized in that The random number is used to determine second information through a one-way function, and the second information is used to determine the first token.

4. The method according to claim 2 or 3, characterized in that Also includes: The terminal receives a first response, where the first response is used to indicate one of the following: successful revocation of the first token, triggering of the process for revoking the first token, or receipt of the first request, and the first response includes the random number or second information, where the second information is obtained based on a one-way function and the random number.

5. The method according to any one of claims 2 to 4, characterized in that: Also includes: The terminal generates the random number and second information, where the second information is obtained according to a one-way function and the random number; The terminal sends the second information to the authorization function network element, where the second information corresponds to the first token.

6. The method according to claim 5, characterized in that Before the terminal generates the random number and the second information, the method further includes: The terminal detects a first operation of the first user, where the first operation is used to indicate that the first user agrees to authorize the first service to the first user.

7. The method according to claim 1, characterized in that The first information includes auxiliary information for identifying the first token.

8. The method according to claim 7, characterized in that The auxiliary information includes at least one of the following: information for identifying the authorization scope of the first token; Information for identifying a service application software programming interface corresponding to the first token; Information used to identify the authorization function network element corresponding to the first token; information for identifying the first user; Information for identifying an open function of an application software programming interface corresponding to the first token; information for identifying the validity period of the first token; Information for identifying the issuance time of the first token.

9. The method according to claim 7 or 8, characterized in that Also includes: The terminal detects a first operation of the first user, where the first operation is used to indicate that the first user agrees to authorize the first service to the first user; The terminal acquires and stores the auxiliary information.

10. The method according to claim 9, characterized in that Also includes: The terminal receives an authorization code corresponding to the first token, where the authorization code is used to determine that the first token corresponding to the auxiliary information is a token authorized by an authorization function network element.

11. The method according to claim 1, characterized in that The first information includes an authorization code corresponding to the first token.

12. The method according to claim 11, characterized in that Also includes: The terminal receives an authorization code corresponding to the first token from an authorization function network element.

13. The method according to claim 11 or 12, characterized in that: The first request also includes: indication information of the first user, and the indication information of the first user and the first information are used to determine the first token.

14. The method according to any one of claims 1 to 13, characterized in that The terminal sends a first request, including at least one of the following: The terminal sends the first request to the authorization function network element according to the address information of the authorization function network element; or The terminal sends the first request to the authorization function network element through an application software programming interface caller.

15. A communication method, characterized in that: include: receiving a first request from a terminal, the first request being used to request the revocation of a first token, the first request comprising first information, The first information is used to determine the first token, where the first token is a token for authorizing the first user to provide the first service; According to the first request, the first token is determined.

16. The method according to claim 15, characterized in that The first information includes a random number, and the random number is used to determine the first token.

17. The method according to claim 16, characterized in that The random number is used to determine second information through a one-way function, and the second information is used to determine the first token.

18. The method according to claim 16 or 17, characterized in that Also includes: A first response is sent to the terminal, where the first response is used to indicate one of the following: successful revocation of the first token, triggering of the process for revoking the first token, or receipt of the first request, and the first response includes the random number or second information, where the second information is obtained based on a one-way function and the random number.

19. The method according to any one of claims 16 to 18, characterized in that Also includes: receiving second information from the terminal, where the second information is obtained according to a one-way function and the random number; The second information is matched with the first token.

20. The method according to any one of claims 16 to 19, characterized in that Also includes: A notification message is sent to the caller of the application software programming interface, where the notification message is used to indicate one of the following: successful revocation of the first token, triggering of the process of revoking the first token, or receipt of the first request, and the notification message includes indication information of the first token.

21. The method of claim 15, wherein: The first information includes auxiliary information for identifying the first token.

22. The method according to claim 21, characterized in that The auxiliary information includes at least one of the following: information for identifying the authorization scope of the first token; Information for identifying a service application software programming interface corresponding to the first token; Information used to identify the authorization function network element corresponding to the first token; information for identifying the first user; Information for identifying an open function of an application software programming interface corresponding to the first token; information for identifying the validity period of the first token; Information for identifying the issuance time of the first token.

23. The method of claim 15, wherein: The first information includes an authorization code corresponding to the first token.

24. The method of claim 23, wherein: Also includes: An authorization code corresponding to the first token is sent to the terminal.

25. The method according to claim 23 or 24, characterized in that The first request also includes: indication information of the first user, and the indication information of the first user and the first information are used to determine the first token.

26. The method according to any one of claims 15 to 25, characterized in that Also includes: Revoking the first token; or, A second request is sent to the authorization function network element, where the second request is used to request revocation of the first token.

27. The method according to any one of claims 15 to 26, characterized in that Receiving a first request from a terminal includes at least one of the following: receiving the first request sent by the terminal according to the address information of the authorization function network element; or The first request from the terminal is received through an application software programming interface caller.

28. A communication device, characterized in that: include: A communication unit for receiving and sending information; A processing unit, configured to execute the method according to any one of claims 1 to 27 through the communication unit.

29. A communication device, characterized in that: comprising a processor configured to execute the method according to any one of claims 1 to 27.

30. A computer program product, characterized in that The computer program product comprises: a computer program code, and when the computer program code is executed, the method according to any one of claims 1 to 27 is implemented.

Images