Communication method and device

Abstract

A communication method and apparatus are provided. The method includes the following: A terminal sends a first request, which is used to request the revocation of a first token. The first request includes first information, which is used to determine a first token, which is a token for authorizing a first user to a first service. According to the method, a user can control a terminal to initiate a procedure to revoke a first token, thereby revoking authorization for the first service corresponding to the first token.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular, to a communication method and apparatus.

Background Art

[0002] The capability exposure architecture of the 3rd generation partnership project (3GPP) network provides a mode for the 3GPP network to provide services to the outside. In such an architecture, an application function (AF) may process and / or acquire 3GPP-related data information by using capabilities provided by the 3GPP network. This may include processing and / or acquiring data of the 3GPP network, and may include processing and / or acquiring user-related data of the 3GPP network. When processing and / or acquiring user-related data, the AF needs to obtain authorization from the user. For example, the AF may request the 3GPP network to send the user's location information to the outside. If authorization from the user is not obtained, the user's privacy information may be exposed. In another example, the AF may request the 3GPP network to modify the quality of service (QoS) for the user. If authorization from the user is not obtained, the user experience may not match expectations, and the user may further be charged an additional fee.

[0003] After a service is authorized by a user, the authorization for the service may be revoked. How the service revocation procedure should be designed requires further research.

Summary of Invention

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

[0005] According to a first aspect, embodiments of the present application provide a communication method. The method may be applied to a terminal, or to a module in the terminal, for example, a chip, a chip system, or a processor, or to a logical node, a logical module, or software that can implement all or part of the functions of the terminal. The following description uses an example in which the method is applied to a terminal. The method includes: The terminal may determine first information, which is used to determine a first token, which is a token for authorizing a first service to a first user. The terminal sends a first request, which includes first information, which is used to request the revocation of the first token.

[0006] According to this method, a terminal can initiate a procedure to revoke a first token by including first information in a first request. In this way, a user can control the terminal to initiate a procedure to revoke a first token and revoke authorization for a first service corresponding to the first token.

[0007] In a possible design, the first piece of information includes a random number, which is used to determine the first token. According to this design, the terminal can initiate a procedure to revoke the first token by including a random number in the first request. In this way, the user can control the terminal to initiate a procedure to revoke the first token and revoke authorization for the first service corresponding to the first token.

[0008] In a possible design, a random number may be used to determine a second piece of information via a one-way function, and this second piece of information is used to determine the first token. In this design, the random number can be protected via the one-way function. In this way, applications or AFs other than the user agent on the terminal cannot obtain the information related to the random number and therefore cannot initiate a revocation procedure against the first token, thus improving the communication security of the terminal.

[0009] In a possible design, the terminal may also receive a first response. The first response indicates one of the following: that the first token has been successfully revoked, that a procedure to revoke the first token has been triggered, or that the first request has been received. The first response contains a random number or second information, the second information being obtained based on a one-way function and a random number. According to this design, the terminal can know in a timely manner that one of the following has been successfully revoked: that the first token has been successfully revoked, that a procedure to revoke the first token has been triggered, or that the first request has been received.

[0010] In a possible design, the terminal may generate a random number and a second piece of information, the second piece of information being obtained based on a one-way function and the random number. The terminal may then send the second piece of information to an authorization function network element, the second piece of information corresponding to the first token. According to this design, the random number used to initiate the revocation procedure for the first token may be generated by the terminal and protected via a one-way function. In this way, applications or AFs other than the user agent on the terminal cannot obtain the information related to the random number and therefore cannot initiate the revocation procedure for the first token, thus improving the communication security of the terminal.

[0011] In a possible design, the terminal may detect a first action by a first user before generating random numbers and second information, where the first action indicates that the first user consents to authorizing the first service to the first user. According to this design, the terminal generates random numbers and second information only after detecting the user's first action. In this way, the terminal's energy consumption can be reduced because it does not need to generate random numbers for tokens that the user does not consent to.

[0012] In a possible design, the first information includes auxiliary information used to identify the first token. According to this design, the terminal can initiate a procedure to revoke the first token by including the auxiliary information in the first request. In this way, the user can control the terminal to initiate a procedure to revoke the first token and revoke authorization for the first service corresponding to the first token.

[0013] Optionally, the supplementary information is: Information used to identify the authorization scope of the first token, Information used to identify the service application programming interface (API) corresponding to the first token, Information used to identify the AzF corresponding to the first token, Information used to identify the first user, Information used to identify the API exposure function corresponding to the first token, Information used to identify the validity period of the first token, and Information used to identify the issuance time of the first token, It includes at least one of the following.

[0014] In a possible design, the terminal may detect a first action by a first user, which indicates that the first user consents to authorizing a first service to the first user. The terminal then retrieves and stores auxiliary information. According to this design, the terminal retrieves and stores auxiliary information only after detecting the user's first action. In this way, the terminal does not need to retrieve and store auxiliary information for tokens that the user does not consent to, thus reducing the terminal's energy consumption and saving its memory resources.

[0015] In a possible design, the terminal may receive an authorization code corresponding to a 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 a token revocation procedure can be initiated based on the auxiliary information.

[0016] In a possible design, the first information includes an authorization code corresponding to the first token. According to this design, the terminal can initiate a procedure to revoke the first token by including the authorization code in the first request. In this way, the user can control the terminal to initiate a procedure to revoke the first token and revoke authorization for the first service corresponding to the first token.

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

[0018] In a possible design, the first request further includes indication information for a first user, and the indication information for the first user and the first information are used to determine the first token. The indication information for the first user may be used to quickly narrow down the range of tokens to be determined, thereby improving the speed of determining the first token. For example, the first device stores tokens for multiple users. The first device may select the token for the first user from the tokens of multiple users based on the indication information for the first user, and select the first token from the tokens of the first user based on the first information. The first device may use the user indication information as an index for the tokens of multiple users. Thus, the first device can quickly exclude tokens of users other than the first user, narrowing the range of tokens to be determined and improving the speed of determining the first token.

[0019] In a possible design, the terminal sends the first request to AzF based on AzF's address information, or the terminal sends the first request to AzF via an API invoker. This design allows the terminal to send the first request to AzF flexibly.

[0020] According to a second aspect, embodiments of the present application provide a communication method. The method may be applied to a first device. The first device may be an API invoker, a device including an API invoker (e.g., a terminal or AF), or an AzF, or a module used in an API invoker, a device including an API invoker, or an AzF, e.g., a chip, a chip system, or a processor, or a logical node, logical module, or software capable of implementing all or part of the functions of an API invoker, a device including an API invoker, or an AzF. The method includes: The first device receiving a first request from a terminal, the first request being used to request the cancellation of a first token, the first request including first information, the first information being used to determine a first token, the first token being a token for authorizing a first service to a first user. The first device may determine a first token based on the first request.

[0021] According to this method, a terminal can initiate a procedure to revoke a first token by including first information in a first request. In this way, a user can control the terminal to initiate a procedure to revoke a first token and revoke authorization for a first service corresponding to the first token.

[0022] In a possible design, the first piece of information includes a random number, which is used to determine the first token. According to this design, the terminal can initiate a procedure to revoke the first token by including a random number in the first request. In this way, the user can control the terminal to initiate a procedure to revoke the first token and revoke authorization for the first service corresponding to the first token.

[0023] In a possible design, the random number is used to determine second information via a one-way function, and the second information is used to determine the first token. In this design, the random number can be protected via a one-way function. In this way, applications or AFs other than the user agent on the terminal cannot obtain information related to the random number, and therefore cannot initiate a revocation procedure for the first token, thereby improving the communication security of the terminal.

[0024] In a possible design, the first apparatus may further send a first response to the terminal. The first response indicates one of that the first token has been successfully revoked, that a procedure for revoking the first token has been triggered, or that the first request has been received. The first response includes a random number or second information, where the second information is obtained based on a one-way function and the random number. According to this design, the terminal can timely know one of that the first token has been successfully revoked, that the procedure for revoking the first token has been triggered, or that the first request has been received.

[0025] In a possible design, the first apparatus may receive second information from the terminal, where the second information is obtained based on a one-way function and a random number. The first apparatus can then associate the second information with the first token. According to this design, the first apparatus can quickly determine the corresponding first token based on the second information.

[0026] In a possible design, the first apparatus may send a notification message to an API invoker, where the notification message may indicate one of that the first token has been successfully revoked, that a procedure for revoking the first token has been triggered, or that the first request has been received, and the notification message includes indication information of the first token. According to this design, the API invoker can timely know one of that the first token has been successfully revoked, that the procedure for revoking the first token has been triggered, or that the first request has been received.

[0027] In a possible design, the first information includes auxiliary information used to identify the first token. According to this design, the terminal can initiate a procedure for revoking the first token by including the auxiliary information in the first request. In this way, a user can control the terminal to initiate the procedure for revoking the first token, thereby revoking the authorization for the first service corresponding to the first token.

[0028] Optionally, the auxiliary information is information used to identify the authorization scope of the first token, information used to identify the service API corresponding to the first token, information used to identify the AzF corresponding to the first token, information used to identify the first user, information used to identify the API exposure function corresponding to the first token, information used to identify the validity period of the first token, and information used to identify the issuance time of the first token, comprises at least one of the foregoing.

[0029] In a possible design, the first information includes an authorization code corresponding to the first token. According to this design, the terminal can initiate a procedure for revoking the first token by including the authorization code in the first request. In this way, a user can control the terminal to initiate the procedure for revoking the first token, thereby revoking the authorization for the first service corresponding to the first token.

[0030] In a possible design, the first apparatus may send the authorization code corresponding to the first token to the terminal. In this way, the terminal can obtain the authorization code corresponding to the first token in a timely manner.

[0031] In a possible design, the first request further includes indication information for a first user, and the indication information for the first user and the first information are used to determine the first token. The indication information for the first user may be used to quickly narrow down the range of tokens to be determined, thereby improving the speed of determining the first token. For example, the first device stores tokens for multiple users. The first device may select the token for the first user from the tokens of multiple users based on the indication information for the first user, and select the first token from the tokens of the first user based on the first information. The first device may use the user indication information as an index for the tokens of multiple users. Thus, the first device can quickly exclude tokens of users other than the first user, narrowing the range of tokens to be determined and improving the speed of determining the first token.

[0032] In a possible design, the first device may revoke the first token, or the first device may send a second request to AzF, which is used to request the revocation of the first token. According to this design, the first device may revoke the first token or request AzF to revoke the first token.

[0033] In a possible design, the first device may receive a first request sent by a terminal based on the address information of an AzF network element, or the first device may receive a first request from a terminal via an API inviter. According to this design, the first device can flexibly receive the first request from a terminal.

[0034] According to a third aspect, embodiments of the present application provide a communication method. The method may be applied to a terminal, or to a module in the terminal, for example, a chip, a chip system, or a processor, or to a logical node, a logical module, or software that can implement all or part of the functions of the terminal. The following description uses an example in which the method is applied to a terminal. The method includes: The terminal may receive third information indicating that the authorization to be revoked is a first authorization that permits a first user to use a first service. After detecting a second action by the first user, the terminal may send fourth information indicating that the second action indicates that the first user consents to the revocation of the first authorization, and the fourth information is used to trigger the revocation of the first authorization.

[0035] According to this method, the terminal will only trigger the revocation of the first authorization after the second operation of the first user has been detected, i.e. ,to -kun Cancellation A fourth piece of information is sent to trigger the procedure, thereby preventing the interruption of services desired by the user due to the revocation of authorization, i.e., preventing a denial of service to the user.

[0036] In a possible design, before receiving the third information, the terminal sends a third request, which includes indication information for the first service. According to this design, the terminal can trigger the revocation of the first authorization by including the indication information for the first service in the third request.

[0037] According to a fourth aspect, embodiments of the present application provide a communication method. The method may be applied to a third device, which may be an AzF, or a module used in an AzF, such as a chip, chip system, or processor, or a logical node, logical module, or software capable of implementing all or part of the functions of an AzF. The method includes: the third device sending third information to a terminal, which indicates that the authorization to be revoked is a first authorization that permits a first user to use a first service. The third device may receive fourth information sent by the terminal based on a second operation of the first user, which indicates that the first user consents to the revocation of the first authorization, and the fourth information is used to trigger the revocation of the first authorization.

[0038] According to this method, the terminal will only trigger the revocation of the first authorization after the second operation of the first user has been detected, i.e. ,to -kun Cancellation A fourth piece of information is sent to trigger the procedure, thereby preventing the interruption of services desired by the user due to the revocation of authorization, i.e., preventing a denial of service to the user.

[0039] In a possible design, before sending the third information, the third device may receive a third request from the terminal, which includes indication information for the first service. According to this design, the terminal may trigger the revocation of the first authorization by including the indication information for the first service in the third request.

[0040] In a possible design, a third device may send a fifth piece of information to an API invoker, which is used to revoke the first authorization. According to this design, the API invoker can obtain the fifth piece of information which is used by the user to revoke the first authorization, so the first authorization can be revoked by using the fifth piece of information.

[0041] In a possible design, the fifth piece of information is the second token. Optionally, the type of the second token is either a revoked token, or the value of the first field in the second token is a specified value. This design provides multiple ways in which the second token is used to revoke the first authorization.

[0042] According to a fifth aspect, the present application provides a communication device. The communication device may be a terminal or a module within a terminal (for example, a circuit or a chip), or a logical node, logical module, or software capable of implementing all or part of the functions of a terminal. The communication device has the function of implementing the first aspect. For example, the communication device includes a corresponding module, unit, or means for performing the operation in the first or third aspect. The module, unit, or means may be implemented by software, by hardware, or by hardware running the corresponding software.

[0043] In a possible design, the communication device includes a processing unit and an interface unit. The interface unit may be configured to receive and transmit signals to implement communication between the communication device and another device. The processing unit may be configured to perform some internal operations of the communication device. The functions performed by the processing unit and the interface unit may correspond to the operations in the first or third embodiment.

[0044] In a possible design, the communication device may include a processor, which may be coupled to memory. The memory may store computer programs or instructions necessary to implement the functions in the first or third embodiment. The processor may execute the computer programs or instructions stored in memory. When the computer programs or instructions are executed, the communication device becomes capable of implementing the methods in any possible design of the first or third embodiment.

[0045] In a possible design, the communication device includes a processor and memory. The memory may store computer programs or instructions necessary to implement the functions in the first or third embodiment. The processor may execute the computer programs or instructions stored in memory. When the computer programs or instructions are executed, the communication device becomes capable of implementing the methods in any possible design of the first or third embodiment.

[0046] In a possible design, the communication device includes a processor and interface circuitry. The processor is configured to communicate with another device through the interface circuitry and to carry out a method in any possible design of the first or third embodiment.

[0047] According to the sixth aspect, the present application provides a communication device. The communication device may be an API invoker, a device including an API invoker (e.g., a terminal or AF), or an AzF, or a module (e.g., a circuit or chip) in an API invoker, a device including an API invoker, or an AzF, or a logical node, logical module, or software capable of implementing all or part of the functions of an API invoker, a device including an API invoker, or an AzF. The communication device has the function of implementing the second or fourth aspect. For example, the communication device includes a corresponding module, unit, or means for performing the operation in the second or fourth aspect. The module, unit, or means may be implemented by software, by hardware, or by hardware running the corresponding software.

[0048] In a possible design, the communication device includes a processing unit and an interface unit. The interface unit may be configured to receive and transmit signals to implement communication between the communication device and another device. The processing unit may be configured to perform some internal operations of the communication device. The functions performed by the processing unit and the interface unit may correspond to the operations in the second or fourth embodiment.

[0049] In a possible design, the communication device may include a processor, which may be coupled to memory. The memory may store computer programs or instructions necessary to implement the functions in the second or fourth embodiment. The processor may execute the computer programs or instructions stored in memory. When the computer programs or instructions are executed, the communication device becomes capable of implementing the methods in any possible design of the second or fourth embodiment.

[0050] In a possible design, the communication device includes a processor and memory. The memory may store computer programs or instructions necessary to implement the functions in the second or fourth embodiment. The processor may execute the computer programs or instructions stored in memory. When the computer programs or instructions are executed, the communication device becomes capable of implementing the methods in any possible design of the second or fourth embodiment.

[0051] In a possible design, the communication device includes a processor and interface circuitry. The processor is configured to communicate with another device through the interface circuitry and to implement a method in any possible design of the second or fourth embodiment.

[0052] In the fifth or sixth aspect, the processor may be understood to be implemented in hardware or in software. When the processor is implemented in hardware, it may be a logic circuit, an integrated circuit, etc. When the processor is implemented in software, it may be a general-purpose processor and is implemented by reading software code stored in memory. In addition, there may be one or more processors and one or more memories. The memory may be integrated with the processor, or the memory and processor may be arranged separately. In certain implementations, the memory and processor may be integrated on one chip or arranged on different chips. The type of memory and the arrangement of the memory and processor are not limited to the embodiments of this application.

[0053] According to the seventh aspect, the present application provides a communication system. The communication system may include a communication device according to the fifth aspect and a communication device according to the sixth aspect. Optionally, when the communication device according to the fifth aspect implements the method according to the first aspect, the communication device according to the sixth aspect implements the method according to the second aspect. When the communication device according to the fifth aspect implements the method according to the third aspect, the communication device according to the sixth aspect implements the method according to the fourth aspect.

[0054] According to the eighth aspect, the present application provides a computer-readable storage medium. The computer storage medium stores computer-readable instructions. When a computer reads and executes a computer-readable instruction, the computer becomes capable of carrying out a method in any one of the possible designs of the first through fourth aspects.

[0055] According to the ninth aspect, the present application provides a computer program product. When a computer reads and executes the computer program product, the computer is able to implement a method in any one of the possible designs of the first through fourth aspects.

[0056] According to the tenth aspect, the present application provides a chip configured to read a computer program stored in memory and to carry out a method in any one of the possible designs of the first through fourth aspects.

[0057] For technical effects that can be achieved in any one of the fifth through tenth embodiments, please refer to the technical effects that can be achieved in any possible design in any one of the first through fourth embodiments. No repetition is provided. [Brief explanation of the drawing]

[0058] [Figure 1] This is a diagram showing the architecture of a communication system according to an embodiment of this application. [Figure 2] This is a diagram showing the architecture of another communication system according to an embodiment of this application. [Figure 3] This is a flowchart of the first communication method according to an embodiment of the present application. [Figure 4] This is a flowchart of the first token application method according to an embodiment of this application. [Figure 5] This is a flowchart of the first token cancellation method according to an embodiment of the present application. [Figure 6] This is a flowchart of the second token application method according to the embodiment of this application. [Figure 7] This is a flowchart of a second token cancellation method according to an embodiment of the present application. [Figure 8] This is a flowchart of the third token application method according to the embodiment of this application. [Figure 9] This is a flowchart of a third token cancellation method according to an embodiment of the present application. [Figure 10] This is a flowchart of a second communication method according to an embodiment of the present application. [Figure 11]This is a flowchart of a third communication method according to an embodiment of the present application. [Figure 12] This is a diagram showing the structure of a communication device according to an embodiment of this application. [Figure 13] This is a diagram showing the structure of another communication device according to an embodiment of this application. [Modes for carrying out the invention]

[0059] To further clarify the purpose, technical solutions, and advantages of the embodiments of this application, the embodiments of this application will be described in more detail below with reference to the accompanying drawings.

[0060] The architecture of a communication system to which the method provided in this application is applied will be described below.

[0061] Figure 1 is a diagram of the architecture of a communication system to which embodiments of this application are applicable, and shows a fifth-generation (5G) network architecture based on a service-based architecture. As shown in Figure 1, the communication system may include three parts: a terminal portion, a carrier network portion, and a data network (DN). The functions of some network elements are described below.

[0062] A terminal, also called a terminal device or user equipment (UE), is a device with wireless receiving and transmitting capabilities that may be deployed on land, including indoor, outdoor, handheld, or in-vehicle terminals, or on water (e.g., on a ship), or in the air (e.g., on an aircraft, balloon, or satellite). A terminal may also be a mobile phone, tablet computer (pad), computer with wireless transmitting and receiving 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, or wireless terminal in smart home.

[0063] The terminal may establish a connection to the carrier network through an interface provided by the carrier network (e.g., N1) and use services such as data and / or voice provided by the carrier network. The terminal may further access the DN through the carrier network and use carrier services and / or services provided by third parties deployed on the DN. The third party may be a service provider other than the carrier network and the terminal, and may provide services such as data and / or voice to the terminal. The specific form of representation of the third party may be determined specifically based on the actual application scenario and is not limited herein.

[0064] The carrier network may be a network deployed by a carrier and may include access network devices and core network devices. In possible implementations, the carrier network may further include AF network elements. Alternatively, AF network elements may not belong to the carrier network but to a third party.

[0065] Access network devices are devices in a wireless network, including, for example, radio access network (RAN) nodes or radio access network devices that connect terminals to the wireless network. Currently, some examples of access network devices include next-generation node B (gNodeB, gNB) in 5G, transmission reception point (TRP), evolved node B (eNB), radio network controller (RNC), node B (NodeB, NB), base station controller (BSC), base transceiver station (BTS), home base station (e.g., home evolved node B or home node B, HNB), baseband unit (BBU), wireless fidelity (Wi-Fi) access point (access point, AP), and integrated access and backhaul (IAB). In implementations, access network devices are used as alternatives in future communication systems (e.g., the 6th generation). th It may also be an access network device in a 6G (generation) communication system.

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

[0067] In this application, a mobility management network element is a control plane network element provided by the carrier network, responsible for access control and mobility management for terminals to access the carrier network, and includes functions such as mobility status management, temporary user identity assignment, and user authentication and authorization. In 5G, the mobility management network element may be an access and mobility management function (AMF) network element. In future communications such as 6G, the mobility management network element may still be an AMF network element or may have a different name. This is not limited to this application.

[0068] In this application, a session management network element is a control plane network element provided by the carrier network and is responsible for managing protocol data unit (PDU) sessions of terminals. A PDU session is a channel used to transmit PDUs, and terminals and DNs must transmit PDUs to each other through the PDU session. SMF network elements are responsible for establishing, maintaining, and deleting PDU sessions. The functions of a session management network element include session management (e.g., session establishment, modification, and release, including maintaining tunnels between user plane network elements and access network devices), selection and control of user plane network elements, service and session continuity (SSC) mode selection, and roaming. In 5G, a session management network element may be a session management function (SMF) network element. In future communications such as 6G, a session management network element may still be an SMF network element, or it may be a network element with a different name but having all or some of the functions of a session management network element. This is not limited to this application.

[0069] In this application, a network-exposed network element is a control plane network element provided by an operator. The network-exposed network element securely exposes the external interface of the operator network to a third party. The interface is, for example, a service API. For example, when a session management network element needs to communicate with a third-party network element, the network-exposed network element may act as a relay for communication between the session management network element and the third-party network element. When the network-exposed network element acts as a relay, it may translate subscriber identification information and third-party network element identification information. For example, when sending a subscriber's subscriber permanent identifier (SUPI) from the operator network to a third party, the network-exposed network element may translate the SUPI to the corresponding external identity (ID). Conversely, when sending an external ID (third-party network element ID) to the operator network, the network-exposed network element may translate the external ID to a SUPI. In 5G, a network-exposed network element may be an NEF network element. In future communications such as 6G, a network-exposed network element may still be an NEF network element or may have a different name. This is not limited to the present application.

[0070] In embodiments of this application, a communication device configured to implement the functions of an access network device, terminal, or core network device may be an access network device, terminal, or core network device, or a device capable of supporting the implementation of functions by an access network device, terminal, or core network device, such as a chip system. This device may be installed within the access network device, terminal, or core network device. The technical solutions provided in embodiments of this application will be described using examples in which the device configured to implement the functions of an access network device is an access network device, the device configured to implement the functions of a terminal is a terminal, and the device configured to implement the functions of a core network device is a core network device.

[0071] A DN (Database Network) is a network located outside the carrier network. The carrier network may access multiple DNs, and multiple services may be deployed on the DNs to provide services such as data and / or voice to terminals. For example, the DN could be the private network of a smart factory, where sensors installed in the smart factory are terminals, and the sensor control server could be deployed within the DN, providing services to the sensors. The sensors could communicate with the control server to obtain instructions from the control server, and transmit collected sensor data to the control server according to those instructions. In another example, the DN could be a company's internal office network, where the company's employees' mobile phones or computers are terminals, and these employees' mobile phones or computers could access information, data resources, etc., on the company's internal office network.

[0072] In Figure 1, N1, N2, N3, N4, etc., are interface sequence numbers. For the meaning of these interface sequence numbers, please refer to the definitions in the 3GPP standard protocol. This is not limited to the definitions provided herein.

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

[0074] An API invoker is typically a third-party application that enters into a service agreement with a public land mobile network (PLMN) operator. The application can run on a terminal or an AF (Airport Facility). Therefore, the API invoker can be part of the terminal or part of the AF. The API invoker may have functions such as providing API invoker identity information and other information necessary for API invoker authentication, supporting mutual authentication with CCF (Customer Classification Facility), obtaining authorization before accessing service APIs, discovering service APIs, and exploring and calling service APIs. For the location of the API invoker in the communication network, please refer to the AF network elements or UE (Union Interface) in Figure 1.

[0075] The CCF may have the following functions: to perform authentication to the API invoker based on the API invoker's identity information and other information necessary for the API invoker's authentication; to support mutual authentication with the API invoker; to provide authorization to the API invoker before the API invoker can access the service API; to publish and store service API information and support service API discovery; to control access to the service API according to policies configured by the PLMN operator; to monitor service API calls; to store service API call logs and provide service API call logs to authorization function network elements; to perform billing based on service API call logs; to add and remove new API invokers; to store policy configurations for CAPIF and service API relationships; to support auditing based on access logs (e.g., to detect whether there is abuse); and to support publishing and / or discovering service APIs by using other CAPIF core functions during interworking with CAPIF. Optionally, the CCF may be a device in the core network or a device in another network. This is not limited to the present application.

[0076] AzF is configured to obtain user authorization. In this application, AuF and AzF may be interchangeable. In addition, AzF and CCF each have authorization functions, and AzF and CCF may be installed on the same device or on different devices. The following description uses an example in which AzF and CCF are installed on the same device. In this case, AzF and CCF may not be distinguished. Specifically, the following AzF and CCF may be interchangeable and may also be referred to as an authorization server.

[0077] An AEF is configured to provide a service API and is the entry point for API invokers to call the service API. An AEF may have the functions of authenticating API invokers based on identity information provided by the CCF and other information required for API invoker authentication, verifying authorization provided by the CCF, and recording the number of times the service API has been called by the CCF. For example, an AEF may be an NEF. In other words, for the location of the AEF in the communication network, see the NEF network element in Figure 1.

[0078] The API Exposure Feature Network element is a feature network element that enables API providers to expose APIs, and may expose information about service APIs to the CCF, thereby allowing API inviters to find information about service APIs in the CCF. Note that the API Exposure Feature Network element and the NEF may be deployed together.

[0079] The API management network element manages service APIs, for example, by monitoring the status of service APIs and recording call information. Note that the API management network element and NEF may be deployed together.

[0080] An RO client is an application client used by a user, which may display an operating interface to the user. An RO client may be, for example, an operating system or a browser, or it may be an application on the UE as shown in Figure 1. In this application, an RO client may also be referred to as a user agent, and these two terms may be used interchangeably.

[0081] In Figure 2, CAPIF-1, CAPIF-1e, CAPIF-2, CAPIF-2e, etc., are reference points. For the meaning of these reference points, please refer to the definitions in the 3GPP standard protocol, which are not limited to those defined herein.

[0082] It should be noted that the communication systems shown in Figures 1 and 2 are not limiting to the communication systems to which the embodiments of this application can be applied. Therefore, the communication methods provided in the embodiments of this application are further applicable to a variety of standard communication systems, such as long-term evolution (LTE) communication systems, 5G communication systems, 6G communication systems, future communication systems, vehicle-to-everything (V2X), long-term evolution-vehicle (LTE-V, LTE-V), vehicle-to-vehicle (V2V), the Internet of Things (V2X), machine-type communications (MTC), the Internet of Things (IoT), long-term evolution-machine-to-machine (LTE-M, LTE-M), machine-to-machine (M2M), and the Internet of Things (IoT). In addition, the communication systems provided in this application may be used in terrestrial networks (TN) and / or non-terrestrial networks (NTN), but are not limited to this. Furthermore, it should be noted that the names of network elements in the communication system are not limited to the embodiments of this application. For example, network elements may have different names in different standard communication systems. In another example, when multiple network elements are integrated into the same physical device, this physical device may have a different name as an alternative.

[0083] To facilitate understanding of this application, the terminology used in this application is explained below.

[0084] (1) A token is a digital object, data field, or string containing authorization or authentication information. For example, a token may indicate authorization for one or more users to one or more services or resources.

[0085] Tokens can be classified into several types based on their purpose, for example, access tokens (access_token), refresh tokens (refresh_token), and identity tokens (ID token). An access token is a credential used to access a protected resource, and may be used, for example, to authorize an API invoker to access an API service corresponding to the access token through the Access Firmware Fund (AEF), such as a QoS service. A refresh token is a credential used to obtain an access token, and may be used, for example, to authorize an API invoker to request a new token from the CCF when the current access token expires. In other words, a refresh token may be used to refresh the usage time of the current token. In addition, a refresh token may be used as an alternative to shorten the validity period of the current access token or to reduce the permission scope of the current access token.

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

[0087] 1. Expiration Time: This can be used to determine the expiration time of a token. For example, in a token claim, the expiration time {12 / 02 / 2023} indicates that the token expires on December 2, 2023.

[0088] 2. API Invoker Identifier (ID): Indicates the API Invoker corresponding to the token. For example, the token's claims include API Invoker ID #1. If the token is an access token, it indicates that the API Invoker corresponding to API Invoker ID #1 is authorized to access the API service corresponding to the access token through AEF. If the token is a refresh token, it indicates that the API Invoker corresponding to API Invoker ID #1 is authorized to request CCF to obtain a refreshed token.

[0089] 3. AEF ID: Indicates the AEF corresponding to the token. For example, the token's claims include AEF ID #1. If the token is an access token, it indicates that the API invoker is authorized to access the API service corresponding to the access token through the AEF corresponding to AEF ID #1.

[0090] 4. Service Indication Information: This indicates the service authorized by the token. The service indication information may also be an API service ID, which is also sometimes called a service API ID or service ID. For example, the token's claims include API service ID #1. If the token is an access token, it indicates that the API invoker is authorized to access the API service corresponding to API service ID #1 through the AEF.

[0091] 5. User Indication Information: Indicates the user corresponding to the token. User indication information may be the user's ID or the ID of the device corresponding to the user.

[0092] 6. Scope: Used to determine the authorization scope of the token. For example, the token's scope claim includes AEF ID #1, API Service ID #1, and API Service ID #2, indicating that the API Invoker is authorized to access the API services corresponding to API Service ID #1 and API Service ID #2 through AEF #1.

[0093] Optionally, each of the pieces of information in the above claims may be a separate claim. For example, expiration time may be a claim, and scope may be a separate claim. Note that service indication information may be a separate claim or may be included in the scope claim. The specific claims that include service indication information are not limited in this application.

[0094] It should be noted that tokens may also be classified based on whether they contain information such as claims. For example, a structured type token contains one or more of the above-mentioned claim information. The token's recipient or verifier (e.g., AEF) can retrieve the claim information from the token. In another example, an opaque type token does not contain the above-mentioned claim information, and the token's recipient or verifier (e.g., AEF) must indirectly retrieve or verify the claim information by requesting it from another network element using other information in the token. Optionally, this other information may be reference information, such as a token ID or reference ID. Tokens may also be classified in other ways. For example, a bearer-type token means that the token's bearer is authorized to use the resource or service corresponding to the token, while a message authentication code (MAC)-type token requires the token's bearer to further prove that the bearer possesses the corresponding MAC key, and then the bearer is authorized to use the resource or service corresponding to the token. Token classification methods are not limited in this application.

[0095] Optionally, the token may further include a signature. The signature may be a CCF signature on the token's claims and may be used to protect the integrity and / or confidentiality of the token.

[0096] In this application, the token may or may not be encrypted. If the token is encrypted, the token holder (e.g., an API invoker) must obtain a decryption key in order to read the claims in the token. Whether or not the token is encrypted is not limited in this application.

[0097] (2) A user agent, also sometimes called an RO client, may be an application that corresponds to a user and can initiate various requests on behalf of the user. A user agent may include at least one of the following: a browser, an application on the terminal, a client, a command-line tool, or an Internet Access Robot. A user agent can be provided on the terminal.

[0098] This application provides security protection for a communication channel between two network elements. Specific methods for security protection are not limited in this application. The two network elements are, for example, a user agent and an API invoker, a user agent and an AzF, or an API invoker and an AzF.

[0099] In the following of this application, association may be replaced with binding.

[0100] In this application, "sending information to (a terminal)" may be understood to mean that the destination end of the information is the terminal, and may include sending information directly or indirectly to the terminal. "Receiving information from (a terminal)" may be understood to mean that the source end of the information is the terminal, and may include receiving information directly or indirectly from the terminal. The information may undergo necessary processing, such as formatting changes, between the source and destination ends of the information transmission. However, the destination end can understand valid information from the source end. Similar expressions in this application may be understood similarly. Details are not described again herein.

[0101] Currently, 3GPP networks can provide services externally. For example, services provided externally by a 3GPP network include providing user location information. After obtaining authorization for user location information, an API invoker may obtain user location information through the 3GPP network. In another example, services provided externally by a 3GPP network include QoS services. An API invoker may request the 3GPP network to change the QoS service level for a user or terminal. After obtaining authorization for a specific level of QoS service, the API invoker may establish or modify a PDU session corresponding to that level for the user or terminal through the 3GPP network, thereby ensuring that the communication quality for the user or terminal meets the requirements for that level.

[0102] After an API invoker obtains authorization, that authorization may be revoked. International Internet Engineering Task Force (IETF) standards support mechanisms for authorization revocation (i.e., token revocation) initiated by the API invoker (i.e., the client). However, with regard to token revocation procedures initiated by the API invoker, it is impossible to guarantee that the token revocation procedure is authorized by the user. For example, if a malicious application exists on a device such as a terminal or cloud platform, the malicious application may obtain information about the client and then initiate a token revocation procedure to cause a service interruption to the user, i.e., a denial of service (DoS). For example, with regard to refresh tokens, if a malicious application obtains the ID of a refresh token, the malicious application may initiate a refresh token revocation procedure. Therefore, how user-authorized service revocation should be designed, for example, how user-authorized token revocation procedures should be designed, requires further research.

[0103] In view of this, embodiments of the present application provide a communication method. Figure 3 is a schematic flowchart corresponding to the communication method according to embodiments of the present application. In Figure 3, the method is illustrated by using an example in which the terminal and the first device are the execution body of the interaction illustration. However, the execution body of the interaction illustration is not limited in this application. The first device may be an API Invoker or AzF, or a module used in the API Invoker or AzF, such as a chip, chip system, or processor, or a logical node, logical module, or software capable of implementing all or part of the functions of the API Invoker or AzF. Optionally, the terminal in Figure 3 may be replaced with a user agent.

[0104] As shown in Figure 3, this method includes the following steps.

[0105] S301: The terminal determines a first piece of information, which may be used to determine a first token, and the first token may be a token for authorizing a first service to a first user.

[0106] The specific details of the first piece of information are described in the following methods a1, a2, and a3, and are not described here.

[0107] S302: The terminal sends a first request, and in response, the first device receives the first request.

[0108] The first request may include first information, and the first request is used to request the revocation of the first token. In this way, the first device can determine, based on the first information in the first request, 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. This is not limited to the present application.

[0109] In some examples, a terminal may send a first request directly to a first device. For example, the first device may be an API invoker, and the terminal may send a first request to the API invoker based on the API invoker's address information. The API invoker's address information may be, for example, the API invoker's Internet Protocol (IP) address and / or uniform resource locator (URL) address. In another example, the first device may be an AzF, and the terminal may send a first request to the AzF based on the AzF's address information. The AzF's address information may be, for example, the AzF's IP address and / or URL. The AzF's address information may be obtained by the terminal from the API invoker.

[0110] In some other examples, a terminal may send a first request to a first device through a second device. The second device may include one or more devices. For example, the first device may be AzF and the second device may be an API invoker. The terminal may send a first request to AzF through the API invoker.

[0111] Optionally, the first request may further include indication information for a first user. This indication information may be, for example, the name or ID of the first user, or the ID of the device corresponding to the first user (e.g., SUPI or generic public subscription identifier, GPSI). The indication information for the first user and the first information may be used to determine the first token. For example, the first device stores tokens for multiple users. The first device may select the first user's token from the tokens of multiple users based on the indication information for the first user, and select the first token from the tokens of the first user based on the first information. The first device may use the user indication information as an index for the tokens of multiple users. In this example, the first device can quickly exclude tokens of users other than the first user to narrow the range of tokens to be determined and improve the speed of determining the first token. In another example, the first piece of information corresponds to multiple tokens, and the token corresponding to the first user among the multiple tokens is the first token. In this way, the first device can first find the multiple tokens based on the first piece of information and, based on the indication information of the first user, select the token corresponding to the first user from among the multiple tokens as the first token. The multiple tokens may be tokens for multiple users, and the tokens for multiple users may be stored by the first device.

[0112] S303: The first device determines the first token based on the first request.

[0113] The first device may determine a first token based on the first information in the first request. The specific details of how the first device determines the first token are described in the following schemes a1, a2, and a3, and are not described here.

[0114] In some possible configurations, the first device is an API invoker. After determining the first token, the API invoker may send a second request to AzF. The second request may include the first token or indication information for the first token (e.g., ID) and may be used to request 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.

[0115] In some other possible configurations, the first device is AzF. After determining the first token, AzF may revoke the first token. The specific process by which AzF revokes the first token is not limited in this application.

[0116] According to the method shown in Figure 3, the terminal can initiate a procedure to revoke the first token by including the first information in the first request. In this way, the user can control the terminal to initiate a procedure to revoke the first token and revoke authorization for the first service corresponding to the first token.

[0117] As described above, the first information may be used to determine the first token. The first information may be used in multiple ways, for example, in way a1, way a2, or way a3 to determine the first token.

[0118] Method a1: The first piece of information includes a random number, which may be used to determine the first token.

[0119] Random numbers may be used in multiple schemes, for example, to determine the first token in scheme b1 or scheme b2.

[0120] Method b1: There is a correspondence #1 between a random number and a first token. The first device stores correspondence #1. In this way, in S303, after receiving a first request containing a random number, the first device may determine a first token based on the random number and correspondence #1, and then determine that the first request is used to request the cancellation of the first token.

[0121] Optionally, the first device may obtain correspondence #1 by using steps A1 to A3 below.

[0122] A1: The terminal generates random numbers.

[0123] Random numbers may be generated after the terminal detects the first action of the first user. The first action may indicate that the first user consents to the authorization of the first service to the first user. For example, in the process of requesting the first token, the terminal displays popup window #1. Popup window #1 includes a display area asking "Do you consent to the authorization of the first service to the first user?" and "Yes" and "No" action areas. The first action may include a touchscreen operation performed by the first user on the "Yes" action area.

[0124] Optionally, the terminal may store the random number after generating it.

[0125] In some possible configurations, the terminal may store a correspondence between a random number and a first service and / or a first user, thereby enabling the terminal to determine a first token based on the correspondence. For example, the terminal may store indication information for a first service corresponding to a random number. In this way, the terminal can determine a first service based on the random number. In another example, the terminal may store indication information for a first user corresponding to a random number. In this way, the terminal can determine a first user based on the random number. In yet another example, the terminal may store indication information for both a first service and a first user corresponding to a random number. In this way, the terminal can determine a first service for a first user based on the random number. Optionally, the terminal may, as an alternative to more accurately determining the first token, store a correspondence between a random number and authorization information other than the indication information for the first service and the indication information for the first user. For example, authorization information may include, but is not limited to, at least one of the following: information regarding authorization scope, information regarding service APIs, information regarding AzF, information regarding AEF, information regarding authorization validity period, and information regarding authorization time.

[0126] A2: The terminal sends a random number, and the first device receives the random number accordingly.

[0127] For the method by which the terminal sends random numbers, see the method by which the terminal sends the first request in S302. Only the first request is replaced with a random number. Details are not described again in this specification. The random number may be included in an existing message or in a new message. This is not limited in this application. Optionally, the terminal may encrypt the random number before or when sending it. Correspondingly, the first device may decrypt the received message to obtain the random number. Whether or not to encrypt the random number is not limited in this application.

[0128] Optionally, the terminal may send a random number in the process of requesting the first token. For example, the terminal may send a random number after detecting the first operation and generating a random number. See step A1 for the specifics of detecting the first operation. Further details are not described herein.

[0129] A3: The first device obtains correspondence #1 by associating a random number with the first token or the authorization code corresponding to the first token. Correspondence #1 may 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 may store correspondence #1.

[0130] In some possible schemes, in scheme b1, after S303, the method shown in Figure 3 further includes step A4.

[0131] A4: The first device sends a first response, and in response, the terminal receives the first response.

[0132] The first response may indicate that the first token has been successfully revoked, that a procedure to revoke the first token has been triggered, or that the first request has been received. Optionally, the first response may include a random number. In this way, after receiving the first response, the terminal may determine, based on the random number and the correspondence #1 between the random number and the first token, that the first token has been successfully revoked, that a procedure to revoke the first token has been triggered, or that the first request has been received. The first response may be an existing message (e.g., a revocation response) or a new message. This is not limited to the present application.

[0133] In some cases, the first device may send the first response directly to the terminal. For example, the first device may be AzF, and AzF may send the first response to the terminal based on the terminal's address information. The terminal's address information may be, for example, the terminal's IP address.

[0134] In some other examples, the first device may send a first response to the terminal through a second device. The second device may include one or more devices. For example, the first device may be AzF and the second device may be an API Invoker. AzF may send a first response to the terminal through the API Invoker.

[0135] In this system, the terminal can be notified in a timely manner that the first token has been successfully revoked, that the procedure for revoking the first token has been triggered, or that the first device has received the first request.

[0136] Method b2: A random number is used to determine a second piece of information via a one-way function. In other words, there is a functional relationship between the random number and the second piece of information, or the second piece of information is determined based on the random number and the one-way function. The second piece of information can be used to determine the first token. For example, the one-way function could be a hash function, a key derivation function (KDF), etc. The following example uses a hash function as the one-way function.

[0137] In some possible schemes, there is a correspondence #2 between the second piece of information and the first token. The first device stores the correspondence #2 and the hash function. Thus, in S303, after receiving a first request containing a random number, the first device may determine the second piece of information based on the random number and the hash function, determine the first token based on the second piece of information and the correspondence #2, and then determine that the first request is used to request the cancellation of the first token. For example, the random number is rand. After receiving the first request, the first device may compute Utid=hash(rand), where Utid is the second piece of information. The first device may then determine the first token corresponding to Utid based on Utid and the correspondence #2. Optionally, when Utid is computed, the one-way function may include additional parameters other than the random number. For example, the one-way function may be expressed as Utid=hash(rand, another parameter). For example, another parameter may include at least one of the following: the terminal ID, the first device ID, etc. Note that the quantity and values ​​of other parameters are not limited in this application. The method for calculating the second information by the first device (e.g., a one-way function) and the quantity and / or type of parameters required to calculate the second information may be pre-configured or determined through negotiation between the first device and the terminal. This is not limited in this application.

[0138] Optionally, the first device may obtain correspondence #2 by using steps B1 to B3 below.

[0139] B1: The terminal generates a random number and a second piece of information.

[0140] For specific details regarding the generation of random numbers by the terminal, see step A1. Further details are not provided herein. After generating random numbers, the terminal may perform calculations on the random numbers via a one-way function to obtain second information. The method for the terminal to calculate the second information is the same as the method for the first device to calculate the second information. For further details, see the description in scheme b2 that the first device can determine the second information based on random numbers and a hash function. Further details are not provided herein.

[0141] Optionally, the terminal may store the random number after generating it.

[0142] B2: The terminal sends the second piece of information, and in response, the first device receives the second piece of information.

[0143] For the method by which the terminal sends the second piece of information, please refer to the method by which the terminal sends a random number in step A2. The random number is simply replaced with the second piece of information. Further details will not be explained again in this specification.

[0144] B3: The first device associates the second information with the first token to obtain correspondence #2. Correspondence #2 may be a direct correspondence between the second information and the first token, or it may be 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, the second information may be a one-to-one correspondence with 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 may store correspondence #2.

[0145] In some possible schemes, in scheme b2, after S303, the method shown in Figure 3 further includes step B4.

[0146] B4: The first device sends a first response, and in response, the terminal receives the first response.

[0147] The first response may indicate one of the following: that the first token has been successfully revoked, that a procedure to revoke the first token has been triggered, or that 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 may determine second information based on the random number and a hash function, determine the first token based on the second information and correspondence #2, and then determine that the first response indicates one of the following: that the first token has been successfully revoked, that a procedure to revoke the first token has been triggered, or that the first device has received the first request. In some other examples, the first response includes second information. In this way, after receiving the first response, the terminal may determine, based on the second information and correspondence #2, that the first token has been successfully revoked, that a procedure to revoke the first token has been triggered, or that the first device has received the first request. The first response may be an existing message (e.g., a cancellation response) or a new message. This is not limited to the present application.

[0148] For the manner in which the first device sends the first response, please refer to step A4. Further details will not be described again in this specification.

[0149] In this system, the terminal can be notified in a timely manner that the first token has been successfully revoked.

[0150] In some possible methods, after S303, the method shown in Figure 3 further includes step B5.

[0151] B5: The first device sends a notification message to the API Invoker, and in response, the API Invoker receives a notification message from the first device.

[0152] The notification message indicates one of the following: that the first token has been successfully revoked, that a procedure to revoke the first token has been triggered, or that the first request has been received. For example, the notification message may include indication information for the first token (e.g., the token ID). In this way, after receiving the notification message, the API invoker may determine one of the following: that the first token has been successfully revoked, that a procedure to revoke the first token has been triggered, or that the first device has received the first request.

[0153] The sequence for performing steps B4 and B5 is not limited in this application.

[0154] In method a1, the terminal can initiate a first token revocation procedure based on a random number. In this way, the user can control the terminal by using a user agent on the terminal to initiate the first token revocation procedure, and thus the revocation procedure is authorized by the user, thereby preventing the interruption of a service desired by the user due to the revocation of authorization, i.e., preventing a denial of service to the user.

[0155] In addition, in method a1, the random number used to initiate the first token revocation procedure may be generated by the terminal and protected via a one-way function. In this way, applications or AFs other than the user agent on the terminal cannot obtain information related to the random number and therefore cannot initiate the revocation procedure for the first token, thus improving the terminal's communication security.

[0156] Method a2: The first information includes auxiliary information used to identify the first token. In this way, in S303, the first device can determine the first token based on the auxiliary information.

[0157] For example, auxiliary information may include at least one of the following:

[0158] 1. Information used to identify the authorization 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 verifying user indication information (e.g., an open identifier (openID) method). The authorized service scope may include authorized service scopes corresponding to each of the AEFs. Optionally, Information #1 may be used to determine the scope in the claims of the first token.

[0159] 2. Information used to identify 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 services, terminal location information acquisition, and services subscribed to by the first user. Optionally, Information #2 may be used to determine the API service ID in the claims of the first token.

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

[0161] 4. Information used to identify user indication information (hereinafter referred to as Information #4): For example, Information #4 may include indication information for a first user. For specific details of the indication information for a first user, see the description of the indication information for a first user in S302. Details are not described again herein. Information #4 may be used to determine the claim “sub” in the claim set of the first token, which 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 a terminal corresponding to the first user.

[0162] 5. Information used to identify 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: name, URL, ID, etc., of the AEF network element corresponding to the first token. Information #5 may be used to determine the parameter "aud" in the claims of the first token, which indicates the recipient (audience) of the first token. The recipient of the first token may include the AEF network element corresponding to the first token.

[0163] 6. Information used to identify the validity period of the first token (hereinafter referred to as Information #6): Information #6 may be used to determine the parameter "exp" in the claims of the first token, which indicates the expiration time of the first token.

[0164] 7. Information used to identify the issuance time of the first token (hereinafter referred to as Information #7): Information #7 may be used to determine the claim or parameter "iat" (i.e., issued at) in the claim set of the first token, which indicates the issuance time of the first token.

[0165] It should be noted that the auxiliary information may include information other than the seven types of information described above. Optionally, the auxiliary information may include information corresponding to any claim in the first token and / or any information in the claims of the first token. The first device determines the first token by identifying the claim corresponding to the auxiliary information or by identifying the information in the claim corresponding to the auxiliary information. The auxiliary information helps to narrow the search scope for determining the first token in multiple tokens, thereby enabling the first token to be determined accurately. For example, if a claim in a token includes an API invoker identifier, the auxiliary information may include information used to identify the API invoker identifier. The first device may determine the first token containing the API invoker identifier by identifying the API invoker identifier in the claim based on the information used to identify the API invoker identifier.

[0166] Optionally, the information in the supplementary information and the claims of the first token may differ in format, precision, etc. For example, information #7 in the supplementary information may include July 2023. The claim "iat" of the first token may include July 27, 2023.

[0167] After receiving the auxiliary information, the first device may search the token database for a first token that matches the auxiliary information based on the auxiliary information. The token database may be stored in the first device or in a device other than the first device, but is not limited to this application. Optionally, the first device may compare the auxiliary information with the claims of tokens in the token database and select a token whose claims match the auxiliary information as the first token. For example, in the auxiliary information, information #2 indicates a 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. In the claims of token #1, the API service ID indicates a QoS service, claim "sub" indicates user #1, claim "aud" indicates AEF network element #1, and claim "exp" indicates September 10, 2023. The first device may determine token #1 to be the first token.

[0168] In some possible schemes, auxiliary information may be acquired and stored by the terminal after it has detected the first action of the first user. For specific details of how the terminal detects the first action of the first user, see scheme a1. Further details are not described herein.

[0169] Optionally, AzF may further send an authorization code corresponding to the first token. In response, 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. In other words, the authorization code may be used to determine that the first token corresponding to the auxiliary information is a token authorized by AzF.

[0170] In method a2, the terminal can initiate a first token revocation procedure based on auxiliary information. In this way, the user can control the terminal by using the user agent on the terminal to initiate the first token revocation procedure, and thus the revocation procedure is authorized by the user, thereby preventing the interruption of a service desired by the user due to the revocation of authorization, i.e., preventing a denial of service to the user.

[0171] Method 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 based on the authorization code.

[0172] The authorization code may be obtained from AzF by the terminal. For example, in the process of requesting the first token, AzF sends the authorization code to the terminal. For the method by which AzF sends the authorization code to the terminal, see the method by which the first device sends the first response in step A4. The only differences are that the first device is replaced by AzF and the first response is replaced by the authorization code. Further details are not described herein.

[0173] Optionally, the terminal may store at least one of the following: a correspondence between an authorization code and a first service and / or a first user, or a correspondence between an authorization code and authorization information other than the indication information for the first service and the indication information for the first user, thereby the terminal determines the first token based on the correspondence. For the manner in which the terminal stores the above correspondences, see the description of the following in step A1: The terminal stores a correspondence between a random number and a first service and / or a first user. The terminal stores a correspondence between a random number and authorization information other than the indication information for the first service and the indication information for the first user. The random number is simply replaced with an authorization code. Further details are not described herein.

[0174] An authorization code may correspond to one or more tokens, and it should be understood that one or more tokens include a first token. In some examples, a first device may determine one or more tokens based on the authorization code and trigger the revocation of each of the one or more tokens. The following describes how a first device determines one or more tokens, using a first token as an example. For example, the first device stores correspondence #3 between an authorization code and a first token. After receiving an authorization code, the first device may determine the first token based on the authorization code and correspondence #3. In some other examples, a first request in S302 includes an authorization code and indication information for a first service. The first device determines one or more tokens based on the authorization code, and the first device selects the token among the one or more tokens that corresponds to the indication information for a first service as the first token and triggers the revocation of the first token.

[0175] In method a3, the terminal can initiate a first token revocation procedure based on the authorization code. In this way, the user can control the terminal by using the user agent on the terminal to initiate the first token revocation procedure, and thus the revocation procedure is authorized by the user, thereby preventing the interruption of a service desired by the user due to authorization revocation, i.e., preventing a denial of service to the user.

[0176] Embodiments of this application provide 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 a procedure to revoke the first token based on the random number. See the flowcharts shown in Figures 4 and 5. The procedure of this method will be described in particular below using an example in which the first device is AzF and the second device is an API invoker.

[0177] Figure 4 shows the method for applying for the first token. This method includes the following steps:

[0178] S401: The API invoker sends an authorization request to the user agent on the terminal.

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

[0180] S402: The user agent sends an authorization request to AzF.

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

[0182] Message #a1 is used to request confirmation from the first user whether they consent to the authorization of the first service to the first user. Optionally, message #a1 may include the requested authorization scope.

[0183] S404: The user agent detects a first action by a first user, and the first action may indicate that the first user consents to authorizing a first service to the first user.

[0184] For specific details regarding the detection of the first action of the first user by the user agent, please refer to step A1. Further details will not be described again in this specification.

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

[0186] For specific details of S405, please refer to step B1. Further details are not provided in this specification.

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

[0188] Message #a2 indicates that the first user consents to the authorization of the first service to the first user. Message #a2 further contains second information.

[0189] S407: AzF associates the second piece of information with the authorization code corresponding to the first token. Optionally, AzF may store the correspondence between the second piece of information and the authorization code.

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

[0191] The execution sequences of S407 and S408 are not limited in this application.

[0192] S409: The user agent sends an authorization code to the API invoker.

[0193] S410: The API invoker sends request #a1 to AzF.

[0194] Request #a1 may contain an authorization code and be used to request the acquisition of the first token.

[0195] S411:AzF sends the first token to the API inviter.

[0196] For specific details regarding S401 through S404, S406, and S408 through S411, please refer to the explanation of the token application procedure in the IETF standard.

[0197] S407 is an optional step. For example, after S410, the method shown in Figure 4 further includes S412: AzF associates the second piece of information with the first token. Optionally, AzF may store the correspondence between the second piece of information and the first token. The execution sequence of S411 and S412 is not limited in this application. When the method shown in Figure 4 includes S412, the method shown in Figure 4 may not include S407.

[0198] According to the method shown in Figure 4, the user agent may generate random numbers and second information, and AzF may associate the second information with the first token or the authorization code corresponding to the first token.

[0199] Figure 5 shows a method for revoking the first token. This method includes the following steps:

[0200] S501: The user agent stores a random number.

[0201] Random numbers may be generated by the user agent in S405.

[0202] Optionally, the user agent in the terminal may further store indication information for the first user. For specific details of the indication information for the first user, see the description of the indication information for the first user in S302. Further details are not described again in this specification.

[0203] S502: After detecting the first user action required to activate the user agent, the terminal starts the user agent.

[0204] Step S502 is optional. For example, if the user agent is already running, the method shown in Figure 5 does not need to include S502.

[0205] S503: The user agent sends a cancellation request #a1 containing a random number to AzF.

[0206] Cancellation request #a1 may also be the first request in S302. For S503, please refer to S302. No repetition is provided.

[0207] S504: AzF determines the first token based on a random number.

[0208] For specific details of S504, please refer to Method b2. Further details are not provided in this specification.

[0209] S505: AzF sends revocation request #a2 to AEF, which is used to request the release of the resource corresponding to the first token.

[0210] In some examples, revocation request #a2 may include information from the first token. For example, revocation request #a2 may include at least one of the pieces of information from the first token, such as service indication information and claim information such as scope. In this way, after receiving revocation request #a2, AEF may determine that revocation request #a2 is used to request the release of the resource corresponding to the first token.

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

[0212] S506: AEF is triggered to release the resource corresponding to the first token.

[0213] The specific processes that trigger the AEF to release the resources corresponding to the first token are not limited to those described herein.

[0214] S507: AEF sends cancellation response #a2 to AzF.

[0215] Cancellation response #a2 is a response message to cancellation request #a2, indicating one of the following: that the release of the resource corresponding to the first token was successful or triggered, or that cancellation request #a2 was received.

[0216] S508:AzF sends a revocation notice to the API invoker, which may indicate one of the following: that the first token has been successfully revoked, that the procedure to revoke the first token has been triggered, or that revocation request #a2 has been received.

[0217] The cancellation notice may also be the notification message in step B5. For the specific content of S508, please refer to step B5. Further details are not provided herein.

[0218] Optionally, after receiving a revocation notice, the API invoker may update the token database, for example, by identifying the first token in the token database as revoked.

[0219] S509: AzF sends cancellation response #a1 to the user agent.

[0220] Cancellation response #a1 is a response message to cancellation request #a1, indicating one of the following: that the first token has been successfully canceled, that the procedure for canceling the first token has been triggered, or that cancellation request #a1 has been received. Cancellation response #a1 may also be the first response in step B4. For the specific content of S509, see step B4. Further details are not described herein.

[0221] The execution sequences of S508 and S509 are not limited in this application.

[0222] S509 is an optional step.

[0223] According to the method shown in Figures 4 and 5, the user agent may initiate a revocation procedure for the first token based on a random number, thereby authorizing the revocation procedure by the user. In addition, AzF associates 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 expects to revoke can be revoked, thereby preventing the interruption of services desired by the user due to authorization revocation, i.e., preventing a denial of service to the user. Furthermore, in this method, the random number used to initiate the revocation procedure for the first token may be generated by the terminal and protected via a one-way function. In this way, third-party applications or AFs on the terminal cannot obtain information related to the random number and therefore cannot initiate a revocation procedure for the first token, thus improving the security of the token revocation procedure.

[0224] Embodiments of this application provide another communication method. This method 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 a procedure to revoke the first token based on the auxiliary information. See the flowcharts shown in Figures 6 and 7. The procedure of this method will be described in particular below by using an example in which the first device is an AzF or API invoker.

[0225] Figure 6 shows the method for applying for the first token. This method includes the following steps:

[0226] S601: The API invoker sends an authorization request to the user agent on the terminal.

[0227] S602: The user agent sends an authorization request to AzF.

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

[0229] S604: The user agent detects a first action by a first user, and the first action may indicate that the first user consents to authorizing a first service to the first user.

[0230] For specific details of S601 to S604, please refer to S401 to S404. Further details are not provided in this specification.

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

[0232] For specific details regarding the supplementary information, please refer to the explanation of supplementary information in Method a2. Further details will not be provided in this specification.

[0233] The execution sequence of S605 and S604 is not limited in this application. For example, S605 may be executed before S604 (after S603 has been executed). Note that the advantage of storing auxiliary information after S605 is that the token corresponding to the auxiliary information has been authorized by the user. For auxiliary information stored before S604, the token application corresponding to the auxiliary information has not been authorized by the user. Optionally, if the user agent detects after the auxiliary information has been stored that the user does not consent to authorizing the first service to the first user, the user agent may delete the stored auxiliary information.

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

[0235] Message #a2 indicates that the first user consents to the authorization of the first service to the first user.

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

[0237] S608: The user agent checks the supplementary information based on the authorization code.

[0238] In particular, after receiving an authorization code corresponding to the first token, the user agent may confirm that the authorization code was successfully obtained in response to the token request corresponding to the auxiliary information, and the auxiliary information stored in S605 may continue to be retained. Optionally, if the user agent does not receive an authorization code within a specified time, the user agent may delete the auxiliary information stored in S605. The specified time may be pre-configured, determined by the user agent, or set for the user agent by the network. This is not limited to the present application.

[0239] S608 is an optional step.

[0240] S609: The user agent sends an authorization code to the API invoker.

[0241] The execution sequences of S608 and S609 are not limited in this application.

[0242] S610: The API Invoker sends request #a1 to AzF.

[0243] Request #a1 may contain an authorization code and be used to request the acquisition of the first token.

[0244] S611:AzF sends the first token to the API inviter.

[0245] For specific details regarding S601 through S604, S606 and S607, and S609 through S611, please refer to the explanation of the token application procedure in the IETF standard.

[0246] According to the method shown in Figure 6, the user agent may store auxiliary information used to identify the first token.

[0247] Figure 7 shows a method for revoking the first token. This method includes the following steps:

[0248] S701: After detecting the first user action required to activate the user agent, the terminal starts the user agent.

[0249] For specific details of S701, please refer to S502. Further details are not provided in this specification.

[0250] S702: Establish a secure channel between the user agent and the API invoker.

[0251] For example, the user agent may be a web browser, and a transport layer security (TLS) channel may be established between the user agent and the API invoker. The TLS channel may also be a hypertext transfer protocol secure (HTTPS) channel.

[0252] Step S702 is optional. For example, if the communication between the user agent and the API invoker is secure or protected in another way, the method shown in Figure 7 may not include S702.

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

[0254] Cancellation request #b1 may be the first request in S302. Correspondingly, see S302 for S703. Further details are not provided herein.

[0255] In implementation a1, the first device may be an API invoker. Following S703, the method shown in Figure 7 includes S704 and S705.

[0256] S704: The API invoker determines the first token based on the auxiliary information.

[0257] For specific details of S704, please refer to Method a2. Further details are not provided in this specification.

[0258] S705: The API Invoker sends cancellation request #b2 to AzF.

[0259] A revocation request #b2 may include the first token and / or indication information for the first token and may be used to request the revocation of the first token. After receiving a revocation request #b2, AzF may revoke the first token. The specific process by which AzF revoks the first token is not limited in this application.

[0260] In implementation a2, the first device may be AzF. Following S703, the method shown in Figure 7 includes S706 and S707.

[0261] S706: The API invoker sends a cancellation request #b1, including supplementary information, to AzF.

[0262] S707:AzF determines the first token based on the supplementary information.

[0263] For specific details of S707, please refer to Method a2. Further details are not provided in this specification.

[0264] After determining the first token, AzF may revoke the first token. The specific process by which AzF revokes the first token is not limited in this application.

[0265] Following S705 or S707, the method shown in Figure 7 further includes S708.

[0266] S708: AzF sends a revocation response #b1 to the API invoker, which may indicate one of the following: that the first token has been successfully revoked, that the procedure for revoking the first token has been triggered, or that a revocation request (for example, revocation request #b2 in S705 or revocation request #b1 in S706) used to request the revocation of the first token has been received.

[0267] Optionally, after receiving revocation response #b1, the API invoker may update the token database, for example, by identifying the first token in the token database as revoked.

[0268] In some possible scenarios, the API invoker may further forward the cancellation response #b1 to the user agent.

[0269] According to the methods shown in Figures 6 and 7, the user agent may initiate a first token revocation procedure based on auxiliary information, and the revocation procedure is authorized by the user, thereby preventing the interruption of a service desired by the user due to the revocation of authorization, i.e., preventing a denial of service to the user.

[0270] Embodiments of this application provide another communication method. This method is another possible example of the method shown in Figure 3. In this method, the first information is an authorization code, and a user agent can initiate a procedure to revoke the first token based on the authorization code. See the flowcharts shown in Figures 8 and 9. The procedure of this method will be described in particular below by using an example in which the first device is an AzF or an API invoker.

[0271] Figure 8 shows the method for applying for the first token. This method includes the following steps:

[0272] S801: The API invoker sends an authorization request to the user agent on the terminal.

[0273] S802: The user agent sends an authorization request to AzF.

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

[0275] S804: The user agent detects a first action by a first user, and the first action may indicate that the first user consents to authorizing a first service to the first user.

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

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

[0278] For specific details of S801 to S806, please refer to S401 to S404 and S606 and S607. Further details are not provided in this specification.

[0279] S807: The user agent remembers the authorization code.

[0280] S808: the user agent sends an authorization code to the API invoker.

[0281] The execution sequence of S807 and S808 is not limited in the present application.

[0282] S809: the API invoker sends request #a1 to AzF.

[0283] S810: AzF sends the first token to the API invoker.

[0284] For specific content from S808 to S810, please refer to S609 to S611. Details will not be repeated herein.

[0285] For specific content from S801 to S806 and from S808 to S810, please refer to the description of token application procedures in IETF standards.

[0286] According to the method shown in FIG. 8, the user agent can store the authorization code corresponding to the first token.

[0287] FIG. 9 shows a method for revoking the first token. The method includes the following steps.

[0288] S901: after detecting a first user operation for running the user agent, a terminal starts the user agent.

[0289] For specific content of S901, please refer to S502. Details will not be repeated herein.

[0290] Optionally, the user agent may further store indication information of the first user. For specific content of the indication information of the first user, please refer to the description of the indication information of the first user in S302. Details will not be repeated herein.

[0291] S902: Establish a secure channel between the user agent and the API invoker.

[0292] For specific details of S902, please refer to S702. Further details are not provided herein.

[0293] S903: The user agent sends a revocation request #c1 containing the authorization code to the API invoker.

[0294] Cancellation request #c1 may be the first request in S302. For S903, see S302. Further details are not provided herein.

[0295] In implementation b1, the first device may be an API invoker. Following S903, the method shown in Figure 9 includes S904 and S905.

[0296] S904: The API invoker determines the first token based on the verification code.

[0297] For specific details of S904, please refer to Method a3. Further details are not provided in this specification.

[0298] S905: The API Invoker sends a cancellation request #c2 to AzF.

[0299] For specific details of S905, please refer to S705. Further details are not provided in this specification.

[0300] In implementation b2, the first device may be AzF. Following S903, the method shown in Figure 9 includes S906 and S907.

[0301] S906: The API invoker sends revocation request #c1, which includes the authorization code, to AzF.

[0302] S907: AzF determines a first token based on the authorization code.

[0303] For the specific content of S907, refer to mode a3. Details will not be repeated herein.

[0304] After determining the first token, AzF may revoke the first token. The specific process for AzF to revoke the first token is not limited in the present application.

[0305] After S905 or S907, the method shown in FIG. 9 further includes S908.

[0306] S908: AzF sends a revocation response #c1 to an API invoker, where the revocation response #c1 may indicate one of the following: the first token has been successfully revoked; the procedure for revoking the first token has been triggered; or a revocation request used to request revocation of the first token (for example, revocation request #c2 in S905 or revocation request #c1 in S906) has been received.

[0307] For the specific content of S908, refer to S708, which differs only in that revocation response #b1 is replaced with revocation response #c1. Details will not be repeated herein.

[0308] According to the methods shown in FIG. 8 and FIG. 9, the user agent may initiate the revocation procedure for the first token based on the authorization code, therefore the revocation procedure is authorized by the user, thereby avoiding interruption of a service desired by the user resulting from authorization revocation, that is, avoiding denial of service to the user.

[0309] Embodiments of this application provide another communication method. Figure 10 is a schematic flowchart corresponding to the communication method according to embodiments of this application. In Figure 10, the method is illustrated by using an example in which the terminal and the third device are the execution body of the interaction illustration. However, the execution body of the interaction illustration is not limited in this application. The third device may be an AzF, or a module used in the AzF, such as a chip, chip system, or processor, or a logical node, logical module, or software capable of implementing all or some of the functions of the AzF. Optionally, the terminal in Figure 10 may be replaced with a user agent.

[0310] S1001: The terminal sends a third request, and in response, the third device receives the third request.

[0311] A third request may include indication information for the first service and may be used to request the revocation of the authorization for the first service. For specific details of the indication information for the first service, see “Service Indication Information” in the glossary above. Further details are not provided herein.

[0312] For the method by which the terminal sends the third request, please refer to the method by which the terminal sends the first request in S302. The only difference is that the first device is replaced by the third device, and the first request is replaced by the third request. Further details will not be explained again in this specification.

[0313] S1002: The third device sends third information, and in response, the terminal receives the third information.

[0314] The third piece of information may indicate that the authorization to be revoked is the first authorization that permits the first user to use the first service. For example, the third piece of information may include indication information for the first service, which is contained in a specified field or message. In this way, when the terminal parses the indication information for the first service from the specified field or message, the terminal may determine that the authorization to be revoked is the first authorization that permits the first user to use the first service.

[0315] For the method by which the third device sends the third information, please refer to the method by which the first device sends the first response in step A4. The only difference is that the first device is replaced by the third device and the first response is replaced by the third information. Further details will not be explained again in this specification.

[0316] S1003: The terminal detects a second action by the first user, and the second action may indicate that the first user consents to the revocation of the first authorization.

[0317] After receiving the third piece of information, the terminal may ask the first user whether they agree to the revocation of the first authorization. For example, after receiving the third piece of information, the terminal displays a pop-up window #2. Pop-up window #2 includes a display area asking "Do you agree to the revocation of the authorization for the first service to the first user?" and "Yes" and "No" action areas. The second action may include a touchscreen operation performed by the first user on the "Yes" action area.

[0318] S1004: The terminal sends the fourth piece of information, and in response, the third device receives the fourth piece of information.

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

[0320] For the method by which the terminal sends the fourth piece of information, please refer to the method by which the terminal sends the first request in S302. The only difference is that the first device is replaced by the third device and the first request is replaced by the fourth piece of information. Further details will not be explained again in this specification.

[0321] S1005: The third device sends the fifth piece of information, and in response, the API Invocer receives the fifth piece of information.

[0322] The fifth piece of information is the information used to revoke the first authorization. Optionally, the fifth piece of information is the second token.

[0323] In some examples, the type of the second token is a revoked token. Field #1 in the second token may relate to the first authorization. For example, the first token is a token for authorizing a first user to a first service, and field #1 in the second token is the indication information for the first token. In this way, after receiving the second token, the API invoker may decide that the first authorization should be revoked based on the indication information for the first token in field #1.

[0324] In some other examples, the value of the first field in the second token is a specified value. The specified value is, for example, a null value or another value. For example, the type of the second token is an access token. Field #1 in the second token relates to the first authorization, and the value of the first field in the second token is a specified value. In this way, after receiving the second token, the API invoker may decide that the first authorization should be revoked based on field #1 and the first field.

[0325] Steps S1001 and S1005 are optional steps.

[0326] According to the method shown in Figure 10, the terminal will only trigger the revocation of the first authorization, i.e., talk, after the second action of the first user has been detected. Cancellation A fourth piece of information is sent to trigger the procedure, thereby preventing the interruption of services desired by the user due to the revocation of authorization, i.e., preventing a denial of service to the user.

[0327] Embodiments of this application provide another communication method. This method is a possible example of the method shown in Figure 10. Please refer to the flowchart shown in Figure 11. The procedure of this method will be described in particular below by using an example in which the first device is AzF.

[0328] S1101: After detecting the first user action required to activate the user agent, the terminal starts the user agent.

[0329] For specific details of S1101, please refer to S502. Further details are not provided in this specification.

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

[0331] Revocation request #d1 contains indication information for the first service and is used to request the revocation of the first authorization for the first service.

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

[0333] Revocation request #d2 contains indication information for the first service and is used to request the revocation of the first authorization for the first service.

[0334] S1104: The user agent sends a cancellation request #d2 to AzF.

[0335] Cancellation request #d2 may be the third request in S1001. For the specific details of S1104, please refer to S1001. Further details are not provided herein.

[0336] S1105: AzF sends a third piece of information to the user agent.

[0337] For specific details of S1105, please refer to S1002. Further details are not provided in this specification.

[0338] S1106: The user agent detects a second action by the first user, and the second action may indicate that the first user consents to the revocation of the authorization for the first service to the first user.

[0339] S1107: The user agent sends a fourth piece of information to AzF.

[0340] For specific details of S1107, please refer to S1004. Further details are not provided in this specification.

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

[0342] For specific details regarding the second token, please refer to the description of the second token in S1005. Further details are not provided herein.

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

[0344] S1110: The API invoker sends request #d1 to AzF. Request #d1 contains an authorization code corresponding to a second token and may be used to request the acquisition of a second token.

[0345] S 1108 Step S1110 is an optional step.

[0346] S1111:AzF sends a second token to the API inviter.

[0347] S1112: The API inviter sends a second token to the AEF.

[0348] S1113: AEF revokes the first authorization based on the second token and releases the resources corresponding to the first authorization.

[0349] According to the method shown in Figure 11, the user agent may initiate an authorization revocation procedure based on the second token, and the revocation procedure is therefore authorized by the user, thereby preventing the interruption of a service desired by the user due to authorization revocation, i.e., preventing a denial of service to the user.

[0350] Based on the same technical concepts as the method embodiments described above, embodiments of this application provide a communication device shown in Figure 12 that can be configured to perform the functions of the relevant steps in the method embodiments described above. The functions can be implemented by hardware, by software, or by the hardware running corresponding software. The hardware or software includes one or more modules corresponding to the functions described above. The structure of the communication device is shown in Figure 12 and includes an interface unit 1201 and a processing unit 1202. The communication device 1200 may be a terminal, an API invoker, an API invoker-inclusive device (e.g., a terminal or AF), or an AzF, or a module used in a terminal, an API invoker, an API invoker-inclusive device, or an AzF, e.g., a chip, a chip system, or a processor, or a logical node, logical module, or software that can implement all or part of the functions of a terminal, an API invoker, an API invoker-inclusive device, or an AzF. In addition, the communication device 1200 may implement the communication methods provided in the embodiments and examples described above. The functions of the units in the communication device 1200 are described below.

[0351] The interface unit 1201 is configured to input and / or output information. When outputting information, the interface unit 1201 may output information to a device other than the communication device 1200, or to another unit within the communication device 1200. In some schemes, the interface unit 1201 may be implemented by using at least one of a physical interface, a communication module, a communication interface, and an input / output interface. In some other schemes, the interface unit 1201 may be implemented by using an interface circuit, such as a mobile communication module. The mobile communication module may include at least one antenna, at least one filter, one or more switches, a power amplifier, a low noise amplifier (LNA), etc.

[0352] The processing unit 1202 may be configured to support the communication device 1200 when performing the processing actions in the above-described embodiment of the method. The processing unit 1202 may be implemented by using a processor. For example, the processor may be a central processing unit (CPU), or another general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or another programmable logic device, a transistor logic device, a hardware component, or any combination thereof. The general-purpose processor may be a microprocessor, or any conventional processor, etc.

[0353] In the implementation, the communication device 1200 is used in the terminal in the embodiment of this application shown in Figure 3. The specific functions of the processing unit 1202 in this implementation will be described below.

[0354] The processing unit 1202 is configured to determine a first piece of information, which is used to determine a first token, which is a token for authorizing a first service to a first user, and to send a first request through the interface unit 1201, which includes the first piece of information, and which is used to request the revocation of the first token.

[0355] In some possible configurations, the processing unit 1202 is further configured to receive a first response through the interface unit 1201, the first response indicating one of the following: that the first token has been successfully revoked, that a procedure to revoke the first token has been triggered, or that the first request has been received, the first response containing a random number or second information, the second information being obtained based on a one-way function and a random number.

[0356] In some other possible configurations, the processing unit 1202 is further configured to generate a random number and a second piece of information, the second piece of information being obtained based on a one-way function and the random number, and to send the second piece of information to an authorization function network element through the interface unit 1201, the second piece of information being corresponding to a first token.

[0357] Optionally, the processing unit 1202 is further configured to detect a first operation of a first user before generating random numbers and second information, the first operation indicating that the first user consents to authorizing a first service to the first user.

[0358] In some examples, the processing unit 1202 is further configured to detect a first operation of a first user, the first operation being an indication that the first user consents to authorization of a first service to the first user, and to acquire and store auxiliary information.

[0359] In some possible configurations, the processing unit 1202 is further configured to receive an authorization code corresponding to a first token through the interface unit 1201, and 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.

[0360] In some other possible configurations, the processing unit 1202 is further configured to receive an authorization code corresponding to a first token from an authorization function network element via the interface unit 1201.

[0361] Optionally, the processing unit 1202 may be further configured to send a first request to an authorization function network element based on the address information of the authorization function network element via the interface unit 1201, or to send a first request to an authorization function network element via an application programming interface invoker.

[0362] In another implementation, the communication device 1200 is used in the first device in the embodiment of this application shown in Figure 3. The specific functions of the processing unit 1202 in this implementation are described below.

[0363] The processing unit 1202 is configured to receive a first request from a terminal through the interface unit 1201, wherein 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 a first token, and the first token is a token for authorizing a first service to a first user, and to determine a first token based on the first request.

[0364] In some possible configurations, the processing unit 1202 is further configured to send a first response to the terminal through the interface unit 1201, the first response indicating that the first token has been successfully revoked, that a procedure to revoke the first token has been triggered, or that the first request has been received, the first response containing a random number or second information, the second information being obtained based on a one-way function and a random number.

[0365] Optionally, the processing unit 1202 is further configured to receive second information from a terminal via the interface unit 1201, the second information being obtained based on a one-way function and random numbers, and to associate the second information with a first token.

[0366] In some possible configurations, the processing unit 1202 is further configured to send a notification message to an application programming interface invoker via the interface unit 1201, the notification message indicating one of the following: that a first token has been successfully revoked, that a procedure to revoke a first token has been triggered, or that a first request has been received, and the notification message includes indication information for the first token.

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

[0368] For example, the processing unit 1202 is further configured to revoke the first token or send a second request to an authorization function network element through the interface unit 1201, the second request being used to request the revocation of the first token.

[0369] In some possible configurations, the processing unit 1202 is further configured to receive a first request sent by a terminal based on address information of an authorization function network element via the interface unit 1201, or to receive a first request from a terminal via an application programming interface invoker.

[0370] In another implementation, the communication device 1200 is used in the terminal in the embodiment of this application shown in Figure 10. The specific functions of the processing unit 1202 in this implementation are described below.

[0371] The processing unit 1202 is configured to: receive third information through the interface unit 1201, the third information indicating that the authorization to be revoked is a first authorization that permits a first user to use a first service; detect a second operation by the first user, the second operation indicating that the first user consents to the revocation of the first authorization; and send fourth information through the interface unit 1201, the fourth information being used to trigger the revocation of the first authorization.

[0372] In some possible configurations, the processing unit 1202 is further configured to send a third request through the interface unit 1201 before receiving the third information, the third request containing indication information for the first service.

[0373] In another implementation, the communication device 1200 is used in a third device in the embodiment of this application shown in Figure 10. The specific functions of the processing unit 1202 in this implementation are described below.

[0374] The processing unit 1202 is configured to: send third information to the terminal through the interface unit 1201, the third information indicating that the authorization to be revoked is a first authorization that permits a first user to use a first service; and receive fourth information sent by the terminal through the interface unit 1201 based on a second operation of the first user, the second operation indicating that the first user consents to the revocation of the first authorization, and the fourth information being used to trigger the revocation of the first authorization.

[0375] In some possible configurations, the processing unit 1202 is further configured to receive a third request from a terminal through the interface unit 1201, the third request including indication information for the first service.

[0376] In some examples, the processing unit 1202 is further configured to send a fifth piece of information to the application programming interface invoker via the interface unit 1201, which is used to revoke the first authorization.

[0377] For a more detailed description of the processing unit 1202 and the interface unit 1201, please refer directly to the relevant descriptions in the method embodiments shown in Figures 3 and 5. Further details will not be described again in this specification.

[0378] It should be noted that the modularization in the above embodiments of this application is illustrative and merely a logical functional division. Other division methods may be used in actual implementations. In addition, the functional units in the embodiments of this application may be integrated into a single processing unit, exist physically independently, or two or more units may be integrated into a single unit. The integrated unit may be implemented in hardware form or in the form of a software functional unit.

[0379] When an integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, the integrated unit may be stored on a computer-readable storage medium. Based on such understanding, the technical solution of this application may be implemented in the form of a software product, either in essence, in part, or in part, of the prior art. A computer software product includes several instructions for instructing a computer device or processor (which may be a personal computer, server, or network device) to carry out all or part of the steps of the method described in the embodiments of this application, which are stored on a storage medium. The storage medium includes any medium capable of storing program code, such as a USB flash drive, removable hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0380] Based on the same technical concept, embodiments of the present application provide a communication device shown in Figure 13, which can be configured to carry out the relevant steps in the method embodiments described above. The communication device may be a terminal, an API invoker, an API invoker-inclusive device (e.g., a terminal or AF), or an AzF, or a module used in a terminal, an API invoker, an API invoker-inclusive device, or an AzF, e.g., a chip, a chip system, or a processor, or a logical node, logical module, or software capable of implementing all or part of the functions of a terminal, an API invoker, an API invoker-inclusive device, or an AzF. In addition, the communication device may implement the communication methods provided in the embodiments and examples described above, and may have the functions of the communication device shown in Figure 12. As shown in Figure 13, the communication device 1300 includes a processor 1302. Optionally, the communication device 1300 further includes an interface circuit 1301 and a memory 1303. The interface circuit 1301, the processor 1302, and the memory 1303 are coupled to each other.

[0381] Optionally, the interface circuit 1301, processor 1302, and memory 1303 are coupled to each other via bus 1304. Bus 1304 may be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, or the like. Buses can be classified into address buses, data buses, control buses, etc. For ease of representation, only one thick line is used for representation in Figure 13, but this does not mean that there is only one bus or only one type of bus.

[0382] The interface circuit 1301 is configured to input and / or output information. When outputting information, the interface circuit 1301 may output information to a device other than the communication device 1300, or to another unit within the communication device 1300. For example, the interface circuit 1301 may be implemented by using at least one of the following: a physical interface, a communication module, a communication interface, an input / output interface, and a mobile communication module. The mobile communication module may include at least one antenna, at least one filter, a switch, a power amplifier, an LNA, and one or more others.

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

[0384] In the implementation, the communication device 1300 is used in the terminal in the embodiment of this application shown in Figure 3. Specific functions of the processor 1302 in this implementation are described below.

[0385] The processor 1302 is configured to determine a first piece of information, which is used to determine a first token, which is a token for authorizing a first service to a first user; and to send a first request through the interface circuit 1301, which includes the first piece of information, and which is used to request the revocation of the first token.

[0386] In another implementation, the communication device 1300 is used in the first device in the embodiment of this application shown in Figure 3. Specific functions of the processor 1302 in this implementation are described below.

[0387] The processor 1302 is configured to receive a first request from a terminal through the interface circuit 1301, wherein 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 a first token, the first token is a token for authorizing a first service to a first user, and to determine a first token based on the first request.

[0388] In another implementation, the communication device 1300 is used in the terminal in the embodiment of this application shown in Figure 10. Specific functions of the processor 1302 in this implementation are described below.

[0389] The processor 1302 is configured to: receive third information through the interface circuit 1301, the third information indicating that the authorization to be revoked is a first authorization that permits a first user to use a first service; detect a second operation by the first user, the second operation indicating that the first user consents to the revocation of the first authorization; and send fourth information through the interface circuit 1301, the fourth information being used to trigger the revocation of the first authorization.

[0390] In another implementation, the communication device 1300 is used in a third device in the embodiment of this application shown in Figure 10. Specific functions of the processor 1302 in this implementation are described below.

[0391] The processor 1302 is configured to: send third information to a terminal through interface circuit 1301, the third information indicating that the authorization to be revoked is a first authorization that permits a first user to use a first service; and receive fourth information sent by the terminal through interface circuit 1301 based on a second operation of the first user, the second operation indicating that the first user consents to the revocation of the first authorization, and the fourth information being used to trigger the revocation of the first authorization.

[0392] For specific functions of processor 1302, please refer to the description of the communication methods provided in the above embodiments and examples of this application, and the description of specific functions of the communication device 1200 in the embodiments of this application shown in Figure 12. Further details are not described herein.

[0393] Memory 1303 is configured to store program instructions, data, and the like. In particular, program instructions may include program code, and program code may include computer operation instructions. Memory 1303 may include RAM and may further include non-volatile memory, such as at least one magnetic disk memory. Processor 1302 executes program instructions stored in memory 1303 and uses the data stored in memory 1303 to implement the above functions, thereby implementing the communication method provided in the above embodiments of this application. Memory 1303 may be integrated with processor 1302 or may be an external memory of the communication device.

[0394] The memory 1303 in Figure 13 of this application may be volatile memory or non-volatile memory, or may be understood to include both volatile and non-volatile memory. The non-volatile memory may be ROM, programmable ROM (PROM), eraseable 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 and function as an external cache. Many forms of RAM are available, not as an example but as an example, such as static random access memory (Static RAM, SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (Synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (Double Data Rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (Enhanced SDRAM, ESDRAM), synchlink dynamic random access memory (Synchlink DRAM, SLDRAM), and direct rambus random access memory (Direct Rambus RAM, DR RAM). It should be noted that the memories for the systems and methods described herein are intended to include, but are not limited to, these memories and any other suitable type of memory.

[0395] Based on the embodiments described above, embodiments of this application further provide a computer program product including computer executable instructions. When the computer program product is run, the method provided in the embodiments described above is carried out.

[0396] Based on the embodiments described above, embodiments of this application further provide a computer-readable storage medium. The computer-readable storage medium stores a computer program. When the computer program is executed by a computer, the computer becomes capable of carrying out the methods provided in the embodiments described above.

[0397] The storage medium may be any available medium that can be accessed by a computer. Computer-readable medium may include, but not limited to, computer-readable medium, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store expected program code in the form of instructions or data structures and that can be accessed by a computer.

[0398] Based on the embodiments described above, embodiments of this application further provide a chip configured to read a computer program stored in memory and implement the method provided in the embodiments described above.

[0399] Based on the embodiments described above, embodiments of this application provide a chip system. The chip system includes a processor configured to support a computer device in implementing the functions related to the device in the embodiments described above. In possible designs, the chip system further includes memory, which is configured to store programs and data required by the computer device. The chip system may include a chip, or it may include a chip and other separate components.

[0400] In the embodiments of this application, unless otherwise stated or unless there is a logical inconsistency, the terminology and / or descriptions between different embodiments are consistent and may refer to one another, and technical features in different embodiments may be combined into new embodiments based on their internal logical relationships.

[0401] Those skilled in the art should understand that embodiments of this application may be provided as methods, systems, or computer program products. Accordingly, this application may take the form of hardware-only embodiments, software-only embodiments, or embodiments combining software and hardware aspects. In addition, this application may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, magnetic disk memory, CD-ROM, optical memory, etc.) that includes computer-usable program code.

[0402] This application is described with reference to flowcharts and / or block diagrams of the methods, devices (systems), and computer program products described herein. Computer program instructions may be used to implement each of the processes and / or blocks in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams. These computer program instructions may be provided to a general-purpose computer, a dedicated computer, an embedded processor, or a processor of another programmable data processing device to generate a machine, where the instructions executed by the computer or the processor of the other programmable data processing device generate a machine for implementing a particular function in one or more processes in the flowchart and / or one or more blocks in the block diagram.

[0403] These computer program instructions may, alternatively, be stored in computer-readable memory that can be directed to a computer or another programmable data processing device to operate in a specific manner, thereby generating an artifact that includes an instruction unit. The instruction unit implements one or more processes in a flowchart and / or one or more blocks in a block diagram.

[0404] These computer program instructions may, alternatively, be loaded onto a computer or another programmable data processing device, thereby performing a series of operations and steps on the computer or other programmable device to generate a computer implementation. Thus, instructions executed on the computer or other programmable device provide steps for implementing specific functions in one or more processes in a flowchart and / or in one or more blocks in a block diagram.

[0405] In the embodiments of this application, unless otherwise stated or unless there is a logical inconsistency, the terminology and / or descriptions between different embodiments are consistent and may refer to one another, and technical features in different embodiments may be combined into new embodiments based on their internal logical relationships.

[0406] In this application, “at least one” means one or more, and “multiple” means two or more. The term “and / or” describes the relationship between the associated objects and indicates that three relationships may exist. For example, A and / or B may indicate three cases: only A exists, both A and B exist, and only B exists. A and B may be singular or plural. In the textual descriptions of this application, the character “ / ” usually indicates an “or” relationship between the associated objects.

[0407] The various numbers in the embodiments of this application are used solely for illustrative purposes and not to limit the scope of the embodiments. The sequence numbers of the processes described above do not imply a sequence of execution. The sequence of execution of the processes should be determined according to the function and internal logic of the processes.

[0408] It is clear that a person skilled in the art can make various modifications and alterations to this application without departing from its scope. Therefore, this application is intended to encompass such modifications and alterations, provided that they fall within the scope of the claims of this application and the equivalent art thereto.

Claims

1. A step of determining first information by a terminal, wherein the first information is used to determine a first token, and the first token is a token for authorizing a first service to a first user. The steps include: sending a first request by the terminal, wherein the first request includes the first information, and the first request is used to request the revocation of the first token; A communication method that includes this.

2. The method according to claim 1, wherein 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, wherein the random number is used to determine a second piece of information via a one-way function, and the second piece of information is used to determine the first token.

4. The step of receiving a first response from the terminal, the first response indicating one of the following: that the first token has been successfully revoked, that a procedure for revoking the first token has been triggered, or that the first request has been received, and the first response includes the random number or the second information, the second information being obtained based on the one-way function and the random number. The method according to claim 2 or 3, further comprising:

5. A step of generating the random number and the second information using the terminal, wherein the second information is obtained based on the one-way function and the random number, The steps include: sending the second information to an authorization function network element via the terminal, wherein the second information corresponds to the first token; The method according to any one of claims 2 to 4, further comprising:

6. Before the step of generating the random number and the second information by the terminal, A step of detecting a first operation of the first user by the terminal, wherein the first operation indicates that the first user consents to authorizing the first service to the first user. The method according to claim 5, further comprising:

7. The method according to claim 1, wherein the first information includes auxiliary information used to identify the first token.

8. The aforementioned auxiliary information is, Information used to identify the authorization scope of the first token, Information used to identify the service application programming interface corresponding to the first token, Information used to identify the authorization function network element corresponding to the first token, Information used to identify the first user, Information used to identify the application programming interface exposure function corresponding to the first token, Information used to identify the validity period of the first token, and Information used to identify the issuance time of the first token, The method according to claim 7, comprising at least one of the following.

9. The steps include detecting a first operation of the first user using the terminal, wherein the first operation indicates that the first user consents to authorizing the first service to the first user, The terminal acquires and stores the auxiliary information, The method according to claim 7 or 8, further comprising:

10. The step of receiving an authorization code corresponding to the first token by the terminal, wherein 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. The method according to claim 9, further comprising:

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

12. The terminal receives the authorization code corresponding to the first token from the authorization function network element. The method according to claim 11, further comprising:

13. The method according to claim 11 or 12, wherein the first request further 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 step of sending the first request by the terminal is: The terminal sends the first request to the authorization function network element based on the address information of the authorization function network element, or The terminal sends the first request to the authorization function network element through the application programming interface invoker. A method according to any one of claims 1 to 13, comprising at least one of the following.

15. A step of receiving a first request from a terminal, wherein 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 for authorizing a first service to a first user, A step of determining the first token based on the first request, A communication method that includes this.

16. The method according to claim 15, wherein 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, wherein the random number is used to determine a second piece of information via a one-way function, and the second piece of information is used to determine the first token.

18. A step of sending a first response to the terminal, the first response indicating that the first token has been successfully revoked, that a procedure for revoking the first token has been triggered, or that the first request has been received, the first response including the random number or the second information, the second information being obtained based on the one-way function and the random number. The method according to claim 16 or 17, further comprising:

19. A step of receiving the second information from the terminal, wherein the second information is obtained based on the one-way function and the random number, The steps include associating the second information with the first token, The method according to any one of claims 16 to 18, further comprising:

20. Steps include sending a notification message to an application programming interface invoker, wherein the notification message indicates that the first token has been successfully revoked, that a procedure for revoking the first token has been triggered, or that the first request has been received, and the notification message includes indication information for the first token. The method according to any one of claims 16 to 19, further comprising:

21. The method according to claim 15, wherein the first information includes auxiliary information used to identify the first token.

22. The aforementioned auxiliary information is, Information used to identify the authorization scope of the first token, Information used to identify the service application programming interface corresponding to the first token, Information used to identify the authorization function network element corresponding to the first token, Information used to identify the first user, Information used to identify the application programming interface exposure function corresponding to the first token, Information used to identify the validity period of the first token, and Information used to identify the issuance time of the first token, The method according to claim 21, comprising at least one of the following.

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

24. Step of sending the authorization code corresponding to the first token to the terminal. The method according to claim 23, further comprising:

25. The method according to claim 23 or 24, wherein the first request further 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 step of revoking the first token, or A step of sending a second request to the authorization function network element, wherein the second request is used to request the revocation of the first token, The method according to any one of claims 15 to 25, further comprising:

27. The step of receiving the first request from the terminal is: The step of receiving the first request sent by the terminal based on the address information of the authorization function network element, or The step of receiving the first request from the terminal through the application programming interface inviter, The method according to any one of claims 15 to 26, comprising at least one of the following.

28. A communication unit configured to receive and send information, A processing unit configured to carry out the method described in any one of claims 1 to 27 through the communication unit, A communication device equipped with the following features.

29. A communication device comprising a processor, wherein the processor is configured to carry out the method according to any one of claims 1 to 27.

30. A computer program product comprising computer program code, wherein when the computer program code is executed, the method according to any one of claims 1 to 27 is implemented.

Images