CN117998362A

CN117998362A - 通信方法和通信装置

Info

Publication number: CN117998362A
Application number: CN202211378343.2A
Authority: CN
Inventors: 胡力; 吴�荣
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-11-04
Filing date: 2022-11-04
Publication date: 2024-05-07
Also published as: WO2024094047A1

Abstract

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

Description

通信方法和通信装置

技术领域

本申请涉及通信领域，并且更具体地，涉及一种通信方法和通信装置。

背景技术

第三代合作伙伴计划(3rd Generation Partnership Project，3GPP)能力放开架构提供了一种3GPP对外提供服务的方式。在这种架构下，应用功能(applicationfunction，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调用者处理的业务安全性要求的信息。

第三方面，提供了一种通信方法，应用于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调用者的授权。

第四方面，提供了一种通信方法，应用于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调用者均支持的能力。

第五方面，提供了一种通信方法，应用于CAPIF中，CAPIF中包括应用软件编程接口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调用者的第一请求消息，所述第一请求消息用于请求撤销所述第一令牌；所述第一授权实体将所述第一令牌和/或所述第一令牌的描述信息缓存至所述第一授权实体本地的撤销列表中。

基于上述方案，在CAPIF中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 divisionduplex，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 landmobile network，PLMN)，也可以称为运营商网络等。PLMN是由政府或其所批准的经营者为公众提供陆地移动通信业务目的而建立和经营的网络，主要是移动网络运营商(mobilenetwork 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也可以称为用户设备(userequipment，UE)。本申请中的终端设备110是一种具有无线收发功能的设备，可以经无线接入网(radio access network，RAN)140中的接入网设备(或者也可以称为接入设备)与一个或多个核心网(core network，CN)设备进行通信。终端设备110也可称为接入终端、终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、用户代理或用户装置等。终端设备110可以部署在陆地上，包括室内或室外、手持或车载；也可以部署在水面上(例如轮船等)；还可以部署在空中(例如飞机、气球和卫星上等)。终端设备110可以是蜂窝电话(cellular phone)、无绳电话、会话启动协议(session initiation protocol，SIP)电话、智能电话(smart phone)、手机(mobile phone)、无线本地环路(wireless localloop，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 stationcontroller，BSC)、基站收发台(base transceiver station，BTS)、家庭基站(例如，homeevolved 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、网络功能存储库功能(networkfunction repository function，NRF)132、策略控制功能(policy control function，PCF)133、统一数据管理功能(unified data management，UDM)134、统一数据存储库功能(unified data repository，UDR)135、网络数据分析功能(network data analyticsfunction，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包括数据包路由和传输、数据包检测、业务用量上报、服务质量(qualityof 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 identitymodule，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安全能力，以及上下行NASCOUNT值。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。其中，注册信息包含APIinvoker的信息，例如登记细节、注册需求等。登记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 OAuthtoken。

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授权及认证方法，该授权请求消息包含APIinvoker ID和API name、以及授权方法，该授权方法使用客户端凭证client_credential模式的认证(OAuth)方式。

S360，CCF向API invoker发送获得授权响应消息。

CCF确认API invoker可访问API name授权后，该授权响应消息包含refresh_token以及access_token，两个token都包含声明和签名。声明包含以下内容：超时时间，APIInvoker 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用于APIinvoker向CCF请求获得新的access_token和/或新的refresh_token。

示例性地，API invoker可以向CCF发送Refresh_Token Request消息，该消息用于请求CCF更新授权，消息中携带Refresh_token。在成功校验Refresh_token后，CCF向APIinvoker发送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确定发起令牌撤销请求。

需要说明的是，该实施例中主要涉及令牌撤销流程，所以下文主要针对APIinvoker确定发起令牌撤销请求之后的流程进行说明，对于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不支持撤销APIinvoker的授权，则第一授权实体可以无需发送第二请求消息。

作为另一种可能的实现方式，CCF在发送第二请求消息之前已知CCF不支持撤销令牌，则CCF可以无需发送第二请求消息。

作为又一种可能的实现方式，CCF在发送第二请求消息之前已知AEF支持撤销APIinvoker的授权，则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是否支持撤销APIinvoker的授权的能力，该请求消息#1可以是服务API开放请求(Service API publishrequest)消息。回复消息#1包含CCF支持的能力，其中，若CCF支持撤销token的能力，则回复消息#1包含CCF支持撤销token的能力，否则回复消息#1不包含撤销token的能力。

另外，CCF可在向AEF发送第二请求消息前，确定AEF不支持撤销API invoker的授权的能力或CCF不支持撤销令牌的情况下，CCF可不向AEF发送第二请求消息，并直接向APIinvoker发送第一响应消息，该第一响应消息中携带第一原因值，第一原因值用于指示所述第一令牌撤销失败的原因。

作为一种可能的实现方式，第一原因值用于指示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 invokerID、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 invocationRequest消息。原因值可以为unauthorized_client，用于指示本次API调用未被授权。

进一步地，AEF执行撤销授权之后，通过第一指示信息通知撤销结果，图4所示的方法流程还包括：

S460，AEF向CCF发送第一指示信息，或者说CCF接收来自AEF的第一指示信信息。

具体地，该第一指示信息用于指示撤销结果。

示例性地，撤销结果可以是撤销成功或撤销失败。

在撤销失败的情况下，第一指示信息中还可以携带第二原因值，指示撤销失败的原因。

作为一种可能的实现方式，AEF撤销失败可能是由于AEF不支持撤销授权的能力，从而AEF撤销授权失败。

可选地，在该实现方式下，第一指示信息中携带的第二原因值用于指示撤销失败的原因是AEF不支持撤销授权的能力。

作为另一种可能的实现方式，AEF撤销失败可能是由于第一令牌是无效的令牌(如，第一令牌的签名校验失败，或者第一令牌已过期，或者第一令牌不属于当前APIinvoker)或者第一令牌是被撤销的令牌。

可选地，在该实现方式下，第一指示信息中携带的第二原因值用于指示撤销失败的原因是第一令牌是无效的，第一令牌已经被撤销等。

示例性地，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都一视同仁，影响整体通信性能，但也可以区分出支持撤销令牌能力的APIinvoker，仅为这类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，AEFID。

步骤二：CCF根据本地缓存的API invoker的第一信息，确定提供超时时长小于时长门限的令牌。

例如，CCF在接收到获得授权请求消息后，根据API invoker ID获得API invokerID对应的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，AEFID和第一信息。

步骤二：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授权后，向APIinvoker发送Obtain Authorization Response获得授权响应消息，该消息包含第一令牌，第一令牌包含第一令牌的声明。第一令牌的声明中包含超时时间。

由于第一令牌的超时时间较短，第一令牌的将在较短时间内无效，因此APIinvoker无需主动撤销授权也可以实现被动撤销授权。

本申请还提供一种通信方法，通过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若后续通过RefreshRequest消息收到在撤销列表中的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可以为前文中发起令牌撤销流程的APIinvoker。

例如，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可以是ServiceAPI 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调用请求消息中携带的令牌，确定是否同意APIinvoker的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，或者是APIinvoker的组成部件(如芯片)。

该装置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用于执行图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执行的操作。

应理解，本申请实施例中提及的处理器可以是中央处理单元(centralprocessing unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signalprocessor，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)、同步连接动态随机存取存储器(synchlinkDRAM，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、或APIinvoker执行的操作。

例如，逻辑电路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-onlymemory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims

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所述的方法，其特征在于，根据权利要求20所述的方法，其特征在于，所述方法还包括：

所述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开放功能网元拒绝所述服务请求消息。

26.根据权利要求19至25中任一项所述的方法，其特征在于，在所述撤销结果为撤销所述API调用者的授权失败的情况下，所述第一指示信息中包括第二原因值，所述第二原因值用于指示撤销所述API调用者的授权失败的原因为所述API开放功能不支持撤销授权。

27.一种通信方法，其特征在于，应用于通用应用软件编程接口框架CAPIF中，所述CAPIF中包括应用软件编程接口API调用者、第一授权实体和API开放功能网元，其中，所述API开发功能网元用于在所述API调用者获得授权的情况下，向所述API调用者提供指定服务API的访问，所述方法包括：

所述第一授权实体向所述API开放功能网元发送第二请求消息，所述第二请求消息用于请求所述API开放功能网元撤销所述API调用者的授权；

所述API开放功能网元根据所述第二请求消息撤销所述API调用者的授权得到撤销结果，所述撤销结果包括撤销所述API调用者的授权成功或者失败。

28.根据权利要求27所述的方法，其特征在于，所述方法包括：

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中任一项所述的方法。