WO2024094047A1 - 通信方法和通信装置 - Google Patents

通信方法和通信装置 Download PDF

Info

Publication number
WO2024094047A1
WO2024094047A1 PCT/CN2023/128993 CN2023128993W WO2024094047A1 WO 2024094047 A1 WO2024094047 A1 WO 2024094047A1 CN 2023128993 W CN2023128993 W CN 2023128993W WO 2024094047 A1 WO2024094047 A1 WO 2024094047A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
token
authorization
caller
information
Prior art date
Application number
PCT/CN2023/128993
Other languages
English (en)
French (fr)
Inventor
胡力
吴�荣
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2024094047A1 publication Critical patent/WO2024094047A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/082—Access security using revocation of authorisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol

Definitions

  • the present application relates to the field of communications, and more specifically, to a communication method and a communication device.
  • the 3rd Generation Partnership Project (3GPP) capability release architecture provides a way for 3GPP to provide services to the outside world.
  • the application function (AF) network element can request the 3GPP network to process some 3GPP information. This information can include the processing of network data and the processing of user data.
  • AF should obtain the user's authorization.
  • AF can request 3GPP to send the user's location information to the outside world. If the user's authorization is not obtained, the user's privacy information may be exposed.
  • An embodiment of the present application provides a communication method, where an API caller can initiate a token revocation process to implement token revocation in CAPIF.
  • a communication method is provided, which is applied in CAPIF, wherein CAPIF includes an application software programming interface API caller (API invoker), a first authorization entity and an API open function network element (AEF), wherein the API development function network element is used to provide the API caller with access to a specified service API if the API caller is authorized.
  • API invoker application software programming interface API caller
  • AEF API open function network element
  • the method can be executed by the API caller, or it can be executed by a chip or circuit configured in the API caller, and this application does not limit this. For convenience, the following description is taken as an example of the execution of the API caller.
  • the communication method includes: the API caller obtains a first token from the first authorization entity, the first token is used to represent that the API caller is authorized to access the specified service API; when a trigger condition is met, the API caller requests the first authorization entity to revoke the first token.
  • the API caller is an entity that needs to call the service API
  • the first authorization entity can be used to authenticate the API caller based on the API caller's identity and other information
  • the API open function network element is the provider of the service API and the service communication entrance between the service API and the API caller.
  • the API caller after the API caller obtains the first token from the first authorization entity in CAPIF, it can initiate the process of revoking the first token when certain trigger conditions are met. That is to say, the token configured by the API caller can be revoked through the revocation process, so that the API caller can actively revoke the token and improve security protection.
  • the trigger condition includes the API caller receiving an event notification message from the first authorization entity, and the event indicated by the event notification message includes at least one of the following: the designated service API is unavailable, the designated service API has been upgraded, the API caller is offline, the designated service API call fails, the access control policy is unavailable, the API caller authorization is revoked, the API caller has been upgraded, API topology hiding has been created, and API topology hiding has been revoked.
  • the trigger condition for the API caller to initiate the first token revocation process can be: an event notification message sent by the first authorization entity, that is, the configured token can be revoked when certain events occur to avoid the failure of calling the service API based on the configured token.
  • the API caller can initiate a token revocation process to avoid failed calls to the service API using the configured token.
  • the trigger condition includes that the API caller receives a rejection message from the API open function network element, and the rejection reason indicated by the rejection message includes at least one of the following: the API caller is not authorized rights, the specified service API is unavailable, a protocol error, or an application error.
  • the trigger condition for the API caller to initiate the first token revocation process may be: a message that the API open function network element rejects the call, thereby avoiding failure of calling the service API based on the configured token.
  • the API open function network element indicates through a rejection message that it refuses to call the service API.
  • the API caller can revoke the configured token, thereby avoiding the call failure when initiating the service API call through the configured token.
  • the API caller triggers token revocation after receiving error information from the network side.
  • the configured token can be automatically revoked to improve the robustness of the system.
  • the method further includes: the API caller receives a first reason value from the first authorization entity, and the first reason value is used to indicate a reason why the first token revocation failed.
  • the first reason value is carried in a first response message, and the first response message is used to indicate a success or failure in revoking the first token.
  • the first response message carries the first reason value.
  • the first authorization entity can notify the API caller of the reason for the revocation failure through the first reason value, so that the API caller can know the reason for the revocation failure.
  • the failure reason cannot be resolved, it can avoid repeatedly initiating the revocation process and causing unnecessary signaling overhead.
  • the method when the reason for the failure of revocation of the first token is that the first authorization entity does not support revocation of the first token, the method also includes: the API caller reselects a second authorization entity based on the first reason value, and requests the second authorization entity to revoke the first token.
  • the API caller can reselect a second authorization entity and initiate the process of revoking the first token through the second authorization entity to improve the revocation success rate.
  • the method before the API caller reselects the second authorization entity, the method further includes: the API caller determines that the number of failed revocations of the first token is less than a number threshold.
  • the API caller stops reselecting the authorization entity and stops requesting the revocation of the first token. This avoids the situation where the API open function network element does not support the revocation of the first token, and the authorization entity is blindly reselected to repeatedly initiate the token revocation process, thereby increasing the signaling overhead.
  • the API caller when the reason for the failure of revocation of the first token is that the API open function network element does not support revocation of authorization, sends a first message to the first authorization entity, and the first message is used to instruct the first authorization entity to provide a token with a timeout period less than a time threshold; or, the API caller stops requesting the revocation of the first token.
  • the API caller can instruct the first authorization entity to provide a token with a timeout duration less than the duration threshold through the first information, or stop requesting the revocation of the first token. This ensures the stability of the system.
  • the method before the API caller obtains the first token from the first authorization entity, the method also includes: the API caller sends first information to the first authorization entity, and the first information is used to instruct the first authorization entity to provide a token with a timeout duration less than a duration threshold.
  • the API caller informs its own needs through the first information, so that the first authorization entity can treat different API callers differently.
  • the first information includes at least one of the following information: information indicating that the API caller supports the ability to revoke tokens; information indicating that the token expiration period required by the API caller is less than a threshold; information indicating the token timeout period required by the API caller; information indicating business security requirements to be processed by the API caller.
  • the API caller can indicate in different ways that the required token timeout duration is less than the duration threshold, thereby improving the flexibility of the solution.
  • a communication method is provided, which is applied to CAPIF, wherein CAPIF includes an application software programming interface API caller, a first authorization entity, and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API if the API caller is authorized.
  • the method can be executed by the first authorization entity, or it can be executed by a chip or circuit configured in the first authorization entity, and this application does not limit this. For convenience, the following description is taken as an example of execution by the first authorization entity.
  • the communication method includes: the first authorization entity provides a first token to the API caller, and the first token is used to represent the The API caller is authorized to access the designated service API; the first authorization entity receives a first request message from the API caller, and the first request message is used to request the revocation of the first token; the first authorization entity sends a second request message to the API open function network element, and the second request message is used to request the API open function network element to revoke the authorization of the API caller.
  • the first authorization entity in CAPIF after the first authorization entity in CAPIF receives the first request message to revoke the first token from the API caller, it can send a second request message to the API open function network element to request the API open function network element to revoke the authorization of the API caller. That is to say, the first authorization entity actively pushes the revocation information of the authorization to be revoked to the API open function network element to ensure that the event of requesting token revocation can be pushed to the correct API open function network element in real time and be correctly revoked, thereby improving security protection.
  • the first authorization entity receives first indication information from the API open function network element, where the first indication information is used to indicate a revocation result.
  • the method further includes: the first authorization entity notifying the API caller whether the revocation of the first token is successful based on the revocation result.
  • the first indication information when the revocation result is a failure to revoke the authorization of the API caller, the first indication information includes a second reason value, and the second reason value is used to indicate the reason for the failure to revoke the authorization of the API caller.
  • the second request message also includes second indication information, and the second indication information is used to indicate the revocation of the authorization of the API caller.
  • the second request message can be a message sent by the existing first authorization entity to the API open function network element, and the second indication information is a newly added element in the second request message.
  • the original function of the second request message can be other functions except revoking authorization, but the function of revoking authorization is realized by adding a new element.
  • the second request message is a message sent by the newly added first authorization entity to the API open function network element.
  • the function of the second request message can be defined as revoking authorization.
  • the first request message includes the first token
  • the method before the first authorization entity sends the second request message to the API open function network element, the method also includes: the first authorization entity determines the identifier of the API open function network element based on the description information of the first token.
  • the first request message includes token type indication information (token type), and before the first authorization entity sends the second request message to the API open function network element, the method also includes: the first authorization entity determines that the first token is an access token (access_token) based on the token type indication information.
  • token type token type
  • access_token access token
  • the first authorization entity can determine the API open function network element according to the description information of the first token, ensuring that the event of requesting token revocation can be pushed to the correct API open function network element in real time.
  • the method before the first authorization entity sends a second request message to the API open function network element, the method also includes: the first authorization entity determines that the API open function network element supports revoking the authorization of the API caller.
  • the first authorization entity obtains first capability information of the API open function network element, where the first capability information is used to indicate that the API open function network element supports revoking authorization of the API caller.
  • the first authorization entity can obtain the capability information of the API open function network element before sending the second request message, and send the second request message to the API open function network element on the premise that the API open function network element supports token revocation.
  • the overhead of system messages can be reduced.
  • the second request message includes the first token and/or description information of the first token.
  • the second request message also includes second capability information, and the second capability information is used to indicate that the first authorization entity supports token revocation.
  • the method when the revocation result is a successful revocation of the API caller's authorization, the method further includes: the first authorization entity sends a first response message to the API caller, and the first response message is used to indicate that the first token is successfully revoked.
  • the method further includes: the first authorization entity notifying the API caller whether the revocation of the first token is successful based on the revocation result.
  • the revocation result is a failure to revoke the authorization of the API caller.
  • the first indication information includes a second reason value, and the second reason value is used to indicate that the reason for the failure to revoke the authorization of the API caller is that the API open function network element does not support the revocation of the authorization of the API caller.
  • the method also includes: the first authorization entity notifies the API caller, based on the second reason value, that the reason for the failure to revoke the first token is that the API open function network element does not support revoking the API caller's authorization.
  • the first authorization entity can notify the API caller of the reason for the revocation failure through the first reason value, so that the API caller can know the reason for the revocation failure.
  • the failure reason cannot be resolved, it can avoid repeatedly initiating the revocation process and causing unnecessary signaling overhead.
  • the method before the first authorization entity provides the first token to the API caller, the method also includes: the first authorization entity receives first information from the API caller, the first information being used to indicate that the first authorization entity provides a token with a timeout period less than a time threshold; and the first authorization entity generates the first token with a timeout period less than the time threshold based on the first information.
  • the API caller informs its own needs through the first information, so that the first authorization entity can treat different API callers differently and provide tokens that meet the needs for API callers who need a timeout duration less than the time threshold token.
  • the first information includes at least one of the following information: information indicating that the API caller supports the ability to revoke tokens; information indicating that the token timeout period required by the API caller is less than a threshold; information indicating the token timeout period required by the API caller; information indicating business security requirements to be processed by the API caller.
  • the API caller can indicate in different ways that the required token timeout duration is less than the duration threshold, thereby improving the flexibility of the solution.
  • a communication method is provided, which is applied to CAPIF, wherein CAPIF includes an application software programming interface API caller, a first authorization entity and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API if the API caller is authorized.
  • the method can be executed by an API open function network element, or it can be executed by a chip or circuit configured in the API open function network element, and the present application does not limit this. For convenience, the following description is given by taking the execution of the API open function network element as an example.
  • the communication method includes: the API open function network element receives a second request message from the first authorization entity, the second request message is used to request the revocation of the authorization of the API caller; the API open function network element revokes the authorization according to the revocation information to obtain a revocation result, wherein the revocation result includes the success or failure of revoking the authorization of the API caller.
  • the first authorization entity can send a second request message to the API open function network element to request the API open function network element to revoke the authorization of the API caller. That is to say, the first authorization entity actively pushes the revocation information of the authorization to be revoked to the API open function network element to ensure that the event of requesting token revocation can be pushed to the correct API open function network element in real time and be correctly revoked, thereby improving security protection.
  • the method further includes: the API open function network element sends first indication information to the first authorization entity, and the first indication information is used to indicate the revocation result.
  • the first request message also includes second indication information, and the second indication information is used to indicate the revocation of the authorization of the API caller; the API open function network element revokes the authorization according to the revocation information, including: the API open function network element determines the revocation of the authorization according to the revocation information based on the second indication information.
  • the second request message can be a message sent by the existing first authorization entity to the API open function network element, and the second indication information is a newly added information element in the second request message.
  • the original function of the second request message can be other functions except revoking the authorization of the API caller, but the function of requesting to revoke the authorization of the API caller is realized by adding a new information element.
  • the method before the API open function network element receives a second request message from the first authorization entity, the method also includes: the API open function network element sends first capability information to the first authorization entity, and the first capability information is used to indicate that the API open function network element supports revoking the authorization of the API caller.
  • the first authorization entity can obtain the capability information of the API open function network element before sending the second request message, and send the second request message to the API open function network element on the premise that the API open function network element supports token revocation.
  • the overhead of system messages can be reduced.
  • the API open function network element when the second request message includes the first token, revokes the authorization according to the second request message, including: the API open function network element caches the first token To the local token revocation list of the API open function network element, wherein the token revocation list is used to record the revoked tokens.
  • the method further includes: the API open function network element receives a service request message, and the service request message includes the first token; after determining that the first token is revoked according to the token revocation list, the API open function network element rejects the service request message.
  • determining that the first token is revoked according to the token revocation list includes: determining that the first token is in the token revocation list.
  • the API open function network element when the second request message includes the description information of the first token, the API open function network element revokes the authorization based on the second request message, including: the API open function network element caches the description information of the first token in the information list of the API open function network element, wherein the information list is used to record the information of the token whose authorization is revoked.
  • the method further includes: the API open function network element receives a service request message, and the service request message includes the first token; after determining that the first token is revoked of authorization based on the information list, the API open function network element rejects the service request message.
  • determining that the first token is revoked according to the information list includes: determining that the description information of the first token is in the information list.
  • the first indication information when the revocation result is a failure to revoke the API caller's authorization, includes a second reason value, and the second reason value is used to indicate that the reason for the failure to revoke the API caller's authorization is that the API open function does not support the revocation of the API caller's authorization.
  • a communication method is provided, which is applied to CAPIF, wherein CAPIF includes an application software programming interface API caller, a first authorization entity, and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API when the API caller is authorized.
  • the method can be executed by the API caller, or it can be executed by a chip or circuit configured in the API caller, and the present application does not limit this. For convenience, the following description is taken as an example of the execution of the API caller.
  • the communication method includes: the API caller sends first information to the first authorization entity, the first information is used to instruct the first authorization entity to provide a token with a timeout period less than a time threshold; the API caller obtains a first token from the first authorization entity, the first token is used to represent that the API caller is authorized to access the designated service API, and the timeout period of the first token is less than the time threshold.
  • the API caller informs its needs through the first information, so that the first authorized entity can perceive the needs of the API caller, and can treat different API callers differently. Setting the token timeout too short may increase the signaling overhead, because the API caller will frequently request a new token from the first authorized entity, but setting the token timeout too long may reduce security.
  • API callers who require tokens with a timeout period less than the time threshold and only provide such API callers with tokens with a shorter timeout period, thereby ensuring the stability of the system.
  • the first information includes at least one of the following information: information indicating that the API caller supports the ability to revoke tokens; information indicating that the token timeout period required by the API caller is less than a threshold; information indicating the token timeout period required by the API caller; information indicating business security requirements to be processed by the API caller.
  • the API caller can indicate in different ways that the required token timeout duration is less than the duration threshold, thereby improving the flexibility of the solution.
  • the method further includes: the API caller receives second information from the first authorization entity, and the second information is used to indicate capabilities supported by both the first authorization entity and the API caller.
  • a communication method is provided, which is applied to CAPIF, wherein CAPIF includes an application software programming interface API caller, a first authorization entity, and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API when the API caller is authorized.
  • the method can be executed by the first authorization entity, or it can be executed by a chip or circuit configured in the first authorization entity, and the present application does not limit this. For convenience, the following description is taken as an example of execution by the first authorization entity.
  • the communication method includes: the first authorization entity receives first information from the API caller, the first information is used to instruct the first authorization entity to provide a token with a timeout period less than a time threshold; the first authorization entity generates the first token with a timeout period less than the time threshold based on the first information, the first token is used to represent that the API caller is authorized to access the designated service API; the first authorization entity provides the first token to the API caller.
  • the API caller informs its needs through the first information, so that the first authorized entity can perceive the needs of the API caller, and can treat different API callers differently. Setting the token timeout too short may increase the signaling overhead, because the API caller will frequently request a new token from the first authorized entity, but setting the token timeout too long may reduce security.
  • API callers who require tokens with a timeout period less than the time threshold and only provide such API callers with tokens with a shorter timeout period, thereby ensuring the stability of the system.
  • the first information includes at least one of the following information: information indicating that the API caller supports the ability to revoke tokens; information indicating that the token timeout period required by the API caller is less than a threshold; information indicating the token timeout period required by the API caller; information indicating business security requirements to be processed by the API caller.
  • the API caller can indicate in different ways that the required token timeout duration is less than the duration threshold, thereby improving the flexibility of the solution.
  • the method further includes: the first authorization entity sends second information to the API caller, and the second information is used to indicate capabilities supported by both the first authorization entity and the API caller.
  • the method before the first authorization entity provides the first token to the API caller, the method also includes: the first authorization entity determines that the API open function network element does not support revoking the authorization of the API caller.
  • the first authorization entity sets a token with a shorter timeout period. In this way, when the API open function network element does not support the ability to actively revoke the authorization of the API caller, security can be increased at the cost of increasing signaling overhead.
  • a communication method is provided, which is applied to CAPIF, wherein CAPIF includes an application software programming interface API caller, a first authorization entity, and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API when the API caller is authorized.
  • the method can be executed by the first authorization entity, or it can be executed by a chip or circuit configured in the first authorization entity, and this application does not limit this. For convenience, the following description is taken as an example of execution by the first authorization entity.
  • the communication method includes: the first authorization entity provides a first token to the API caller, and the first token is used to represent that the API caller is authorized to access the specified service API; the first authorization entity receives a first request message from the API caller, and the first request message is used to request the revocation of the first token; the first authorization entity caches the first token and/or the description information of the first token in the first authorization entity's local revocation list.
  • the API caller after the API caller obtains the first token from the first authorization entity in CAPIF, it can initiate the process of revoking the first token through a first request message when certain trigger conditions are met. That is to say, the token configured by the API caller can be revoked through the revocation process, so that the API caller can actively revoke the token and improve security protection.
  • the method further includes: the first authorization entity sends a first response message to the API caller, and the first response message is used to indicate whether the revocation of the first token is successful or failed.
  • the method before the first authorization entity provides the first token to the API caller, the method also includes: the first authorization entity receives first information from the API caller, the first information being used to indicate that the first authorization entity provides a token with a timeout period less than a time threshold; and the first authorization entity generates the first token with a timeout period less than the time threshold based on the first information.
  • the API caller informs its own needs through the first information, so that the first authorization entity can treat different API callers differently.
  • the first information includes at least one of the following information: information indicating that the API caller supports the ability to revoke tokens; information indicating that the token timeout period required by the API caller is less than a threshold; information indicating the token timeout period required by the API caller; information indicating business security requirements to be processed by the API caller.
  • the API caller can indicate in different ways that the required token timeout duration is less than the duration threshold, thereby improving the scheme. flexibility.
  • the method further includes: the first authorization entity sends second information to the API caller, and the second information is used to indicate capabilities supported by both the first authorization entity and the API caller.
  • the method also includes: the first authorization entity receives an authorization verification request message from the API open function network element, and the authorization verification request message is used to request the first authorization entity to verify whether the first token is valid; the first authorization entity determines whether the first token is valid based on the local revocation list of the first authorization entity and the first token; the first authorization entity sends an authorization verification response message to the API open function network element, and the authorization verification response message is used to indicate whether the first token is valid.
  • the API open function network element actively sends an authorization verification request message, requesting the first authorization entity to verify whether the authorization is revoked, so as to realize real-time verification of whether the token is revoked.
  • the authorization verification request message includes at least one of the following information: the first token, description information of the first token, or capability information of the API open function network element.
  • a communication method is provided, which is applied to CAPIF, wherein CAPIF includes an application software programming interface API caller, a first authorization entity and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API if the API caller is authorized.
  • the method can be executed by an API open function network element, or it can be executed by a chip or circuit configured in the API open function network element, and the present application does not limit this. For convenience, the following description will be given by taking the execution of the API open function network element as an example.
  • the communication method includes: the API open function network element receives an API call request message from the API caller, the API call request message includes a first token, and the first token is used to represent that the API caller is authorized to access the specified service API; the API open function network element sends an authorization verification request message to the first authorization entity, and the authorization verification request message is used to request the first authorization entity to verify whether the first token is valid; the API open function network element receives an authorization verification response message from the first authorization entity, and the authorization verification response message is used to indicate whether the first token is valid.
  • the API open function network element actively sends an authorization verification request message, requesting the first authorization entity to verify whether the authorization is revoked, so as to realize real-time verification of whether the token is revoked.
  • the authorization verification request message includes at least one of the following information: the first token, description information of the first token, or capability information of the API open function network element.
  • the method before the API open function network element sends an authorization verification request message to the first authorization entity, the method also includes: the API open function network element determines whether the verification token supported by the first authorization entity is valid.
  • the API open function network element determines in advance whether the first authorization entity supports the ability to verify authorization, and does not send an authorization verification request message if it does not support it, thereby reducing the overhead of system messages.
  • the API open function network element sends an API call response message to the API caller, and the API call response message is used to reject or accept the API call.
  • the API call response message includes a reason value for rejection.
  • a communication device which may be an API caller in CAPIF, or may be a chip or circuit in an API caller, and is used to implement the method shown in the first aspect above.
  • the CAPIF includes an application software programming interface API caller, a first authorization entity, and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API if the API caller is authorized.
  • the device includes: a transceiver module, used to obtain a first token from the first authorization entity, the first token is used to represent that the communication device is authorized to access the specified service API; the transceiver module is also used to request the first authorization entity to revoke the first token when a trigger condition is met.
  • the trigger condition includes the transceiver module receiving an event notification message from the first authorization entity, and the event indicated by the event notification message includes at least one of the following: the designated service API is not available, the designated service API has been upgraded, the communication device is offline, the designated service API call fails, the access control policy is unavailable, the communication device authorization is revoked, the communication device has been upgraded, the API topology hiding has been created, and the API topology hiding has been revoked.
  • the trigger condition includes the transceiver module receiving a rejection message from the API open function network element, and the rejection reason indicated by the rejection message includes at least one of the following: the API caller is not authorized, the specified service API is unavailable, a protocol error, or an application error.
  • the transceiver module is further used to receive a first cause value from the first authorization entity, where the first cause value is used to indicate a cause of failure to revoke the first token.
  • the first cause value is carried in a first response message, where the first response message is used to indicate success or failure of revocation of the first token.
  • the first response message carries the first cause value.
  • the device when the reason for the failure of revocation of the first token is that the first authorization entity does not support the revocation of the first token, the device also includes: a processing module, used to reselect a second authorization entity based on the first reason value; the transceiver module is also used to request the second authorization entity to revoke the first token.
  • the processing module before the processing module reselects the second authorization entity, the processing module is further used to determine that the number of failed revocations of the first token is less than a number threshold.
  • the transceiver module when the reason for the failure of revocation of the first token is that the API open function network element does not support the revocation of the first token, the transceiver module is also used to send first information to the first authorization entity, and the first information is used to instruct the first authorization entity to provide a token with a timeout period less than a time threshold; or, the communication device stops requesting the revocation of the first token.
  • the transceiver module before the transceiver module obtains the first token from the first authorization entity, the transceiver module is also used to send first information to the first authorization entity, wherein the first information is used to instruct the first authorization entity to provide a token whose timeout duration is less than a duration threshold.
  • the first information includes at least one of the following information: information indicating that the communication device supports the ability to revoke tokens; information indicating that the token timeout period required by the communication device is less than a threshold; information indicating the token timeout period required by the communication device; information indicating business security requirements to be processed by the API caller.
  • the transceiver module is further used to receive second information from the first authorization entity, where the second information is used to indicate capabilities supported by both the first authorization entity and the communication device.
  • the technical effects of the method shown in the above eighth aspect and its possible design can refer to the technical effects in the first aspect and its possible design.
  • a communication device which may be a first authorization entity in CAPIF, or may be a chip or circuit in the first authorization entity, for implementing the method shown in the second aspect above, wherein CAPIF includes an application software programming interface API caller, a first authorization entity and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API if the API caller is authorized.
  • CAPIF includes an application software programming interface API caller, a first authorization entity and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API if the API caller is authorized.
  • the device includes: a transceiver module, used to provide a first token to the API caller, the first token is used to represent that the API caller is authorized to access the specified API; the transceiver module is also used to receive a first request message from the API caller, the first request message is used to request the revocation of the first token; the transceiver module is also used to send a second request message to the API open function network element, the second request message is used to request the API open function network element to revoke the authorization of the API caller.
  • the transceiver module is further used to receive first indication information from the API open function network element, and the first indication information is used to indicate the revocation result.
  • the second request message also includes second indication information, and the second indication information is used to indicate the revocation of the authorization of the API caller.
  • the second request message is a message sent by the newly added communication device to the API open function network element.
  • the function of the second request message can be defined as revoking the authorization of the API caller.
  • the first request message includes the first token
  • the processing module is used to obtain the identifier of the API open function network element based on the description information of the first token.
  • the first request message includes token type indication information (token type), and before the transceiver module sends the second request message to the API open function network element, the processing module is used to determine that the first token is an access token (access_token) based on the token type indication information.
  • token type token type
  • access_token access token
  • the processing module obtains first capability information of the API open function network element, and the first capability information is used to indicate that the API open function network element supports revoking the authorization of the API caller.
  • the second request message includes the first token and/or description information of the first token.
  • the second request message further includes second capability information,
  • the second capability information is used to indicate that the communication device supports token revocation.
  • the transceiver module when the revocation result is a successful revocation of the authorization of the API caller, the transceiver module is also used to send a first response message to the API caller, and the first response message is used to indicate that the revocation of the first token is successful.
  • the processing module when the revocation result is a failure to revoke the authorization of the API caller, the processing module sends a first reason value to the API caller based on the revocation result, and the first reason value is used to indicate the reason for the failure to revoke the first token.
  • the first indication information includes a second reason value
  • the second reason value is used to indicate that the reason for the failure to revoke the API caller's authorization is that the API open function does not support the revocation of the API caller's authorization
  • the reason for the failure to revoke the first token is that the API open function does not support the revocation of the API caller's authorization
  • the transceiver module before the transceiver module provides the first token to the API caller, the transceiver module is also used to receive first information from the API caller, and the first information is used to instruct the communication device to provide a token with a timeout duration less than a duration threshold; the processing module determines that the timeout duration of the first token is less than the duration threshold based on the first information.
  • the first information includes at least one of the following information: information indicating that the API caller supports the ability to revoke tokens; information indicating that the token timeout period required by the API caller is less than a threshold; information indicating the token timeout period required by the API caller; information indicating business security requirements to be processed by the API caller.
  • the transceiver module is further used to send second information to the API caller, where the second information is used to indicate capabilities supported by both the communication device and the API caller.
  • a communication device which may be an API open function network element in CAPIF, or may be a chip or circuit in an API open function network element, for implementing the method shown in the third aspect above, wherein CAPIF includes an application software programming interface API caller, a first authorization entity and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API if the API caller is authorized.
  • CAPIF includes an application software programming interface API caller, a first authorization entity and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API if the API caller is authorized.
  • the device includes: a transceiver module, used to receive a second request message from the first authorization entity, the second request message is used to request the revocation of the authorization of the API caller, the second request message includes revocation information, and the revocation information is used to indicate the authorization to be revoked; a processing module, used to revoke the authorization according to the revocation information; the transceiver module is also used to send first indication information to the first authorization entity, and the first indication information is used to indicate the revocation result.
  • the first request message also includes second indication information, and the second indication information is used to indicate the revocation of the authorization of the API caller; the A processing module revokes the authorization according to the revocation information, including: the processing module determines to revoke the authorization according to the revocation information based on the second indication information.
  • the transceiver module before the transceiver module receives the second request message from the first authorization entity, the transceiver module is also used to send first capability information to the first authorization entity, and the first capability information is used to indicate that the communication device supports revoking the authorization of the API caller.
  • the processing module when the second request message includes the first token, the processing module revokes the authorization based on the second request message, including: the processing module caches the first token in a local token revocation list of the communication device, wherein the token revocation list is used to record revoked authorization tokens.
  • the transceiver module after the processing module revokes the authorization according to the revocation information, the transceiver module is also used to receive a service request message, which includes the first token; after determining that the first token is revoked according to the token revocation list, the processing module rejects the service request message.
  • the processing module when the second request message includes the description information of the first token, the processing module revokes the authorization based on the second request message, including: the processing module caches the description information of the first token in an information list of the communication device, wherein the information list is used to record the information of the token whose authorization is revoked.
  • the transceiver module is further used to receive a service request message, the service request message including the first token; After the information list determines that the first token is revoked, the processing module rejects the service request message.
  • the first indication information when the revocation result is a failure to revoke the API caller's authorization, includes a second reason value, and the second reason value is used to indicate that the reason for the failure to revoke the API caller's authorization is that the communication device does not support the revocation of the API caller's authorization.
  • a communication device which may be an API caller in CAPIF, or may be a chip or circuit in an API caller, and is used to implement the method shown in the fourth aspect above.
  • CAPIF includes an application software programming interface API caller, a first authorization entity, and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API if the API caller is authorized.
  • the device includes: a transceiver module, used to send first information to the first authorization entity, the first information is used to instruct the first authorization entity to provide a token with a timeout period less than a time threshold; the transceiver module is also used to obtain a first token from the first authorization entity, the first token is used to represent that the communication device is authorized to access the specified service API, and the timeout period of the first token is less than the time threshold.
  • the first information includes at least one of the following information: information indicating that the communication device supports the ability to revoke tokens; information indicating that the communication device requires a token timeout period that is less than a threshold; information indicating the communication device requires a token timeout period; information indicating service security requirements to be processed by the communication device.
  • the transceiver module is further used to receive second information from the first authorization entity, where the second information is used to indicate capabilities supported by both the first authorization entity and the communication device.
  • a communication device which may be a first authorization entity in CAPIF, or may be a chip or circuit in the first authorization entity, for implementing the method shown in the fifth aspect above, wherein the CAPIF includes an application software programming interface API caller, a first authorization entity and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API if the API caller is authorized.
  • the CAPIF includes an application software programming interface API caller, a first authorization entity and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API if the API caller is authorized.
  • the device includes: a transceiver module, used to receive first information from the API caller, the first information is used to instruct the communication device to provide a token with a timeout period less than a time threshold; a processing module, used to determine that the timeout period of the first token is less than the time threshold based on the first information, the first token is used to represent that the API caller is authorized to access the specified service API; the transceiver module is also used to provide the first token to the API caller.
  • a transceiver module used to receive first information from the API caller, the first information is used to instruct the communication device to provide a token with a timeout period less than a time threshold
  • a processing module used to determine that the timeout period of the first token is less than the time threshold based on the first information, the first token is used to represent that the API caller is authorized to access the specified service API
  • the transceiver module is also used to provide the first token to the API caller.
  • the first information includes at least one of the following information: information indicating that the API caller supports the ability to revoke tokens; information indicating that the token timeout period required by the API caller is less than a threshold; information indicating the token timeout period required by the API caller; information indicating business security requirements to be processed by the API caller.
  • the transceiver module is further used to send second information to the API caller, where the second information is used to indicate capabilities supported by both the communication device and the API caller.
  • the processing module before the transceiver module provides the first token to the API caller, the processing module is also used to determine that the API open function network element does not support revoking the authorization of the API caller.
  • a communication device which may be a first authorization entity in CAPIF, or may be a chip or circuit in the first authorization entity, and is used to implement the method shown in the sixth aspect above, wherein the CAPIF includes an application software programming interface API caller, a first authorization entity and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API if the API caller is authorized.
  • the CAPIF includes an application software programming interface API caller, a first authorization entity and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API if the API caller is authorized.
  • the device includes: a transceiver module, used to provide a first token to the API caller, the first token is used to represent that the API caller is authorized to access the specified service API; the transceiver module is also used to receive a first request message from the API caller, the first request message is used to request revocation of the first token, the first request message includes the first token; a processing module, used to cache the first token and/or the description information of the first token into a local revocation list of the communication device.
  • the transceiver module is further used to send a first response message to the API caller, and the first response message is used to indicate whether the revocation of the first token is successful or failed.
  • the transceiver module before the transceiver module provides the first token to the API caller, the transceiver module is also used to receive first information from the API caller, where the first information is used to instruct the communication device to provide a token whose timeout duration is less than a time threshold; the processing module determines the timeout duration of the first token based on the first information. Less than the duration threshold.
  • the first information includes at least one of the following information: information indicating that the API caller supports the ability to revoke tokens; information indicating that the token timeout period required by the API caller is less than a threshold; information indicating the token timeout period required by the API caller; information indicating business security requirements to be processed by the API caller.
  • the transceiver module is also used to send second information to the API caller, and the second information is used to indicate capabilities supported by both the communication device and the API caller.
  • the transceiver module is further used to receive an authorization verification request message from the API open function network element, and the authorization verification request message is used to request the communication device to verify whether the first token is valid; the processing module determines whether the first token is valid based on the local revocation list of the communication device and the first token; the transceiver module is also used to send an authorization verification response message to the API open function network element, and the authorization verification response message is used to indicate whether the first token is valid.
  • the authorization verification request message includes at least one of the following information: the first token, description information of the first token, or capability information of the API open function network element.
  • a communication device which may be an API open function network element in CAPIF, or may be a chip or circuit in the API open function network element, for implementing the method shown in the seventh aspect above, wherein the CAPIF includes an application software programming interface API caller, a first authorization entity and an API open function network element, wherein the API development function network element is used to provide the API caller with access to a specified service API if the API caller is authorized.
  • the device includes: a transceiver module, used to receive an API call request message from the API caller, the API call request message includes a first token, and the first token is used by the device to verify whether the API caller is authorized to access the specified service API; the transceiver module is also used to send an authorization verification request message to the first authorization entity, and the authorization verification request message is used to request the first authorization entity to verify whether the first token is valid; the transceiver module is also used to receive an authorization verification response message from the first authorization entity, and the authorization verification response message is used to indicate whether the first token is valid.
  • the authorization verification request message includes at least one of the following information: the first token, description information of the first token, or capability information of the communication device.
  • the processing module determines whether a verification token supported by the first authorization entity is valid.
  • the transceiver module is also used to send an API call response message to the API caller, and the API call response message is used to reject or accept the API call.
  • the API call response message includes a reason value for rejection.
  • a communication system comprising a first authorization entity and an API open function network element, wherein the first authorization entity is used to execute the method shown in the above second aspect, and the API open function network element executes the method shown in the above third aspect.
  • the communication system also includes an API caller, and the API caller executes the method shown in the first aspect above.
  • a communication system comprising a first authorization entity and an API caller, wherein the API caller is used to execute the method shown in the fourth aspect, and the first authorization entity executes the method shown in the fifth aspect.
  • a communication system including a first authorization entity and an API open function network element, wherein the first authorization entity is used to execute the method shown in the above sixth aspect, and the API open function network element executes the method shown in the above seventh aspect.
  • the communication system also includes an API caller, which executes the method shown in the first aspect above.
  • a communication device which includes: a memory for storing programs; a processor for executing the programs stored in the memory, and when the programs stored in the memory are executed, the processor is used to execute the methods provided in the above aspects.
  • the present application provides a processor for executing the methods provided in the above aspects.
  • the process of sending the above information and obtaining/receiving the above information in the above methods can be understood as the process of the processor outputting the above information and the process of the processor receiving the input above information.
  • the processor When outputting the above information, the processor outputs the above information to the transceiver so that the transceiver can transmit it. After being output by the processor, the above information may also need to undergo other processing before reaching the transceiver.
  • the transceiver obtains/receives the above information and inputs it into the processor. Furthermore, After the transceiver receives the above information, the above information may need to be processed further and then input into the processor.
  • the receiving request message mentioned in the above method can be understood as the processor receiving input information.
  • the processor may be a processor specifically used to execute these methods, or may be a processor that executes computer instructions in a memory to execute these methods, such as a general-purpose processor.
  • the memory may be a non-transitory memory, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or may be separately arranged on different chips.
  • ROM read-only memory
  • a computer-readable storage medium which stores a program code for execution by a device, and the program code includes a method for executing the methods provided in the above aspects.
  • a computer program product comprising instructions is provided.
  • the computer program product is run on a computer, the computer is used to execute the methods provided in the above aspects.
  • a chip which includes a processor and a communication interface, and the processor reads instructions stored in a memory through the communication interface to execute the methods provided in the above aspects.
  • the chip may further include a memory, in which instructions are stored, and the processor is used to execute the instructions stored in the memory.
  • the processor is used to execute the methods provided by the above aspects.
  • FIG1 is a schematic diagram of a network architecture 100 provided in the present application.
  • FIG. 2 is a schematic diagram of a CAPIF system.
  • Figure 3 is a schematic flow chart of CCF authorizing API invoker to call a specific API from AEF.
  • FIG4 is a schematic flow chart of a communication method provided in the present application.
  • FIG5 is a schematic flow chart of another communication method provided by the present application.
  • FIG6 is a schematic flow chart of yet another communication method provided in the present application.
  • FIG. 7 is a schematic block diagram of a communication device 10 provided in an embodiment of the present application.
  • FIG. 8 is a schematic diagram of another communication device 20 provided in an embodiment of the present application.
  • FIG. 9 is a schematic diagram of a chip system 30 provided in an embodiment of the present application.
  • the technical solution provided in this application can be applied to various communication systems, such as: new radio (NR) system, long term evolution (LTE) system, LTE frequency division duplex (FDD) system, LTE time division duplex (TDD) system, etc.
  • NR new radio
  • LTE long term evolution
  • FDD frequency division duplex
  • TDD time division duplex
  • D2D device to device
  • V2X vehicle to everything
  • M2M machine to machine
  • MTC machine type communication
  • IoT Internet of things
  • PLMN public land mobile network
  • MNO mobile network operators
  • 3GPP networks generally include but are not limited to 5G networks, fourth-generation mobile communication (4th-generation, 4G) networks, and other future communication systems, such as (6th-generation, 6G) networks, etc.
  • FIG1 is a schematic diagram of a 5G network architecture 100 provided by the present application, taking the 5G network architecture based on the service-based architecture SBA in the non-roaming scenario defined in the 3GPP standardization process as an example.
  • the network architecture may include three parts, namely, the terminal device part, the DN and the operator network PLMN part. The functions of the network elements of each part are briefly described below.
  • the terminal device part may include a terminal device 110, which may also be referred to as user equipment (UE).
  • the terminal device 110 in the present application is a device with wireless transceiver functions, which can communicate with one or more core network (CN) devices via the access network device (or also referred to as access device) in the radio access network (RAN) 140.
  • CN core network
  • the terminal device 110 can also be referred to as an access terminal, terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, user agent or user device, etc.
  • the terminal device 110 can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; it can also be deployed on the water surface (such as a ship, etc.); it can also be deployed in the air (such as an airplane, a balloon and a satellite, etc.).
  • the terminal device 110 can be a cellular phone, a cordless phone, a session initiation protocol (SIP) phone, a smart phone, a mobile phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), etc.
  • SIP session initiation protocol
  • WLL wireless local loop
  • PDA personal digital assistant
  • the terminal device 110 may also be a handheld device with wireless communication function, a computing device or other device connected to a wireless modem, a vehicle-mounted device, a wearable device, a drone device or an Internet of Things, a terminal in the Internet of Vehicles, a 5G network and any form of terminal in the future network, a relay user device or a terminal in the future evolved 6G network, etc.
  • the relay user device may be, for example, a 5G residential gateway (RG).
  • the terminal device 110 may be a virtual reality (VR) terminal, an augmented reality (AR) terminal, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical, a wireless terminal in smart grid, a wireless terminal in transportation safety, a wireless terminal in smart city, a wireless terminal in smart home, etc.
  • the terminal device here refers to a 3GPP terminal.
  • the embodiment of the present application does not limit the type or type of the terminal device. For ease of explanation, the present application will be described later using UE as an example to refer to the terminal device.
  • the PLMN part of the operator network may include but is not limited to the (radio) access network ((radio) access network, (R)AN) 120 and the core network (core network, CN).
  • (R)AN 120 can be regarded as a sub-network of the operator network, and is an implementation system between the service nodes in the operator network and the terminal device 110.
  • the terminal device 110 To access the operator network, the terminal device 110 first passes through (R)AN 120, and then can be connected to the service node of the operator network through (R)AN 120.
  • the access network device (RAN device) in the embodiment of the present application is a device that provides wireless communication functions for the terminal device 110, and can also be called a network device.
  • the RAN device includes but is not limited to: the next generation node base station (gNB) in the 5G system, the evolved node B (eNB) in the long term evolution (LTE), the radio network controller (RNC), the node B (NB), the base station controller (BSC), the base transceiver station (BTS), the home base station (for example, home evolved node B, or home node B, HNB), the base band unit (BBU), the transmission point (TRP), the transmitting point (TP), the small base station device (pico), the mobile switching center, or the network device in the future network.
  • the name of the device with the access network device function may be different.
  • the above-mentioned device providing wireless communication function for the terminal device 110 is collectively referred to as access network equipment or RAN or AN for short. It should be understood that the specific type of access network equipment is not limited herein.
  • the CN part may include but is not limited to the following NFs: user plane function (UPF) 130, network exposure function (NEF) 131, network function repository function (NRF) 132, policy control function (PCF) 133, unified data management function (UDM) 134, unified data repository function (UDR) 135, network data analysis function (NWDAF) 136, authentication server function (AUSF) 137, access and mobility management function (AMF) 138, session management function (SMF) 139.
  • UPF user plane function
  • NEF network exposure function
  • NRF network function repository function
  • PCF policy control function
  • UDM unified data management function
  • UDR unified data repository function
  • NWDAF authentication server function
  • AMF access and mobility management function
  • SMSF session management function
  • the data network DN 140 which may also be referred to as a packet data network (PDN), is usually a network located outside the operator network, such as a third-party network.
  • the DN may also be deployed by the operator, that is, the DN is part of the PLMN. This application does not limit whether the DN belongs to the PLMN.
  • the operator network PLMN may access multiple data networks DN 140, and multiple services may be deployed on the data network DN 140, which may provide services such as data and/or voice to the terminal device 110.
  • the data network DN 140 may be a private network of a smart factory, and the sensors installed in the workshop of the smart factory may be the terminal devices 110.
  • the control server in which the sensors are deployed in the data network DN 140 may provide services for the sensors.
  • the sensors may communicate with the control server, obtain instructions from the control server, and transmit the collected sensor data to the control server according to the instructions.
  • the data network DN 140 may be an internal office network of a company, and the mobile phones or computers of the company's employees may be the terminal devices 110, and the employees' mobile phones or computers may access information, data resources, etc. on the company's internal office network.
  • the terminal device 110 can establish a connection with the operator network through an interface (such as N1, etc.) provided by the operator network and use data and/or voice services provided by the operator network.
  • the business network accesses the data network DN 140 and uses the operator services deployed on the data network DN 140 and/or services provided by a third party.
  • UPF 130 is a gateway provided by the operator and is the gateway for the operator network to communicate with the data network DN 140.
  • UPF network function 130 includes user-plane related functions such as packet routing and transmission, packet detection, service usage reporting, quality of service (QoS) processing, legal monitoring, uplink packet detection, downlink packet storage, etc.
  • QoS quality of service
  • NEF 131 is a control plane function provided by the operator. It mainly enables third parties to use the services provided by the network, supports the network to open its capabilities, event and data analysis, provides PLMN security configuration information from external applications, and converts the interactive information inside and outside the PLMN. It provides an API interface for the operator network to be open to the outside world, and provides it for the interaction between external servers and internal operator networks.
  • NRF 132 is a control plane function provided by the operator, which can be used to maintain real-time information of network functions and services in the network. For example, it supports network service discovery, maintains the services supported by the NF configuration data (NF profile) of the NF instance, supports service discovery of the communication proxy (SCP), maintains the SCP configuration data (SCP profile) of the SCP instance, sends notifications about newly registered, deregistered, and updated NFs and SCPs, and maintains the health status of NF and SCP operations.
  • NF profile the services supported by the NF configuration data
  • SCP communication proxy
  • SCP profile SCP configuration data
  • PCF 133 is a control plane function provided by the operator. It supports a unified policy framework to govern network behavior, provide policy rules to other control functions, contract information related to policy decisions, etc.
  • UDM 134 is a control plane function provided by the operator, responsible for storing information such as the subscriber permanent identifier (SUPI) of the subscriber in the operator network, the generic public subscription identifier (GPSI) of the subscriber, and credentials.
  • the SUPI will be encrypted during transmission, and the encrypted SUPI is called the hidden subscriber subscription identifier (SUCI).
  • the information stored by the UDM network function 134 can be used for authentication and authorization of the terminal device 110 to access the operator network.
  • the subscriber of the above-mentioned operator network can specifically be a user who uses the services provided by the operator network, such as a user who uses a mobile phone chip card (subscriber identity module, SIM) card of China Telecom, or a user who uses a mobile phone chip card of China Mobile, etc.
  • the credentials of the above-mentioned subscriber can be a small file storing long-term keys stored in the mobile phone chip card or information related to the encryption of the mobile phone chip card, which is used for authentication and/or authorization.
  • permanent identifiers, credentials, security contexts, authentication data (cookies), and tokens are equivalent to verification/authentication and authorization-related information. In the embodiments of the present application, no distinction or restriction is made for the sake of convenience of description.
  • UDR 135 is a control plane function provided by the operator. It provides the functions of storing and retrieving contract data for UDM, storing and retrieving policy data for PCF, and storing and retrieving user's NF group ID (group ID) information.
  • NWDAF 136 is a control plane function provided by the operator. Its main function is to collect data from NF, external application function AF and operation, administration and maintenance (OAM) system, and provide NWDAF service registration, data opening and analysis data to NF and AF.
  • OAM administration and maintenance
  • AUSF 137 is a control plane function provided by the operator, which is usually used for primary authentication, i.e., authentication between the terminal device 110 (subscriber) and the operator network. After receiving the authentication request initiated by the subscriber, the AUSF network function 137 can authenticate and/or authorize the subscriber through the authentication information and/or authorization information stored in the UDM network function 134, or generate the authentication and/or authorization information of the subscriber through the UDM network function 134. The AUSF network function 137 can feed back the authentication information and/or authorization information to the subscriber.
  • AMF 138 is a control plane network function provided by the operator network, responsible for access control and mobility management of the terminal device 110 accessing the operator network, including, for example, mobility status management, allocation of temporary user identities, authentication and authorization of users, etc.
  • AMF 138 is used to establish NAS connection with UE and has the same 5G NAS security context as UE.
  • the 5G NAS security context includes KAMF, key identification information with the same NAS layer key, UE security capability, and uplink and downlink NAS COUNT values.
  • NAS layer keys include NAS encryption keys and NAS integrity protection keys, which are used for confidentiality protection and integrity protection of NAS messages respectively.
  • SMF 139 is a control plane network function provided by the operator network, responsible for managing the PDU session of the terminal device 110.
  • the PDU session is a channel for transmitting PDUs.
  • the terminal device needs to transmit PDUs to and from the data network DN 140 through the PDU session.
  • the PDU session is established, maintained, and deleted by the SMF network function 139.
  • the SMF network function 139 includes session management (such as session establishment, modification, and release, including tunnel maintenance between the user plane function UPF 130 and (R)AN 120), selection and control of the UPF network function 130, service and session continuity (SSC) mode selection, roaming, and other session-related functions.
  • session management such as session establishment, modification, and release, including tunnel maintenance between the user plane function UPF 130 and (R)AN 120
  • SSC service and session continuity
  • AF 141 is a control plane network function provided by the operator network, which is used to provide application layer information. It can interact with the policy framework through the network open function network element or directly interact with the policy framework to make policy decision requests, etc. It can be located inside or outside the operator network.
  • network elements or functions can be physical entities in hardware devices, software instances running on dedicated hardware, or virtualized functions instantiated on a shared platform (e.g., a cloud platform). It can also be implemented by software.
  • Nnef, Nnrf, Npcf, Nudm, Nudr, Nnwdaf, Nausf, Namf, Nsmf, N1, N2, N3, N4, and N6 are interface serial numbers.
  • the meaning of the above interface serial numbers can be found in the meaning defined in the 3GPP standard protocol, and this application does not limit the meaning of the above interface serial numbers.
  • the interface name between the various network functions in the figure is only an example.
  • the interface name of the system architecture may also be other names, which is not limited in this application.
  • the name of the message (or signaling) transmitted between the above network elements is only an example and does not constitute any limitation on the function of the message itself.
  • network functions (such as NEF 131 ... SMF139) are collectively referred to as NFs, that is, the NFs described later in the embodiments of the present application can be replaced by any network functions.
  • FIG. 1 only schematically describes some network functions, and the NFs described later are not limited to the network functions shown in FIG. 1.
  • the above-mentioned network architecture applied to the embodiment of the present application is only a network architecture described from the perspective of a service-oriented architecture, and the network architecture applicable to the embodiment of the present application is not limited to this. Any network architecture that can realize the functions of the above-mentioned network elements is applicable to the embodiment of the present application.
  • AMF, SMF, UPF, NEF, AUSF, NRF, PCF, and UDM shown in the figure can be understood as network elements used to implement different functions in the core network, for example, they can be combined into network slices as needed.
  • These core network network elements can be independent devices or integrated into the same device to implement different functions. This application does not limit the specific form of the above network elements.
  • this application mainly relates to a capability exposure architecture under the 5G architecture, such as the Common API Framework (CAPIF) system shown in Figure 2.
  • Figure 2 is a schematic diagram of a CAPIF system.
  • the CAPIF system can be applied to 4G or 5G systems, and obviously can also be applied to communication systems of other standards, which is not limited by this application.
  • the following is a brief introduction to the various components of the CAPIF system:
  • API caller It can also be called API calling entity, usually a third-party application that has signed a service agreement with the public land mobile network (PLMN) operator, such as machine to machine (M2M) application, internet of things (IoT) application, vehicle-to-everything (V2X) application, etc. These applications can run in terminal devices or network devices.
  • PLMN public land mobile network
  • M2M machine to machine
  • IoT internet of things
  • V2X vehicle-to-everything
  • the API calling entity includes but is not limited to the following functions: 1) providing the API caller identity and other information required for API caller authentication to support authentication; 2) supporting mutual authentication with CAPIF; 3) obtaining authorization before accessing the service API; 4) discovering service API information; 5) calling the service API.
  • CAPIF Core Function including but not limited to the following functions: 1) Authenticate API callers based on the identity and other information required for API caller authentication; 2) Support mutual authentication with API callers; 3) Provide authorization for API callers before accessing service APIs; 4) Publish, store and support discovery of service API information; 5) Control business API access according to policies configured by PLMN operators; 6) Store logs of service API calls and provide service API call logs to authorized entities; 7) Bill based on service API call logs; 8) Monitor service API calls; 9) Add new API callers and exit API callers; 10) Store policy configurations related to CAPIF and business APIs; 11) Support access logs for auditing (e.g., detecting abuse); 12) Support publishing and discovering service API information using another CAPIF core function in CAPIF docking.
  • API Exposing Function It is the provider of the service API and the service communication entry point between the service API and the API caller. It can also be used as the entry point for the API calling entity to call the API. For example, it authenticates the API calling entity based on the API calling entity's identity and the information provided by CCF, receives the authentication information provided by CCF, and synchronizes the API log to CCF.
  • the AEF can be a NEF.
  • API publishing function used to provide API publishing function so that API calling entities can discover the API.
  • API management function which is used to provide management of API, for example, auditing API call logs provided by CCF, monitoring events reported by CCF, configuring access and billing policies for API, detecting API status, and registering API call entities.
  • AuF Authentication Function
  • Service API refers to the API opened by AEF, which can be called API on AEF and can be discovered and called by API calling entities. It mainly includes some specific service type APIs, which can be used by API calling entities to use the resources and services provided by operators, such as QoS control APIs, broadcast type APIs, IoT type APIs, etc.
  • FIG3 is a schematic flow chart of CCF authorizing API invoker to AEF to call a specific API. The following steps are included:
  • API invoker sends a registration API invoker request message to CCF.
  • the registration API invoker request message includes registration information and registration API.
  • the registration information includes information of API invoker, such as registration details, registration requirements, etc.
  • the registration API includes a list of APIs that need to be registered.
  • CCF sends a register API invoker response message to the API invoker.
  • the response message includes registration status, registered information, and Service API information.
  • the registration status indicates the result of registration (e.g., registration success or failure);
  • the registered information includes API invoker ID, and authorization and authentication methods.
  • the API invoker ID is assigned by CCF to the API invoker.
  • the authorization and authentication methods indicate which authorization and authentication methods are used.
  • the authorization and authentication methods include but are not limited to:
  • PSK Pre-Shared Key
  • PKI Public Key Infrastructure
  • TLS with OAuth token Transport Layer Security Authorization Token
  • Service API information indicates the information of the registered API, including service API name (name), AEF location, IP address, port number, or protocol, etc.
  • API invoker sends a discovery service request message to CCF.
  • the service request message includes an API invoker ID and request information, wherein the request information includes criteria for discovering certain APIs, such as preferred API open function (AEF) location, protocol, etc.
  • AEF preferred API open function
  • CCF sends a discovery service response message to the API invoker.
  • the service response message includes service API information.
  • the service API information responds to the API requested in step S330.
  • the information elements included in the service API information refer to the description of the Service API information in step S320, which will not be repeated here.
  • API invoker sends an authorization request message to CCF.
  • the authorization request message contains API invoker ID and API name, as well as authorization method, which uses client credential client_credential mode authentication (OAuth).
  • CCF sends an authorization response message to the API invoker.
  • the authorization response message contains refresh_token and access_token.
  • Both tokens contain declarations and signatures.
  • the declaration contains the following: timeout, API Invoker ID, AEF ID, service API ID.
  • the declaration can also contain a user ID.
  • the signature is the digital signature of the CCF on the token.
  • API invoker sends an API call request message to AEF.
  • the API call request message contains API invoker ID, service API ID and access_token, and optionally also contains user ID.
  • AEF verifies the signature of the token.
  • AEF verifies the signature of the token through the pre-configured CCF credentials (e.g., certificate).
  • AEF verifies the declaration part: AEF determines whether the API Invoker ID in the token declaration is consistent with the API Invoker ID in the message. AEF determines whether the service API ID in the token declaration is consistent with the service API ID requested in the message. Optionally, AEF determines whether the user ID in the token declaration is consistent with the user ID requested in the message. AEF determines whether the current token has timed out based on the timeout period.
  • step S390 If the above judgment is passed, the AEF executes step S390. If the judgment is not passed, the API call request message is rejected.
  • AEF sends an API call response message to API Invoker.
  • used for indication may include being used for direct indication and being used for indirect indication.
  • indication information When describing that a certain indication information is used for indicating A, it may include that the indication information directly indicates A or indirectly indicates A, but it does not mean that A must be included in the indication information.
  • the information indicated by the indication information is called the information to be indicated.
  • the information to be indicated can be sent as a whole, or divided into multiple sub-information and sent separately, and the sending period and/or sending time of these sub-information can be the same or different.
  • the specific sending method is not limited in this application. Among them, the sending period and/or sending time of these sub-information can be pre-defined, for example, pre-defined according to the protocol, or can be configured by the transmitting end device by sending configuration information to the receiving end device.
  • the "storage” involved in the embodiments of the present application may refer to storage in one or more memories.
  • the one or more memories may be separately set or integrated in an encoder or decoder, a processor, or a communication device.
  • the one or more memories may also be partially separately set and partially integrated in a decoder, a processor, or a communication device.
  • the type of memory may be any form of storage medium, which is not limited by the present application.
  • the “protocol” involved in the embodiments of the present application may refer to a standard protocol in the communication field, for example, it may include an LTE protocol, an NR protocol, and related protocols used in future communication systems, and the present application does not limit this.
  • RRC radio resource control
  • the term "and/or" in this article is only a description of the association relationship of the associated objects, indicating that there can be three relationships.
  • a and/or B can mean: A exists alone, A and B exist at the same time, and B exists alone.
  • the character "/" in this article generally indicates that the associated objects before and after are in an "or" relationship.
  • the communication method provided in the embodiments of the present application can be applied to a 5G system, for example, the communication system shown in FIG. 1 .
  • the embodiments shown below do not particularly limit the specific structure of the execution subject of the method provided in the embodiments of the present application, as long as it is possible to communicate according to the method provided in the embodiments of the present application by running a program that records the code of the method provided in the embodiments of the present application.
  • the execution subject of the method provided in the embodiments of the present application may be a network element, or a functional module in the network element that can call and execute the program.
  • FIG4 is a schematic flow chart of a communication method provided by the present application.
  • the CAPIF includes an application software programming interface API caller (hereinafter referred to as API invoker for the sake of convenience of description), a first authorization entity (including CCF or AuF, hereinafter referred to as CCF for the sake of convenience of description) and an API open function network element (hereinafter referred to as AEF for the sake of convenience of description).
  • API invoker for the sake of convenience of description
  • CCF or AuF including CCF or AuF, hereinafter referred to as CCF for the sake of convenience of description
  • AEF API open function network element
  • the API caller is an entity that needs to call a service API; the first authorization entity can be used to authenticate and authorize the API caller based on the API caller's identity and other information; the API open function network element is the provider of the service API and the service communication entrance between the service API and the API caller. Specifically, the API development function network element is used to provide the API caller with access to the specified service API if the API caller is authorized.
  • the communication method shown in FIG4 includes the following steps:
  • the API invoker obtains the first token from the CCF, or the CCF provides the first token to the API invoker.
  • the first token is used by the AEF to verify whether the API invoker is authorized to access the specified service API.
  • the first token is used to ensure that the API invoker is authorized to access the specified service API.
  • the API invoker obtains a token from CCF.
  • the token can contain an access_token and/or a refresh_token.
  • the access_token is used by AEF to authorize the API invoker to access the relevant API.
  • the refresh_token is used by the API invoker to request a new access_token and/or a new refresh_token from CCF.
  • the API invoker can send a Refresh_Token Request message to CCF, which is used to request CCF to update authorization, and the message carries the Refresh_token.
  • CCF After successfully verifying the Refresh_token, CCF sends a Refresh_Token Response message to the API invoker, which carries a new access_token and/or a new refresh_token.
  • this embodiment mainly involves the revocation of access_token, so the API invoker can only obtain access_token when obtaining token from CCF, and there is no limitation on whether to obtain refresh_token in this embodiment.
  • a token contains a claim.
  • a token can also contain a signature.
  • the access_token obtained by the API invoker contains one or more of the following information:
  • the AEF identifier, the service API identifier, and the user identifier may be included in a declared scope, and the scope is used to indicate the scope of the access request.
  • the user identifier is optional information, that is, the scope of the access_token may not carry the user identifier.
  • the scope of the access_token indicates that the request carrying the Token is authorized to access the specific API provided by the specific AEF.
  • the scope of the access_token indicates that the request carrying the access_token is authorized to access the specific API provided by the specific AEF to call the resources of the specific user.
  • the signature of access_token is the signature generated by CCF for the declaration part of access_token.
  • the API invoker can determine whether to initiate a revocation request according to the trigger condition to revoke the first token.
  • the method flow shown in FIG4 also includes:
  • API invoker determines whether to initiate a token revocation request.
  • the API invoker when the trigger condition is met, the API invoker requests the CCF to revoke the first token.
  • the API invoker may request the CCF to revoke the first token through a first request message.
  • the API invoker determines whether to send a revocation request (Revocation Request) message to CCF based on different trigger conditions to request token revocation.
  • triggering conditions include but are not limited to the following conditions:
  • the instruction is obtained by the API invoker, and the API invoker can initiate the process of revoking the first token based on the instruction.
  • the API invoker receives a notification message from CCF, which contains an event notification message from CCF.
  • the events notified by the event notification message include but are not limited to:
  • the specified service API is not available (SERVICE_API_UNAVAILABLE);
  • the specified service API has been upgraded (SERVICE_API_UPDATE);
  • API invoker is offline (API_INVOKER_OFFBOARDED);
  • API invoker authorization is revoked (API_INVOKER_AUTHORIZATION_REVOKED);
  • API invoker has been upgraded (API_INVOKER_UPDATED);
  • API topology hiding has been created (API_TOPOLOGY_HIDING_CREATED);
  • API topology hiding is revoked (API_TOPOLOGY_HIDING_REVOKED), etc.
  • the API invoker receives a rejection message from AEF.
  • the API invoker receives a message from AEF indicating that the API caller is not authorized (e.g., a 401 indication), the specified service API is unavailable (e.g., a 503 indication), and other protocol errors, application errors, and other reasons.
  • the API Invoker triggers token revocation after receiving a message from CCF or AEF, and can automatically revoke expired tokens to improve system robustness.
  • the trigger conditions a) to c) above are only examples of how the API invoker determines whether to initiate a token revocation request, and do not constitute any limitation on the scope of protection of this application.
  • the API invoker can also trigger the initiation of a token revocation request in other ways.
  • the network side CCF or AEF
  • the API invoker can periodically initiate a token revocation request. Examples are not given here one by one.
  • the API invoker determines not to initiate a token revocation request.
  • the API invoker determines to initiate a token revocation request.
  • this embodiment mainly involves the token revocation process, so the following mainly describes the process after the API invoker determines to initiate a token revocation request, and does not elaborate on the case where the API invoker determines not to initiate a token revocation request (for example, the API invoker can wait for the trigger condition to be met before initiating a token revocation request).
  • the API invoker determines to initiate a token revocation request, it sends a first request message to the CCF to request the CCF to revoke the first token.
  • the method flow shown in FIG4 also includes:
  • API invoke sends the first request message to CCF, or CCF receives the first request message from API invoke.
  • the first request message is used to request the revocation of the first token.
  • the first request message may be called a revocation request message, and the first request message includes a token type and a corresponding token, wherein the token type is used to indicate the type of the revoked token, which may be an access_token and/or a refresh_token, and the token is used to indicate the value of the revoked token.
  • this embodiment mainly involves revocation of access_token, and the first request message includes a token type indicating that the type of the revoked token is access_token.
  • revoking the first token is used as an example for explanation, and the first request message also includes the first token.
  • API invoke can also send a first request message to CCF to request the cancellation of refresh_token, but this situation is not described in detail in this embodiment.
  • the CCF may send a second request message to the AEF, requesting the AEF to revoke the authorization of the API caller.
  • the CCF revokes the authorization of the received refresh_token without determining whether to send a second request message to the AEF.
  • CCF stores the received refresh_token in the revoked token list. If a refresh_token in the revoked token list is received later through a Refresh Request message, the refresh_token is considered invalid. In the case where the refresh_token is invalid, CCF rejects the API invoker's request to update the token.
  • This embodiment mainly considers the access_token revocation process.
  • CCF can request AEF to revoke the authorization of API invoker through a second request message.
  • the first request message includes the first token.
  • CCF determines AEF based on the declaration of the first token. For example, after receiving the first request message, CCF determines that the first token is access_token based on the token type carried in the first request message. Then, CCF obtains AEF ID based on the declaration of the first token carried in the first request message, and sends the second request message to AEF indicated by AEF ID based on AEF ID to request AEF to revoke the authorization of API invoker.
  • the AEF identifier already in the declaration of the first token can be used to allow CCF to actively push the revocation information to be revoked to AEF, so as to ensure that the first token can be pushed to the correct AEF in real time, so as to realize the correct revocation of authorization of the first token.
  • the method flow shown in FIG4 also includes:
  • S440 The CCF sends a second request message to the AEF, or the AEF receives the second request message from the CCF.
  • the second request message is used to request the AEF to revoke the authorization of the API invoker, and the second request message includes the first token and/or the declaration of the first token.
  • the first token and/or the declaration of the first token may be referred to as revocation information, and the revocation information is used to indicate the authorization to be revoked.
  • the second request message may be a message sent by an existing CCF to an AEF, and the second request message also includes second indication information, which is used to indicate the revocation of authorization of the API invoker.
  • the second indication information is a newly added element in the second request message, indicating a newly added function of the existing message.
  • the second indication information may also be used to indicate the revocation of authorization of a token type, so that the AEF verifies the information of revoking authorization during the process of verifying the token.
  • the second indication information can also be used to indicate the needs of the API invoker, such as, the second indication information can also be used to indicate that the API invoker requests to revoke the access_token.
  • the above instructions illustrate how to reuse the used signaling to request AEF to revoke the authorization of API invoker by adding a new cell in the existing signaling.
  • the original function of the second request message can be other functions except the function indicated by the second indication information, but the function of requesting to revoke the authorization of API invoker is realized by adding a new cell.
  • the second request message is a newly added message sent by CCF to AEF.
  • the function of the second request message can be defined as revoking API invoker authorization.
  • the second request message includes revocation information, and the revocation information is used to indicate the information required to revoke the API invoker authorization.
  • the revocation information may be a first token.
  • the revocation information may be a statement of the first token.
  • the revocation information is part or all of the statement of the first token, such as the revocation information is at least one of the corresponding API invoker ID, Service API ID, user ID, and other information of the first token.
  • the capability can be negotiated between CCF and AEF through the second request message.
  • the capabilities of AEF involved in this embodiment mainly include whether to support the capability of revoking authorization, and the capabilities of CCF mainly include whether to support the capability of revoking tokens. Whether to support the revocation of authorization affects whether the token revocation can be successful, so whether AEF supports the capability of revoking authorization involved below can be described as whether AEF supports the capability of revoking tokens.
  • the second request message may also include second capability information to indicate the capabilities supported by the CCF.
  • the second capability information indicates whether the CCF supports the revocation of the first token.
  • the AEF may inform its own capabilities by responding to the second request message. Specifically, the AEF sends a second response message to the CCF, and the second response message carries the capabilities supported by the AEF. If the AEF supports revocation of authorization, the second response message includes the capability of the AEF to support revocation of authorization, otherwise the second response message does not include the capability of the AEF to support revocation of authorization.
  • CCF can determine whether to send the second request message to AEF before sending the second request message to AEF. That is to say, before CCF actively pushes the second request message, it determines in advance whether AEF supports the ability to revoke authorization, and does not send the second request message if it does not support it, thereby reducing the overhead of system messages.
  • the CCF may determine whether to send the second request message to the AEF in the following ways:
  • the first authorization entity does not need to send the second request message.
  • the CCF may not need to send the second request message.
  • CCF can send the second request message.
  • the CCF can obtain the capability information of the AEF in advance, the CCF can determine whether to send the second request message to the AEF based on the capability information of the AEF.
  • CCF may obtain the capability information of AEF through the following process:
  • Step 1 AEF sends a first message to CCF, and the first message includes capability information of AEF. For example, if AEF supports revocation of authorization, the capability information of AEF indicates that AEF supports revocation of authorization.
  • Step 2 CCF sends a second message to AEF, and the second message includes the capability information of CCF.
  • CCF learns whether AEF supports revoking authorization. If CCF supports revoking tokens, CCF carries the capability information of CCF in the second message to indicate that CCF supports revoking tokens; if CCF does not support revoking tokens, CCF carries the capability information of CCF in the second message to indicate that CCF does not support revoking tokens.
  • AEF sends request message #1 to CCF, and CCF sends reply message #1 to AEF.
  • Request message #1 includes the first capability information of AEF, which is used to indicate whether AEF supports the ability to revoke the authorization of API invoker.
  • the request message #1 can be a service API publish request message.
  • Reply message #1 includes the capabilities supported by CCF, wherein if CCF supports the ability to revoke tokens, reply message #1 includes the ability that CCF supports to revoke tokens, otherwise reply message #1 does not include the ability to revoke tokens.
  • CCF may determine that AEF does not support the ability to revoke the authorization of API invoker or CCF does not support the revocation of token. In this case, CCF may not send the second request message to AEF and directly send the first response message to API invoker.
  • the first response message carries a first reason value, and the first reason value is used to indicate the reason why the revocation of the first token failed.
  • the first cause value is used to indicate that the CCF does not support the revocation of the current type of token, for example, it may be unsupported_token_type.
  • the API invoker can optionally reselect a CCF after receiving the first response message.
  • the CCF reselected by the API invoker is called the second CCF.
  • the API invoker sends the above-mentioned first request message #1 to the second CCF, requesting the revocation of the first token and re-initiating the token revocation process.
  • the actions performed by the second CCF after re-initiating the token revocation process are similar to those performed by the above-mentioned CCF, which will not be repeated here.
  • the API invoker before the API invoker reselects the second CCF, it determines that the number of failed first token revocations is less than a threshold. That is, after the CCF is reselected a preset number of times (e.g., 3 times) without success, the API invoker stops initiating token revocation.
  • the API invoker can request CCF to provide a token with a timeout period less than the duration threshold.
  • the API invoker can request CCF to provide a token with a timeout period less than the duration threshold.
  • the API invoker stops requesting revocation of the first token.
  • the AEF after the AEF receives the second request message, it executes the authorization revocation process according to the revocation information carried in the second request message.
  • the method process shown in FIG4 also includes:
  • AEF executes revocation of authorization according to the revocation information.
  • the AEF determines to revoke the authorization according to the revocation information after receiving the second request message.
  • the AEF may determine to revoke the authorization according to the revocation information based on the second indication information carried in the second request message.
  • capability information is not negotiated between CCF and AEF, that is, in this implementation, after receiving the second request message, AEF may fail to revoke the authorization indicated by the revocation information according to the revocation information.
  • AEF receives a second request message, and the second request message includes second capability information, and the second capability information includes the ability of CCF to support revoking tokens.
  • AEF compares the second capability information with the capabilities it supports. If AEF does not support the ability to revoke tokens, AEF replies with third capability information through the first indication information.
  • the third capability information does not include the ability to support revoking tokens, which means that the ability to revoke tokens is not supported by both AEF and CCF. Therefore, it implicitly indicates that the revocation result is a revocation failure, and the reason for the failure is that AEF does not support the ability to revoke tokens.
  • the first indication information may also include a second reason value, and the second reason value is used to indicate that the reason for the failure of revocation is that AEF does not support revocation of authorization.
  • CCF may send a first reason value to the API invoker based on the second reason value, and the first reason value indicates that the reason for the failure of revocation of the first token is that AEF does not support revocation of authorization.
  • AEF supports revocation of authorization, but if the revocation fails due to other reasons, for example, the first token is invalid (e.g., the signature verification of the first token fails, or the first token has expired, or the first token does not belong to the current API invoker) or the first token has been revoked, AEF indicates that the revocation result is revocation failure through a first indication message.
  • the first indication information may further include a second reason value, where the second reason value is used to indicate that the reason for the revocation failure is that the first token is invalid, the first token has been revoked, etc.
  • the AEF performs the following steps to revoke authorization:
  • AEF stores the received first token in a token revocation list, where the token revocation list is used to record revoked tokens. If AEF subsequently receives an API invocation request message sent by API invoker, and the access_token carried in the API invocation request is in the token revocation list, then the aceess_token is considered invalid and the API call is rejected.
  • the AEF receives a service request message, which includes a first token.
  • the AEF determines that the first token is revoked according to a locally cached token revocation list (such as determining that the first token is in the token revocation list)
  • the AEF rejects the service request message.
  • the AEF stores the received declaration part of the first token in the revocation list.
  • the AEF obtains the timeout period of the first token, the API invoker ID, the AEF ID, the authorization API, user ID, etc., and stores this information in an information list, where the information list is used to record the information of the revoked token. If the timeout period expires, AEF can remove the line of information in the information list. If AEF subsequently receives an API invocation Request message sent by API invoker, and the access_token statement in the message is in the information list, the access_token is considered invalid and the API call is rejected.
  • the AEF receives a service request message, which includes a first token.
  • the AEF determines that the first token is revoked according to the locally cached information list (such as determining that the declaration of the first token is in the information list)
  • the AEF rejects the service request message.
  • AEF rejects the API invocation Request message of the API invoker.
  • the reason value can be unauthorized_client, which is used to indicate that this API call is not authorized.
  • the method flow shown in FIG4 further includes:
  • the AEF sends first indication information to the CCF, or the CCF receives the first indication information from the AEF.
  • the first indication information is used to indicate the revocation result.
  • the revocation result may be a revocation success or a revocation failure.
  • the first indication information may also carry a second reason value to indicate the reason for the revocation failure.
  • the AEF revocation failure may be due to the fact that the AEF does not support the capability of revoking authorization, and thus the AEF fails to revoke authorization.
  • the second cause value carried in the first indication information is used to indicate that the reason for the revocation failure is that the AEF does not support the capability of revoking authorization.
  • AEF revocation failure may be due to the first token being an invalid token (e.g., the signature verification of the first token fails, or the first token has expired, or the first token does not belong to the current API invoker) or the first token is a revoked token.
  • the second reason value carried in the first indication information is used to indicate that the reason for the revocation failure is that the first token is invalid, the first token has been revoked, etc.
  • the AEF may indicate a revocation failure by indicating an error request, indicating that the server does not understand the syntax of the request, and the like.
  • the CCF and the AEF may complete the negotiation of the capability information through the second request message and the first indication information.
  • the specific negotiation process includes:
  • AEF receives a second request message, and the second request message includes second capability information, and the second capability information includes the ability of CCF to support revoking tokens.
  • AEF compares the second capability information with the capabilities it supports. If AEF does not support the ability to revoke tokens, AEF replies with third capability information through the first indication information.
  • the third capability information does not include the ability to support revoking tokens, which means that the ability to revoke tokens is not supported by both AEF and CCF. Therefore, it implicitly indicates that the revocation result is a revocation failure, and the reason for the failure is that AEF does not support the ability to revoke tokens.
  • CCF After receiving the first indication information and learning the revocation result, CCF notifies API invoker of the revocation result through a first response message.
  • the method flow shown in FIG4 also includes:
  • CCF sends the first response message to the API invoker, or the API invoker receives the first response message from CCF.
  • the first response message is used to indicate a successful revocation or a failed revocation.
  • the first response message may also carry a first cause value, where the first cause value is used to indicate the reason for the token revocation failure.
  • the first cause value is used to indicate that the CCF does not support the revocation of the current type of token, for example, it may be unsupported_token_type.
  • the API invoker can optionally reselect a CCF after receiving the first response message.
  • the CCF reselected by the API invoker is called the second CCF.
  • the API invoker sends the above-mentioned first request message #1 to the second CCF, requesting the revocation of the first token and re-initiating the token revocation process.
  • the API invoker reselects the CCF, which can eliminate the revocation failure caused by the CCF not supporting the revocation authorization capability, and stops reselecting after multiple unsuccessful reselections, which can prevent the revocation failure caused by the specific AEF not supporting the revocation authorization capability. Therefore, the probability of successful revocation is improved.
  • the first cause value is used to indicate that the AEF does not support the ability to revoke the API invoker's authorization (e.g., the CCF receives the second cause value from the AEF, indicating that the AEF does not support the ability to revoke the API invoker's authorization).
  • the API invoker may stop requesting the revocation of the first token after receiving the first response message;
  • the API invoker can request the CCF to provide a token with a timeout period less than the duration threshold.
  • the API invoker can request the CCF to provide a token with a timeout period less than the duration threshold.
  • the communication method shown in FIG4 is that CCF actively notifies AEF to revoke authorization in a timely manner. In this way, the authorization of the token will be revoked in real time, thereby achieving real-time revocation.
  • the present application also provides a communication method that controls the timeout duration of the token by sensing the capabilities or requirements of the API invoker through CCF, thereby achieving a method of passively revoking authorization. The method is described in detail below in conjunction with FIG5.
  • FIG5 is a schematic flow chart of another communication method provided by the present application, comprising the following steps:
  • API invoker sends the first information to CCF.
  • the first information is used to instruct CCF to provide a token with a timeout period that is less than the time threshold.
  • the timeout period that is less than the time threshold can be understood as a shorter timeout period of the token.
  • the timeout period of the token provided by CCF is 10 hours. If CCF receives the first information from API invoker#1, the timeout period of the token provided by CCF to API invoker#1 is 1 hour (or other values less than 1), thereby increasing security.
  • the first information includes at least one of the following information:
  • Information indicating the business security requirement to be processed by the API caller (eg, high business security requirement).
  • the API invoker indicates through the first information that the token timeout period required by the API invoker is less than 2 hours; for another example, the API invoker indicates through the first information that the token timeout period required by the API invoker is 1 hour; for another example, the API invoker indicates through the first information that the security requirement for the current business to be processed is high.
  • the API invoker sends the first information to CCF through the registration request or discovery service request process.
  • an API invoker sends a registration request message to CCF for the API invoker to register with CCF, and the registration request message carries the first information.
  • an API invoker sends a service discovery request message to CCF for the API invoker to discover a service API.
  • the service discovery request message carries the first information.
  • the API invoker sends the first message to CCF by initiating the token revocation process.
  • the API invoker receives a first response message indicating that the token revocation fails, then the API invoker can send a first message to the CCF to request a token with a timeout duration less than the duration threshold.
  • the API invoker sends the first message to CCF through the process of requesting to obtain a token.
  • the API invoker sends an authorization request message to the CCF for the API invoker to obtain authorization.
  • the authorization request message carries the first information.
  • CCF may provide the API invoker with a token whose timeout duration is less than the duration threshold.
  • the method flow shown in FIG5 also includes:
  • CCF sends the first token to the API invoker.
  • the timeout duration of the first token is less than the duration threshold.
  • the first information is the information that the API invoker supports the ability to revoke tokens.
  • CCF senses the ability of the API invoker to support the revocation of tokens, and can treat API invokers differently. Setting the token timeout too short may increase signaling overhead, because the API invoker will frequently request new tokens from the CCF, but setting it too long may result in reduced security. Therefore, by sensing the capabilities of the API invoker, it is possible to avoid treating all API invokers equally, which affects the overall communication performance, but it is also possible to distinguish API invokers that support the ability to revoke tokens, and only provide such API invokers with tokens with shorter timeouts, thereby ensuring the stability of the system.
  • CCF can determine based on the capability information of the API invoker whether to reply with a supported capability indication to indicate whether CCF supports the ability to revoke the token.
  • CCF If CCF also supports the ability to revoke tokens, then the supported capabilities include the ability to revoke tokens. Otherwise, the supported capabilities do not include the ability to revoke tokens. CCF saves the capability information of the API invoker.
  • CCF sends a registration response message or a discovery service response message to the API invoker.
  • the registration response message or the discovery service response message includes supported capabilities, and the supported capabilities are used to indicate capabilities supported by both CCF and the API invoker.
  • the CCF may send the first token to the API invoker through the current authorization process, including the following steps:
  • Step 1 API invoker sends Obtain Authorization Request message to CCF, which is used to request a token to access AEF.
  • Obtain Authorization Request message contains API invoker ID and AEF ID.
  • Step 2 CCF determines to provide a token with a timeout duration less than the duration threshold based on the first information of the API invoker cached locally.
  • CCF After receiving the authorization request message, CCF obtains the capability information of the API invoker corresponding to the API invoker ID according to the API invoker ID. If the API invoker supports the ability to revoke the token, CCF sets the timeout time to a shorter time, such as 1 hour, when generating access_token.
  • the shorter time is a preconfigured time and is not limited in this embodiment.
  • CCF If the API invoker does not support the ability to revoke tokens, CCF generates access_tokens using a normal timeout period, which is another preconfigured period, such as 15 days.
  • the CCF sending the first token and the first information to the API invoker can be implemented through the current authorization process, including the following steps:
  • Step 1 API invoker sends an Obtain Authorization Request message to CCF, which is used to request a token to access AEF.
  • the Obtain Authorization Request message contains API invoker ID, AEF ID and the first information.
  • Step 2 CCF provides the API invoker with a token with a timeout duration less than the duration threshold based on the first information in the authorization request message.
  • CCF determines to provide a token with a timeout period less than the time threshold for the API invoker according to the first information carried in the authorization request message. For example, when CCF generates access_token, it sets the timeout period to a shorter period, such as 1 hour.
  • the shorter period is a preconfigured period, which is not limited in this embodiment.
  • CCF can also determine to provide a token with a timeout period less than the time threshold based on the fact that AEF does not support revocation of authorization. That is to say, the above step S510 is optional. Even if the API invoker does not provide the first information, CCF can also determine to provide a token with a timeout period less than the time threshold based on the capability information of AEF. It can be understood that in this embodiment, CCF can sense the capabilities of AEF. If AEF does not support the ability to actively revoke tokens, then CCF sets a shorter token timeout period.
  • AEF supports the ability to actively revoke tokens
  • CCF does not need to specially set the token timeout period, but uses the method shown in Figure 4 for active revocation. In this way, when AEF does not support the ability to actively revoke tokens, security can be increased at the cost of increased signaling overhead. When AEF supports the ability to actively revoke tokens, security can be guaranteed without increasing signaling overhead.
  • CCF determines to use a shorter timeout based on the first information of the API invoker and/or the fact that AEF does not support the ability to revoke tokens.
  • CCF obtains the capability information of AEF, wherein the process of CCF obtaining the capability information of AEF can refer to the description of CCF obtaining the capability information of AEF in FIG4 , which is not repeated here.
  • CCF saves the capability of AEF.
  • CCF obtains the capability of AEF from the saved AEF capability according to the AEF ID in the Obtain Authorization Request message.
  • Step 3 After CCF confirms that the API invoker can access the API name authorization according to the local policy, it sends Obtain Authorization Response to the API invoker to obtain the authorization response message, which contains the first token, and the first token contains the declaration of the first token.
  • the declaration of the first token contains the timeout period.
  • the API invoker can passively revoke authorization without actively revoking authorization.
  • the present application also provides a communication method, in which the AEF actively requests the CCF to verify whether the authorization is revoked.
  • the method is described in detail below in conjunction with Figure 6.
  • FIG6 is a schematic flow chart of another communication method provided by the present application, comprising the following steps:
  • the API invoker obtains the first token from the CCF, or the CCF provides the first token to the API invoker.
  • API invoker determines whether to initiate a token revocation request.
  • API invoke sends the first request message to CCF, or CCF receives the first request message from API invoke.
  • steps S610 to S620 reference may be made to the description of steps S410 to S430 in FIG. 4 , which will not be repeated here.
  • the first token is revoked according to the first request message.
  • the method flow shown in FIG6 further includes:
  • S640 The CCF revokes the first token according to the first request message.
  • CCF stores the first token received into a token revocation list, where the token revocation list is used to record revoked tokens.
  • the refresh_token if a refresh_token in the revocation list is subsequently received through a Refresh Request message, the refresh_token is considered invalid. In the case where the refresh_token is invalid, CCF rejects the update token request of API invoke.
  • access_token after receiving the AEF verification request, it is determined whether the access_token is valid. See the subsequent step S680, which will not be repeated here.
  • the CCF stores the declaration part of the received first token into an information list, wherein the information list is used to record the information of the revoked authorization token.
  • CCF obtains the timeout period, API invoker ID, authorization API, user ID, etc. of the first token based on the declaration of the first token, and stores this information in an information list. If the timeout period expires, CCF can remove the row of information in the revocation list.
  • refresh_token For refresh_token, if the refresh_token statement received through the Refresh Request message is consistent with the information list, the refresh_token is considered invalid. In the case of invalid refresh_token, CCF rejects the API invoker's request to update the token.
  • access_token After receiving the AEF verification request, it is determined whether the access_token is valid. The specific determination is shown in the subsequent step S680, which will not be repeated here.
  • CCF sends the first response message to the API invoker, or the API invoker receives the first response message from CCF.
  • the first response message is used to indicate whether the first token is revoked successfully or failed.
  • the first response message may also carry a first cause value. If it is due to the CCF not supporting the ability to revoke tokens, the first cause value may be unsupported_token_type, etc., to indicate that the CCF does not support the revocation of the current type of token.
  • the API invoker can reselect a CCF after receiving the first response message.
  • the CCF reselected by the API invoker is called the second CCF.
  • the API invoker sends the above-mentioned first request message to the second CCF to re-initiate the token revocation process.
  • the actions performed by the second CCF after re-initiating the token revocation process are similar to those performed by the above-mentioned CCF, which will not be repeated here.
  • the API invoker determines that the number of failed first token revocations is less than a threshold before reselecting the second CCF. That is, after reselecting the CCF a preset number of times (such as 3 times) has not been successful, the API invoker stops initiating token revocation.
  • API invoker sends an API call request message to AEF.
  • the API invoker can be the API invoker that initiates the token revocation process mentioned above.
  • API invoker#1 can also send an API call request message to AEF.
  • the API invoker may be a different API invoker from the API invoker that initiates the token revocation process mentioned above.
  • API invoker#1 initiates the revocation process for the first token, and API invoker#2 sends an API call request message to AEF.
  • the API call request message contains API invoker ID, service API ID, user ID and token.
  • the AEF may send an authorization verification request message to the CCF, requesting the CCF to verify whether the token carried in the API call request message is valid.
  • the AEF after receiving the API call request message, the AEF directly sends an authorization verification request message to the CCF, requesting the CCF to verify whether the token carried in the API call request message is valid.
  • AEF determines whether it is necessary to send an authorization verification request message to CCF. It can be understood that AEF does not blindly send an authorization verification request message to CCF. If it is not necessary to send, there is no need to send the authorization verification request message; if it is necessary to send, the authorization verification request message is sent. Unnecessary signaling overhead can be avoided.
  • AEF obtains the token carried in the API call request message and determines whether it is necessary to send an authorization verification request message to CCF based on the timeout period of the token. If the timeout period of the token is greater than a certain threshold, AEF determines to send an authorization verification request message to CCF, otherwise, AEF determines not to send an authorization verification request message to CCF and considers that the token has not been revoked.
  • AEF obtains the token carried in the API call request message, and determines whether it is necessary to send an authorization verification request message to CCF according to the number of times the token is used. If the number of times the token is used is greater than a certain threshold, AEF determines to send an authorization verification request message to CCF, otherwise, AEF determines not to send an authorization verification request message to CCF, and considers that the token has not been revoked.
  • This embodiment mainly involves a process in which the AEF sends an authorization verification request message to the CCF.
  • the method process shown in FIG6 also includes:
  • AEF sends an authorization verification request message to CCF.
  • the authorization verification request message is used to request authorization verification, and the authorization verification request message includes the first token and/or the declaration of the first token.
  • the first token and/or the declaration of the first token can be referred to as authorization verification information, and the authorization verification information is used to indicate Indicates the information to be verified.
  • the authorization verification request message may be a message sent by an existing AEF to a CCF, and the authorization verification request message further includes third indication information, which is used to indicate authorization verification.
  • the third indication information is a new information element added to the authorization verification request message, indicating a new function of the existing message.
  • the second indication information may also be used to indicate the revocation of authorization of the token type, so that the CCF verifies the information to be verified during the token verification process.
  • the third indication information may also be used to indicate a requirement of the AEF, for example, the third indication information may also be used to indicate that the AEF requests authorization to verify the information to be verified.
  • the above instructions illustrate how to reuse the used signaling to request CCF authorization verification by adding new cells in the existing signaling.
  • the original function of the authorization verification request message can be other functions except the function indicated by the third indication information, but the authorization verification function is realized by adding new cells.
  • the authorization verification request message is a newly added message sent by the AEF to the CCF.
  • the function of the authorization verification request message can be defined as authorization verification.
  • the authorization verification request message includes authorization verification information, which is used to indicate the authorization to be verified.
  • the authorization verification information may be a first token.
  • the authorization verification information may be a declaration of the first token.
  • the authorization verification information is part or all of the declaration of the first token, such as the authorization verification information is at least one of the corresponding API invoker ID, Service API ID, user ID, and other information of the first token.
  • CCF and AEF may negotiate capability through the authorization verification request message.
  • the authorization verification request message may also include fourth capability information, which is used to indicate the capabilities supported by the AEF.
  • the fourth capability information indicates whether the AEF supports the ability to verify that a token has been revoked.
  • the CCF may inform its own capabilities by responding to the authorization verification request message. Specifically, the CCF sends an authorization verification response message to the AEF, and the authorization verification response message carries the capabilities supported by the CCF. If the AEF supports revoking authorization, the authorization verification response message includes the ability of the CCF to support verification that a token has been revoked. Otherwise, the authorization verification response message does not include the ability of the CCF to support verification that a token has been revoked.
  • the AEF may obtain the capability information of the CCF before sending the authorization verification request message to the CCF.
  • the AEF may obtain the capability information of the CCF through the following process:
  • Step 1 CCF sends a third message to AEF, and the third message includes capability information of CCF. For example, if CCF supports the capability of verifying that a token is revoked, the capability information of CCF indicates that CC supports the capability of verifying that a token is revoked.
  • Step 2 AEF sends a fourth message to CCF, and the fourth message includes the capability information of AEF. For example, after receiving the third message, AEF learns whether CCF supports the capability of verifying that the token is revoked. If AEF supports the capability of verifying that the token is revoked, AEF carries the capability information of CCF in the fourth message to indicate that CCF supports the capability of verifying that the token is revoked; if AEF does not support the capability of verifying that the token is revoked, AEF carries the capability information of AEF in the fourth message to indicate that AEF does not support the capability of verifying that the token is revoked.
  • AEF sends request message #2 to CCF
  • CCF sends reply message #2 to AEF.
  • Request message #2 includes capability information of AEF, which is used to indicate whether AEF supports the capability of verifying token revocation.
  • Request message #2 may be a Service API publish request message.
  • Reply message #2 includes supported capabilities, where if CCF also supports the capability of verifying token revocation, the supported capabilities also include the capability of verifying token revocation, otherwise the supported capabilities do not include the capability of verifying token revocation.
  • AEF may determine whether CCF supports the capability of verifying that the token is revoked based on the capability information supported by CCF before sending the authorization verification request message to CCF. If not, AEF may not send the authorization verification request message to CCF. That is to say, before AEF sends the authorization verification request message, it determines in advance whether CCF supports the capability of verifying that the token is revoked, and does not send the authorization verification request message if it does not support it, thereby reducing the overhead of system messages.
  • the AEF may determine whether to send an authorization verification request message to the CCF in the following ways:
  • the AEF before sending the authorization verification request message, the AEF knows that the CCF does not support the capability of verifying that a token is revoked, so the first authorization entity does not need to send the authorization verification request message.
  • the AEF may not need to send the authorization verification request message.
  • the AEF before sending the authorization verification request message, the AEF knows that the CCF supports the capability of verifying that a token is revoked, and the AEF may send the authorization verification request message.
  • AEF determines that CCF does not support the ability to verify token revocation
  • AEF can directly send an API call response message to the API invoker, and the API call response message is used to reject the API call.
  • the API call response message includes a rejection reason value #1, and the reason value #1 is an unauthorized user (unauthorized client).
  • the CCF after receiving the authorization verification request message from the AEF, performs authorization verification.
  • the method flow shown in FIG6 also includes:
  • CCF performs authorization verification according to the authorization verification information.
  • the CCF determines to revoke the authorization according to the revocation information after receiving the authorization verification request message.
  • the CCF can determine to perform the authorization verification according to the authorization verification information based on the third indication information carried in the authorization verification request message.
  • CCF may reject the authorization verification request because it does not support authorization verification.
  • CCF receives an authorization verification request message, and the authorization verification request message includes the capability information of AEF.
  • the capability information of AEF includes the ability of AEF to support the revocation of verification token.
  • CCF compares the capability information of AEF with the capabilities it supports. If CCF does not support the ability to verify the revocation of token, CCF replies to the capability information of CCF through an authorization verification response message.
  • the capability information of CCF does not include the ability to support the revocation of verification token, which means that the ability to verify the revocation of token is not supported by both AEF and CCF. Therefore, it implicitly indicates that the verification result is verification failure, and the reason for the failure is that CCF does not support the ability to verify the revocation of token.
  • the authorization verification response message also includes a reason value #2, where the reason value #2 is used to indicate that the reason for the verification failure is that the CCF does not support authorization verification.
  • CCF supports the ability to verify that a token has been revoked, but if the verification fails for other reasons, for example, Token #1 is invalid (e.g., the signature verification of Token #1 fails, or Token #1 has expired, or Token #1 does not belong to the current API invoker) or Token #1 has been revoked, CCF indicates that the verification result is successful through an authorization verification response message.
  • Token #1 is invalid (e.g., the signature verification of Token #1 fails, or Token #1 has expired, or Token #1 does not belong to the current API invoker) or Token #1 has been revoked
  • CCF indicates that the verification result is successful through an authorization verification response message.
  • CCF supports the ability to verify that a token has been revoked.
  • the CCF performs authorization verification including:
  • CCF stores a token revocation list. If the received token #1 is stored in the token revocation list, the token #1 is considered invalid;
  • CCF stores the information list. If the received declaration of token #1 is stored in the information list, token #1 is considered invalid.
  • CCF in addition to verifying whether token #1 is revoked, can also verify whether token #1 is valid during the authorization verification process. Specifically, if CCF does not verify whether token #1 is valid, AEF can verify whether token #1 is valid.
  • CCF sends an authorization verification response message to AEF.
  • CCF sends an authorization verification response message to AEF.
  • the authorization verification response message includes a verification result, which can be that the token is not revoked or that the token has been revoked, or that the token is valid or that the token is invalid.
  • the authorization verification response message also includes supported capabilities. If the CCF also supports the capability of verifying that a token is revoked, the supported capabilities also include the capability of verifying that a token is revoked, otherwise the supported capabilities do not include the capability of verifying that a token is revoked.
  • AEF sends an API call response message to the API invoker based on the verification result.
  • the message also includes a reason value #3.
  • Reason value #3 can be unsupported_token_type. unsupported_token_type is used to indicate that the AEF does not support the revocation of the current type of token.
  • the API invoker can try to reselect the AEF and initiate the API call attempt again. After the AEF is reselected a preset number of times (such as 3 times) and still fails, the API call attempt is stopped.
  • CCF determines whether AEF supports revoking authorization (the specific method of determining AEF capabilities can refer to the description in the above embodiment). If AEF supports revoking authorization, the process of revoking tokens is executed through the method shown in FIG4 to improve security. If AEF does not support revoking authorization, the method process shown in FIG5 is used to provide a token with a timeout duration less than the duration threshold to improve security.
  • CCF determines whether AEF supports revoking authorization. If AEF supports revoking authorization, the process of verifying the token is performed through the method shown in FIG6 to improve security. If AEF does not support revoking authorization, the method process shown in FIG5 is used to improve security by providing a token with a timeout duration less than the duration threshold.
  • the embodiment shown in FIG4 and the embodiment shown in FIG6 can be combined to form a new embodiment.
  • the AEF verifies the token carried in the API call request message according to the locally cached revoked token list (or information list), determines whether to approve the API call request of the API invoker, and for accuracy, according to the method flow shown in FIG6, the AEF verifies through the CCF whether the token carried in the API call request message is a valid token.
  • the devices in the existing network architecture are mainly used as examples for exemplary description (such as CCF, AEF, etc.), and it should be understood that the specific form of the device is not limited in the embodiments of the present application. For example, devices that can achieve the same function in the future are applicable to the embodiments of the present application.
  • the methods and operations implemented by the device can also be implemented by components of the device (such as chips or circuits).
  • the communication method provided by the embodiment of the present application is described in detail above in conjunction with Figures 4 to 6.
  • the above communication method is mainly introduced from the perspective of interaction between various protocol layers of the terminal device. It is understandable that in order to implement the above functions, the terminal device includes a hardware structure and/or software module corresponding to each function.
  • the embodiment of the present application can divide the functional modules of the transmitting end device or the receiving end device according to the above method example.
  • each functional module can be divided corresponding to each function, or two or more functions can be integrated into one processing module.
  • the above integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical functional division. There may be other division methods in actual implementation. The following is an example of dividing each functional module corresponding to each function.
  • FIG7 is a schematic block diagram of a communication device 10 provided in an embodiment of the present application.
  • the device 10 includes a transceiver module 11 and a processing module 12.
  • the transceiver module 11 can implement corresponding communication functions, and the processing module 12 is used to perform data processing, or in other words, the transceiver module 11 is used to perform operations related to receiving and sending, and the processing module 12 is used to perform other operations besides receiving and sending.
  • the transceiver module 11 can also be called a communication interface or a communication unit.
  • the device 10 may further include a storage module 13, which may be used to store instructions and/or data.
  • the processing module 12 may read the instructions and/or data in the storage module so that the device implements the actions of the devices in the aforementioned method embodiments.
  • the device 10 may correspond to the API invoker in the above method embodiment, or a component of the API invoker (such as a chip).
  • the device 10 can implement the steps or processes executed by the API invoker in the above method embodiment, wherein the transceiver module 11 can be used to execute the operations related to the sending and receiving of the API invoker in the above method embodiment, and the processing module 12 can be used to execute the operations related to the processing of CeEF in the above method embodiment.
  • the transceiver module 11 is used to obtain a first token from the first authorization entity, where the first token is used to represent that the communication device is authorized to access a specified service API; the transceiver module 11 is also used to determine, based on a trigger condition, to send a first request message to the first authorization entity, where the first request message is used to request the revocation of the first token.
  • the transceiver module 11 is used to send first information to the first authorization entity, where the first information is used to instruct the first authorization entity to provide a token whose timeout duration is less than a time threshold; the transceiver module 11 is also used to receive from the first authorization entity The entity obtains a first token, where the first token is used to represent that the communication device is authorized to access a specified service API, and a timeout duration of the first token is less than a duration threshold.
  • the transceiver module 11 can be used to execute the steps of sending and receiving information in the method, such as steps S410 , S430 and S470 ; the processing module 12 can be used to execute the processing steps in the method, such as step S420 .
  • the transceiver module 11 may be used to execute the steps of sending and receiving information in the method, such as steps S510 and S520 ; and the processing module 12 may be used to execute the processing steps in the method.
  • the transceiver module 11 can be used to execute the steps of sending and receiving information in the method, such as steps S610, S630, S650, S660 and S691; the processing module 12 can be used to execute the processing steps in the method, such as step S620.
  • the device 10 may correspond to the CCF in the above method embodiment, or be a component of the CCF (such as a chip).
  • the device 10 can implement the steps or processes corresponding to the CCF execution in the above method embodiment, wherein the transceiver module 11 can be used to perform the CCF transceiver related operations in the above method embodiment, and the processing module 12 can be used to perform the CCF processing related operations in the above method embodiment.
  • the transceiver module 11 is used to provide a first token to the API caller, wherein the first token is used to represent that the API caller is authorized to access a specified service API; the transceiver module 11 is also used to receive a first request message from the API caller, wherein the first request message is used to request the revocation of the first token; the transceiver module 11 is also used to send a second request message to the API open function network element, wherein the second request message is used to request the API open function network element to revoke the authorization of the API caller.
  • the transceiver module 11 is used to receive first information from the API caller, wherein the first information is used to instruct the communication device to provide a token whose timeout period is less than a time threshold; the processing module 12 is used to determine, based on the first information, that the timeout period of the first token is less than the time threshold, and the first token is used to represent that the API caller is authorized to access the specified service API; the transceiver module 11 is also used to provide the first token to the API caller.
  • the transceiver module 11 is used to provide a first token to the API caller, wherein the first token is used to represent that the API caller is authorized to access a specified service API; the transceiver module 11 is also used to receive a first request message from the API caller, wherein the first request message is used to request revocation of the first token, and the first request message includes the first token; the processing module 12 is used to cache the first token and/or the description information of the first token in a local revocation list of the communication device.
  • the transceiver module 11 can be used to execute the steps of sending and receiving information in the method, such as steps S410 , S430 , S440 , S460 , and S470 ; the processing module 12 can be used to execute the processing steps in the method.
  • the transceiver module 11 may be used to execute the steps of sending and receiving information in the method, such as steps S510 and S520 ; and the processing module 12 may be used to execute the processing steps in the method.
  • the transceiver module 11 can be used to execute the steps of sending and receiving information in the method, such as steps S610, S630, S670, and S690; the processing module 12 can be used to execute the processing steps in the method, such as step S680.
  • the device 10 may correspond to the AEF in the above method embodiment, or be a component (such as a chip) of the AEF.
  • the device 10 can implement the steps or processes corresponding to the AEF execution in the above method embodiment, wherein the transceiver module 11 can be used to perform the AEF transceiver related operations in the above method embodiment, and the processing module 12 can be used to perform the AEF processing related operations in the above method embodiment.
  • the transceiver module 11 is used to receive a second request message from the first authorization entity, the second request message is used to request the revocation of the authorization of the API caller, the second request message includes revocation information, and the revocation information is used to indicate the authorization to be revoked; the processing module 12 is used to revoke the authorization according to the revocation information; the transceiver module 11 is also used to send a first indication information to the first authorization entity, and the first indication information is used to indicate the revocation result.
  • the transceiver module 11 is used to receive an API call request message from the API caller, wherein the API call request message includes a first token, and the first token is used to represent that the API caller is authorized to access the specified service API; the transceiver module 11 is also used to send an authorization verification request message to the first authorization entity, and the authorization verification request message is used to request the first authorization entity to verify whether the first token is valid; the transceiver module 11 is also used to receive an authorization verification response message from the first authorization entity, and the authorization verification response message is used to indicate whether the first token is valid.
  • the transceiver module 11 may be used to execute the steps of sending and receiving information in the method, such as steps S440 and S460 ; the processing module 12 may be used to execute the processing steps in the method, such as step S450 .
  • the transceiver module 11 can be used to execute the steps of sending and receiving information in the method, such as steps S660, S670, S690 and S691; the processing module 12 can be used to execute the processing steps in the method.
  • module here may refer to an application specific integrated circuit (ASIC), an electronic circuit, a processor (such as a shared processor, a dedicated processor or a group processor, etc.) and a memory for executing one or more software or firmware programs, a merged logic circuit and/or other suitable components that support the described functions.
  • ASIC application specific integrated circuit
  • processor such as a shared processor, a dedicated processor or a group processor, etc.
  • memory for executing one or more software or firmware programs, a merged logic circuit and/or other suitable components that support the described functions.
  • the device 10 can be specifically the mobile management network element in the above-mentioned embodiment, and can be used to execute the various processes and/or steps corresponding to the mobile management network element in the above-mentioned method embodiments; or, the device 10 can be specifically the terminal device in the above-mentioned embodiment, and can be used to execute the various processes and/or steps corresponding to the terminal device in the above-mentioned method embodiments. To avoid repetition, it will not be repeated here.
  • the device 10 of each of the above schemes has the function of implementing the corresponding steps performed by the device (such as terminal device, network device) in the above method.
  • This function can be implemented by hardware, or by hardware executing the corresponding software implementation.
  • the hardware or software includes one or more modules corresponding to the above functions; for example, the transceiver module can be replaced by a transceiver (for example, the sending unit in the transceiver module can be replaced by a transmitter, and the receiving unit in the transceiver module can be replaced by a receiver), and other units, such as processing modules, can be replaced by processors to respectively perform the transceiver operations and related processing operations in each method embodiment.
  • the transceiver module 11 may also be a transceiver circuit (for example, may include a receiving circuit and a sending circuit), and the processing module may be a processing circuit.
  • FIG8 is a schematic diagram of another communication device 20 provided in an embodiment of the present application.
  • the device 20 includes a processor 21, and the processor 21 is used to execute a computer program or instruction stored in a memory 22, or read data/signaling stored in the memory 22 to execute the method in each method embodiment above.
  • the processor 21 is used to execute a computer program or instruction stored in a memory 22, or read data/signaling stored in the memory 22 to execute the method in each method embodiment above.
  • the device 20 further includes a memory 22, and the memory 22 is used to store computer programs or instructions and/or data.
  • the memory 22 can be integrated with the processor 21, or can also be separately arranged.
  • the memory 22 is one or more.
  • the device 20 further includes a transceiver 23, and the transceiver 23 is used for receiving and/or sending signals.
  • the processor 21 is used to control the transceiver 23 to receive and/or send signals.
  • the device 20 is used to implement the operations performed by the API invoker in the above method embodiments.
  • the device 20 is used to implement the operations performed by the CCF in the above method embodiments.
  • the device 20 is used to implement the operations performed by the AEF in the above method embodiments.
  • processors mentioned in the embodiments of the present application may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • the general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.
  • the memory mentioned in the embodiments of the present application may be a volatile memory and/or a non-volatile memory.
  • the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory.
  • the volatile memory may be a random access memory (RAM).
  • a RAM may be used as an external cache.
  • RAM includes the following forms: static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct rambus RAM (DR RAM).
  • SRAM static RAM
  • DRAM dynamic RAM
  • SDRAM synchronous DRAM
  • DDR SDRAM double data rate SDRAM
  • ESDRAM enhanced SDRAM
  • SLDRAM synchronous link DRAM
  • DR RAM direct rambus RAM
  • the processor is a general-purpose processor, DSP, ASIC, FPGA or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, the memory (storage module) can be integrated into the processor.
  • memory described herein is intended to include, but is not limited to, these and any other suitable types of memory.
  • FIG9 is a schematic diagram of a chip system 30 provided in an embodiment of the present application.
  • the chip system 30 (or also referred to as a processing system) includes a logic circuit 31 and an input/output interface 32.
  • the logic circuit 31 can be a processing circuit in the chip system 30.
  • the logic circuit 31 can be coupled to the storage unit and call the instructions in the storage unit so that the chip system 30 can implement the methods and functions of each embodiment of the present application.
  • the input/output interface 32 can be an input/output circuit in the chip system 30, outputting information processed by the chip system 30, or inputting data or signaling information to be processed into the chip system 30 for processing.
  • the chip system 30 is used to implement the operations performed by CCF, AEF, or API invoker in the above method embodiments.
  • the logic circuit 31 is used to implement the processing-related operations performed by the CCF, AEF, or API invoker in the above method embodiments;
  • the input/output interface 32 is used to implement the sending and/or receiving-related operations performed by the CCF, AEF, or API invoker in the above method embodiments.
  • An embodiment of the present application also provides a computer-readable storage medium on which computer instructions are stored for implementing the methods executed by CCF, AEF, or API invoker in the above-mentioned method embodiments.
  • the computer program when executed by a computer, the computer can implement the methods performed by CCF, AEF, or API invoker in each embodiment of the above method.
  • An embodiment of the present application also provides a computer program product, comprising instructions, which, when executed by a computer, implement the methods performed by CCF, AEF, or API invoker in the above-mentioned method embodiments.
  • An embodiment of the present application also provides a communication system, including the aforementioned CCF and AEF.
  • the communication system also includes an API invoker.
  • the disclosed devices and methods can be implemented in other ways.
  • the device embodiments described above are only schematic.
  • the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed.
  • the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
  • the computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.
  • the computer can be a personal computer, a server, or a network device, etc.
  • the computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center.
  • the computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that contains one or more available media integrations.
  • the available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state disk (SSD)).
  • the aforementioned available medium includes, but is not limited to, various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

一种通信方法，应用于通用应用软件编程接口框架CAPIF中，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，API开放功能网元用于在API调用者获得授权的情况下，向API调用者提供指定服务API的访问。该方法包括：API调用者从第一授权实体获取第一令牌，第一令牌用于表征API调用者被授权访问指定服务API。在满足某些触发条件的情况下，API调用者向第一授权实体请求撤销第一令牌。在CAPIF中API调用者可以发起第一令牌的撤销流程，提高安全保护。

Description

通信方法和通信装置
本申请要求于2022年11月04日提交国家知识产权局、申请号为202211378343.2、发明名称为“通信方法和通信装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信领域，并且更具体地，涉及一种通信方法和通信装置。
背景技术
第三代合作伙伴计划(3rd Generation Partnership Project，3GPP)能力放开架构提供了一种3GPP对外提供服务的方式。在这种架构下，应用功能(application function，AF)网元可以请求3GPP网络处理一些3GPP的信息。这些信息可以包含对于网络数据的处理，也可以包含用户数据的处理。特别对于用户数据的处理，AF应该需要获得用户的授权。例如，AF可以请求3GPP对外发送用户的位置信息，如果未获得用户的授权，可能会暴露了用户的隐私信息。
但是，用户授权以后，也有可能撤回授权。因此，如何设计一种撤回授权的方法成为亟待解决的问题。
发明内容
本申请实施例提供一种通信方法，API调用者可以发起令牌的撤销流程，以实现CAPIF中的令牌撤销。
第一方面，提供了一种通信方法，应用于CAPIF中，CAPIF中包括应用软件编程接口API调用者(API invoker)、第一授权实体和API开放功能网元(AEF)，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问。该方法可以由API调用者执行，或者，也可以由配置于API调用者中的芯片或电路执行，本申请对此不作限定。为了方便，以下以API调用者执行为例进行说明。
该通信方法包括：所述API调用者从所述第一授权实体获取第一令牌，所述第一令牌用于表征所述API调用者被授权访问所述指定服务API；在满足触发条件的情况下，所述API调用者向所述第一授权实体请求撤销所述第一令牌。其中，API调用者为需要调用服务API的实体，第一授权实体可以用于基于API调用者的标识和其它信息认证API调用者，API开放功能网元是服务API的提供者，也是服务API与API调用者的服务通信入口。
基于上述方案，在CAPIF中API调用者从第一授权实体获取到第一令牌之后，可以在某些触发条件满足的情况下，发起撤销第一令牌的流程，也就是说API调用者被配置的令牌可以通过撤销流程撤销，以实现API调用者主动撤销令牌，提高安全保护。
结合第一方面，在第一方面的某些实现方式中，所述触发条件包括所述API调用者接收到来自所述第一授权实体的事件通知消息，所述事件通知消息指示的事件包括以下至少一项：所述指定服务API不可使用、所述指定服务API已升级、所述API调用者掉线、所述指定服务API调用失败、接入控制策略不可用、所述API调用者授权被撤销、所述API调用者已升级、API拓扑隐藏已创建、API拓扑隐藏被撤销。
基于上述方案，API调用者发起第一令牌撤销流程所基于的触发条件可以是：第一授权实体发送的事件通知消息，也就是说可以在某些事件发生的情况下，撤销已配置的令牌，避免基于已配置的令牌执行调用服务API失败。
例如，发生指定服务API不可使用事件时，API调用者可以发起令牌撤销流程，避免通过已配置的令牌发起服务API的调用，而调用失败。
结合第一方面，在第一方面的某些实现方式中，所述触发条件包括所述API调用者接收到来自所述API开放功能网元的拒绝消息，所述拒绝消息指示的拒绝原因包括以下至少一项：所述API调用者未被授 权、所述指定服务API不可用、协议错误、或应用错误。
基于上述方案，API调用者发起第一令牌撤销流程所基于的触发条件可以是：API开放功能网元拒绝调用的消息，避免基于已配置的令牌执行调用服务API失败。
例如，API开放功能网元通过拒绝消息指示拒绝调用服务API，则API调用者在接收到拒绝消息之后，可以撤销已配置的令牌，从而避免通过已配置的令牌发起服务API的调用，而调用失败。
综上，不管触发条件是接收到来自第一授权实体的事件通知消息，还是接收到来自API开放功能网元的拒绝消息，都可以理解为API调用者接收来自网络侧的错误信息后触发令牌撤销，可自动化撤销已配置的令牌，提升系统鲁棒性。
结合第一方面，在第一方面的某些实现方式中，所述方法还包括：所述API调用者接收来自所述第一授权实体的第一原因值，所述第一原因值用于指示所述第一令牌撤销失败的原因。例如，第一原因值携带在第一响应消息中，所述第一响应消息用于指示所述第一令牌撤销成功或者失败，在第一响应消息用于指示所述第一令牌撤销失败的情况下，所述第一响应消息中携带所述第一原因值。
基于上述方案，撤销令牌失败的情况下，第一授权实体可以通过第一原因值通知API调用者撤销失败的原因，以使得API调用者能够获知本次撤销失败的原因，在该失败原因无法解决的情况下，避免重复发起撤销流程而造成不必要的信令开销。
结合第一方面，在第一方面的某些实现方式中，在所述第一令牌撤销失败的原因为所述第一授权实体不支持所述第一令牌撤销时，所述方法还包括：所述API调用者根据所述第一原因值重新选择第二授权实体，并向所述第二授权实体请求撤销所述第一令牌。
基于上述方案，撤销令牌失败的情况下，若本次撤销失败是由于第一授权实体不支持第一令牌撤销，API调用者可以重新选择一个第二授权实体，通过该第二授权实体发起撤销第一令牌的流程，提高撤销成功率。
结合第一方面，在第一方面的某些实现方式中，在所述API调用者重新选择所述第二授权实体之前，所述方法还包括：所述API调用者确定所述第一令牌撤销失败的次数小于次数门限。
基于上述方案，撤销令牌失败，且重选授权实体多次仍未撤销成功的情况下，API调用者停止重选授权实体，停止请求撤销第一令牌，避免是因为API开放功能网元不支持第一令牌撤销的情况下，盲目重选授权实体重复发起撤销令牌流程，而增大信令开销。
结合第一方面，在第一方面的某些实现方式中，在所述第一令牌撤销失败的原因为所述API开放功能网元不支持撤销授权时，所述API调用者向所述第一授权实体发送第一信息，所述第一信息用于指示所述第一授权实体提供超时时长小于时长门限的令牌；或者，所述API调用者停止请求撤销第一令牌。
基于上述方案，撤销令牌失败的情况下，若本次撤销失败是由于API开放功能网元不支持第一令牌撤销，API调用者可以通过第一信息指示第一授权实体提供超时时长小于时长门限的令牌，或者停止请求撤销第一令牌。保障了系统的稳定性。
结合第一方面，在第一方面的某些实现方式中，在所述API调用者从所述第一授权实体获取第一令牌之前，所述方法还包括：所述API调用者向所述第一授权实体发送第一信息，所述第一信息用于指示所述第一授权实体提供超时时长小于时长门限的令牌。
基于上述方案，API调用者通过第一信息告知自身的需求，可以实现第一授权实体有区别的对待不同API调用者。
结合第一方面，在第一方面的某些实现方式中，所述第一信息包括以下信息中的至少一项：指示所述API调用者支持撤销令牌能力的信息；指示所述API调用者所需令牌过期时长小于阈值的需求；指示所述API调用者所需令牌超时时长的信息；指示待所述API调用者处理的业务安全性要求的信息。
基于上述方案，API调用者可以通过不同的方式指示所需的令牌超时时长小于时长门限，提高方案的灵活性。
第二方面，提供了一种通信方法，应用于CAPIF中，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问。该方法可以由第一授权实体执行，或者，也可以由配置于第一授权实体中的芯片或电路执行，本申请对此不作限定。为了方便，以下以第一授权实体执行为例进行说明。
该通信方法包括：所述第一授权实体向所述API调用者提供第一令牌，所述第一令牌用于表征所述 API调用者被授权访问所述指定服务API；所述第一授权实体接收来自所述API调用者的第一请求消息，所述第一请求消息用于请求撤销所述第一令牌；所述第一授权实体根据向所述API开放功能网元发送第二请求消息，所述第二请求消息用于请求所述API开放功能网元撤销所述API调用者的授权。
基于上述方案，在CAPIF中第一授权实体在接收到来自API调用者的撤销第一令牌的第一请求消息之后，可以向API开放功能网元发送第二请求消息，以实现请求API开放功能网元撤销API调用者的授权，也就是说第一授权实体主动向API开放功能网元推送待撤销授权的撤销信息，以保障请求令牌撤销的事件能被实时推送到正确的API开放功能网元上被正确撤销，提高安全保护。
结合第二方面，在第二方面的某些实现方式中，所述第一授权实体接收来自所述API开放功能网元的第一指示信息，所述第一指示信息用于指示撤销结果。
结合第二方面，在第二方面的某些实现方式中，所述方法还包括：所述第一授权实体根据所述撤销结果，通知所述API调用者所述第一令牌撤销是否成功。
结合第二方面，在第二方面的某些实现方式中，在所述撤销结果为撤销所述API调用者的授权失败的情况下，所述第一指示信息中包括第二原因值，所述第二原因值用于指示撤销所述API调用者的授权失败的原因。
结合第二方面，在第二方面的某些实现方式中，所述第二请求消息中还包括第二指示信息，所述第二指示信息用于指示撤销所述API调用者的授权。
基于上述方案，第二请求消息可以为已有的第一授权实体向所述API开放功能网元发送的消息，而第二指示信息为第二请求消息中新增的信元。该实现方式下第二请求消息原本的功能可以为除撤销授权之外的其他功能，但是通过新增信元实现撤销授权的功能。
结合第二方面，在第二方面的某些实现方式中，第二请求消息为新增的第一授权实体向所述API开放功能网元发送的消息，该实现方式下第二请求消息的功能可以定义为撤销授权。
结合第二方面，在第二方面的某些实现方式中，所述第一请求消息中包括所述第一令牌，在所述第一授权实体向所述API开放功能网元发送第二请求消息之前，所述方法还包括：所述第一授权实体根据所述第一令牌的描述信息，确定所述API开放功能网元的标识。
结合第二方面，在第二方面的某些实现方式中，所述第一请求消息中包括令牌类型指示信息(token type)，在所述第一授权实体向所述API开放功能网元发送第二请求消息之前，所述方法还包括：所述第一授权实体根据所述令牌类型指示信息确定所述第一令牌为接入令牌(access_token)。
基于上述方案，第一授权实体可以根据第一令牌的描述信息确定API开放功能网元，确保请求令牌撤销的事件能被实时推送到正确的API开放功能网元上。
结合第二方面，在第二方面的某些实现方式中，在所述第一授权实体向所述API开放功能网元发送第二请求消息之前，所述方法还包括：所述第一授权实体确定所述API开放功能网元支持撤销所述API调用者的授权。
例如，所述第一授权实体获取所述API开放功能网元的第一能力信息，所述第一能力信息用于指示所述API开放功能网元支持撤销所述API调用者的授权。
基于上述方案，第一授权实体在发送第二请求消息之前可以获取API开放功能网元的能力信息，在API开放功能网元支持撤销令牌的前提下向API开放功能网元发送第二请求消息，通过提前判断API开放功能网元是否支持撤销所述API调用者的授权的能力，并在不支持的情况下不发送第二请求消息，从而减少对系统消息的开销。
结合第二方面，在第二方面的某些实现方式中，所述第二请求消息包括所述第一令牌和/或所述第一令牌的描述信息。
结合第二方面，在第二方面的某些实现方式中，所述第二请求消息中还包括第二能力信息，所述第二能力信息用于指示所述第一授权实体支持撤销令牌。
结合第二方面，在第二方面的某些实现方式中，在所述撤销结果为撤销所述API调用者的授权成功的情况下，所述方法还包括：所述第一授权实体向所述API调用者发送第一响应消息，所述第一响应消息用于指示所述第一令牌撤销成功。
结合第二方面，在第二方面的某些实现方式中，所述方法还包括：所述第一授权实体根据所述撤销结果，通知所述API调用者所述第一令牌撤销是否成功。
结合第二方面，在第二方面的某些实现方式中，在所述撤销结果为撤销所述API调用者的授权失败 的情况下，所述第一指示信息中包括第二原因值，所述第二原因值用于指示撤销所述API调用者的授权失败的原因为所述API开放功能网元不支持撤销所述API调用者的授权。
结合第二方面，在第二方面的某些实现方式中，所述方法还包括：所述第一授权实体根据所述第二原因值，通知所述API调用者所述第一令牌撤销失败的原因为所述API开放功能网元不支持撤销所述API调用者的授权。
基于上述方案，撤销令牌失败的情况下，第一授权实体可以通过第一原因值通知API调用者撤销失败的原因，以使得API调用者能够获知本次撤销失败的原因，在该失败原因无法解决的情况下，避免重复发起撤销流程而造成不必要的信令开销。
结合第二方面，在第二方面的某些实现方式中，在所述第一授权实体向所述API调用者提供第一令牌之前，所述方法还包括：所述第一授权实体接收来自所述API调用者的第一信息，所述第一信息用于指示所述第一授权实体提供超时时长小于时长门限的令牌；所述第一授权实体根据所述第一信息生成超时时长小于时长门限的所述第一令牌。
基于上述方案，API调用者通过第一信息告知自身的需求，可以实现第一授权实体有区别的对待不同API调用者，为需要超时时长小于时长门限令牌的API调用者提供满足需求的令牌。
结合第二方面，在第二方面的某些实现方式中，所述第一信息包括以下信息中的至少一项：指示所述API调用者支持撤销令牌能力的信息；指示所述API调用者所需令牌超时时长小于阈值的需求；指示所述API调用者所需令牌超时时长的信息；指示待所述API调用者处理的业务安全性要求的信息。
基于上述方案，API调用者可以通过不同的方式指示所需的令牌超时时长小于时长门限，提高方案的灵活性。
第三方面，提供了一种通信方法，应用于CAPIF中，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问。该方法可以由API开放功能网元执行，或者，也可以由配置于API开放功能网元中的芯片或电路执行，本申请对此不作限定。为了方便，以下以API开放功能网元执行为例进行说明。
该通信方法包括：所述API开放功能网元接收来自所述第一授权实体的第二请求消息，所述第二请求消息用于请求撤销所述API调用者的授权；所述API开放功能网元根据所述撤销信息撤销所述授权得到撤销结果，其中，所述撤销结果包括撤销所述API调用者的授权成功或者失败。
基于上述方案，在CAPIF中第一授权实体可以向API开放功能网元发送第二请求消息，以实现请求API开放功能网元撤销API调用者的授权，也就是说第一授权实体主动向API开放功能网元推送待撤销授权的撤销信息，以保障请求令牌撤销的事件能被实时推送到正确的API开放功能网元上被正确撤销，提高安全保护。
结合第三方面，在第三方面的某些实现方式中，所述方法还包括：所述API开放功能网元向所述第一授权实体发送第一指示信息，所述第一指示信息用于指示撤销结果。
结合第三方面，在第三方面的某些实现方式中，所述第一请求消息还包括第二指示信息，所述第二指示信息用于指示撤销所述API调用者的授权；所述API开放功能网元根据所述撤销信息撤销所述授权，包括：所述API开放功能网元根据所述第二指示信息确定根据所述撤销信息撤销所述授权。
基于上述方案，第二请求消息可以为已有的第一授权实体向所述API开放功能网元发送的消息，而第二指示信息为第二请求消息中新增的信元。该实现方式下第二请求消息原本的功能可以为除撤销所述API调用者的授权之外的其他功能，但是通过新增信元实现请求撤销所述API调用者的授权的功能。
结合第三方面，在第三方面的某些实现方式中，在所述API开放功能网元接收来自所述第一授权实体的第二请求消息之前，所述方法还包括：所述API开放功能网元向所述第一授权实体发送第一能力信息，所述第一能力信息用于指示所述API开放功能网元支持撤所述API调用者的销授权。
基于上述方案，第一授权实体在发送第二请求消息之前可以获取API开放功能网元的能力信息，在API开放功能网元支持撤销令牌的前提下向API开放功能网元发送第二请求消息，通过提前判断API开放功能网元是否支持撤销所述API调用者的授权的能力，并在不支持的情况下不发送第二请求消息，从而减少对系统消息的开销。
结合第三方面，在第三方面的某些实现方式中，在所述第二请求消息包括所述第一令牌时，所述API开放功能网元根据所述第二请求消息撤销所述授权，包括：所述API开放功能网元将所述第一令牌缓存 至所述API开放功能网元本地的令牌撤销列表中，其中，所述令牌撤销列表用于记录被撤销授权的令牌。
结合第三方面，在第三方面的某些实现方式中，在所述API开放功能网元根据所述第二请求消息撤销所述授权之后，所述方法还包括：所述API开放功能网元接收服务请求消息，所述服务请求消息中包括所述第一令牌；在根据所述令牌撤销列表确定所述第一令牌被撤销授权之后，所述API开放功能网元拒绝所述服务请求消息。
结合第三方面，在第三方面的某些实现方式中，根据所述令牌撤销列表确定所述第一令牌被撤销授权包括：确定所述第一令牌在所述令牌撤销列表中。
结合第三方面，在第三方面的某些实现方式中，在所述第二请求消息包括所述第一令牌的描述信息时，所述API开放功能网元根据所述第二请求消息撤销所述授权，包括：所述API开放功能网元将所述第一令牌的描述信息缓存至所述API开放功能网元的信息列表中，其中，所述信息列表用于记录被撤销授权的令牌的信息。
结合第三方面，在第三方面的某些实现方式中，在所述API开放功能网元根据所述第二请求消息撤销所述授权之后，所述方法还包括：所述API开放功能网元接收服务请求消息，所述服务请求消息中包括所述第一令牌；在根据所述信息列表确定所述第一令牌被撤销授权之后，所述API开放功能网元拒绝所述服务请求消息。
结合第三方面，在第三方面的某些实现方式中，根据所述信息列表确定所述第一令牌被撤销授权包括：确定所述第一令牌的描述信息在所述信息列表中。
结合第三方面，在第三方面的某些实现方式中，在所述撤销结果为撤销所述API调用者的授权失败的情况下，所述第一指示信息中包括第二原因值，所述第二原因值用于指示撤销所述API调用者的授权失败的原因为所述API开放功能不支持撤销所述API调用者的授权。
第四方面，提供了一种通信方法，应用于CAPIF中，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问。该方法可以由API调用者执行，或者，也可以由配置于API调用者中的芯片或电路执行，本申请对此不作限定。为了方便，以下以API调用者执行为例进行说明。
该通信方法包括：所述API调用者向所述第一授权实体发送第一信息，所述第一信息用于指示所述第一授权实体提供超时时长小于时长门限的令牌；所述API调用者从所述第一授权实体获取第一令牌，所述第一令牌用于表征所述API调用者被授权访问服务所述指定服务API，所述第一令牌的超时时长小于时长门限。
基于上述方案，在CAPIF中API调用者通过第一信息告知自身的需求，以使得第一授权实体感知API调用者的需求，可以实现有区别的对待不同的API调用者。令牌超时时间设置过短可能导致信令开销增多，因为API调用者会频繁向第一授权实体请求新的令牌，但令牌超时时间设置过长又可能导致安全性降低。
因此，通过感知API调用者的需求，可以避免对所有API调用者都一视同仁，影响整体通信性能，但也可以区分出需要超时时长小于时长门限的令牌的API调用者，仅为这类API调用者提供超时时间较短的令牌，从而保障了系统的稳定性。
结合第四方面，在第四方面的某些实现方式中，所述第一信息包括以下信息中的至少一项：指示所述API调用者支持撤销令牌能力的信息；指示所述API调用者所需令牌超时时长小于阈值的需求；指示所述API调用者所需令牌超时时长的信息；指示待所述API调用者处理的业务安全性要求的信息。
基于上述方案，API调用者可以通过不同的方式指示所需的令牌超时时长小于时长门限，提高方案的灵活性。
结合第四方面，在第四方面的某些实现方式中，所述方法还包括：所述API调用者接收来自所述第一授权实体的第二信息，所述第二信息用于指示所述第一授权实体和所述API调用者均支持的能力。
第五方面，提供了一种通信方法，应用于CAPIF中，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问。该方法可以由第一授权实体执行，或者，也可以由配置于第一授权实体中的芯片或电路执行，本申请对此不作限定。为了方便，以下以第一授权实体执行为例进行说明。
该通信方法包括：所述第一授权实体接收来自所述API调用者的第一信息，所述第一信息用于指示所述第一授权实体提供超时时长小于时长门限的令牌；所述第一授权实体根据所述第一信息生成超时时长小于时长门限的所述第一令牌，所述第一令牌用于表征所述API调用者被授权访问所述指定服务API；所述第一授权实体向所述API调用者提供所述第一令牌。
基于上述方案，在CAPIF中API调用者通过第一信息告知自身的需求，以使得第一授权实体感知API调用者的需求，可以实现有区别的对待不同的API调用者。令牌超时时间设置过短可能导致信令开销增多，因为API调用者会频繁向第一授权实体请求新的令牌，但令牌超时时间设置过长又可能导致安全性降低。
因此，通过感知API调用者的需求，可以避免对所有API调用者都一视同仁，影响整体通信性能，但也可以区分出需要超时时长小于时长门限的令牌的API调用者，仅为这类API调用者提供超时时间较短的令牌，从而保障了系统的稳定性。
结合第五方面，在第五方面的某些实现方式中，所述第一信息包括以下信息中的至少一项：指示所述API调用者支持撤销令牌能力的信息；指示所述API调用者所需令牌超时时长小于阈值的需求；指示所述API调用者所需令牌超时时长的信息；指示待所述API调用者处理的业务安全性要求的信息。
基于上述方案，API调用者可以通过不同的方式指示所需的令牌超时时长小于时长门限，提高方案的灵活性。
结合第五方面，在第五方面的某些实现方式中，所述方法还包括：所述第一授权实体向所述API调用者发送第二信息，所述第二信息用于指示所述第一授权实体和所述API调用者均支持的能力。
结合第五方面，在第五方面的某些实现方式中，在所述第一授权实体向所述API调用者提供所述第一令牌之前，所述方法还包括：所述第一授权实体确定所述API开放功能网元不支持撤销所述API调用者的授权。
基于上述方案，若API开放功能网元不支持主动撤销所述API调用者的授权的能力，那么第一授权实体就设置较短超时时长的令牌。这样当API开放功能网元不支持主动撤销所述API调用者的授权能力时，可以以在增加信令开销的代价下增加安全性。
第六方面，提供了一种通信方法，应用于CAPIF中，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问。该方法可以由第一授权实体执行，或者，也可以由配置于第一授权实体中的芯片或电路执行，本申请对此不作限定。为了方便，以下以第一授权实体执行为例进行说明。
该通信方法包括：所述第一授权实体向所述API调用者提供第一令牌，所述第一令牌用于表征所述API调用者被授权访问所述指定服务API；所述第一授权实体接收来自所述API调用者的第一请求消息，所述第一请求消息用于请求撤销所述第一令牌；所述第一授权实体将所述第一令牌和/或所述第一令牌的描述信息缓存至所述第一授权实体本地的撤销列表中。
基于上述方案，在CAPIF中API调用者从第一授权实体获取到第一令牌之后，可以在某些触发条件满足的情况下，通过第一请求消息发起撤销第一令牌的流程，也就是说API调用者被配置的令牌可以通过撤销流程撤销，以实现API调用者主动撤销令牌，提高安全保护。
结合第六方面，在第六方面的某些实现方式中，所述方法还包括：所述第一授权实体向所述API调用者发送第一响应消息，所述第一响应消息用于指示所述第一令牌撤销成功或失败。
结合第六方面，在第六方面的某些实现方式中，在所述第一授权实体向所述API调用者提供第一令牌之前，所述方法还包括：所述第一授权实体接收来自所述API调用者的第一信息，所述第一信息用于指示所述第一授权实体提供超时时长小于时长门限的令牌；所述第一授权实体根据所述第一信息生成超时时长小于时长门限的所述第一令牌。
基于上述方案，API调用者通过第一信息告知自身的需求，可以实现第一授权实体有区别的对待不同API调用者。
结合第六方面，在第六方面的某些实现方式中，所述第一信息包括以下信息中的至少一项：指示所述API调用者支持撤销令牌能力的信息；指示所述API调用者所需令牌超时时长小于阈值的需求；指示所述API调用者所需令牌超时时长的信息；指示待所述API调用者处理的业务安全性要求的信息。
基于上述方案，API调用者可以通过不同的方式指示所需的令牌超时时长小于时长门限，提高方案的 灵活性。
结合第六方面，在第六方面的某些实现方式中，所述方法还包括：所述第一授权实体向所述API调用者发送第二信息，所述第二信息用于指示所述第一授权实体和所述API调用者均支持的能力。
结合第六方面，在第六方面的某些实现方式中，所述方法还包括：所述第一授权实体接收来自所述API开放功能网元的授权校验请求消息，所述授权校验请求消息用于请求所述第一授权实体校验所述第一令牌是否有效；所述第一授权实体根据所述第一授权实体本地的撤销列表和所述第一令牌确定所述第一令牌是否有效；所述第一授权实体向所述API开放功能网元发送授权校验响应消息，所述授权校验响应消息用于指示所述第一令牌是否有效。
基于上述方案，API开放功能网元主动发送授权校验请求消息，请求第一授权实体校验授权是否被撤销的，以实现实时校验令牌是否被撤销。
结合第六方面，在第六方面的某些实现方式中，所述授权校验请求消息中包括以下信息中的至少一项：所述第一令牌、所述第一令牌的描述信息、或所述API开放功能网元的能力信息。
第七方面，提供了一种通信方法，应用于CAPIF中，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问。该方法可以由API开放功能网元执行，或者，也可以由配置于API开放功能网元中的芯片或电路执行，本申请对此不作限定。为了方便，以下以API开放功能网元执行为例进行说明。
该通信方法包括：所述API开放功能网元接收来自所述API调用者的API调用请求消息，所述API调用请求消息包括第一令牌，所述第一令牌用于表征所述API调用者被授权访问所述指定服务API；所述API开放功能网元向所述第一授权实体发送授权校验请求消息，所述授权校验请求消息用于请求所述第一授权实体校验所述第一令牌是否有效；所述API开放功能网元接收来自所述第一授权实体的授权校验响应消息，所述授权校验响应消息用于指示所述第一令牌是否有效。
基于上述方案，在CAPIF中API开放功能网元主动发送授权校验请求消息，请求第一授权实体校验授权是否被撤销的，以实现实时校验令牌是否被撤销。
结合第七方面，在第七方面的某些实现方式中，所述授权校验请求消息中包括以下信息中的至少一项：所述第一令牌、所述第一令牌的描述信息、或所述API开放功能网元的能力信息。
结合第七方面，在第七方面的某些实现方式中，在所述API开放功能网元向所述第一授权实体发送授权校验请求消息之前，所述方法还包括：所述API开放功能网元确定所述第一授权实体支持校验令牌是否有效。
基于上述方案，在API开放功能网元主动发送授权校验请求消息前，通过提前判断第一授权实体是否支持校验授权的能力，并在不支持的情况下不发送授权校验请求消息，从而减少对系统消息的开销。
结合第七方面，在第七方面的某些实现方式中，所述API开放功能网元向所述API调用者发送API调用响应消息，所述API调用响应消息用于拒绝或接受API调用，在所述API调用响应消息用于拒绝API调用的情况下，所述API调用响应消息中包括拒绝的原因值。
第八方面，提供了一种通信装置，该装置可以为CAPIF中的API调用者，或者可以为API调用者中的芯片或电路，用于实现上述第一方面所示的方法，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问。
该装置包括：收发模块，用于从所述第一授权实体获取第一令牌，所述第一令牌用于表征所述通信装置被授权访问所述指定服务API；所述收发模块，还用于在满足触发条件的情况下，向所述第一授权实体请求撤销所述第一令牌。
结合第八方面，在第八方面的某些实现方式中，所述触发条件包括所述收发模块接收到来自所述第一授权实体的事件通知消息，所述事件通知消息指示的事件包括以下至少一项：所述指定服务API不可使用、所述指定服务API已升级、所述通信装置掉线、所述指定服务API调用失败、接入控制策略不可用、所述通信装置授权被撤销、所述通信装置已升级、API拓扑隐藏已创建、API拓扑隐藏被撤销。
结合第八方面，在第八方面的某些实现方式中，所述触发条件包括所述收发模块接收到来自所述API开放功能网元的拒绝消息，所述拒绝消息指示的拒绝原因包括以下至少一项：所述API调用者未被授权、所述指定服务API不可用、协议错误、或应用错误。
结合第八方面，在第八方面的某些实现方式中，所述收发模块，还用于接收来自所述第一授权实体的第一原因值，所述第一原因值用于指示所述第一令牌撤销失败的原因。例如，第一原因值携带在第一响应消息中，所述第一响应消息用于指示所述第一令牌撤销成功或者失败，在第一响应消息用于指示所述第一令牌撤销失败的情况下，所述第一响应消息中携带所述第一原因值。
结合第八方面，在第八方面的某些实现方式中，在所述第一令牌撤销失败的原因为所述第一授权实体不支持所述第一令牌撤销时，所述装置还包括：处理模块，用于根据所述第一原因值重新选择第二授权实体；所述收发模块，还用于向所述第二授权实体请求撤销所述第一令牌。
结合第八方面，在第八方面的某些实现方式中，在所述处理模块重新选择所述第二授权实体之前，所述处理模块还用于确定所述第一令牌撤销失败的次数小于次数门限。
结合第八方面，在第八方面的某些实现方式中，在所述第一令牌撤销失败的原因为所述API开放功能网元不支持所述第一令牌撤销时，所述收发模块，还用于向所述第一授权实体发送第一信息，所述第一信息用于指示所述第一授权实体提供超时时长小于时长门限的令牌；或者，所述通信装置停止请求撤销第一令牌。
结合第八方面，在第八方面的某些实现方式中，在所述收发模块从所述第一授权实体获取第一令牌之前，所述收发模块，还用于向所述第一授权实体发送第一信息，所述第一信息用于指示所述第一授权实体提供超时时长小于时长门限的令牌。
结合第八方面，在第八方面的某些实现方式中，所述第一信息包括以下信息中的至少一项：指示所述通信装置支持撤销令牌能力的信息；指示所述通信装置所需令牌超时时长小于阈值的需求；指示所述通信装置所需令牌超时时长的信息；指示待所述API调用者处理的业务安全性要求的信息。
结合第八方面，在第八方面的某些实现方式中，所述收发模块，还用于接收来自所述第一授权实体的第二信息，所述第二信息用于指示所述第一授权实体和所述通信装置均支持的能力。
以上第八方面及其可能的设计所示方法的技术效果可参照第一方面及其可能的设计中的技术效果。
第九方面，提供了一种通信装置，该装置可以为CAPIF中的第一授权实体，或者可以为第一授权实体中的芯片或电路，用于实现上述第二方面所示的方法，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问。
该装置包括：收发模块，用于向所述API调用者提供第一令牌，所述第一令牌用于表征所述API调用者被授权访问所述指定API；所述收发模块，还用于接收来自所述API调用者的第一请求消息，所述第一请求消息用于请求撤销所述第一令牌；所述收发模块，还用于向所述API开放功能网元发送第二请求消息，所述第二请求消息用于请求所述API开放功能网元撤销所述API调用者的授权。
结合第九方面，在第九方面的某些实现方式中，所述收发模块，还用于接收来自所述API开放功能网元的第一指示信息，所述第一指示信息用于指示撤销结果。
结合第九方面，在第九方面的某些实现方式中，所述第二请求消息中还包括第二指示信息，所述第二指示信息用于指示撤销所述API调用者的授权。
结合第九方面，在第九方面的某些实现方式中，第二请求消息为新增的所述通信装置向所述API开放功能网元发送的消息，该实现方式下第二请求消息的功能可以定义为撤销所述API调用者的授权。
结合第九方面，在第九方面的某些实现方式中，所述第一请求消息中包括所述第一令牌，在所述收发模块向所述API开放功能网元发送第二请求消息之前，处理模块，用于根据所述第一令牌的描述信息获得所述API开放功能网元的标识。
结合第九方面，在第九方面的某些实现方式中，所述第一请求消息中包括令牌类型指示信息(token type)，在所述收发模块向所述API开放功能网元发送第二请求消息之前，处理模块，用于根据所述令牌类型指示信息确定所述第一令牌为接入令牌(access_token)。
结合第九方面，在第九方面的某些实现方式中，在所述收发模块向所述API开放功能网元发送第二请求消息之前，所述处理模块获取所述API开放功能网元的第一能力信息，所述第一能力信息用于指示所述API开放功能网元支持撤销所述API调用者的授权。
结合第九方面，在第九方面的某些实现方式中，所述第二请求消息包括所述第一令牌和/或所述第一令牌的描述信息。
结合第九方面，在第九方面的某些实现方式中，所述第二请求消息中还包括第二能力信息，所述第 二能力信息用于指示所述通信装置支持撤销令牌。
结合第九方面，在第九方面的某些实现方式中，在所述撤销结果为撤销所述API调用者的授权成功的情况下，所述收发模块，还用于向所述API调用者发送第一响应消息，所述第一响应消息用于指示所述第一令牌撤销成功。
结合第九方面，在第九方面的某些实现方式中，在所述撤销结果为撤销所述API调用者的授权失败的情况下，所述处理模块根据所述撤销结果向所述API调用者发送第一原因值，所述第一原因值用于指示所述第一令牌撤销失败的原因。
结合第九方面，在第九方面的某些实现方式中，所述第一指示信息中包括第二原因值，所述第二原因值用于指示撤销所述API调用者的授权失败的原因为所述API开放功能不支持所述撤销所述API调用者的授权，所述第一令牌撤销失败的原因为所述API开放功能不支持撤销所述API调用者的授权；在所述收发模块根据所述撤销结果向所述API调用者发送第一原因值之前，所述处理模块实体根据所述第二原因值，通知所述API调用者所述第一令牌撤销失败的原因为所述API开放功能网元不支持撤销所述API调用者的授权。
结合第九方面，在第九方面的某些实现方式中，在所述收发模块向所述API调用者提供第一令牌之前，所述收发模块，还用于接收来自所述API调用者的第一信息，所述第一信息用于指示所述通信装置提供超时时长小于时长门限的令牌；所述处理模块根据所述第一信息确定所述第一令牌的超时时长小于时长门限。
结合第九方面，在第九方面的某些实现方式中，所述第一信息包括以下信息中的至少一项：指示所述API调用者支持撤销令牌能力的信息；指示所述API调用者所需令牌超时时长小于阈值的需求；指示所述API调用者所需令牌超时时长的信息；指示待所述API调用者处理的业务安全性要求的信息。
结合第九方面，在第九方面的某些实现方式中，所述收发模块，还用于向所述API调用者发送第二信息，所述第二信息用于指示所述通信装置和所述API调用者均支持的能力。
以上第九方面及其可能的设计所示方法的技术效果可参照第二方面及其可能的设计中的技术效果。
第十方面，提供了一种通信装置，该装置可以为CAPIF中的API开放功能网元，或者可以为API开放功能网元中的芯片或电路，用于实现上述第三方面所示的方法，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问。
该装置包括：收发模块，用于接收来自所述第一授权实体的第二请求消息，所述第二请求消息用于请求撤销所述API调用者的授权，所述第二请求消息包括撤销信息，所述撤销信息用于指示待撤销的授权；处理模块，用于根据所述撤销信息撤销所述授权；所述收发模块，还用于向所述第一授权实体发送第一指示信息，所述第一指示信息用于指示撤销结果。
结合第十方面，在第十方面的某些实现方式中，所述第一请求消息还包括第二指示信息，所述第二指示信息用于指示撤销所述API调用者的授权；所述A处理模块根据所述撤销信息撤销所述授权，包括：所述处理模块根据所述第二指示信息确定根据所述撤销信息撤销所述授权。
结合第十方面，在第十方面的某些实现方式中，在所述收发模块接收来自所述第一授权实体的第二请求消息之前，所述收发模块，还用于向所述第一授权实体发送第一能力信息，所述第一能力信息用于指示所述通信装置支持撤销所述API调用者的授权。
结合第十方面，在第十方面的某些实现方式中，在所述第二请求消息包括所述第一令牌时，所述处理模块根据所述第二请求消息撤销所述授权，包括：所述处理模块将所述第一令牌缓存至所述通信装置本地的令牌撤销列表中，其中，所述令牌撤销列表用于记录被撤销授权的令牌。
结合第十方面，在第十方面的某些实现方式中，在所述处理模块根据所述撤销信息撤销所述授权之后，所述收发模块，还用于接收服务请求消息，所述服务请求消息中包括所述第一令牌；在根据所述令牌撤销列表确定所述第一令牌被撤销授权之后，所述处理模块拒绝所述服务请求消息。
结合第十方面，在第十方面的某些实现方式中，在所述第二请求消息包括所述第一令牌的描述信息时，所述处理模块根据所述第二请求消息撤销所述授权，包括：所述处理模块将所述第一令牌的描述信息缓存至所述通信装置的信息列表中，其中，所述信息列表用于记录被撤销授权的令牌的信息。
结合第十方面，在第十方面的某些实现方式中，在所述处理模块根据所述第二请求消息撤销所述授权之后，所述收发模块，还用于接收服务请求消息，所述服务请求消息中包括所述第一令牌；在根据所 述信息列表确定所述第一令牌被撤销授权之后，所述处理模块拒绝所述服务请求消息。
结合第十方面，在第十方面的某些实现方式中，在所述撤销结果为撤销所述API调用者的授权失败的情况下，所述第一指示信息中包括第二原因值，所述第二原因值用于指示撤销所述API调用者的授权失败的原因为所述通信装置不支持撤销所述API调用者的授权。
以上第十方面及其可能的设计所示方法的技术效果可参照第三方面及其可能的设计中的技术效果。
第十一方面，提供了一种通信装置，该装置可以为CAPIF中的API调用者，或者可以为API调用者中的芯片或电路，用于实现上述第四方面所示的方法，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问。
该装置包括：收发模块，用于向所述第一授权实体发送第一信息，所述第一信息用于指示所述第一授权实体提供超时时长小于时长门限的令牌；所述收发模块，还用于从所述第一授权实体获取第一令牌，所述第一令牌用于表征所述通信装置被授权访问所述指定服务API，所述第一令牌的超时时长小于时长门限。
结合第十一方面，在第十一方面的某些实现方式中，所述第一信息包括以下信息中的至少一项：指示所述通信装支持撤销令牌能力的信息；指示所述通信装所需令牌超时时长小于阈值的需求；指示所述通信装所需令牌超时时长的信息；指示待所述通信装处理的业务安全性要求的信息。
结合第十一方面，在第十一方面的某些实现方式中，所述收发模块，还用于接收来自所述第一授权实体的第二信息，所述第二信息用于指示所述第一授权实体和所述通信装置均支持的能力。
以上第十一方面及其可能的设计所示方法的技术效果可参照第四方面及其可能的设计中的技术效果。
第十二方面，提供了一种通信装置，该装置可以为CAPIF中的第一授权实体，或者可以为第一授权实体中的芯片或电路，用于实现上述第五方面所示的方法，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问。
该装置包括：收发模块，用于接收来自所述API调用者的第一信息，所述第一信息用于指示所述通信装置提供超时时长小于时长门限的令牌；处理模块，用于根据所述第一信息确定第一令牌的超时时长小于时长门限，所述第一令牌用于表征所述API调用者被授权访问所述指定服务API；所述收发模块，还用于向所述API调用者提供所述第一令牌。
结合第十二方面，在第十二方面的某些实现方式中，所述第一信息包括以下信息中的至少一项：指示所述API调用者支持撤销令牌能力的信息；指示所述API调用者所需令牌超时时长小于阈值的需求；指示所述API调用者所需令牌超时时长的信息；指示待所述API调用者处理的业务安全性要求的信息。
结合第十二方面，在第十二方面的某些实现方式中，所述收发模块，还用于向所述API调用者发送第二信息，所述第二信息用于指示所述通信装置和所述API调用者均支持的能力。
结合第十二方面，在第十二方面的某些实现方式中，在所述收发模块向所述API调用者提供所述第一令牌之前，所述处理模块还用于确定所述API开放功能网元不支持撤销所述API调用者的授权。
以上第十二方面及其可能的设计所示方法的技术效果可参照第五方面及其可能的设计中的技术效果。
第十三方面，提供了一种通信装置，该装置可以为CAPIF中的第一授权实体，或者可以为第一授权实体中的芯片或电路，用于实现上述第六方面所示的方法，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问。
该装置包括：收发模块，用于向所述API调用者提供第一令牌，所述第一令牌用于表征所述API调用者被授权访问所述指定服务API；所述收发模块，还用于接收来自所述API调用者的第一请求消息，所述第一请求消息用于请求撤销所述第一令牌，所述第一请求消息中包括所述第一令牌；处理模块，用于将所述第一令牌和/或所述第一令牌的描述信息缓存至所述通信装置本地的撤销列表中。
结合第十三方面，在第十三方面的某些实现方式中，所述收发模块，还用于向所述API调用者发送第一响应消息，所述第一响应消息用于指示所述第一令牌撤销成功或失败。
结合第十三方面，在第十三方面的某些实现方式中，在所述收发模块向所述API调用者提供第一令牌之前，所述收发模块，还用于接收来自所述API调用者的第一信息，所述第一信息用于指示所述通信装置提供超时时长小于时长门限的令牌；所述处理模块根据所述第一信息确定所述第一令牌的超时时长 小于时长门限。
结合第十三方面，在第十三方面的某些实现方式中，所述第一信息包括以下信息中的至少一项：指示所述API调用者支持撤销令牌能力的信息；指示所述API调用者所需令牌超时时长小于阈值的需求；指示所述API调用者所需令牌超时时长的信息；指示待所述API调用者处理的业务安全性要求的信息。
结合第十三方面，在第十三方面的某些实现方式中，所述收发模块，还用于向所述API调用者发送第二信息，所述第二信息用于指示所述通信装置和所述API调用者均支持的能力。
结合第十三方面，在第十三方面的某些实现方式中，所述收发模块，还用于接收来自所述API开放功能网元的授权校验请求消息，所述授权校验请求消息用于请求所述通信装置校验所述第一令牌是否有效；所述处理模块根据所述通信装置本地的撤销列表和所述第一令牌确定所述第一令牌是否有效；所述收发模块，还用于向所述API开放功能网元发送授权校验响应消息，所述授权校验响应消息用于指示所述第一令牌是否有效。
结合第十三方面，在第十三方面的某些实现方式中，所述授权校验请求消息中包括以下信息中的至少一项：所述第一令牌、所述第一令牌的描述信息、或所述API开放功能网元的能力信息。
以上第十三方面及其可能的设计所示方法的技术效果可参照第六方面及其可能的设计中的技术效果。
第十四方面，提供了一种通信装置，该装置可以为CAPIF中的API开放功能网元，或者可以为API开放功能网元中的芯片或电路，用于实现上述第七方面所示的方法，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问。
该装置包括：收发模块，用于接收来自所述API调用者的API调用请求消息，所述API调用请求消息包括第一令牌，所述第一令牌用于所述信装置验证是否授权所述API调用者访问所述指定服务API；所述收发模块，还用于向所述第一授权实体发送授权校验请求消息，所述授权校验请求消息用于请求所述第一授权实体校验所述第一令牌是否有效；所述收发模块，还用于接收来自所述第一授权实体的授权校验响应消息，所述授权校验响应消息用于指示所述第一令牌是否有效。
结合第十四方面，在第十四方面的某些实现方式中，所述授权校验请求消息中包括以下信息中的至少一项：所述第一令牌、所述第一令牌的描述信息、或所述通信装置的能力信息。
结合第十四方面，在第十四方面的某些实现方式中，在所述收发模块向所述第一授权实体发送授权校验请求消息之前，所述处理模块确定所述第一授权实体支持校验令牌是否有效。
结合第十四方面，在第十四方面的某些实现方式中，所述收发模块，还用于向所述API调用者发送API调用响应消息，所述API调用响应消息用于拒绝或接受API调用，在所述API调用响应消息用于拒绝API调用的情况下，所述API调用响应消息中包括拒绝的原因值。
以上第十四方面及其可能的设计所示方法的技术效果可参照第七方面及其可能的设计中的技术效果。
第十五方面，提供了一种通信系统，包括第一授权实体和API开放功能网元，其中，所述第一授权实体用于执行上述第二方面所示的方法，所述API开放功能网元执行上述第三方面所示的方法。
结合第十五方面，在第十五方面的某些实现方式中，所述通信系统还包括API调用者，所述API调用者执行上述第一方面所示的方法。
第十六方面，提供了一种通信系统，包括第一授权实体和API调用者，其中，所述API调用者用于执行上述第四方面所示的方法，所述第一授权实体执行上述第五方面所示的方法。
第十七方面，提供了一种通信系统，包括第一授权实体和API开放功能网元，其中，所述第一授权实体用于执行上述第六方面所示的方法，所述API开放功能网元执行上述第七方面所示的方法。
结合第十七方面，在第十七方面的某些实现方式中，所述通信系统还包括API调用者，所述API调用者执行上述第一方面所示的方法。
第十八方面，提供一种通信装置，该装置包括：存储器，用于存储程序；处理器，用于执行存储器存储的程序，当存储器存储的程序被执行时，处理器用于执行上述各方面提供的方法。
第十九方面，本申请提供一种处理器，用于执行上述各方面提供的方法。在执行这些方法的过程中，上述方法中有关发送上述信息和获取/接收上述信息的过程，可以理解为由处理器输出上述信息的过程，以及处理器接收输入的上述信息的过程。在输出上述信息时，处理器将该上述信息输出给收发器，以便由收发器进行发射。该上述信息在由处理器输出之后，还可能需要进行其他的处理，然后再到达收发器。类似的，处理器接收输入的上述信息时，收发器获取/接收该上述信息，并将其输入处理器。更进一步的， 在收发器收到该上述信息之后，该上述信息可能需要进行其他的处理，然后再输入处理器。
基于上述原理，举例来说，前述方法中提及的接收请求消息可以理解为处理器接收输入的信息。
对于处理器所涉及的发射、发送和获取/接收等操作，如果没有特殊说明，或者，如果未与其在相关描述中的实际作用或者内在逻辑相抵触，则均可以更加一般性的理解为处理器输出和接收、输入等操作，而不是直接由射频电路和天线所进行的发射、发送和接收操作。
在实现过程中，上述处理器可以是专门用于执行这些方法的处理器，也可以是执行存储器中的计算机指令来执行这些方法的处理器，例如通用处理器。上述存储器可以为非瞬时性(non-transitory)存储器，例如只读存储器(read only memory，ROM)，其可以与处理器集成在同一块芯片上，也可以分别设置在不同的芯片上，本申请实施例对存储器的类型以及存储器与处理器的设置方式不做限定。
第二十方面，提供一种计算机可读存储介质，该计算机可读介质存储用于设备执行的程序代码，该程序代码包括用于执行上述各方面提供的方法。
第二十一方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机用于执行上述各方面提供的方法。
第二十二方面，提供一种芯片，该芯片包括处理器与通信接口，该处理器通过该通信接口读取存储器上存储的指令，用于执行上述各方面提供的方法。
可选地，作为一种实现方式，该芯片还可以包括存储器，该存储器中存储有指令，该处理器用于执行该存储器上存储的指令，当该指令被执行时，该处理器用于执行上述各方面提供的方法。
附图说明
图1是本申请提供的网络架构100的示意图。
图2是一种CAPIF系统的示意图。
图3是一种CCF授权API invoker到AEF调用特定的API的示意性流程图。
图4是本申请提供的一种通信方法的示意性流程图。
图5是本申请提供的另一种通信方法的示意性流程图。
图6是本申请提供的又一种通信方法的示意性流程图。
图7是本申请实施例提供的通信装置10的示意性框图。
图8是本申请实施例提供另一种通信装置20的示意图。
图9是本申请实施例提供一种芯片系统30的示意图。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。
本申请提供的技术方案可以应用于各种通信系统，例如：新无线(new radio，NR)系统、长期演进(long term evolution，LTE)系统、LTE频分双工(frequency division duplex，FDD)系统、LTE时分双工(time division duplex，TDD)系统等。本申请提供的技术方案还可以应用于设备到设备(device to device，D2D)通信，车到万物(vehicle-to-everything，V2X)通信，机器到机器(machine to machine，M2M)通信，机器类型通信(machine type communication，MTC)，以及物联网(internet of things，IoT)通信系统或者其他通信系统。
在通信系统中，由运营者运营的部分可称为公共陆地移动网络(public land mobile network，PLMN)，也可以称为运营商网络等。PLMN是由政府或其所批准的经营者为公众提供陆地移动通信业务目的而建立和经营的网络，主要是移动网络运营商(mobile network operator，MNO)为用户提供移动宽带接入服务的公共网络。本申请实施例中所描述的PLMN，具体可为符合3GPP标准要求的网络，简称3GPP网络。3GPP网络通常包括但不限于5G网络、第四代移动通信(4th-generation，4G)网络，以及未来的其他通信系统，例如(6th-generation，6G)网络等。
为了方便描述，本申请实施例中将以PLMN或5G网络为例进行说明。
图1是本申请提供的5G网络架构100的示意图，以3GPP标准化过程中定义的非漫游场景下，基于服务化架构SBA的5G网络架构为例。如图所示，该网络架构可以包括三部分，分别是终端设备部分、DN和运营商网络PLMN部分。下面对各部分的网元的功能进行简单说明。
终端设备部分可以包括终端设备110，该终端设备110也可以称为用户设备(user equipment，UE)。 本申请中的终端设备110是一种具有无线收发功能的设备，可以经无线接入网(radio access network，RAN)140中的接入网设备(或者也可以称为接入设备)与一个或多个核心网(core network，CN)设备进行通信。终端设备110也可称为接入终端、终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、用户代理或用户装置等。终端设备110可以部署在陆地上，包括室内或室外、手持或车载；也可以部署在水面上(例如轮船等)；还可以部署在空中(例如飞机、气球和卫星上等)。终端设备110可以是蜂窝电话(cellular phone)、无绳电话、会话启动协议(session initiation protocol，SIP)电话、智能电话(smart phone)、手机(mobile phone)、无线本地环路(wireless local loop，WLL)站、个人数字处理(personal digital assistant，PDA)等。或者，终端设备110还可以是具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它设备、车载设备、可穿戴设备、无人机设备或物联网、车联网中的终端、5G网络以及未来网络中的任意形态的终端、中继用户设备或者未来演进的6G网络中的终端等。其中，中继用户设备例如可以是5G家庭网关(residential gateway，RG)。例如终端设备110可以是虚拟现实(virtual reality，VR)终端、增强现实(augmented reality，AR)终端、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程医疗(remote medical)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端等。这里的终端设备指的是3GPP终端。本申请实施例对终端设备的类型或种类等并不限定。为便于说明，本申请后续以UE代指终端设备为例进行说明。
运营商网络PLMN部分可以包括但不限于(无线)接入网((radio)access network，(R)AN)120和核心网(core network，CN)部分。
(R)AN 120可以看作是运营商网络的子网络，是运营商网络中业务节点与终端设备110之间的实施系统。终端设备110要接入运营商网络，首先是经过(R)AN 120，进而可通过(R)AN 120与运营商网络的业务节点连接。本申请实施例中的接入网设备(RAN设备)，是一种为终端设备110提供无线通信功能的设备，也可以称为网络设备，RAN设备包括但不限于：5G系统中的下一代基站节点(next generation node base station，gNB)、长期演进(long term evolution，LTE)中的演进型节点B(evolved node B，eNB)、无线网络控制器(radio network controller，RNC)、节点B(node B，NB)、基站控制器(base station controller，BSC)、基站收发台(base transceiver station，BTS)、家庭基站(例如，home evolved nodeB，或home node B，HNB)、基带单元(base band unit，BBU)、传输点(transmitting and receiving point，TRP)、发射点(transmitting point，TP)、小基站设备(pico)、移动交换中心，或者未来网络中的网络设备等。采用不同无线接入技术的系统中，具备接入网设备功能的设备的名称可能会有所不同。为方便描述，本申请所有实施例中，上述为终端设备110提供无线通信功能的装置统称为接入网设备或简称为RAN或AN。应理解，本文对接入网设备的具体类型不作限定。
CN部分可以包括但不限于如下NF：用户面功能(user plane function，UPF)130、网络开放功能(network exposure function，NEF)131、网络功能存储库功能(network function repository function，NRF)132、策略控制功能(policy control function，PCF)133、统一数据管理功能(unified data management，UDM)134、统一数据存储库功能(unified data repository，UDR)135、网络数据分析功能(network data analytics function，NWDAF)136、认证服务器功能(authentication server function，AUSF)137、接入与移动性管理功能(access and mobility management function，AMF)138、会话管理功能(session management function，SMF)139。
数据网络DN 140，也可以称为分组数据网络(packet data network，PDN)，通常是位于运营商网络之外的网络，例如第三方网络。当然，在一些实现方式中，DN也可以由运营商进行部署，即DN属于PLMN中的一部分。本申请对DN是否属于PLMN不作限制。运营商网络PLMN可以接入多个数据网络DN 140，数据网络DN 140上可部署多种业务，可为终端设备110提供数据和/或语音等服务。例如，数据网络DN 140可以是某智能工厂的私有网络，智能工厂安装在车间的传感器可以是终端设备110，数据网络DN 140中部署了传感器的控制服务器，控制服务器可为传感器提供服务。传感器可与控制服务器通信，获取控制服务器的指令，根据指令将采集的传感器数据传送给控制服务器等。又例如，数据网络DN 140可以是某公司的内部办公网络，该公司员工的手机或者电脑可为终端设备110，员工的手机或者电脑可以访问公司内部办公网络上的信息、数据资源等。终端设备110可通过运营商网络提供的接口(例如N1等)与运营商网络建立连接，使用运营商网络提供的数据和/或语音等服务。终端设备110还可通过运 营商网络访问数据网络DN 140，使用数据网络DN 140上部署的运营商业务，和/或第三方提供的业务。
下面对CN包含的NF功能进行进一步简要说明。
1、UPF 130是由运营商提供的网关，是运营商网络与数据网络DN 140通信的网关。UPF网络功能130包括数据包路由和传输、数据包检测、业务用量上报、服务质量(quality of service，QoS)处理、合法监听、上行数据包检测、下行数据包存储等用户面相关的功能。
2、NEF 131是由运营商提供的控制面功能，主要使能第三方使用网络提供的服务，支持网络开放其能力、事件及数据分析、从外部应用给PLMN安全配备信息、PLMN内外交互信息的转换，提供运营商网络对外开放的API接口，提供给外部服务端与内部运营商网络的交互等。
3、NRF 132是由运营商提供的控制面功能，可用于维护网络中网络功能、服务的实时信息。例如支持网络服务发现、维护NF实例的NF配置数据(NF profile)支持的服务、支持通信代理(service communication proxy，SCP)的服务发现、维护SCP实例的SCP配置数据(SCP profile)、发送有关新注册、去注册、更新的NF和SCP的通知、维护NF和SCP运行的健康状态等。
4、PCF 133是由运营商提供的控制面功能，它支持统一的策略框架来治理网络行为、向其他控制功能提供策略规则、策略决策相关的签约信息等。
5、UDM 134是由运营商提供的控制面功能，负责存储运营商网络中签约用户的用户永久标识符(subscriber permanent identifier，SUPI)、签约用户的公开使用的签约标识(generic public subscription identifier，GPSI)，信任状(credential)等信息。其中SUPI在传输过程中会先进行加密，加密后的SUPI被称为隐藏的用户签约标识符(subscription concealed identifier，SUCI)。UDM网络功能134所存储的这些信息可用于终端设备110接入运营商网络的认证和授权。其中，上述运营商网络的签约用户具体可为使用运营商网络提供的业务的用户，例如使用中国电信的手机芯卡(subscriber identity module，SIM)卡的用户，或者使用中国移动的手机芯卡的用户等。上述签约用户的信任状可以是手机芯卡中存储的长期密钥或者跟手机芯卡加密相关的信息等存储的小文件，用于认证和/或授权。需要说明的是，永久标识符、信任状、安全上下文、认证数据(cookie)、以及令牌等同验证/认证、授权相关的信息，在本申请实施例中，为了描述方便起见不做区分、限制。
6、UDR 135是由运营商提供的控制面功能，为UDM提供存储和获取签约数据的功能、为PCF提供存储和获取策略数据、存储和获取用户的NF群组ID(group ID)信息等。
7、NWDAF 136是由运营商提供的控制面功能，其主要功能是从NF、外部应用功能AF以及运维管理(operations，administration and maintenance，OAM)系统等处收集数据，对NF和AF提供NWDAF业务注册、数据开放和分析数据等。
8、AUSF 137是由运营商提供的控制面功能，通常用于一级认证，即终端设备110(签约用户)与运营商网络之间的认证。AUSF网络功能137接收到签约用户发起的认证请求之后，可通过UDM网络功能134中存储的认证信息和/或授权信息对签约用户进行认证和/或授权，或者通过UDM网络功能134生成签约用户的认证和/或授权信息。AUSF网络功能137可向签约用户反馈认证信息和/或授权信息。
9、AMF 138是由运营商网络提供的控制面网络功能，负责终端设备110接入运营商网络的接入控制和移动性管理，例如包括移动状态管理，分配用户临时身份标识，认证和授权用户等功能。
AMF 138用于与UE进行NAS连接，拥有与UE相同的5G NAS安全上下文。5G NAS安全上下文包括KAMF、NAS层级密钥与其相同的密钥标识信息、UE安全能力，以及上下行NAS COUNT值。NAS层级密钥包括NAS加密密钥和NAS完整性保护密钥，分别用于NAS消息的机密性保护和完整性保护。
10、SMF 139是由运营商网络提供的控制面网络功能，负责管理终端设备110的PDU会话。PDU会话是一个用于传输PDU的通道，终端设备需要通过PDU会话与数据网络DN 140互相传送PDU。PDU会话由SMF网络功能139负责建立、维护和删除等。SMF网络功能139包括会话管理(例如会话建立、修改和释放，包含用户面功能UPF 130和(R)AN 120之间的隧道维护)、UPF网络功能130的选择和控制、业务和会话连续性(service and session continuity，SSC)模式选择、漫游等会话相关的功能。
11、AF 141是由运营商网络提供的控制面网络功能，用于提供应用层信息，可以通过网络开放功能网元，与策略框架交互或直接与策略框架交互进行策略决策请求等。可以位于运营商网络内，或位于运营商网络外。
可以理解的是，上述网元或者功能既可以是硬件设备中的物理实体，也可以是在专用硬件上运行的软件实例，或者是共享平台(例如，云平台)上实例化的虚拟化功能。简单来说，一个NF可以由硬件来 实现，也可以由软件来实现。
图1中Nnef、Nnrf、Npcf、Nudm、Nudr、Nnwdaf、Nausf、Namf、Nsmf、N1、N2、N3、N4，以及N6为接口序列号。示例性的，上述接口序列号的含义可参见3GPP标准协议中定义的含义，本申请对于上述接口序列号的含义不做限制。需要说明的是，图中的各个网络功能之间的接口名称仅仅是一个示例，在具体实现中，该系统架构的接口名称还可能为其他名称，本申请对此不作限定。此外，上述各个网元之间的所传输的消息(或信令)的名称也仅仅是一个示例，对消息本身的功能不构成任何限定。
为方便说明，本申请实施例中将网络功能(如NEF 131…SMF139)统称/简称为NF，即本申请实施例中后文所描述的NF可替换为任一个网络功能。另外，图1仅示意性地描述了部分网络功能，后文所描述的NF不局限于图1中示出的网络功能。
应理解，上述应用于本申请实施例的网络架构仅是从服务化架构的角度描述的网络架构，适用本申请实施例的网络架构并不局限于此，任何能够实现上述各个网元的功能的网络架构都适用于本申请实施例。
还应理解，图中所示的AMF、SMF、UPF、NEF、AUSF、NRF、PCF、UDM可以理解为核心网中用于实现不同功能的网元，例如可以按需组合成网络切片。这些核心网网元可以各自独立的设备，也可以集成于同一设备中实现不同的功能，本申请对于上述网元的具体形态不作限定。
还应理解，上述命名仅为便于区分不同的功能而定义，不应对本申请构成任何限定。本申请并不排除在5G网络以及未来其它的网络中采用其他命名的可能。例如，在6G网络中，上述各个网元中的部分或全部可以沿用5G中的术语，也可能采用其他名称等。
另外，本申请主要涉及5G架构下的能力开放架构，如图2所示的通用应用软件编程接口(Application Programming Interface，API)框架(Common API Framework，CAPIF)系统。图2是一种CAPIF系统的示意图。该CAPIF系统可以应用于4G或者5G系统，显然也可以应用其他制式的通信系统，本申请不予限制。下面对CAPIF系统中的各个组成部分进行简单介绍：
1、API调用者(API invoker)：也可以称为API调用实体，通常由与公用陆地移动通信网(public land mobile network，PLMN))运营商签定了服务协议的第三方应用，如机器到机器(machine to machine，M2M)应用、物联网(internet of things，IoT)应用、车联网(vehicle-to-everything，V2X)应用等，这些应用可以运行在终端设备中，也可以运行在网络设备中。
API调用实体包括但不限于以下功能：1)提供API调用者身份和API调用者鉴权所需的其他信息，支持鉴权；2)支持与CAPIF的相互认证；3)在访问服务API之前获得授权；4)发现服务API信息；5)调用服务API。
2、CAPIF核心功能(CAPIF Core Function，CCF)：包括但不限于以下功能：1)根据API调用者鉴权所需的身份和其他信息对API调用者进行鉴权；2)支持与API调用者的相互认证；3)在访问服务API之前为API调用者提供授权；4)发布、存储和支持服务API信息的发现；5)根据PLMN运营商配置的策略控制业务API访问；6)存储服务API调用的日志，并将服务API调用日志提供给授权实体；7)根据服务API调用日志计费；8)监控服务API调用；9)加入新的API调用者和退出API调用者；10)存储CAPIF和业务API相关的策略配置；11)支持访问日志进行审计(例如检测滥用)；12)支持在CAPIF对接中使用另一个CAPIF核心函数发布、发现服务API信息。
3、API开放功能(API Exposing Function，AEF)：是服务API的提供者，也是服务API与API调用者的服务通信入口。也可以作为API调用实体调用API的入口，例如，基于API调用实体的标识和CCF提供的信息认证API调用实体，接收CCF提供的认证鉴权信息，同步API日志到CCF上。
包括但不限于以下功能：1)根据CAPIF核心函数提供的API调用者鉴权所需的身份和其他信息，对API调用者进行鉴权；2)验证CAPIF核心职能提供的授权；3)记录CAPIF核心函数的服务API调用。在3GPP网络中，AEF可以是NEF。
4、API发布功能(API publishing function)，用于提供API发布的功能，以便API调用实体可以发现API。
5、API管理功能(API management function)，用于提供对API的管理，例如，审计从CCF提供的API调用日志，监控CCF报告的事件，向API配置访问、计费的策略，检测API的状态，以及注册API调用实体等。
6、鉴权功能(Authorization Function，AuF)网元：用于获得用户授权。示例性地，AuF和CCF可以合设。
7、Service API指的是由AEF开放的API，可以称之为AEF上的API，可以被API调用实体发现并调用。主要包括一些特定服务类型的API，可以用于API调用实体使用运营商提供的资源及服务，例如，QoS控制类的API，广播类型的API，IoT类型的API等。
为便于理解本申请实施例，首先基于图2所示的CAPIF系统简单介绍一下在CAPIF系统中CCF授权API invoker到AEF调用特定的API的流程。
如图3所示，图3是一种CCF授权API invoker到AEF调用特定的API的示意性流程图。包括以下步骤：
S310，API invoker向CCF发送注册API invoker请求消息。
该注册API invoker请求消息包含注册信息和登记API。其中，注册信息包含API invoker的信息，例如登记细节、注册需求等。登记API包含需要登记的API列表。
S320，CCF向API invoker发送注册API invoker响应消息。
该响应消息包含注册状态、已登记信息以及Service API信息。其中，注册状态指示注册的结果(如，注册成功或者失败)；已登记信息包含API invoker ID，以及授权及认证方法，API invoker ID由CCF为API invoker分配，授权及认证方法指示使用何种授权及认证方法，授权及认证方法包括但不限于：
传输层安全(Transport Layer Security，TLS)-预共享密钥(Pe-Shared key，PSK)方式、公共密钥基础设施(Public Key Infrastructure，PKI)、或传输层安全授权令牌(TLS with OAuth token)方式等。本申请中主要考虑授权及认证方法为TLS with OAuth token。
Service API信息指示已登记的API的信息，包含service API名称(name)、AEF位置、IP地址、端口号、或协议等。
S330，API invoker向CCF发送发现服务请求消息。
该服务请求消息包含API invoker ID和请求信息。其中，请求信息包含发现某些API的标准，例如偏好的API开放功能(AEF)位置、协议等。
S340，CCF向API invoker发送发现服务响应消息。
该服务响应消息包含service API信息。其中，service API信息响应于步骤S330所请求的API，service API信息中包括的信元参照步骤S320中关于Service API信息的描述，这里不再赘述。
S350，API invoker向CCF发送获得授权请求消息。
由于CCF选择了TLS with OAuth token授权及认证方法，该授权请求消息包含API invoker ID和API name、以及授权方法，该授权方法使用客户端凭证client_credential模式的认证(OAuth)方式。
S360，CCF向API invoker发送获得授权响应消息。
CCF确认API invoker可访问API name授权后，该授权响应消息包含refresh_token以及access_token，两个token都包含声明和签名。声明包含以下内容：超时时间，API Invoker ID、AEF ID、service API ID。可选地，声明还可以包含用户标识。签名为CCF对token的数字签名。
S370，API invoker向AEF发送API调用请求消息。
API调用请求消息包含API invoker ID、service API ID以及access_token，可选还包含用户标识。
S380，AEF根据API调用请求消息校验access_token。
具体判断如下：
首先，AEF校验token的签名。AEF通过预配置的CCF的凭证(如，证书)，校验token的签名。
其次，AEF校验声明部分：AEF判断token声明中的API Invoker ID是否和消息中的API Invoker ID一致。AEF判断token声明中的service API ID是否和消息中请求的service API ID一致。可选的，AEF判断token声明中的用户标识是否和消息中请求的用户标识一致。AEF根据超时时间判断当前token是否已超时。
若上述判断通过，则AEF执行步骤S390。若判断不通过，则拒绝API调用请求消息。
S390，AEF向API Invoker发送API调用响应消息。
此外，为了便于理解本申请实施例，做出以下几点说明。
第一，在本申请中，“用于指示”可以包括用于直接指示和用于间接指示。当描述某一指示信息用于指示A时，可以包括该指示信息直接指示A或间接指示A，而并不代表该指示信息中一定包括有A。
将指示信息所指示的信息称为待指示信息，则具体实现过程中，对待指示信息进行指示的方式有很多种。待指示信息可以作为一个整体一起发送，也可以分成多个子信息分开发送，而且这些子信息的发送周期和/或发送时机可以相同，也可以不同。具体发送方法本申请不进行限定。其中，这些子信息的发送周期和/或发送时机可以是预先定义的，例如根据协议预先定义的，也可以是发射端设备通过向接收端设备发送配置信息来配置的。
第二，在本申请中示出的“至少一个”是指一个或者多个，“多个”是指两个或两个以上。另外，在本申请的实施例中，“第一”、“第二”以及各种数字编号(例如，“#1”、“#2”等)只是为了描述方便进行的区分，并不用来限制本申请实施例的范围。下文各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定，应该理解这样描述的对象在适当情况下可以互换，以便能够描述本申请的实施例以外的方案。此外，在本申请实施例中，“510”、“520”等字样仅为了描述方便作出的标识，并不是对执行步骤的次序进行限定。
第三，在本申请中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
第四，本申请实施例中涉及的“保存”，可以是指的保存在一个或者多个存储器中。所述一个或者多个存储器，可以是单独的设置，也可以是集成在编码器或者译码器，处理器、或通信装置中。所述一个或者多个存储器，也可以是一部分单独设置，一部分集成在译码器、处理器、或通信装置中。存储器的类型可以是任意形式的存储介质，本申请并不对此限定。
第五，本申请实施例中涉及的“协议”可以是指通信领域的标准协议，例如可以包括LTE协议、NR协议以及应用于未来的通信系统中的相关协议，本申请对此不做限定。
第六，在本申请实施例中，“在…情况下”、“当…时”、“若…”有时可以混用，应当指出的是，在不强调其区别时，其所要表达的含义是一致的。
第七，在本申请实施例中，各术语及英文缩略语，如无线资源控制(RRC)等，均为方便描述而给出的示例性举例，不应对本申请构成任何限定。本申请并不排除在已有或未来的协议中定义其它能够实现相同或相似功能的术语的可能。
第八，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
上文结合图1简单介绍了本申请实施例提供的通信方法能够应用的场景，以及介绍了CCF授权API invoker到AEF调用特定的API的流程，从图3所示的流程可知，可以基于token实现授权及认证，但是目前针对CAPIF系统(仅在OAuth2.0协议中提出可以撤销Token，但是如何在CAPIF系统中实现撤销未提供)未提供支持撤销Token的机制。本申请提供一种通信方法，可以应用在图2所示的CAPIF系统中，并且该CAPIF系统可以应用于图1所示的5G系统，以实现撤销Token。
应理解，本申请实施例提供的通信方法可以应用于5G系统中，例如，图1中所示的通信系统。
还应理解，下文示出的实施例并未对本申请实施例提供的方法的执行主体的具体结构特别限定，只要能够通过运行记录有本申请实施例的提供的方法的代码的程序，以根据本申请实施例提供的方法进行通信即可。例如，本申请实施例提供的方法的执行主体可以是网元，或者，是网元中能够调用程序并执行程序的功能模块。
图4是本申请提供的一种通信方法的示意性流程图。应用于CAPIF中(如图2所示)，该CAPIF中包括应用软件编程接口API调用者(为了便于描述下文称为API invoker)、第一授权实体(包括CCF或AuF，为了便于描述下文称为CCF)和API开放功能网元(为了便于描述下文称为AEF)。其中，API调用者为需要调用服务API的实体；第一授权实体可以用于基于API调用者的标识和其它信息认证及授权API调用者；API开放功能网元是服务API的提供者，也是服务API与API调用者的服务通信入口，具体地，API开发功能网元用于在API调用者获得授权的情况下，向API调用者提供指定服务API的访问。
图4所示的通信方法包括以下步骤：
S410，API invoker从CCF获取第一令牌，或者说CCF向API invoker提供第一令牌。
具体地，第一令牌用于AEF验证是否授权API invoker访问指定服务API。或者说，第一令牌用于API invoker被授权访问指定服务API。
示例性地，API invoker从CCF获得token的方式可以参考图3中步骤S350和S360的描述，这里不再赘述。
例如，API invoker从CCF获得token。token可以包含access_token和/或refresh_token。Access_token用于AEF授权API invoker访问相关的API。refresh_token用于API invoker向CCF请求获得新的access_token和/或新的refresh_token。
示例性地，API invoker可以向CCF发送Refresh_Token Request消息，该消息用于请求CCF更新授权，消息中携带Refresh_token。在成功校验Refresh_token后，CCF向API invoker发送Refresh_Token Response消息，消息中携带新的access_token和/或新的refresh_token。
需要说明的是，该实施例中主要涉及access_token的撤销，所以API invoker从CCF获得token可以仅获得access_token，对于是否获得refresh_token该实施例中不做限定。
通常token包含声明(claim)。可选的，token还可以包含签名(signature)。
示例性地，API invoker获得的access_token的声明包含以下一项或多项信息：
access_token的超时时间、API invoker的标识(API invoker ID)、AEF的标识(AEF ID)、服务API的标识(service API ID)、用户标识等。
其中，AEF的标识、服务API的标识以及用户标识可以包含在声明的范围(scope)中，范围用于指示访问请求的范围。
该用户标识为可选的信息，也就是说access_token的范围中可以不携带该用户标识。在access_token的范围不包括用户标识的情况下，access_token的范围指示该access_token指示该携带Token的请求被授权访问特定AEF提供的特定API。在access_token的范围包括用户标识的情况下，access_token的范围指示携带该access_token的请求被授权访问特定AEF提供的特定API以调用特定用户的资源。
access_token的签名为CCF对access_token的声明部分生成的签名。
应理解，上述的access_token的声明可以理解为access_token的描述信息。
进一步地，在该实施例中API invoker可以根据触发条件确定是否发起撤销请求，以实现撤销第一令牌，图4所示的方法流程还包括：
S420，API invoker确定是否发起令牌撤销请求。
示例性地，在满足触发条件的情况下，API invoker向CCF请求撤销第一令牌。可选地，该实施例中API invoker可以通过第一请求消息，请求CCF撤销第一令牌。
具体地，API invoker根据不同的触发条件，确定是否向CCF发送撤销请求(Revocation Request)消息，以实现请求撤销令牌。
示例性地，触发条件包括但不限于以下条件：
a)由用户主动触发。
例如，用户点击退出登录，该指令被API invoker获得，则API invoker可以基于该指令发起撤销第一令牌的流程。
b)API invoker接收到来自CCF的事件通知消息。
例如，API invoker收到来自CCF的通知消息，该通知消息包含来自CCF的事件通知(event notification)消息，该事件通知消息通知的事件包括但不限于：
指定服务API不可使用(SERVICE_API_UNAVAILABLE)；
指定服务API已升级(SERVICE_API_UPDATE)；
API invoker掉线(API_INVOKER_OFFBOARDED)；
指定服务API调用失败(SERVICE_API_INVOCATION_FAILURE)；
接入控制策略不可用(ACCESS_CONTROL_POLICY_UNAVAILABLE)；
API invoker授权被撤销(API_INVOKER_AUTHORIZATION_REVOKED)；
API invoker已升级(API_INVOKER_UPDATED)；
API拓扑隐藏已创建(API_TOPOLOGY_HIDING_CREATED)；
API拓扑隐藏被撤销(API_TOPOLOGY_HIDING_REVOKED)等。
具体地，上述涉及的事件的详细描述可参考3GPP TS 29.222第8.3.4.3.3节中关于的事件的定义，这里不再赘述。
c)API invoker接收到来自AEF的拒绝消息。
例如，API invoker接收到来自AEF的所述API调用者未被授权(如，401指示)、所述指定服务API不可用(如，503指示)及其他协议错误、应用错误等原因。
该实施例中API Invoker接收来自CCF或AEF的消息后触发token撤销，可自动化撤销过期token，以提升系统鲁棒性。
应理解，上述的触发条件a)至c)只是举例说明API invoker如何确定是否发起令牌撤销请求，对本申请的保护范围不构成任何的限定，API invoker还可以通过其他方式触发发起令牌撤销请求。例如，网络侧(CCF或AEF)通过明示信息指示可以发起令牌撤销请求；还例如，API invoker可以周期性发起令牌撤销请求。这里不再一一举例说明。
作为一种可能的实现方式，上述的触发条件不满足，则API invoker确定不发起令牌撤销请求。
作为另一种可能的实现方式，上述的触发条件中的至少一个满足，则API invoker确定发起令牌撤销请求。
需要说明的是，该实施例中主要涉及令牌撤销流程，所以下文主要针对API invoker确定发起令牌撤销请求之后的流程进行说明，对于API invoker确定不发起令牌撤销请求不进行详述(如，API invoker可以等待触发条件满足时发起令牌撤销请求)。
具体地，API invoker确定发起令牌撤销请求的情况下，通过向CCF发送第一请求消息请求CCF撤销第一令牌，图4所示的方法流程还包括：
S430，API invoke向CCF发送第一请求消息，或者说CCF接收来自API invoke的第一请求消息。
具体地，第一请求消息用于请求撤销第一令牌。该第一请求消息可以称为撤销请求消息，第一请求消息中包含令牌类型(token type)以及对应的token，其中，token type用于指示撤销的token的类型，可以是access_token和/或refresh_token，token用于指示被撤销的token的值。
示例性地，该实施例主要涉及access_token的撤销，则第一请求消息中包括令牌类型指示撤销的token的类型为access_token。该实施例中以撤销第一令牌为例进行说明，则第一请求消息中还包括第一令牌。
另外，需要说明的是该实施例中API invoke也可以向CCF发送第一请求消息，以实现请求撤销refresh_token，只是该实施例中不对该情况进行详述。
CCF接收到第一请求消息之后，可以向AEF发送第二请求消息，请求AEF撤销所述API调用者的授权。
需要说明的是，若第一请求消息中携带的token type指示refresh_token，则CCF撤销收到的refresh_token的授权，无需判断是否向AEF发送第二请求消息。
例如，CCF将收到的refresh_token存储到撤销的token列表中，若后续通过Refresh Request消息收到在撤销列表中的refresh_token，则认为refresh_token是无效的。在refresh_token无效的情况下，CCF拒绝API invoker的更新token请求。
该实施例中主要考虑access_token的撤销流程。在CCF接收到的第一请求消息用于请求撤销access_token的情况下，CCF可以通过第二请求消息请求AEF撤销API invoker的授权。
示例性地，第一请求消息中包括第一令牌，在CCF向AEF发送第二请求消息之前，CCF根据第一令牌的声明，确定AEF。如，CCF在接收到第一请求消息之后，根据第一请求消息中携带的token type确定第一令牌的为access_token，则CCF根据第一请求消息中携带的第一令牌的声明获得AEF ID，并根据AEF ID向AEF ID指示的AEF发送第二请求消息，以请求AEF撤销API invoker的授权。可以利用第一令牌的声明中已有的AEF标识，让CCF主动向AEF推送待撤销的撤销信息，以保障第一令牌能被实时推送到正确的AEF上，实现第一令牌被正确撤销授权。
图4所示的方法流程还包括：
S440，CCF向AEF发送第二请求消息，或者说AEF接收来自CCF的第二请求消息。
具体地，第二请求消息用于请求AEF撤销API invoker的授权，该第二请求消息中包括第一令牌和/或第一令牌的声明。其中，第一令牌和/或第一令牌的声明可以称为撤销信息，撤销信息用于指示待撤销的授权。
作为一种可能的实现方式，第二请求消息可以为已有的CCF向AEF发送的消息，第二请求消息中还包括第二指示信息，第二指示信息用于指示撤销API invoker的授权。第二指示信息为第二请求消息中新增的信元，指示已有的消息的新增功能。
可选的，第二指示信息还可以用于指示撤销token类型的授权，以使得AEF在校验token的过程中校验撤销授权的信息。
可选地，第二指示信息还可以用于指示API invoker的需求，如，第二指示信息还可以用于指示API invoker请求撤销access_token。
应理解，上述指示举例说明如何通过在已有的信令中新增信元的方式复用已用的信令请求AEF撤销API invoker的授权。该实现方式下第二请求消息原本的功能可以为除第二指示信息所指示的功能外的其他功能，但是通过新增信元实现请求撤销API invoker的授权的功能。
作为另一种可能的实现方式，第二请求消息为新增的CCF向AEF发送的消息，该实现方式下第二请求消息的功能可以定义为撤销API invoker授权。
具体地，该第二请求消息中包含撤销信息，撤销信息用于指示撤销API invoker授权所需的信息。
示例性地，撤销信息可以为第一令牌。
示例性地，撤销信息可以为第一令牌的声明。例如，撤销信息为第一令牌的声明的部分或全部内容，如，撤销信息为第一令牌的对应的API invoker ID、Service API ID、用户标识等信息中的至少一项。
可选的，若CCF发送第二请求消息之前，CCF和AEF之间未协商能力信息，CCF和AEF之间可以通过第二请求消息协商能力。该实施例中涉及的AEF的能力主要包括是否支持撤销授权的能力，CCF的能力主要包括是否支持撤销token的能力，而是否支持撤销授权影响令牌撤销是否能够成功，所以下文中涉及的AEF是否支持撤销授权的能力可以描述为AEF是否支持撤销token的能力。
例如，第二请求消息中还可以包含第二能力信息，用于指示CCF支持的能力。如，第二能力信息指示CCF是否支持撤销第一令牌。AEF接收到第二请求消息之后，可以通过响应第二请求消息告知自身的能力，具体地，AEF向CCF发送第二响应消息，该第二响应消息中携带AEF支持的能力，其中，若AEF支持撤销授权，则第二响应消息包含AEF支持撤销授权的能力，否则第二响应消息不包含AEF支持撤销授权的能力。
可选地，为了避免在AEF不支持撤销授权和/或CCF不支持撤销令牌的情况下，请求AEF撤销授权失败。该实施例中CCF在向AEF发送第二请求消息之前，可以确定是否向AEF发送第二请求消息。也就是说在CCF主动推送第二请求消息前，通过提前判断AEF是否支持撤销授权的能力，并在不支持的情况下不发送第二请求消息，从而减少对系统消息的开销。
示例性地，CCF可以通过如下几种方式确定是否向AEF发送第二请求消息：
作为一种可能的实现方式，CCF在发送第二请求消息之前已知AEF不支持撤销API invoker的授权，则第一授权实体可以无需发送第二请求消息。
作为另一种可能的实现方式，CCF在发送第二请求消息之前已知CCF不支持撤销令牌，则CCF可以无需发送第二请求消息。
作为又一种可能的实现方式，CCF在发送第二请求消息之前已知AEF支持撤销API invoker的授权，则CCF可以发送第二请求消息。
也就是说，如果CCF可提前获得AEF的能力信息，则CCF可以基于AEF的能力信息判断是否向AEF发送第二请求消息。
示例性地，CCF可以通过如下流程获得AEF的能力信息：
步骤一：AEF向CCF发送第一消息，该第一消息中包括AEF的能力信息。例如，若AEF支持撤销授权，则AEF的能力信息指示AEF支持撤销授权。
步骤二：CCF向AEF发送第二消息，该第二消息中包括CCF的能力信息。例如，CCF在接收到第一消息之后，获知AEF是否支持撤销授权。若CCF支持撤销令牌，则CCF在第二消息中携带CCF的能力信息指示CCF支持撤销token；若CCF不支持撤销令牌，则CCF在第二消息中携带CCF的能力信息指示CCF不支持撤销token。例如，AEF向CCF发送请求消息#1，CCF向AEF发送回复消息#1。请求消息#1包含AEF的第一能力信息，用于指示AEF是否支持撤销API invoker的授权的能力，该请求消息#1可以是服务API开放请求(Service API publish request)消息。回复消息#1包含CCF支持的能力，其中，若CCF支持撤销token的能力，则回复消息#1包含CCF支持撤销token的能力，否则回复消息#1不包含撤销token的能力。
另外，CCF可在向AEF发送第二请求消息前，确定AEF不支持撤销API invoker的授权的能力或CCF不支持撤销令牌的情况下，CCF可不向AEF发送第二请求消息，并直接向API invoker发送第一响 应消息，该第一响应消息中携带第一原因值，第一原因值用于指示所述第一令牌撤销失败的原因。
作为一种可能的实现方式，第一原因值用于指示CCF不支持当前类型的token的撤销，例如可以为unsupported_token_type。
在该实现方式下，可选地，API invoker在接收到第一响应消息之后可以重新选择一个CCF。为了便于区分API invoker重选的CCF称为第二CCF，API invoker向该第二CCF发送上述的第一请求消息#1，请求撤销所述第一令牌，重新发起令牌撤销流程，具体地重新发起令牌撤销流程之后第二CCF执行的动作与上述的CCF执行的动作类似，这里不再赘述。
可选地，该实现方式下，API invoker重选第二CCF之前确定第一令牌撤销失败的次数小于次数门限，也就是说在重选CCF预设次数(如，3次)仍未成功后，API invoker停止发起令牌撤销。
作为另一种可能的实现方式，第一原因值为AEF不支持撤销API invoker的授权的能力时(如，CCF通过AEF的能力获得，或CCF从AEF处接收到第二原因值，指示AEF不支持撤销API invoker的授权)，API invoker可以请求CCF提供超时时长小于时长门限的令牌，下述将结合图5详细介绍如何提供超时时长小于时长门限的令牌，这里不再赘述。
或者，API invoker停止请求撤销第一令牌。
进一步地，该实施例中AEF接收到第二请求消息之后，根据第二请求消息中携带的撤销信息执行撤销授权流程，图4所示的方法流程还包括：
S450，AEF根据撤销信息执行撤销授权。
示例性地，若第二请求消息为新增的CCF向AEF发送的用于请求撤销授权的消息，AEF接收到第二请求消息之后确定根据撤销信息撤销所述授权。
示例性地，若第二请求消息为已有的CCF向AEF发送的消息，且该第二请求消息原本的功能和撤销授权不同，AEF可以根据第二请求消息中携带的第二指示信息确定根据撤销信息撤销所述授权。
作为一种可能的实现方式，CCF在发送第二请求消息之前，CCF和AEF之间未协商能力信息，也就是说在该实现方式下AEF在接收到第二请求消息之后根据撤销信息撤销该撤销信息所指示的授权可能会失败。
例如，AEF接收到第二请求消息，且第二请求消息包含第二能力信息，第二能力信息包含CCF支持撤销token的能力，AEF对比第二能力信息与自身支持的能力，若AEF不支持该撤销token的能力，则AEF通过第一指示信息回复第三能力信息，该第三能力信息不包含支持撤销token的能力，代表撤销token的能力不是AEF和CCF共同支持，因此隐式指示了撤销结果为撤销失败，且失败原因为AEF不支持撤销token的能力。
可选地，在该实现方式下第一指示信息中还可以包括第二原因值，该第二原因值用于指示撤销失败的原因为AEF不支持撤销授权。进一步地，该实现方式下CCF可以根据该第二原因值向API invoker发送第一原因值，第一原因值指示第一令牌撤销失败的原因是AEF不支持撤销授权。
作为另一种可能的实现方式，AEF支持撤销授权，但因为其他原因撤销失败，例如，第一令牌是无效的(如，第一令牌的签名校验失败，或者第一令牌已过期，或者第一令牌不属于当前API invoker)或者第一令牌已经被撤销，AEF通过第一指示信息指示撤销结果为撤销失败。
可选地，在该实现方式下第一指示信息中还可以包括第二原因值，该第二原因值用于指示撤销失败的原因为第一令牌是无效的，第一令牌已经被撤销等。
作为又一种可能的实现方式，AEF撤销授权成功。
在该实现方式下，AEF执行撤销授权包括：
若撤销信息为第一令牌，AEF将收到的第一令牌存储到令牌撤销列表中，其中，所述令牌撤销列表用于记录被撤销授权的令牌。若后续AEF接收到API invoker发送的API调用请求(API invocation Request)消息，且API调用请求中携带的access_token在令牌撤销列表中，则认为该aceess_token是无效的，拒绝API调用。
例如，在AEF根据所述撤销信息撤销所述授权之后，AEF接收服务请求消息，所述服务请求消息中包括第一令牌，AEF根据本地缓存的令牌撤销列表确定所述第一令牌被撤销授权之后(如确定第一令牌在令牌撤销列表中)，AEF拒绝所述服务请求消息。
若撤销信息为第一令牌或第一令牌的声明部分，AEF将收到的第一令牌的声明部分存储撤销列表中。
示例性地，AEF根据第一令牌的声明部分获得第一令牌的超时时间、API invoker ID、AEF ID、授权 API、用户标识等，将这些信息存储到信息列表中，其中，所述信息列表用于记录被撤销授权的令牌的信息。若超时时间超时，AEF可移除信息列表中的该行信息。若后续AEF接收到API invoker发送的API invocation Request消息,且消息中的access_token的声明在信息列表中，则认为access_token是无效的，拒绝API调用。
例如，在AEF根据所述撤销信息撤销所述授权之后，AEF接收服务请求消息，所述服务请求消息中包括第一令牌，AEF根据本地缓存的信息列表确定所述第一令牌被撤销授权之后(如确定第一令牌的声明在信息列表中)，AEF拒绝所述服务请求消息。
可选地，在access_token无效的情况下，AEF拒绝API invoker的API invocation Request消息。原因值可以为unauthorized_client，用于指示本次API调用未被授权。
进一步地，AEF执行撤销授权之后，通过第一指示信息通知撤销结果，图4所示的方法流程还包括：
S460，AEF向CCF发送第一指示信息，或者说CCF接收来自AEF的第一指示信信息。
具体地，该第一指示信息用于指示撤销结果。
示例性地，撤销结果可以是撤销成功或撤销失败。
在撤销失败的情况下，第一指示信息中还可以携带第二原因值，指示撤销失败的原因。
作为一种可能的实现方式，AEF撤销失败可能是由于AEF不支持撤销授权的能力，从而AEF撤销授权失败。
可选地，在该实现方式下，第一指示信息中携带的第二原因值用于指示撤销失败的原因是AEF不支持撤销授权的能力。
作为另一种可能的实现方式，AEF撤销失败可能是由于第一令牌是无效的令牌(如，第一令牌的签名校验失败，或者第一令牌已过期，或者第一令牌不属于当前API invoker)或者第一令牌是被撤销的令牌。
可选地，在该实现方式下，第一指示信息中携带的第二原因值用于指示撤销失败的原因是第一令牌是无效的，第一令牌已经被撤销等。
示例性地，AEF可以通过指示错误请求、用于指示服务器不理解请求的语法等指示撤销失败。
可选的，若CCF在发送第二请求消息之前，CCF和AEF之间未协商能力信息，CCF和AEF可以通过第二请求消息和第一指示信息完成能力信息的协商，具体的协商过程包括：
AEF接收到第二请求消息，且第二请求消息包含第二能力信息，第二能力信息包含CCF支持撤销token的能力，AEF对比第二能力信息与自身支持的能力，若AEF不支持该撤销token的能力，则AEF通过第一指示信息回复第三能力信息，该第三能力信息不包含支持撤销token的能力，代表撤销token的能力不是AEF和CCF共同支持，因此隐式指示了撤销结果为撤销失败，且失败原因为AEF不支持撤销token的能力。
进一步地，CCF接收到第一指示信息获知撤销结果之后，通过第一响应消息通知API invoker本次撤销的结果，图4所示的方法流程还包括：
S470，CCF向API invoker发送第一响应消息，或者说API invoker接收来自CCF的第一响应消息。
具体地，第一响应消息用于指示撤销成功或撤销失败。
在撤销失败的情况下，第一响应消息中还可以携带第一原因值，第一原因值用于指示令牌撤销失败的原因。
作为一种可能的实现方式，若令牌撤销失败是由于CCF不支持撤销token的能力导致的，则第一原因值用于指示CCF不支持当前类型的token的撤销，例如可以为unsupported_token_type。
在该实现方式下，可选地，API invoker在接收到第一响应消息之后可以重新选择一个CCF。为了便于区分API invoker重选的CCF称为第二CCF，API invoker向该第二CCF发送上述的第一请求消息#1，请求撤销所述第一令牌，重新发起令牌撤销流程。可以理解为API invoker在收到特定的撤销原因值后，重选CCF，可消减由于CCF不支持撤销授权能力导致的撤销失败，而且在重选多次仍未成功后，停止重选，可防止特定AEF不支持撤销授权能力导致的撤销失败。因此，提升撤销成功的概率。
作为另一种可能的实现方式，若令牌撤销失败是由于AEF不支持撤销授权的能力导致的，则第一原因值用于指示AEF不支持撤销API invoker的授权的能力(如，CCF从AEF处接收到第二原因值，指示AEF不支持撤销API invoker的授权)。
在该实现方式下，可选地，API invoker在接收到第一响应消息之后可以停止请求撤销第一令牌；或 者，
在该实现方式下，可选地，API invoker在接收到第一响应消息之后可以请求CCF提供超时时长小于时长门限的令牌，下述将结合图5详细介绍如何提供超时时长小于时长门限的令牌，这里不再赘述。
图4所示的通信方法由CCF主动通知AEF及时撤销授权，如此，token的授权将被实时撤销，从而实现了撤销的实时性。本申请还提供一种通信方法，通过CCF感知API invoker的能力或者需求来控制token的超时时间的时长，从而实现被动撤销授权的方法，下面结合图5详细介绍该方法。
图5是本申请提供的另一种通信方法的示意性流程图。包括以下步骤：
S510，API invoker向CCF发送第一信息。
具体地，第一信息用于指示CCF提供超时时长小于时长门限的令牌。其中，超时时长小于时长门限可以理解为令牌的超时时长较短。例如，一般来说CCF提供的令牌超时时长为10小时，若CCF接收到来自API invoker#1的第一信息，则CCF为API invoker#1提供的令牌的超时时长为1小时(或小于1的其他值)，从而可以增加安全性。
示例性地，第一信息包括以下信息中的至少一项：
指示所述API invoker支持撤销令牌能力的信息；
指示所述API invoker所需令牌超时时长小于阈值的需求；
指示所述API invoker所需令牌超时时长的信息；
指示待所述API调用者处理的业务安全性要求的信息(如，业务安全性要求高)。
例如，API invoker通过第一信息指示API invoker所需令牌超时时长小于2小时；还例如，API invoker通过第一信息指示API invoker所需令牌超时时长为1小时；还例如，API invoker通过第一信息指示当前待处理的业务的安全性要求高。
作为一种可能的实现方式，API invoker通过注册请求或发现服务请求流程向CCF发送第一信息。
例如，API invoker向CCF发送注册请求消息用于API invoker注册到CCF，该注册请求消息中携带第一信息。
还例如，API invoker向CCF发送发现服务请求消息用于API invoker发现某个服务API。该发现服务请求消息中携带第一信息。
作为另一种可能的实现方式，API invoker通过发起撤销令牌流程向CCF发送第一信息。
例如，如图4中所示的API invoker接收到第一响应消息，指示撤销令牌失败，则API invoker可以向CCF发送第一信息，请求提供超时时长小于时长门限的令牌。
作为另一种可能的实现方式，API invoker通过请求获取令牌的流程向CCF发送第一信息。
例如，API invoker向CCF发送获得授权请求消息用于API invoker获得授权。该获得授权请求消息中携带第一信息。
进一步地，CCF在接收到第一信息之后，可以为API invoker提供超时时长小于时长门限的令牌，图5所示的方法流程还包括：
S520，CCF向API invoker发送第一令牌。
该第一令牌的超时时长小于时长门限。
作为一种可能的实现方式，第一信息为API invoker支持撤销令牌能力的信息。该实施例中CCF感知API invoker支持撤销令牌的能力，可以实现有区别的对待API invoker。令牌超时时间设置过短可能导致信令开销增多，因为API invoker会频繁向CCF请求新的令牌，但设置过长又可能导致安全性降低。因此，通过感知API invoker的能力，可以避免对所有API invoker都一视同仁，影响整体通信性能，但也可以区分出支持撤销令牌能力的API invoker，仅为这类API invoker提供超时时间较短的令牌，从而保障了系统的稳定性。
在该实现方式下，CCF接收到第一信息之后，可以根据API invoker的能力信息判断，是否回复支持的能力指示CCF是否支持撤销token的能力。
若CCF也支持撤销token的能力，则支持的能力包含撤销token的能力，否则支持的能力不包含撤销token的能力。CCF保存API invoker的能力信息。
例如，CCF向API invoker发送注册响应消息或发现服务响应消息。该注册响应消息或发现服务响应消息包含支持的能力，支持的能力用于指示CCF和API invoker都支持的能力。
示例性地，CCF向API invoker发送第一令牌可以通过目前的获得授权流程实现，包括以下步骤：
步骤一：API invoker向CCF发送获得授权请求Obtain Authorization Request消息，该消息用于请求获得访问AEF的token。获得授权请求消息包含API invoker ID，AEF ID。
步骤二：CCF根据本地缓存的API invoker的第一信息，确定提供超时时长小于时长门限的令牌。
例如，CCF在接收到获得授权请求消息后，根据API invoker ID获得API invoker ID对应的API invoker的能力信息，若API invoker支持撤销token的能力，则CCF在生成access_token时，将超时时间设置为较短时间，如1小时。该较短时间为预配置的时间，该实施例中不限制。
若API invoker不支持撤销token的能力，则CCF使用正常时间生成access_token。该正常时间为另一预配置的时间，例如15天。
示例性地，CCF向API invoker发送第一令牌以及第一信息可以通过目前的获得授权流程实现，包括以下步骤：
步骤一：API invoker向CCF发送获得授权请求(Obtain Authorization Request)消息，该消息用于请求获得访问AEF的token。获得授权请求消息包含API invoker ID，AEF ID和第一信息。
步骤二：CCF根据获得授权请求消息中的第一信息为API invoker提供超时时长小于时长门限的令牌。
例如，CCF在接收到获得授权请求消息后，根据获得授权请求消息中携带的第一信息确定为API invoker提供超时时长小于时长门限的令牌，如CCF在生成access_token时，将超时时间设置为较短时间，如1小时。该较短时间为预配置的时间，该实施例中不限制。
可选的，该实施例中CCF还可以根据AEF不支持撤销授权确定提供超时时长小于时长门限的令牌。也就是说上述的步骤S510为可选的，即使API invoker未提供第一信息，CCF也可以根据AEF的能力信息确定提供超时时长小于时长门限的令牌。可以理解为该实施例中CCF可以感知AEF的能力，若AEF不支持主动撤销令牌的能力，那么CCF就设置较短的令牌的超时时间。若AEF支持主动撤销令牌能力，那么CCF就无需特殊设置令牌的超时时间，而采用图4所示的方法进行主动撤销，这样当AEF不支持主动撤销令牌能力时，可以以增加信令开销的代价下增加安全性。当AEF支持主动撤销令牌能力时，可以在不增加信令开销的基础上保障安全性。
综上，CCF根据API invoker的第一信息和/或AEF不支持撤销token的能力，确定使用较短的超时时间。
例如，CCF在提供超时时长小于时长门限的令牌之前，获得AEF的能力信息，其中，CCF获得AEF能力信息的过程可以参考图4中关于CCF获得AEF能力信息的描述，这里不再赘述。CCF将AEF的能力保存起来。CCF根据Obtain Authorization Request消息中的AEF ID从保存的AEF能力中获得该AEF的能力。
步骤三：CCF根据本地策略确认API invoker可访问API name授权后，向API invoker发送Obtain Authorization Response获得授权响应消息，该消息包含第一令牌，第一令牌包含第一令牌的声明。第一令牌的声明中包含超时时间。
由于第一令牌的超时时间较短，第一令牌的将在较短时间内无效，因此API invoker无需主动撤销授权也可以实现被动撤销授权。
本申请还提供一种通信方法，通过AEF主动请求CCF校验授权是否被撤销，下面结合图6详细介绍该方法。
图6是本申请提供的又一种通信方法的示意性流程图。包括以下步骤：
S610，API invoker从CCF获取第一令牌，或者说CCF向API invoker提供第一令牌。
S620，API invoker确定是否发起令牌撤销请求。
S630，API invoke向CCF发送第一请求消息，或者说CCF接收来自API invoke的第一请求消息。
步骤S610至步骤S620可以参考图4中步骤S410至S430的描述，这里不再赘述。
具体地，该实施例中CCF接收到第一请求消息之后，根据第一请求消息撤销第一令牌，图6所示的方法流程还包括：
S640，CCF根据第一请求消息撤销第一令牌。
作为一种可能的实现方式，CCF将收到的第一令牌存储到令牌撤销列表中，其中，所述令牌撤销列表用于记录被撤销授权的令牌。对于refresh_token若后续通过Refresh Request消息收到在撤销列表中的refresh_token，则认为refresh_token是无效的。在refresh_token无效的情况下，CCF拒绝API invoke的更新token请求。对于access_token，在接收到AEF校验请求之后，判断access_token是否有效，具体判断 见后续步骤S680，这里不再赘述。
作为另一种可能的实现方式，CCF将收到的第一令牌的声明部分存储到信息列表中，其中，所述信息列表用于记录被撤销授权的令牌的信息。
例如，CCF根据第一令牌的声明获得第一令牌的超时时间、API invoker ID、授权API、用户标识等，将这些信息存储信息列表中，若超时时间超时，CCF可移除撤销列表中的该行信息。
对于refresh_token若后续通过Refresh Request消息收到的refresh_token的声明与信息列表中的一致，则认为refresh_token是无效的。在refresh_token无效的情况下，CCF拒绝API invoker的更新token请求。
对于access_token，在接收到AEF校验请求之后，判断access_token是否有效，具体判断见后续步骤S680，这里不再赘述。
S650，CCF向API invoker发送第一响应消息，或者说API invoker接收来自CCF的第一响应消息。
具体地，第一响应消息用于指示第一令牌撤销成功或撤销失败。
可选地，在撤销失败的情况下，第一响应消息还可以携带第一原因值，若是由于CCF不支持撤销token的能力导致的，则第一原因值可以是unsupported_token_type等。用于指示CCF不支持当前类型的token的撤销。
可选地，API invoker在接收到第一响应消息之后可以重新选择一个CCF。为了便于区分API invoker重选的CCF称为第二CCF，API invoker向该第二CCF发送上述的第一请求消息，重新发起令牌撤销流程，具体地重新发起令牌撤销流程之后第二CCF执行的动作与上述的CCF执行的动作类似，这里不再赘述。
可选地，该实现方式下，API invoker重选第二CCF之前确定第一令牌撤销失败的次数小于次数门限，也就是说在重选CCF预设次数(如3次)仍未成功后，API invoker停止发起令牌撤销。
S660，API invoker向AEF发送API调用请求消息。
作为一种可能的实现方式，该API invoker可以为前文中发起令牌撤销流程的API invoker。
例如，API invoker#1针对第一令牌发起撤销流程之后，API invoker#1还可以向AEF发送API调用请求消息。
作为另一种可能的实现方式，该API invoker可以是和前文中发起令牌撤销流程的API invoker不同的API invoker。
例如，API invoker#1针对第一令牌发起撤销流程，API invoker#2向AEF发送API调用请求消息。
具体地，API调用请求消息包含API invoker ID，service API ID、用户标识以及token。
该实施例中AEF接收到API调用请求消息之后可以向CCF发送授权校验请求消息，请求CCF校验API调用请求消息中携带的令牌是否有效。
作为一种可能的实现方式，AEF接收到API调用请求消息之后直接向CCF发送授权校验请求消息，请求CCF校验API调用请求消息中携带的令牌是否有效。
作为另一种可能的实现方式，AEF接收到API调用请求消息之后确定是否有必要向CCF发送授权校验请求消息。可以理解为，AEF并不是盲目地向CCF发送授权校验请求消息。在没有必要发送的情况下，可以无需发送授权校验请求消息；在有必要发送的情况下，发送授权校验请求消息。可以避免不必要的信令开销。
例如，AEF接收到API调用请求消息之后获取API调用请求消息中携带的令牌，根据该令牌的超时时长确定是否有必要向CCF发送授权校验请求消息。如果该令牌的超时时长大于某个阈值，则AEF确定向CCF发送授权校验请求消息，否则，AEF确定不向CCF发送授权校验请求消息，并认为该令牌未被撤销。
还例如，AEF接收到API调用请求消息之后获取API调用请求消息中携带的令牌，根据该令牌被使用的次数确定是否有必要向CCF发送授权校验请求消息。如果该令牌的使用次数大于某个阈值，则AEF确定向CCF发送授权校验请求消息，否则，AEF确定不向CCF发送授权校验请求消息，并认为该令牌未被撤销。
该实施例中主要涉及AEF向CCF发送授权校验请求消息的流程，图6所示的方法流程还包括：
S670，AEF向CCF发送授权校验请求消息。
具体地，授权校验请求消息用于请求授权校验，该授权校验请求消息中包括第一令牌和/或第一令牌的声明。其中，该实施例中第一令牌和/或第一令牌的声明可以称为授权校验信息，授权校验信息用于指 示待校验的信息。
作为一种可能的实现方式，授权校验请求消息可以为已有的AEF向CCF发送的消息，授权校验请求消息中还包括第三指示信息，第三指示信息用于指授权校验。第三指示信息为授权校验请求消息新增的信元，指示已有的消息的新增功能。
可选的，第二指示信息还可以用于指示撤销token类型的授权，以使得CCF在校验token的过程中校验待校验的信息。
可选地，第三指示信息还可以用于指示AEF的需求，如，第三指示信息还可以用于指示AEF请求授权校验待校验的信息。
应理解，上述指示举例说明如何通过在已有的信令中新增信元的方式复用已用的信令请求CCF授权校验。该实现方式下授权校验请求消息原本的功能可以为除第三指示信息所指示的功能外的其他功能，但是通过新增信元实现授权校验的功能。
作为另一种可能的实现方式，授权校验请求消息为新增的AEF向CCF发送的消息，该实现方式下授权校验请求消息的功能可以定义为授权校验。
具体地，该授权校验请求消息中包含授权校验信息，用于指示待校验的授权。
示例性地，授权校验信息可以为第一令牌。
示例性地，授权校验信息可以为第一令牌的声明。例如，授权校验信息为第一令牌的声明的部分或全部内容，如，授权校验信息为第一令牌的对应的API invoker ID、Service API ID、用户标识等信息中的至少一项。
可选的，若AEF向CCF发送授权校验请求消息之前，CCF和AEF之间未协商能力信息，CCF和AEF之间可以通过授权校验请求消息协商能力。
例如，授权校验请求消息中还可以包含第四能力信息，用于指示AEF支持的能力。如，第四能力信息指示AEF是否支持校验token被撤销的能力。CCF接收到授权校验请求消息之后，可以通过响应授权校验请求消息告知自身的能力，具体地，CCF向AEF发送授权校验响应消息，该授权校验响应消息中携带CCF支持的能力，其中，若AEF支持撤销授权，则授权校验响应消息包含CCF支持校验token被撤销的能力，否则授权校验响应消息不包含CCF支持校验token被撤销的能力。
可选的，AEF可以在向CCF发送授权校验请求消息之前，获得CCF的能力信息。
示例性地，AEF可以通过如下流程获得CCF的能力信息：
步骤一：CCF向AEF发送第三消息，该第三消息中包括CCF的能力信息。例如，若CCF支持校验token被撤销的能力，则CCF的能力信息指示CC支持校验token被撤销的能力。
步骤二：AEF向CCF发送第四消息，该第四消息中包括AEF的能力信息。例如，AEF在接收到第三消息之后，获知CCF是否支持支持校验token被撤销的能力。若AEF支持校验token被撤销的能力，则AEF在第四消息中携带CCF的能力信息指示CCF支持校验token被撤销的能力；若AEF不支持校验token被撤销的能力，则AEF在第四消息中携带AEF的能力信息指示AEF不支持校验token被撤销的能力。
例如，AEF向CCF发送请求消息#2，CCF向AEF发送回复消息#2。请求消息#2包含AEF的能力信息，用于指示AEF是否支持校验token被撤销的能力，该请求消息#2可以是Service API publish request消息。回复消息#2包含支持的能力，其中，若CCF也支持校验token被撤销的能力，则支持的能力也包含校验token被撤销的能力，否则支持的能力不包含校验token被撤销的能力。
可选地，为了避免在CCF不支持校验token被撤销的能力的情况下，请求CCF授权校验失败。AEF可在向CCF发送授权校验请求消息前，根据CCF支持的能力信息判断CCF是否支持校验token被撤销的能力，若不支持，则AEF可不向CCF发送授权校验请求消息。也就是说在AEF发送授权校验请求消息前，通过提前判断CCF是否支持校验token被撤销的能力，并在不支持的情况下不发送授权校验请求消息，从而减少对系统消息的开销。
示例性地，AEF可以通过如下几种方式确定是否向CCF发送授权校验请求消息：
作为一种可能的实现方式，AEF在发送授权校验请求消息之前已知CCF不支持校验token被撤销的能力，则第一授权实体可以无需发送授权校验请求消息。
作为另一种可能的实现方式，AEF在发送授权校验请求消息之前已知AEF不支持支持校验token被撤销的能力，则AEF可以无需发送授权校验请求消息。
作为又一种可能的实现方式，AEF在发送授权校验请求消息之前已知CCF支持校验token被撤销的能力，则AEF可以发送授权校验请求消息。
示例性地，在AEF确定CCF不支持校验token被撤销的能力的情况下，AEF接收到API调用请求消息之后，可以直接向API invoker发送API调用响应消息，该API调用响应消息用于拒绝API调用。可选地，该API调用响应消息中包含拒绝原因值#1，该原因值#1为未授权的用户(unauthorized client)。
具体地，CCF接收到AEF的授权校验请求消息之后，执行授权校验，图6所示的方法流程还包括：
S680，CCF根据授权校验信息执行授权校验。
示例性地，若授权校验请求消息为新增的AEF向CCF发送的用于请求授权校验的消息，CCF接收到授权校验请求消息之后确定根据撤销信息撤销所述授权。
示例性地，若授权校验请求消息为已有的AEF向CCF发送的消息，且该授权校验请求消息原本的功能和授权校验不同，CCF可以根据授权校验请求消息中携带的第三指示信息确定根据授权校验信息执行授权校验。
作为一种可能的实现方式，AEF在发送授权校验请求消息之前，CCF和AEF之间未协商能力信息，也就是说在该实现方式下CCF在接收到授权校验请求消息之后可能由于不支持授权校验拒绝授权校验请求。
例如，CCF接收到授权校验请求消息，且授权校验请求消息包含AEF的能力信息，AEF的能力信息包含AEF支持校验token被撤销的能力，CCF对比AEF的能力信息与自身支持的能力，若CCF不支持校验token被撤销的能力，则CCF通过授权校验响应消息回复CCF的能力信息，该CCF的能力信息不包含支持校验token被撤销的能力，代表校验token被撤销的能力不是AEF和CCF共同支持，因此隐式指示了校验结果为校验失败，且失败原因为CCF不支持校验token被撤销的能力。
可选地，在该实现方式下授权校验响应消息中还包括原因值#2，该原因值#2用于指示校验失败的原因为CCF不支持授权校验。
作为另一种可能的实现方式，CCF支持校验token被撤销的能力，但因为其他原因校验失败，例如，令牌#1是无效的(如，令牌#1的签名校验失败，或者令牌#1已过期，或者令牌#1不属于当前API invoker)或者令牌#1已经被撤销，CCF通过授权校验响应消息指示校验结果为校验成功。
作为又一种可能的实现方式，CCF支持校验token被撤销的能力。
在该实现方式下，CCF执行授权校验包括：
若授权校验信息为令牌#1，CCF保存有令牌撤销列表。若收到的令牌#1存储在令牌撤销列表中，则认为该令牌#1是无效的；
若授权校验信息为令牌#1或令牌#1的声明部分，CCF保存有信息列表。若收到的令牌#1的声明存储在信息列表中，则认为该令牌#1是无效的。
可选地，该实施例中CCF执行授权校验的过程中除了校验令牌#1是否被撤销，还可以校验令牌#1是否有效。具体地，若CCF未校验令牌#1是否有效，可以由AEF校验令牌#1是否有效。
在令牌#1无效的情况下，CCF向AEF发送授权校验响应消息。
S690，CCF向AEF发送授权校验响应消息。
该授权校验响应消息包含校验结果。校验结果可以是toke为未被撤销的或toke为已被撤销的，或toke为有效的或toke为无效的。
可选的，该授权校验响应消息还包含支持的能力。若CCF也支持校验token被撤销的能力，则支持的能力也包含校验token被撤销的能力，否则支持的能力不包含校验token被撤销的能力。
S691，AEF根据校验结果向API invoker发送API调用响应消息。
若响应消息用于拒绝API调用，则该消息还包含原因值#3。原因值#3可以是unsupported_token_typ。unsupported_token_type用于指示AEF不支持当前类型的token的撤销。API invoker在接收到该原因值#3后，可以尝试重选AEF，并再次发起API调用尝试，在重选AEF预设次数(如3次)仍未成功后，停止尝试API调用。
应理解，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
还应理解，在本申请的各个实施例中，如果没有特殊说明以及逻辑冲突，不同的实施例之间的术语和/或描述具有一致性、且可以相互引用，不同的实施例中的技术特征根据其内在的逻辑关系可以组合形 成新的实施例。
例如，图4所示的实施例和图5所示的实施例可以组合形成新的实施例。具体地，首先CCF确定AEF是否支持撤销授权(具体确定AEF能力的方式可以参考上述实施例中的描述)，若AEF支持撤销授权通过图4所示的方法执行撤销令牌的流程，提高安全保障；若AEF不支持撤销授权，通过图5所示的方法流程通过提供超时时长小于时长门限的令牌，提高安全保障。
还例如，图6所示的实施例和图5所示的实施例可以组合形成新的实施例。具体地，首先CCF确定AEF是否支持撤销授权，若AEF支持撤销授权通过图6所示的方法执行验证令牌的流程，提高安全保障；若AEF不支持撤销授权，通过图5所示的方法流程通过提供超时时长小于时长门限的令牌，提高安全保障。
又例如，图4所示的实施例和图6所示的实施例可以组合形成新的实施例。具体地，根据图4所示的方法流程AEF在接收到API invoker的API调用请求消息之后，根据本地缓存的撤销令牌列表(或信息列表)验证API调用请求消息中携带的令牌，确定是否同意API invoker的API调用请求，并且为了准确性根据图6所示的方法流程AEF通过CCF校验API调用请求消息中携带的令牌是否为有效的令牌。
还应理解，在上述一些实施例中，主要以现有的网络架构中的设备为例进行了示例性说明(如CCF，AEF等)，应理解，对于设备的具体形式本申请实施例不作限定。例如，在未来可以实现同样功能的设备都适用于本申请实施例。
可以理解的是，上述各个方法实施例中，由设备(如CCF，AEF)实现的方法和操作，也可以由设备的部件(例如芯片或者电路)实现。
以上，结合图4至图6详细说明了本申请实施例提供的通信方法。上述通信方法主要从终端设备各个协议层之间交互的角度进行了介绍。可以理解的是，终端设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。
本领域技术人员应该可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
以下结合图7至图9详细说明本申请提供的通信装置。应理解，装置实施例的描述与方法实施例的描述相互对应。因此，未详细描述的内容可以参见上文方法实施例，为了简洁，部分内容不再赘述。
本申请实施例可以根据上述方法示例对发射端设备或者接收端设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。下面以采用对应各个功能划分各个功能模块为例进行说明。
图7是本申请实施例提供的通信装置10的示意性框图。该装置10包括收发模块11和处理模块12。收发模块11可以实现相应的通信功能，处理模块12用于进行数据处理，或者说该收发模块11用于执行接收和发送相关的操作，该处理模块12用于执行除了接收和发送以外的其他操作。收发模块11还可以称为通信接口或通信单元。
可选地，该装置10还可以包括存储模块13，该存储模块13可以用于存储指令和/或数据，处理模块12可以读取存储模块中的指令和/或数据，以使得装置实现前述各个方法实施例中设备的动作。
在一种设计中，该装置10可对应于上文方法实施例中的API invoker，或者是API invoker的组成部件(如芯片)。
该装置10可实现对应于上文方法实施例中的API invoker执行的步骤或者流程，其中，收发模块11可用于执行上文方法实施例中API invoker的收发相关的操作，处理模块12可用于执行上文方法实施例中CeEF的处理相关的操作。
在一种可能的实现方式，收发模块11，用于从所述第一授权实体获取第一令牌，所述第一令牌用于表征所述通信装置被授权访问指定服务API；所述收发模块11，还用于根据触发条件确定向所述第一授权实体发送第一请求消息，所述第一请求消息用于请求撤销所述第一令牌。
在另一种可能的实现方式，收发模块11，用于向所述第一授权实体发送第一信息，所述第一信息用于指示所述第一授权实体提供超时时长小于时长门限的令牌；所述收发模块11，还用于从所述第一授权 实体获取第一令牌，所述第一令牌用于表征所述通信装置被授权访问指定服务API，所述第一令牌的超时时长小于时长门限。
其中，当该装置10用于执行图4中的方法时，收发模块11可用于执行方法中的收发信息的步骤，如步骤S410、S430和S470；处理模块12可用于执行方法中的处理步骤，如步骤S420。
当该装置10用于执行图5中的方法时，收发模块11可用于执行方法中的收发信息的步骤，如步骤S510和S520；处理模块12可用于执行方法中的处理步骤。
当该装置10用于执行图6中的方法时，收发模块11可用于执行方法中的收发信息的步骤，如步骤S610、S630、S650、S660和S691；处理模块12可用于执行方法中的处理步骤，如步骤S620。
应理解，各单元执行上述相应步骤的具体过程在上述方法实施例中已经详细说明，为了简洁，在此不再赘述。
在另一种设计中，该装置10可对应于上文方法实施例中的CCF，或者是CCF的组成部件(如芯片)。
该装置10可实现对应于上文方法实施例中的CCF执行的步骤或者流程，其中，收发模块11可用于执行上文方法实施例中CCF的收发相关的操作，处理模块12可用于执行上文方法实施例中CCF的处理相关的操作。
在一种可能的实现方式，收发模块11，用于向所述API调用者提供第一令牌，所述第一令牌用于表征所述API调用者被授权访问指定服务API；所述收发模块11，还用于接收来自所述API调用者的第一请求消息，所述第一请求消息用于请求撤销所述第一令牌；所述收发模块11，还用于向所述API开放功能网元发送第二请求消息，所述第二请求消息用于请求所述API开放功能网元撤销所述API调用者的授权。
在另一种可能的实现方式，收发模块11，用于接收来自所述API调用者的第一信息，所述第一信息用于指示所述通信装置提供超时时长小于时长门限的令牌；处理模块12，用于根据所述第一信息确定第一令牌的超时时长小于时长门限，所述第一令牌用于表征所述API调用者被授权访问指定服务API；所述收发模块11，还用于向所述API调用者提供所述第一令牌。
在又一种可能的实现方式，收发模块11，用于向所述API调用者提供第一令牌，所述第一令牌用于表征所述API调用者被授权访问指定服务API；所述收发模块11，还用于接收来自所述API调用者的第一请求消息，所述第一请求消息用于请求撤销所述第一令牌，所述第一请求消息中包括所述第一令牌；处理模块12，用于将所述第一令牌和/或所述第一令牌的描述信息缓存至所述通信装置本地的撤销列表中。
其中，当该装置10用于执行图4中的方法时，收发模块11可用于执行方法中的收发信息的步骤，如步骤S410、S430、S440、S460和S470；处理模块12可用于执行方法中的处理步骤。
当该装置10用于执行图5中的方法时，收发模块11可用于执行方法中的收发信息的步骤，如步骤S510和S520；处理模块12可用于执行方法中的处理步骤。
当该装置10用于执行图6中的方法时，收发模块11可用于执行方法中的收发信息的步骤，如步骤S610、S630、S670、S690；处理模块12可用于执行方法中的处理步骤，如步骤S680。
应理解，各单元执行上述相应步骤的具体过程在上述方法实施例中已经详细说明，为了简洁，在此不再赘述。
在又一种设计中，该装置10可对应于上文方法实施例中的AEF，或者是AEF的组成部件(如芯片)。
该装置10可实现对应于上文方法实施例中的AEF执行的步骤或者流程，其中，收发模块11可用于执行上文方法实施例中AEF的收发相关的操作，处理模块12可用于执行上文方法实施例中AEF的处理相关的操作。
在一种可能的实现方式，收发模块11，用于接收来自所述第一授权实体的第二请求消息，所述第二请求消息用于请求撤销所述API调用者的授权，所述第二请求消息包括撤销信息，所述撤销信息用于指示待撤销的授权；处理模块12，用于根据所述撤销信息撤销所述授权；所述收发模块11，还用于向所述第一授权实体发送第一指示信息，所述第一指示信息用于指示撤销结果。
在另一种可能的实现方式，收发模块11，用于接收来自所述API调用者的API调用请求消息，所述API调用请求消息包括第一令牌，所述第一令牌用于表征所述API调用者被授权访问指定服务API；所述收发模块11，还用于向所述第一授权实体发送授权校验请求消息，所述授权校验请求消息用于请求所述第一授权实体校验所述第一令牌是否有效；所述收发模块11，还用于接收来自所述第一授权实体的授权校验响应消息，所述授权校验响应消息用于指示所述第一令牌是否有效。
其中，当该装置10用于执行图4中的方法时，收发模块11可用于执行方法中的收发信息的步骤，如步骤S440和S460；处理模块12可用于执行方法中的处理步骤，如步骤S450。
当该装置10用于执行图6中的方法时，收发模块11可用于执行方法中的收发信息的步骤，如步骤S660、S670、S690和S691；处理模块12可用于执行方法中的处理步骤。
应理解，各单元执行上述相应步骤的具体过程在上述方法实施例中已经详细说明，为了简洁，在此不再赘述。
还应理解，这里的装置10以功能模块的形式体现。这里的术语“模块”可以指应用特有集成电路(application specific integrated circuit，ASIC)、电子电路、用于执行一个或多个软件或固件程序的处理器(例如共享处理器、专有处理器或组处理器等)和存储器、合并逻辑电路和/或其它支持所描述的功能的合适组件。在一个可选例子中，本领域技术人员可以理解，装置10可以具体为上述实施例中的移动管理网元，可以用于执行上述各方法实施例中与移动管理网元对应的各个流程和/或步骤；或者，装置10可以具体为上述实施例中的终端设备，可以用于执行上述各方法实施例中与终端设备对应的各个流程和/或步骤，为避免重复，在此不再赘述。
上述各个方案的装置10具有实现上述方法中的设备(如终端设备、网络设备)所执行的相应步骤的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块；例如收发模块可以由收发机替代(例如，收发模块中的发送单元可以由发送机替代，收发模块中的接收单元可以由接收机替代)，其它单元，如处理模块等可以由处理器替代，分别执行各个方法实施例中的收发操作以及相关的处理操作。
此外，上述收发模块11还可以是收发电路(例如可以包括接收电路和发送电路)，处理模块可以是处理电路。
图8是本申请实施例提供另一种通信装置20的示意图。该装置20包括处理器21，处理器21用于执行存储器22存储的计算机程序或指令，或读取存储器22存储的数据/信令，以执行上文各方法实施例中的方法。可选地，处理器21为一个或多个。
可选地，如图8所示，该装置20还包括存储器22，存储器22用于存储计算机程序或指令和/或数据。该存储器22可以与处理器21集成在一起，或者也可以分离设置。可选地，存储器22为一个或多个。
可选地，如图8所示，该装置20还包括收发器23，收发器23用于信号的接收和/或发送。例如，处理器21用于控制收发器23进行信号的接收和/或发送。
作为一种方案，该装置20用于实现上文各个方法实施例中由API invoker执行的操作。
作为另一种方案，该装置20用于实现上文各个方法实施例中由CCF执行的操作。
作为又一种方案，该装置20用于实现上文各个方法实施例中由AEF执行的操作。
应理解，本申请实施例中提及的处理器可以是中央处理单元(central processing unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
还应理解，本申请实施例中提及的存储器可以是易失性存储器和/或非易失性存储器。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)。例如，RAM可以用作外部高速缓存。作为示例而非限定，RAM包括如下多种形式：静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。
需要说明的是，当处理器为通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件时，存储器(存储模块)可以集成在处理器中。
还需要说明的是，本文描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
图9是本申请实施例提供一种芯片系统30的示意图。该芯片系统30(或者也可以称为处理系统)包括逻辑电路31以及输入/输出接口(input/output interface)32。
其中，逻辑电路31可以为芯片系统30中的处理电路。逻辑电路31可以耦合连接存储单元，调用存储单元中的指令，使得芯片系统30可以实现本申请各实施例的方法和功能。输入/输出接口32，可以为芯片系统30中的输入输出电路，将芯片系统30处理好的信息输出，或将待处理的数据或信令信息输入芯片系统30进行处理。
作为一种方案，该芯片系统30用于实现上文各个方法实施例中由CCF、AEF、或API invoker执行的操作。
例如，逻辑电路31用于实现上文方法实施例中由CCF、AEF、或API invoker执行的处理相关的操作；输入/输出接口32用于实现上文方法实施例中由CCF、AEF、或API invoker执行的发送和/或接收相关的操作。
本申请实施例还提供一种计算机可读存储介质，其上存储有用于实现上述各方法实施例中由CCF、AEF、或API invoker执行的方法的计算机指令。
例如，该计算机程序被计算机执行时，使得该计算机可以实现上述方法各实施例中由CCF、AEF、或API invoker执行的方法。
本申请实施例还提供一种计算机程序产品，包含指令，该指令被计算机执行时以实现上述各方法实施例中由CCF、AEF、或API invoker执行的方法。
本申请实施例还提供了一种通信系统，包括前述的CCF和AEF。
可选地，该通信系统还包括API invoker。
上述提供的任一种装置中相关内容的解释及有益效果均可参考上文提供的对应的方法实施例，此处不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。此外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。例如，所述计算机可以是个人计算机，服务器，或者网络设备等。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD)等。例如，前述的可用介质包括但不限于：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (56)

  1. 一种通信方法，其特征在于，应用于通用应用软件编程接口框架CAPIF中，所述CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问，所述方法包括：
    所述API调用者从所述第一授权实体获取第一令牌，所述第一令牌用于表征所述API调用者被授权访问所述指定服务API；
    在满足触发条件的情况下，所述API调用者向所述第一授权实体请求撤销所述第一令牌。
  2. 根据权利要求1所述的方法，其特征在于，所述触发条件包括所述API调用者接收到来自所述第一授权实体的事件通知消息，所述事件通知消息指示的事件包括以下至少一项：
    所述指定服务API不可使用、所述指定服务API已升级、所述API调用者掉线、所述指定服务API调用失败、接入控制策略不可用、所述API调用者授权被撤销、所述API调用者已升级、API拓扑隐藏已创建、API拓扑隐藏被撤销。
  3. 根据权利要求1或2所述的方法，其特征在于，所述触发条件包括所述API调用者接收到来自所述API开放功能网元的拒绝消息，所述拒绝消息指示的拒绝原因包括以下至少一项：
    所述API调用者未被授权、所述指定服务API不可用、协议错误、或应用错误。
  4. 根据权利要求1至3中任一项所述的方法，其特征在于，所述方法还包括：
    所述API调用者接收来自所述第一授权实体的第一原因值，所述第一原因值用于指示所述第一令牌撤销失败的原因。
  5. 根据权利要求4所述的方法，其特征在于，在所述第一令牌撤销失败的原因为所述第一授权实体不支持所述第一令牌撤销时，所述方法还包括：
    所述API调用者根据所述第一原因值，重新选择第二授权实体，并向所述第二授权实体请求撤销所述第一令牌。
  6. 根据权利要求5所述的方法，其特征在于，在所述API调用者重新选择所述第二授权实体之前，所述方法还包括：
    所述API调用者确定所述第一令牌撤销失败的次数小于次数门限。
  7. 根据权利要求1至6中任一项所述的方法，其特征在于，在所述API调用者从所述第一授权实体获取第一令牌之前，所述方法还包括：
    所述API调用者向所述第一授权实体发送第一信息，所述第一信息用于指示所述第一授权实体提供超时时长小于时长门限的令牌。
  8. 根据权利要求6或7所述的方法，其特征在于，所述第一信息包括以下信息中的至少一项：
    指示所述API调用者支持撤销令牌能力的信息；
    指示所述API调用者所需令牌超时时长小于阈值的需求；
    指示所述API调用者所需令牌超时时长的信息；
    指示待所述API调用者处理的业务安全性要求的信息。
  9. 一种通信方法，其特征在于，应用于通用应用软件编程接口框架CAPIF中，所述CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问，所述方法包括：
    所述第一授权实体向所述API调用者提供第一令牌，所述第一令牌用于表征所述API调用者被授权访问所述指定服务API；
    所述第一授权实体接收来自所述API调用者的第一请求消息，所述第一请求消息用于请求撤销所述第一令牌；
    所述第一授权实体向所述API开放功能网元发送第二请求消息，所述第二请求消息用于请求所述API开放功能网元撤销所述API调用者的授权。
  10. 根据权利要求9所述的方法，其特征在于，所述方法还包括：所述第一授权实体接收来自所述API开放功能网元的第一指示信息，所述第一指示信息用于指示撤销结果。
  11. 根据权利要求10所述的方法，其特征在于，所述方法还包括：
    所述第一授权实体根据所述撤销结果，通知所述API调用者所述第一令牌撤销是否成功。
  12. 根据权利要求11所述的方法，其特征在于，在所述撤销结果为撤销所述API调用者的授权失败的情况下，所述第一指示信息中包括第二原因值，所述第二原因值用于指示撤销所述API调用者的授权失败的原因。
  13. 根据权利要求9至12中任一项所述的方法，其特征在于，所述第一请求消息中包括所述第一令牌，在所述第一授权实体向所述API开放功能网元发送第二请求消息之前，所述方法还包括：
    所述第一授权实体根据所述第一令牌的描述信息，确定所述API开放功能网元。
  14. 根据权利要求9至13中任一项所述的方法，其特征在于，所述第一请求消息中包括令牌类型指示信息，在所述第一授权实体向所述API开放功能网元发送第二请求消息之前，所述方法还包括：
    所述第一授权实体根据所述令牌类型指示信息确定所述第一令牌为接入令牌。
  15. 根据权利要求9至14中任一项所述的方法，其特征在于，在所述第一授权实体向所述API开放功能网元发送第二请求消息之前，所述方法还包括：
    所述第一授权实体确定所述API开放功能网元支持撤销所述API调用者的授权。
  16. 根据权利要求9至15中任一项所述的方法，其特征在于，所述第二请求消息包括所述第一令牌和/或所述第一令牌的描述信息。
  17. 根据权利要求9至16中任一项所述的方法，其特征在于，在所述第一授权实体向所述API调用者提供第一令牌之前，所述方法还包括：
    所述第一授权实体接收来自所述API调用者的第一信息，所述第一信息用于指示所述第一授权实体提供超时时长小于时长门限的令牌；
    所述第一授权实体根据所述第一信息生成超时时长小于时长门限的所述第一令牌。
  18. 根据权利要求17所述的方法，其特征在于，所述第一信息包括以下信息中的至少一项：
    指示所述API调用者支持撤销令牌能力的信息；
    指示所述API调用者所需令牌超时时长小于阈值的需求；
    指示所述API调用者所需令牌超时时长的信息；
    指示待所述API调用者处理的业务安全性要求的信息。
  19. 一种通信方法，其特征在于，应用于通用应用软件编程接口框架CAPIF中，所述CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问，所述方法包括：
    所述API开放功能网元接收来自所述第一授权实体的第二请求消息，所述第二请求消息用于请求撤销所述API调用者的授权；
    所述API开放功能网元根据所述第二请求消息撤销所述API调用者的授权得到撤销结果，
    其中，所述撤销结果包括撤销所述API调用者的授权成功或者失败。
  20. 根据权利要求19所述的方法，其特征在于，所述方法还包括：
    所述API开放功能网元向所述第一授权实体发送第一指示信息，所述第一指示信息用于指示撤销结果。
  21. 根据权利要求19或20所述的方法，其特征在于，在所述API开放功能网元接收来自所述第一授权实体的第二请求消息之前，所述方法还包括：
    所述API开放功能网元向所述第一授权实体发送第一能力信息，所述第一能力信息用于指示所述API开放功能网元支持撤销授权。
  22. 根据权利要求19至21中任一项所述的方法，其特征在于，在所述第二请求消息包括所述第一令牌时，所述API开放功能网元根据所述第二请求消息撤销所述授权，包括：
    所述API开放功能网元将所述第一令牌缓存至所述API开放功能网元本地的令牌撤销列表中，其中，所述令牌撤销列表用于记录被撤销授权的令牌。
  23. 根据权利要求22所述的方法，其特征在于，在所述API开放功能网元根据所述第二请求消息撤销所述授权之后，所述方法还包括：
    所述API开放功能网元接收服务请求消息，所述服务请求消息中包括所述第一令牌；
    在根据所述令牌撤销列表确定所述第一令牌被撤销授权之后，所述API开放功能网元拒绝所述服务请求消息。
  24. 根据权利要求19至23中任一项所述的方法，其特征在于，在所述第二请求消息包括所述第一令牌的描述信息时，所述API开放功能网元根据所述第二请求消息撤销所述授权，包括：
    所述API开放功能网元将所述第一令牌的描述信息缓存至所述API开放功能网元的信息列表中，其中，所述信息列表用于记录被撤销授权的令牌的信息。
  25. 根据权利要求24所述的方法，其特征在于，在所述API开放功能网元根据所述第二请求消息撤销所述授权之后，所述方法还包括：
    所述API开放功能网元接收服务请求消息，所述服务请求消息中包括所述第一令牌；
    在根据所述信息列表确定所述第一令牌被撤销授权之后，所述API开放功能网元拒绝所述服务请求消息。
  26. 根据权利要求19至25中任一项所述的方法，其特征在于，在所述撤销结果为撤销所述API调用者的授权失败的情况下，所述第一指示信息中包括第二原因值，所述第二原因值用于指示撤销所述API调用者的授权失败的原因为所述API开放功能不支持撤销授权。
  27. 一种通信方法，其特征在于，应用于通用应用软件编程接口框架CAPIF中，所述CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问，所述方法包括：
    所述第一授权实体向所述API调用者提供第一令牌，所述第一令牌用于表征所述API调用者被授权访问所述指定服务API；
    所述第一授权实体接收来自所述API调用者的第一请求消息，所述第一请求消息用于请求撤销所述第一令牌；
    所述第一授权实体向所述API开放功能网元发送第二请求消息，所述第二请求消息用于请求所述API开放功能网元撤销所述API调用者的授权；
    所述API开放功能网元根据所述第二请求消息撤销所述API调用者的授权得到撤销结果，所述撤销结果包括撤销所述API调用者的授权成功或者失败。
  28. 根据权利要求27所述的方法，其特征在于，所述方法包括：
    在满足触发条件的情况下，所述API调用者向所述第一授权实体请求撤销所述第一令牌。
  29. 一种通信系统，包括第一授权实体和API开放功能网元，其特征在于：所述第一授权实体用于执行如权利要求9至18中任一项所述的方法，所述API开放功能网元用于执行如权利要求19至26中任一项所述的方法。
  30. 根据权利要求29所述的通信系统，其特征在于，还包括API调用者，所述API调用者用于执行如权利要求1至8中任一项所述的方法。
  31. 一种通信装置，其特征在于，所述装置包括：用于执行如权利要求1至8中任一项所述的方法的模块，或者用于执行如权利要求9至18中任一项所述的方法的模块，或者用于执行如权利要求19至26中任一项所述的方法的模块。
  32. 一种通信装置，其特征在于，包括：
    处理器，用于执行存储器中存储的计算机程序，以使得所述装置执行如权利要求1至8中任一项所述的方法，或者以使得所述装置执行如权利要求9至18中任一项所述的方法，或者以使得所述装置执行如权利要求19至26中任一项所述的方法。
  33. 一种计算机程序产品，其特征在于，所述计算机程序产品包括用于执行如权利要求1至8中任一项所述的方法的指令，或者所述计算机程序产品包括用于执行如权利要求9至18中任一项所述的方法的指令，或者所述计算机程序产品包括用于执行如权利要求19至26中任一项所述的方法的指令。
  34. 一种计算机可读存储介质，其特征在于，包括：所述计算机可读存储介质存储有计算机程序；所述计算机程序在计算机上运行时，使得所述计算机执行如权利要求1至8中任一项所述的方法，或者使得所述计算机执行如权利要求9至18中任一项所述的方法，或者使得所述计算机执行如权利要求19至26中任一项所述的方法。
  35. 一种通信方法，其特征在于，应用于CAPIF中，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问，
    所述方法包括：所述API调用者向所述第一授权实体发送第一信息，所述第一信息用于指示所述第 一授权实体提供超时时长小于时长门限的令牌；
    所述API调用者从所述第一授权实体获取第一令牌，所述第一令牌用于表征所述API调用者被授权访问服务所述指定服务API，所述第一令牌的超时时长小于时长门限。
  36. 根据权利要求35所述的方法，其特征在于，所述第一信息包括以下信息中的至少一项：指示所述API调用者支持撤销令牌能力的信息；指示所述API调用者所需令牌超时时长小于阈值的需求；指示所述API调用者所需令牌超时时长的信息；指示待所述API调用者处理的业务安全性要求的信息。
  37. 根据权利要求35或36所述的方法，其特征在于，所述方法还包括：所述API调用者接收来自所述第一授权实体的第二信息，所述第二信息用于指示所述第一授权实体和所述API调用者均支持的能力。
  38. 一种通信方法，其特征在于，应用于CAPIF中，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问，
    所述方法包括：
    所述第一授权实体接收来自所述API调用者的第一信息，所述第一信息用于指示所述第一授权实体提供超时时长小于时长门限的令牌；所述第一授权实体根据所述第一信息生成超时时长小于时长门限的所述第一令牌，所述第一令牌用于表征所述API调用者被授权访问所述指定服务API；所述第一授权实体向所述API调用者提供所述第一令牌。
  39. 根据权利要求38所述的方法，其特征在于，所述第一信息包括以下信息中的至少一项：指示所述API调用者支持撤销令牌能力的信息；指示所述API调用者所需令牌超时时长小于阈值的需求；指示所述API调用者所需令牌超时时长的信息；指示待所述API调用者处理的业务安全性要求的信息。
  40. 根据权利要求38或39所述的方法，其特征在于，所述方法还包括：所述第一授权实体向所述API调用者发送第二信息，所述第二信息用于指示所述第一授权实体和所述API调用者均支持的能力。
  41. 根据权利要求38至40中任一项所述的方法，其特征在于，在所述第一授权实体向所述API调用者提供所述第一令牌之前，所述方法还包括：所述第一授权实体确定所述API开放功能网元不支持撤销所述API调用者的授权。
  42. 一种通信方法，其特征在于，应用于CAPIF中，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问，
    所述方法包括：
    所述第一授权实体向所述API调用者提供第一令牌，所述第一令牌用于表征所述API调用者被授权访问所述指定服务API；所述第一授权实体接收来自所述API调用者的第一请求消息，所述第一请求消息用于请求撤销所述第一令牌；所述第一授权实体将所述第一令牌和/或所述第一令牌的描述信息缓存至所述第一授权实体本地的撤销列表中。
  43. 根据权利要求42所述的方法，其特征在于，所述方法还包括：所述第一授权实体向所述API调用者发送第一响应消息，所述第一响应消息用于指示所述第一令牌撤销成功或失败。
  44. 根据权利要求42或43所述的方法，其特征在于，在所述第一授权实体向所述API调用者提供第一令牌之前，所述方法还包括：
    所述第一授权实体接收来自所述API调用者的第一信息，所述第一信息用于指示所述第一授权实体提供超时时长小于时长门限的令牌；所述第一授权实体根据所述第一信息生成超时时长小于时长门限的所述第一令牌。
  45. 根据权利要求44所述的方法，其特征在于，所述第一信息包括以下信息中的至少一项：指示所述API调用者支持撤销令牌能力的信息；指示所述API调用者所需令牌超时时长小于阈值的需求；指示所述API调用者所需令牌超时时长的信息；指示待所述API调用者处理的业务安全性要求的信息。
  46. 根据权利要求42至45中任一项所述的方法，其特征在于，所述方法还包括：所述第一授权实体向所述API调用者发送第二信息，所述第二信息用于指示所述第一授权实体和所述API调用者均支持的能力。
  47. 根据权利要求42至46中任一项所述的方法，其特征在于，所述方法还包括：所述第一授权实体接收来自所述API开放功能网元的授权校验请求消息，所述授权校验请求消息用于请求所述第一授权 实体校验所述第一令牌是否有效；所述第一授权实体根据所述第一授权实体本地的撤销列表和所述第一令牌确定所述第一令牌是否有效；所述第一授权实体向所述API开放功能网元发送授权校验响应消息，所述授权校验响应消息用于指示所述第一令牌是否有效。
  48. 根据权利要求47所述的方法，其特征在于，所述授权校验请求消息中包括以下信息中的至少一项：所述第一令牌、所述第一令牌的描述信息、或所述API开放功能网元的能力信息。
  49. 一种通信方法，其特征在于，应用于CAPIF中，CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问，
    所述方法包括：
    所述API开放功能网元接收来自所述API调用者的API调用请求消息，所述API调用请求消息包括第一令牌，所述第一令牌用于表征所述API调用者被授权访问所述指定服务API；所述API开放功能网元向所述第一授权实体发送授权校验请求消息，所述授权校验请求消息用于请求所述第一授权实体校验所述第一令牌是否有效；所述API开放功能网元接收来自所述第一授权实体的授权校验响应消息，所述授权校验响应消息用于指示所述第一令牌是否有效。
  50. 根据权利要求49所述的方法，其特征在于，所述授权校验请求消息中包括以下信息中的至少一项：所述第一令牌、所述第一令牌的描述信息、或所述API开放功能网元的能力信息。
  51. 根据权利要求49或50所述的方法，其特征在于，在所述API开放功能网元向所述第一授权实体发送授权校验请求消息之前，所述方法还包括：所述API开放功能网元确定所述第一授权实体支持校验令牌是否有效。
  52. 根据权利要求49至51中任一项所述的方法，其特征在于，所述API开放功能网元向所述API调用者发送API调用响应消息，所述API调用响应消息用于拒绝或接受API调用，在所述API调用响应消息用于拒绝API调用的情况下，所述API调用响应消息中包括拒绝的原因值。
  53. 一种通信装置，其特征在于，所述装置包括：用于执行如权利要求35至37中任一项所述的方法的模块，或者用于执行如权利要求38至41中任一项所述的方法的模块，或者用于执行如权利要求42至48中任一项所述的方法的模块，或者用于执行如权利要求49至52中任一项所述的方法的模块。
  54. 一种通信装置，其特征在于，包括：
    处理器，用于执行存储器中存储的计算机程序，以使得所述装置执行如权利要求35至52中任一项所述的方法。
  55. 一种计算机程序产品，其特征在于，所述计算机程序产品包括用于执行如权利要求35至42中任一项所述的方法的指令。
  56. 一种计算机可读存储介质，其特征在于，包括：所述计算机可读存储介质存储有计算机程序；所述计算机程序在计算机上运行时，使得所述计算机执行如权利要求35至52中任一项所述的方法。
PCT/CN2023/128993 2022-11-04 2023-11-01 通信方法和通信装置 WO2024094047A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211378343.2 2022-11-04
CN202211378343.2A CN117998362A (zh) 2022-11-04 2022-11-04 通信方法和通信装置

Publications (1)

Publication Number Publication Date
WO2024094047A1 true WO2024094047A1 (zh) 2024-05-10

Family

ID=90896151

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/128993 WO2024094047A1 (zh) 2022-11-04 2023-11-01 通信方法和通信装置

Country Status (2)

Country Link
CN (1) CN117998362A (zh)
WO (1) WO2024094047A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103460215A (zh) * 2011-03-08 2013-12-18 电话有限公司 为服务应用提供授权访问以便使用最终用户的受保护资源的方法
CN110046001A (zh) * 2018-01-15 2019-07-23 华为技术有限公司 一种授权撤回的方法及装置
US10887301B1 (en) * 2017-12-12 2021-01-05 United Services Automobile Association (Usaa) Client registration for authorization
CN112470444A (zh) * 2018-11-15 2021-03-09 瑞典爱立信有限公司 用于撤销对api调用者的授权的方法和装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103460215A (zh) * 2011-03-08 2013-12-18 电话有限公司 为服务应用提供授权访问以便使用最终用户的受保护资源的方法
US10887301B1 (en) * 2017-12-12 2021-01-05 United Services Automobile Association (Usaa) Client registration for authorization
CN110046001A (zh) * 2018-01-15 2019-07-23 华为技术有限公司 一种授权撤回的方法及装置
CN112470444A (zh) * 2018-11-15 2021-03-09 瑞典爱立信有限公司 用于撤销对api调用者的授权的方法和装置

Also Published As

Publication number Publication date
CN117998362A (zh) 2024-05-07

Similar Documents

Publication Publication Date Title
EP3657894B1 (en) Network security management method and apparatus
EP4117343A1 (en) Service authentication method, apparatus and system
WO2019220172A1 (en) Token-based debugging for a service-based architecture
US20220095111A1 (en) Flexible authorization in 5g service based core network
WO2021037175A1 (zh) 一种网络切片的管理方法及相关装置
WO2020207156A1 (zh) 认证方法、装置及设备
EP4144152A2 (en) Methods and apparatus for provisioning private network devices during onboarding
US11496894B2 (en) Method and apparatus for extensible authentication protocol
WO2021218878A1 (zh) 切片认证方法及装置
WO2021063298A1 (zh) 实现外部认证的方法、通信装置及通信系统
WO2022247812A1 (zh) 一种鉴权方法、通信装置和系统
CN116113936A (zh) 针对启用区块链的无线系统中的交易管理的方法、架构、装置和系统
WO2021138822A1 (zh) 签约信息获取方法及装置
US11789803B2 (en) Error handling framework for security management in a communication system
US20240048986A1 (en) Communication method and apparatus
WO2020253408A1 (zh) 二级认证的方法和装置
WO2023016160A1 (zh) 一种会话建立方法和相关装置
WO2023011630A1 (zh) 授权验证的方法及装置
WO2024094047A1 (zh) 通信方法和通信装置
US20230106668A1 (en) Systems and methods for ue-initiated nssaa procedures
WO2021164458A1 (zh) 通信方法和相关装置及计算机可读存储介质
WO2021087696A1 (zh) 身份认证方法及通信装置
WO2024093923A1 (zh) 通信方法和通信装置
WO2024032226A1 (zh) 通信方法和通信装置
WO2023216891A1 (zh) 通信方法和网元设备