一种系统、程序以及计算机可读存储介质
1.本技术是分案申请，原申请的申请号是201810035792.4，原申请日是2018年01月15 日，原申请的全部内容通过引用结合在本技术中。
技术领域
2.本技术涉及通信技术领域，尤其涉及一种系统、程序以及计算机可读存储介质。
背景技术：3.在通用api框架(common api framework，capif)系统中，应用软件编程接口(application programming interface，api)调用实体从capif系统中的通用api框架核心功能(capif core function，ccf)获得调用api的授权，然后使用该授权，api调用实体可以执行一次或多次api的调用。
4.上述capif中存在较多的api调用实体以及api，且不同的api可以位于capif中不同的api开放功能(api exposing function，aef)上，因此，调用api的授权管理较为复杂，例如，授权可能会过期或者被无效，但现有技术中仅提供了api调用实体的授权过程，有待进一步完善。
技术实现要素：5.本技术的实施例提供一种系统、程序以及计算机可读存储介质，可以完善调用api的授权管理，进而提升capif系统的效率。
6.为了达到上述目的，本技术的实施例采用以下技术方案：
7.第一方面，提供了一种系统，包括：第一实体和第二实体；所述第二实体，用于向所述第一实体发送授权撤回请求消息，所述授权撤回请求消息携带应用软件编程接口api调用实体的标识；所述第一实体，用于接收来自所述第二实体的所述授权撤回请求消息；所述第一实体，还用于根据所述授权撤回请求消息，向所述第二实体发送授权撤回响应消息，所述授权撤回响应消息用于指示授权撤回成功或失败；所述第二实体，还用于接收来自所述第一实体的所述授权撤回响应消息。该系统完善了调用api的授权管理，使得调用api的授权能够及时被撤回，避免了已经不具备调用api的授权(换言之，授权已经失效或过期)的api调用实体调用api而造成的资源浪费。例如，api调用实体使用原有的授权调用api，aef执行api调用但是最终失败，浪费了aef的处理资源。此外，避免了aef执行已经不具备调用api的授权的api调用实体对api的调用，提升了capif系统的工作效率。
8.结合第一方面，在第一方面的第二种可能的实现方式中，所述第一实体还用于：所述授权撤回请求消息还携带应用软件编程接口api标识，撤回所述api调用实体调用所述api标识对应的api的授权；或者，所述授权撤回请求消息还携带api标识和api开放功能aef 标识，撤回所述api调用实体调用所述aef标识对应的aef上所述api标识对应的api的授权。
9.结合第一方面，在第一方面的第二种可能的实现方式中，所述授权撤回请求消息未携带 api标识，所述第一实体还用于：撤回所述api调用实体调用所述api调用实体对应
的通用 api框架核心功能ccf上所有api的授权；或者，所述授权撤回请求消息还携带aef标识，撤回所述api调用实体调用所述aef标识对应的aef上所有api的授权；或者，所述授权撤回请求消息还携带特定值，撤回所述api调用实体调用所述api调用实体对应的ccf上所有api的授权。通过上述授权撤回请求消息可以灵活地实现撤回不同规模的授权，例如，可以实现ccf上所有api的授权撤回，还可以实现aef上所有api的授权撤回。
10.结合第一方面或上述任一种可能的实现方式，在第一方面的第三种可能的实现方式中，所述第一实体还用于：向所述api调用实体发送授权撤回指示消息。以使得api调用实体能够及时获知其授权信息，避免了api调用实体由于无法知道自己调用某api的的授权信息已经被无效/撤回，依然使用原有的授权调用api，造成了aef执行api调用但是最终失败，浪费了aef的处理资源；此外，api调用实体由于无法知道自己的授权无效或过期，仍然使用原有的授权尝试调用api而造成的api调用实体的处理资源浪费。
11.结合第一方面或上述任一种可能的实现方式，在第一方面的第四种可能的实现方式中，所述第二实体还用于：根据所述api调用实体的授权撤回相关信息，向所述第一实体发送所述授权撤回请求消息。通过实时监控api调用实体的状态，以实现对api调用实体进行授权撤回。
12.结合第一方面的第四种可能的实现方式，在第一方面的第五种可能的实现方式中，所述授权撤回相关信息包括api调用失败的次数，所述第二实体还用于：当所述api调用失败的次数超过阈值时，向所述第一实体发送所述授权撤回请求消息。
13.结合第一方面或上述任一种可能的实现方式，在第一方面的第六种可能的实现方式中，所述授权撤回指示消息携带以下信息中的至少一种：api标识，aef标识，特定值，或者撤回原因值；其中，所述撤回原因值用于指示授权撤回的原因。
14.结合第一方面或上述任一种可能的实现方式，在第一方面的第七种可能的实现方式中，所述第一实体为aef，所述第二实体为所述api调用实体对应的ccf；或者，所述第一实体为所述api调用实体对应的ccf，所述第二实体为aef。
15.结合第一方面的第七种可能的实现种方式，在第一方面的第八种可能的实现方式中，所述第一实体为所述api调用实体对应的ccf，所述第二实体为aef，所述第一实体还用于：向所述ccf对应的aef发送授权撤回通知消息，所述授权撤回通知消息携带所述api调用实体的标识。以使得aef能够及时获知api调用实体的授权信息，避免了api调用实体使用原有的授权调用api时，aef仍旧执行api调用，浪费了aef的处理资源。
16.结合第一方面的第七种可能的实现方式，在第一方面的第九种可能的实现方式中，所述第二实体为aef，所述第一实体为ccf，所述第二实体还用于：接收来自所述api调用实体的api调用请求消息；当所述api调用实体不具备调用所述api调用请求消息用于请求调用的api的授权时，向所述api调用实体发送api调用拒绝消息。通过aef对不具备授权的 api调用实体发送的api调用请求消息进行拒绝，提升了调用api的处理效率，节省了aef 的处理资源。
17.结合第一方面的第七种可能的实现方式或第九种可能的实现方式，在第一方面的第十种可能的实现方式中，所述第二实体还用于：向所述api调用实体发送授权撤回指示消息。以使得api调用实体能够及时获知其授权信息，避免了api调用实体由于无法知道自己调用某 api的的授权信息已经被无效/撤回，依然使用原有的授权调用api，造成了aef执行
api 调用但是最终失败，浪费了aef的处理资源；此外，api调用实体由于无法知道自己的授权无效或过期，仍然使用原有的授权尝试调用api而造成的api调用实体的处理资源浪费。
18.第二方面，提供了一种程序，该程序在被处理器执行时，用于实现以上第一方面的任一系统内第一实体所具有的功能。
19.第三方面，提供了一种计算机可读存储介质，包括第二方面的程序。
20.第四方面，提供了一种程序，该程序在被处理器执行时，用于实现以上第一方面的任一系统内第二实体所具有的功能。
21.第五方面，提供了一种计算机可读存储介质，包括第四方面的程序。
附图说明
22.图1为本技术的实施例提供的一种通用api框架的示意图；
23.图2为本技术的实施例提供的一种授权撤回的流程图；
24.图3为本技术的实施例提供的又一种授权撤回的流程图；
25.图4为本技术的实施例提供的又一种授权撤回的流程图；
26.图5为本技术的实施例提供的又一种授权撤回的流程图；
27.图6为本技术的实施例提供的又一种授权撤回的流程图；
28.图7为本技术的实施例提供的又一种授权撤回的流程图；
29.图8为本技术的实施例提供的又一种授权撤回的流程图；
30.图9为本技术的实施例提供的一种装置的结构示意图；
31.图10为本技术的实施例提供的又一种装置的结构示意图；
32.图11为本技术的实施例提供的又一种装置的结构示意图；
33.图12为本技术的实施例提供的又一种装置的结构示意图；
34.图13为本技术的实施例提供的又一种装置的结构示意图；
35.图14为本技术的实施例提供的一种装置的硬件结构示意图。
具体实施方式
36.本技术描述的系统架构及业务场景是为了更加清楚的说明本技术的技术方案，并不构成对于本技术提供的技术方案的限定，本领域普通技术人员可知，随着系统架构的演变和新业务场景的出现，本技术提供的技术方案对于类似的技术问题，同样适用。
37.如图1所示，图1为一种capif，该网络结构可以应用于4g或5g通信系统，显然也可以应用其它制式的通信系统，不予限制。下面对该capif中的各个组成部分进行简单介绍如下：
38.api调用实体(api invoker)：也可以称为api调用者，一般为与公用陆地移动通信网 (public land mobile network，plmn)运营商签定了服务协议的第三方应用，如机器到机器 (machine to machine，m2m)应用、物联网(internet of things，iot)应用、车联网 (vehicle-to-everything，v2x)应用等，这些应用可以运行在终端设备中，也可以运行在网络设备中，例如，api调用实体可以是plmn网络中的设备，如4g通信系统中的移动性管理实体(mobility management entity，mme)，无线接入网(radio access network，ran)节点，或策略和计费规则功能(policy and charging rules function，pcrf)等，也可以是5g通
信系统中的接入和移动性管理功能(access and mobility management function，amf)、会话管理功能 (session management function，smf)、用户平面功能(user plane function，upf)、策略控制功能(policy control function，pcf)、或应用功能(application function，af)实体等。api 调用实体可以用于：通过认证api调用实体的标识和/或其它信息以实现api调用实体的认证，调用api之前获得调用该api的授权，发现api，以及调用api等。
39.ccf：可以用于基于api调用实体的标识和其它信息认证api调用实体，例如，检查该 api调用实体是否合法；支持和api调用实体的相互鉴权；在api调用实体调用api之前向 api调用实体提供调用api的授权信息；发布，存储和支持api的发现；基于公用陆地移动网(public land mobile network，plmn))plmn运营商的策略进行api的访问控制；存储 api调用的日志，并提供给授权可以获得该日志的功能实体；基于api的日志(log)进行计费；检测api的调用；api invoker的注册；存储配置策略；支持对调用和日志的审计等。
40.aef：可以提供api，也可以作为api调用实体调用api的入口，例如，基于api调用实体的标识和ccf提供的信息认证api调用实体，接收ccf提供的认证鉴权信息，同步api 日志到ccf上。
41.api发布功能(api publishing function,apf)，用于提供api发布的功能，以便api调用实体可以发现api。
42.api管理功能(api management function,amf)，用于提供对api的管理，例如，审计从 ccf提供的api调用日志，监控ccf报告的事件，向api配置访问、计费的策略，检测api 的状态，以及注册api调用实体等。
43.capif api指的是由ccf提供的api，可以被api调用实体发现并调用，主要是一些通用类型的api，包括注册类型的api，安全认证及鉴权类型的api，api发现类型的api等。
44.service api指的是由aef开放的api，可以称之为aef上的api，可以被api调用实体发现并调用。主要包括一些特定服务类型的api，可以用于api调用实体使用运营商提供的资源及服务，例如，qos控制类的api，广播类型的api，iot类型的api等。
45.本技术中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本技术中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。“的”，“相应的(corresponding，relevant)”和“对应的(corresponding)”有时可以混用，应当指出的是，在不强调其区别时，其所要表达的含义是一致的。“a和/或b”可以指的是a和b 中的至少一种。
46.本技术中，“授权”若单独出现，例如，api调用实体的授权，可以指的是api调用实体调用api的授权，也可以指的是api调用实体调用某个api的授权，不予限制。ccf上所有api可以包括ccf所管理的aef上的所有api(即service api)，也可以包括capif api，不予限制。
47.需要指出的是，本技术各实施例中涉及的名词，步骤可以相互借鉴和参考，相同或描述不再重复，各实施例中步骤之间的执行先后顺序可以互换，不予限制。
48.如图2所示，本技术的实施例提供一种授权撤回的方法，该方法可以应用于图1所示的框架中，具体如下所述。
49.201、第一实体接收来自第二实体的授权撤回请求消息。
50.其中，授权撤回请求消息可以携带api调用实体的标识。此外，授权撤回请求消息具体可以为撤回api调用授权请求(revoke api invoker authorization request)。
51.其中，api调用实体的标识可以用于指示api调用实体，具体可以为api调用实体的名称，可以由字母、数字及符合组合而成，可以是统一资源定位符(uniform resource locator， url)，可以是正式域名(fully qualified domain name，fqdn),可以是应用(application)的标识,也可以是api调用实体的地址，如ipv4和/或ipv6的地址。
52.可选地，授权撤回请求消息还携带以下信息中的至少一种：api标识，aef标识，特定值，或者，撤回原因值。
53.具体地，aef标识可以用于指示aef，可以是aef的名称或编号，如url，fqdn，也可以是aef的地址，如ipv4和/或ipv6的地址。
54.其中，api标识可以用于指示api，例如，api的名称，api的编号如001，不予限制。
55.其中，api的名称举例如下：
56.产品名:google calendar api
57.服务名:calendar.googleapis.com
58.包名:google.calendar.v3
59.接口名:google.calendar.v3.calendarservice
60.资源目录://google/calendar/v3
61.api名:calendar
62.其中，撤回原因值可以用于指示授权撤回的原因，例如，调用api被拒绝的次数大于预设阈值，或错误调用api的次数大于预设阈值，不予限制。
63.在一个示例中，该授权撤回请求消息可以用于请求撤回该api调用实体调用该api标识对应的api的授权，即请求撤回该api调用实体调用该api标识对应的api的权限。此时，该授权撤回请求消息可以携带api标识，不予限制。
64.在另一个示例中，授权撤回请求消息可以用于请求撤回该api调用实体调用该api调用实体对应的ccf上所有api的授权。此时，该授权撤回请求消息可以携带特定值，例如，在该授权撤回请求消息的特定位置携带该特定值，或者，将授权撤回请求消息携带的api标识设置为特定值；显然，该授权撤回请求消息也可以不携带api标识，不予限制。
65.在再一个示例中，授权撤回请求消息可以用于请求撤回该api调用实体调用该aef上所有api的授权。此时，授权撤回请求消息可以不携带api标识，但携带aef标识，该aef 标识用于指示该aef，不予限制。
66.其中，第一实体可以为aef，第二实体可以为ccf；或者，第一实体为ccf，第二实体为aef。具体地，上述ccf可以是该api调用实体对应的ccf，例如，管理该api调用实体的ccf。
67.具体地，api调用实体可以通过和ccf之间执行注册流程以注册到capif系统中，ccf 可以实现对api调用实体调用api进行管理,例如，ccf接收api调用实体发送的api发现请求消息，并根据api发现请求消息为api调用实体提供api及其所在的aef信息。其中，一个api调用实体可以注册到多个capif系统中。通常情况下，在capif系统中仅有一个 ccf，可以有多个aef，即一个api调用实体对应一个ccf。当一个capif系统中有多个 ccf时，api调用实体可以通过其中一个ccf注册到capif系统中，此时，api调用实体对应的ccf可以为api
调用实体通过其进行注册的ccf，不予限制。
68.202、第一实体根据授权撤回请求消息，向第二实体发送授权撤回响应消息。
69.可选地，授权撤回响应消息用于指示授权撤回的结果，例如，授权撤回成功或失败。该授权撤回响应消息具体可以为撤回api调用授权响应(revoke api invoker authorizationresponse)。具体地，若授权撤回请求消息用于请求撤回两个或两个以上api调用实体调用api 的授权，那么该授权撤回响应消息可以包括相应的授权撤回的结果，例如，api调用实体1 授权撤回成功，api调用实体2授权撤回失败，不予限制。
70.可选地，该授权撤回响应消息仅仅用于对授权撤回请求消息的应答，表明第一实体已接收到授权撤回请求消息。
71.在一个示例中，当第一实体在接收到授权撤回请求消息时，若该第一实体正在与该api 调用实体协商调用同一个api的授权，那么可以向第二实体发送用于指示授权撤回失败的授权撤回响应消息。
72.可选地，上述方法还包括：
73.203、根据授权撤回请求消息，撤回上述api调用实体调用api的授权。
74.在一个示例中，当上述授权撤回请求消息还携带api标识时，上述方法还包括：第一实体撤回该api调用实体调用该api标识对应的api的授权。换言之，上述根据授权撤回请求消息，撤回上述api调用实体调用api的授权具体可以为撤回该api调用实体调用该api标识对应的api的授权，或者，撤回该api调用实体对api的访问权限(或访问授权)。
75.在另一个示例中，当上述授权撤回请求消息还携带api标识和aef标识时，上述方法还包括：第一实体撤回该api调用实体调用该aef标识对应的aef上该api标识对应的api 的授权。换言之，上述根据授权撤回请求消息，撤回上述api调用实体调用api的授权具体可以为撤回该api调用实体调用该aef标识对应的aef上该api标识对应的api的授权。
76.在另一个示例中，当上述授权撤回请求消息未携带api标识时，上述方法还包括：第一实体撤回该api调用实体调用该api调用实体对应的ccf上所有api的授权。换言之，上述根据授权撤回请求消息，撤回上述api调用实体调用api的授权具体可以为撤回该api调用实体调用该api调用实体对应的ccf上所有api的授权。
77.在另一个示例中，当上述授权撤回请求消息未携带api标识，且上述授权撤回请求消息还携带aef标识时，上述方法还包括：第一实体撤回该api调用实体调用该aef标识对应的aef上所有api的授权。换言之，上述根据授权撤回请求消息，撤回上述api调用实体调用api的授权具体可以为撤回该api调用实体调用该aef标识对应的aef上所有api的授权。
78.在又一个示例中，当上述授权撤回请求消息未携带api标识且上述授权撤回请求消息还携带特定值，或者，上述授权撤回请求消息携带api标识且该api标识被设置为该特定值时，上述方法还包括：第一实体撤回该api调用实体调用该api调用实体对应的ccf上所有api 的授权。换言之，上述根据授权撤回请求消息，撤回上述api调用实体调用api的授权具体可以为撤回该api调用实体调用该api调用实体对应的ccf上所有api的授权。
79.其中，api标识对应的api可以指的是该api标识所指示的api；aef标识对应的aef 可以是aef标识所指示的api。
80.其中，撤回可以指的是第一实体在本地保存的黑名单或白名单中增加或删除或设置无效该api调用实体的相关信息，该黑名单或白名单可以用于确定该api调用实体是否具
备调用 api的授权，可以用于确定该api调用实体是否具备调用api的权限。
81.需要指出的是，本技术中提及的撤回可以替换为无效，撤回，或撤销；授权可以指的是权限，访问授权，访问权限，许可，或允许访问的权限等；调用可以替换为访问，不予限制。
82.在一个示例中，采用黑名单的形式存储api调用实体不具备调用api的授权信息，或者说不具备访问api权限的信息。该黑名单可以基于api，见表1；也可以基于api调用实体，见表2。
83.表1
[0084][0085]
表2
[0086][0087]
其中，api#1可以指的是编号为1的api，api#可以指的是编号为2的api，aef#1可以指的是编号为1的aef。
[0088]
在另一个示例中，采用白名单的形式存储用于指示api调用实体具备调用api的授权的信息，或者说api调用实体具备访问api权限的信息，不再赘述。
[0089]
需要说明的是，步骤203可以在步骤202之前执行，也可以在步骤202之后执行，显然，在执行步骤203的情况下，上述授权撤回响应消息可以用于指示授权撤回成功。此外，当第一实体为ccf时，步骤203可以不执行。
[0090]
本实施例提供的方法，通过第一实体接收来自第二实体的授权撤回请求消息，所述授权撤回请求消息携带api调用实体的标识；所述第一实体根据所述授权撤回请求消息向所述第二实体发送授权撤回响应消息，完善了调用api的授权管理，使得调用api的授权能够及时被撤回，避免了已经不具备调用api的授权(换言之，授权已经失效或过期)的api调用实体调用api而造成的资源浪费。例如，api调用实体使用原有的授权调用api，aef执行api 调用但是最终失败，浪费了aef的处理资源。此外，避免了aef执行已经不具备调用api 的授权的api调用实体对api的调用，提升了capif系统的工作效率。
[0091]
可选地，在上述实施例的第一种实施场景下，上述方法还包括：
[0092]
第一实体向该api调用实体发送授权撤回指示消息。
[0093]
可选地，该授权撤回指示消息携带以下信息中的至少一种：api标识，aef标识，特定值，或者撤回原因值。api标识，aef标识，特定值，以及撤回原因值与步骤201中授权撤回请求消息携带的相关内容可以相同，也可以不同，不予限制。例如，授权撤回指示消息携带的api标识与授权撤回请求消息携带的api标识可以相同，也可以不同，不予限制。
[0094]
其中，授权撤回指示消息可以用于指示：
[0095]
1)撤回该api调用实体调用某一特定api的授权；或者，
[0096]
2)撤回该api调用实体调用该aef上所有api的授权；或者，
[0097]
3)撤回该api调用实体调用该ccf上所有api的授权。
[0098]
具体地，当授权撤回指示消息用于指示上述1)时，授权撤回指示消息可以携带该特定 api标识；当授权撤回指示消息用于指示上述2)时，授权撤回指示消息可以携带aef标识，该aef标识用于指示该aef；当授权撤回指示消息用于指示上述3)时，授权撤回指示消息可以不携带api标识，或者，携带特定值，具体与授权撤回请求消息相似，可以参见授权撤回请求消息的相关描述，不再赘述。
[0099]
在一种实现方式中，授权撤回指示消息可以触发api调用实体重定向到该api调用实体向ccf请求调用api(可以指的是撤回指示消息中提及的api)的最新授权信息(例如，触发api调用实体向ccf发送用于请求调用api的授权信息的请求消息)，或者重定向到api 调用实体与ccf进行安全认证和鉴权的流程，强制api调用实体先获得调用api的最新授权信息，或者强制api调用实体重新认证自己为合法用户之后，才能执行后续的api调用。
[0100]
可以理解的是，授权撤回指示消息可以用于指示撤回该api调用实体调用api的授权，以便于该api调用实体能够根据其最新获得的调用api的授权信息发起api调用流程，避免由于使用失效的授权信息发送api调用请求消息而造成api调用失败，节省了不必要的信息交互，进而能够节省资源，提高效率。
[0101]
其中，该授权撤回指示消息可以为撤回api调用授权通知(revoke api invokerauthorization notify)消息。
[0102]
在一个示例中，第一实体在步骤203之后向第二实体发送授权撤回指示消息。
[0103]
通过上述第一种实施场景提供的方法，使得api调用实体能够及时获知其授权信息，避免了api调用实体由于无法知道自己调用某api的的授权信息已经被无效/撤回，依然使用原有的授权调用api，造成了aef执行api调用但是最终失败，浪费了aef的处理资源；此外，api调用实体由于无法知道自己的授权无效或过期，仍然使用原有的授权尝试调用api 而造成的api调用实体的处理资源浪费。
[0104]
可选地，在上述实施例的第二种实施场景下，第一实体为该api调用实体对应的ccf，第二实体为aef，在第一实体撤回该api调用实体调用该api调用实体对应的ccf上所有 api的授权之后，上述方法还包括：
[0105]
第一实体向该ccf对应的aef发送授权撤回通知消息。
[0106]
其中，授权撤回通知消息可以用于通知撤回该api调用实体调用api的授权，该授权撤回通知消息可以携带该api调用实体的标识。
[0107]
进一步地，授权撤回通知消息还可以携带api标识和/或授权撤回原因值。
[0108]
在一个示例中，授权撤回通知消息可以用于通知撤回该api调用实体调用某一个特定api 的授权，此时，该授权撤回通知消息还可以携带api标识，该api标识用于指示该特定api。
[0109]
此外，授权撤回通知消息具体可以为revoke api invoker authorization notify。
[0110]
其中，ccf对应的aef可以为ccf管理的所有aef，也可以是ccf管理的所有aef 中除
第二实体之外的aef，还可以为ccf管理的aef中与该api调用实体相关的aef，即 api调用实体通过api发现过程从ccf获得至少一个api及该至少一个api所在的aef信息，例如，api调用实体向该ccf发送api发现请求消息，该ccf根据该api发现请求消息为api调用实体提供api及其所在的aef信息，其中，该aef信息对应的aef可以是该 ccf管理的一个或者多个aef，该aef信息对应的aef可以称之为ccf管理的aef中与该api调用实体相关的aef，不予限制。
[0111]
需要指出的是，ccf管理的aef中与该api调用实体相关的aef，可以包括该api调用实体在api发现过程中获得的api中已经调用过的api所在的aef，也可以包括该api 调用实体在api发现过程中获得的api中未曾调用的api所在的aef，不予限制。
[0112]
相应地，第二实体可以根据授权撤回通知消息，更新该api调用实体的授权信息。
[0113]
具体地，如果第二实体未曾保存过该api调用实体的授权,则第二实体保存该api调用实体的授权信息，以便于该aef根据其最新获得的api调用实体的授权信息，对api调用实体的api调用执行合适的操作，例如，当该api调用实体的对某一特定api的授权被撤回，则 aef可以直接拒绝该api调用实体的对该特定api调用请求。
[0114]
通过上述第二种实施场景提供的方法，使得aef能够及时获知api调用实体的授权信息，避免了api调用实体使用原有的授权调用api时，aef仍旧执行api调用，浪费了aef的处理资源。
[0115]
需要说明的是，上述第一种实施场景和上述第二种实施场景可以结合，不予限制。
[0116]
如图3所示，本技术的实施例提供另一种授权撤回的方法，该方法可以应用于图1所示的框架中，具体如下所述。
[0117]
301、第二实体向第一实体发送授权撤回请求消息。
[0118]
其中，授权撤回请求消息可以携带api调用实体的标识。
[0119]
其中，第一实体可以为aef，第二实体可以为ccf；或者，第一实体可以为ccf，第二实体可以为aef。具体地，该ccf可以是api调用实体对应的ccf，可以参见图2所示实施例中的相关描述，不再赘述。
[0120]
302、第二实体接收来自第一实体的授权撤回响应消息。
[0121]
其中，授权撤回响应消息可以参见图2所示实施例的相关描述，例如，可以用于指示授权撤回成功或失败。
[0122]
可选地，步骤301包括：第二实体根据该api调用实体的授权撤回相关信息，向第一实体发送授权撤回请求消息。通过实时监控api调用实体的状态，以实现对api调用实体进行授权撤回。
[0123]
在一个示例中，当授权撤回相关信息满足预设条件时，第二实体向第一实体发送授权撤回请求消息。
[0124]
其中，授权撤回相关信息可以包括以下信息中至少一种：调用api被拒绝的次数，错误调用api的次数，api调用成功的次数。具体地，调用api被拒绝的次数可以指的是该api 调用实体调用某个api被拒绝的次数，即针对某一个api调用被拒绝的次数，也可以是在预设时间段内该api调用实体调用的所有api中被拒绝的次数；错误调用api的次数可以指该api调用实体错误调用某个api被拒绝的次数，即针对某一个api错误调用的次数，也可以是在预设时间段内该api调用实体错误调用的所有api的次数，不予限制。
[0125]
其中，错误调用api可以是使用不合理的参数调用api，例如，api的一个输入参数为字符串类型，api调用实体在调用该api时，输入参数值为数字。再例如，api的输入参数为3个，api调用实体在调用该api时，输入参数的个数为3个以上。
[0126]
在一个示例中，授权撤回相关信息包括api调用失败的次数，当该api调用失败的次数超过阈值时，向第一实体发送授权撤回请求消息。
[0127]
在另一个示例中，若api调用失败的次数以及api错误调用的次数的总和超过阈值，则第二实体向第一实体发送授权撤回请求消息。
[0128]
在再一个示例中，若api调用成功的次数达到上限，或预设时间段内api调用成功的次数达到上限，则第二实体向第一实体发送授权撤回请求消息。
[0129]
可选地，授权撤回请求消息还携带以下信息中的至少一种：api标识，aef标识，特定值，或者，撤回原因值，具体可以参见图2所示实施例中的修改描述，不再赘述。
[0130]
本实施例提供的方法，通过第二实体向第一实体发送授权撤回请求消息，所述授权撤回请求消息携带api调用实体的标识；所述第二实体接收来自所述第一实体的授权撤回响应消息，所述授权撤回响应消息用于指示授权撤回成功或失败该方法，完善了调用api的授权管理，使得调用api的授权能够及时被撤回，避免了已经不具备调用api的授权(换言之，授权已经失效或过期)的api调用实体调用api而造成的资源浪费。例如，api调用实体使用原有的授权调用api，aef执行api调用但是最终失败，浪费了aef的处理资源。此外，避免了aef执行已经不具备调用api的授权的api调用实体对api的调用，提升了capif系统的工作效率。
[0131]
可选地，在上述实施例的第一种实施场景下，第二实体为aef，第一实体为ccf，上述方法还包括：
[0132]
第二实体接收来自该api调用实体的api调用请求消息；第二实体根据该api调用请求消息，拒绝该api调用请求消息。
[0133]
其中，该api调用请求消息可以携带请求调用的api对应的api标识。
[0134]
其中，第二实体根据该api调用请求消息，拒绝该api调用请求消息可以包括：
[0135]
当该api调用实体不具备调用该api调用请求消息用于请求调用的api的授权时，第二实体拒绝该api调用请求消息。
[0136]
具体地，拒绝该api调用请求消息可以包括第二实体向该api调用实体发送api调用拒绝消息，或者，不向该api调用实体发送应答消息等，不予限制。
[0137]
在一个示例中，api调用请求消息请求调用api#1，但aef发现该api调用实体不具备调用api#1的授权，换言之，该api调用实体不具备访问api#1的权限，则aef可以直接向该api调用实体发送api调用拒绝消息，以拒绝该api调用实体发送的api调用请求消息。
[0138]
具体地，aef可以在本地保存一个黑名单或白名单，即对每个api都有一个黑名单或白名单，例如，当aef确定黑名单包含api调用实体的标识，就会拒绝该api调用实体发送的 api调用请求消息。
[0139]
其中，黑名单和白名单均可以以api为索引，例如，api#1：api invoker1，api invoker 2，也可以以api调用实体为索引，例如，api invoker1：api#1,api#3，详情可以参见图2所示实施例中的相关描述，不再赘述。
[0140]
上述第一种实施场景，通过aef对不具备授权的api调用实体发送的api调用请求
消息进行拒绝，提升了调用api的处理效率，节省了aef的处理资源。
[0141]
可选地，在上述实施例的第二种实施场景下，上述方法还包括：
[0142]
第二实体向该api调用实体发送授权撤回指示消息。
[0143]
其中，授权撤回指示消息可以参见图2所示实施例中的相关描述，不再赘述。
[0144]
在一个示例中，第二实体根据授权撤回响应消息向该api调用实体发送授权撤回指示消息，例如，当授权撤回响应消息用于指示该api调用实体的授权撤回成功时，向该api调用实体发送授权撤回指示消息。当授权撤回响应消息用于指示该api调用实体的授权撤回失败时，不向该api调用实体发送授权撤回指示消息。
[0145]
在另一个示例中，第二实体根据授权撤回通知消息向该api调用实体发送授权撤回指示消息，例如，若授权撤回响应消息仅仅用于对授权撤回请求消息的应答，即用于指示第一实体已接收到授权撤回请求消息，那么第二实体可以在接收到第一实体发送的授权撤回通知消息(可以参见本实施例的第三种实施场景)后，再根据授权撤回通知消息向该api调用实体发送授权撤回指示消息。
[0146]
通过向api调用实体发送授权撤回指示消息，使得api调用实体能够及时获知其授权信息，避免了api调用实体由于无法知道自己调用某api的的授权信息已经被无效/撤回，依然使用原有的授权调用api，造成了aef执行api调用但是最终失败，浪费了aef的处理资源；此外，api调用实体由于无法知道自己的授权无效或过期，仍然使用原有的授权尝试调用api而造成的api调用实体的处理资源浪费。
[0147]
可选地，在上述实施例的第三种实施场景下，第二实体为aef，第一实体为ccf，上述方法还包括：
[0148]
第二实体接收来自第一实体的授权撤回通知消息，并根据授权撤回通知消息更新该api 调用实体的授权信息。
[0149]
具体地，如果第二实体未曾保存过该api调用实体的授权,则第二实体保存该api调用实体的授权信息，例如，保存在黑名单或白名单中，以便于该aef根据其最新获得的api调用实体的授权信息，对api调用实体的api调用执行合适的操作，例如，当该api调用实体的对某一特定api的授权被撤回，则aef可以直接拒绝该api调用实体的对该特定api调用请求。
[0150]
通过第一实体向第二实体发送授权撤回通知消息，使得第二实体能够及时更新api调用实体的授权信息，例如，当第二实体为aef时，aef能够及时获知api调用实体的授权信息，避免了api调用实体使用原有的授权调用api时，aef仍旧执行api调用，浪费了aef的处理资源；再例如，当第二实体为ccf时，ccf可以根据授权撤回通知消息及时更新其存储的api调用实体的授权信息，避免了api调用实体从该ccf获得api调用的授权时无法得到最新的授权信息而造成的效率低，资源浪费等问题。
[0151]
需要说明的是，上述各实施场景可以两两结合，也可以三个结合，不予限制。
[0152]
如图4所示，本技术的实施例提供又一种授权撤回的方法，该方法可以应用于图1所示的框架中，具体如下所述。
[0153]
401、aef根据api调用实体的授权撤回相关信息，向ccf发送授权撤回请求消息。
[0154]
其中，授权撤回请求消息可以携带api调用实体的标识，可以参见上述各实施例中的相关描述，不再赘述。
[0155]
其中，授权撤回相关信息可以参见图3所示实施例中的相关描述，不再赘述。
[0156]
具体地，步骤401可以包括：当授权撤回相关信息满足预设条件时，aef向ccf发送授权撤回请求消息。
[0157]
在一个示例中，当该api调用实体调用api被拒绝的次数超过预设阈值时，aef向ccf 发送授权撤回请求消息，该授权撤回请求消息携带该api调用实体的标识。其中，该阈值可以是预配置在aef上，也可以由ccf配置给aef。其中，调用api被拒绝的次数可以是针对某一个特定的api，也可以不做限定。
[0158]
在另一个示例中，当该api调用实体错误调用api次数超过预设阈值时，aef向ccf 发送授权撤回请求消息，该授权撤回请求消息携带该api调用实体的标识。该阈值可以是预配置在aef上，也可以由ccf配置给aef。其中，错误调用api的次数可以是针对某一个特定的api，也可以不做限定。
[0159]
在再一个示例中，当该api调用实体错误调用api次数超过第一阈值，且该api调用实体调用api被拒绝的次数超过第二阈值时，aef向ccf发送授权撤回请求消息，该授权撤回请求消息携带该api调用实体的标识。相似地，错误调用api的次数可以是针对某一个特定的api，也可以不做限定。
[0160]
其中，授权撤回请求消息可以携带以下信息中的至少一种：api标识，aef标识，特定值，或者撤回原因值，其中，aef标识可以用于指示步骤401中的aef，具体可以参见图2 所示实施例中的相关描述，不再赘述。
[0161]
402、ccf根据授权撤回请求消息，向aef发送授权撤回响应消息。
[0162]
其中，授权撤回响应消息可以参见图2所示实施例中的相关描述，例如，可以用于指示授权撤回的结果，即指示授权撤回成功或失败。
[0163]
在一个示例中，ccf在接收到该aef发送的授权撤回请求消息，该授权撤回请求消息用于请求撤回调用某一个特定api的授权时，已经和api调用实体之间进行调用该特定api的授权协商，则向aef发送用于指示授权撤回失败的授权撤回响应消息。
[0164]
相应地，aef接收该授权撤回响应消息，进一步地，该aef可以根据授权撤回响应消息更新该api调用实体调用api的授权信息。
[0165]
403、ccf向api调用实体发送授权撤回指示消息。
[0166]
其中，授权撤回指示消息可以用于指示：
[0167]
1)撤回该api调用实体调用对某一特定api的授权；或者，
[0168]
2)撤回该api调用实体调用该aef上所有api的授权；或者，
[0169]
3)撤回该api调用实体调用该ccf上所有api的授权。
[0170]
可选地，该授权撤回指示消息携带以下信息中的至少一种：api标识，aef标识，特定值，或者撤回原因值。
[0171]
具体地，当授权撤回指示消息用于指示上述1)时，授权撤回指示消息可以携带该特定 api标识；当授权撤回指示消息用于指示上述2)时，授权撤回指示消息可以携带aef标识，该aef标识用于指示该aef；当授权撤回指示消息用于指示上述3)时，授权撤回指示消息可以不携带api标识，或者，携带特定值，具体与授权撤回请求消息相似，可以参见授权撤回请求消息的相关描述，不再赘述。
[0172]
相应地，api调用实体接收授权撤回指示消息，进一步地，该api调用实体可以根据
api调用的总次数，api调用失败的次数，或api调用成功的次数等，其中，该api调用信息可以用于获得授权撤回相关信息；或者，ccf接收aef上报的授权撤回相关信息。
[0193]
在一个示例中，当api调用发生异常时，如api调用实体以错误的方式调用api,aef将错误信息上报给ccf。ccf通过这种方式可以获得该api调用实体在ccf管理的整个系统中的api调用情况，从而根据api调用情况撤回api调用实体调用api的授权。
[0194]
502、aef根据授权撤回请求消息，撤回该api调用实体调用api的授权。
[0195]
其中，步骤502中，撤回该api调用实体调用api的授权可以为：
[0196]
撤回该api调用实体调用某一特定api的授权；或者，
[0197]
撤回该api调用实体调用该aef上所有api的授权。
[0198]
在一个示例中，授权撤回请求消息还携带api标识，aef撤回该api调用实体调用该 api标识对应的api的授权。
[0199]
在另一个示例中，授权撤回请求消息还携带api标识和用于指示步骤502中aef的aef 标识，aef撤回该api调用实体调用该aef上该api标识对应的api的授权。
[0200]
在又一个示例中，当授权撤回请求消息未携带api标识，或者，授权撤回请求消息未携带api标识，但携带用于指示步骤502中aef的aef标识，或者，授权撤回请求消息还携带特定值时，aef撤回该api调用实体调用该aef上所有api的授权。
[0201]
需要说明的是，上述撤回具体可以通过在aef本地保存的黑名单或白名单中增加或删除上述api调用实体的相关记录来实现，参见图2所示实施例中的相关描述，不予限制。
[0202]
503、aef向ccf发送授权撤回响应消息。
[0203]
其中，授权撤回响应消息可以包含授权撤回的结果，可以参见图2所示实施例中的相关描述，例如，用于指示授权撤回成功或失败。
[0204]
在一个示例中，aef上api标识指示的api停止使用(例如，不存在该api，或该api 已经下线)，则aef向ccf返回指示授权撤回失败的撤回响应消息。
[0205]
504、ccf向api调用实体发送授权撤回指示消息。
[0206]
相应地，api调用实体接收该授权撤回指示消息，进一步地，该api调用实体可以根据授权撤回指示消息更新调用api的授权信息。
[0207]
其中，步骤504可以参见步骤403中的相关描述。此外，步骤504可以替换为aef向 api调用实体发送授权撤回指示消息，不予限制。
[0208]
需要指出的是，步骤504-506为可选步骤。具体地，步骤505-506可以在步骤504不执行的情况下执行，不予限制。
[0209]
505、api调用实体向aef发送api调用请求消息。
[0210]
其中，该api调用请求消息可以携带请求调用的api对应的api标识。
[0211]
506、aef根据api调用请求消息，拒绝该请求消息。
[0212]
其中，拒绝该请求可以为向api调用实体发送拒绝消息，也可以不向api调用实体发送应答消息，不予限制。
[0213]
其中，步骤506可以参见图3所示实施例中的相关描述，不再赘述。
[0214]
本实施例提供的方法，通过ccf向aef发送授权撤回请求消息，所述授权撤回请求消息携带api调用实体的标识；aef向ccf发送授权撤回响应消息，所述授权撤回响应消息用于指示授权撤回成功或失败该方法，完善了调用api的授权管理，使得调用api的授权能够
及时被撤回，避免了已经不具备调用api的授权(换言之，授权已经失效或过期)的api调用实体调用api而造成的资源浪费。例如，api调用实体使用原有的授权调用api，aef执行api调用但是最终失败，浪费了aef的处理资源。此外，避免了aef执行已经不具备调用api的授权的api调用实体对api的调用，提升了capif系统的工作效率。
[0215]
如图6所示，本技术的实施例提供又一种授权撤回的方法，该方法可以应用于图1所示的框架中，具体如下所述。
[0216]
601、aef根据api调用实体的授权撤回相关信息，撤回该api调用实体调用api的授权。
[0217]
具体地，步骤601可以包括：当授权撤回相关信息满足预设条件时，撤回该api调用实体调用api的授权。
[0218]
其中，授权撤回相关信息，以及撤回等均可以参见上述实施例中的相关描述，不再赘述。
[0219]
602、aef向ccf发送授权撤回通知消息。
[0220]
其中，授权撤回通知消息可以用于指示：
[0221]
1)撤回该api调用实体调用某一特定api的授权；或者，
[0222]
2)撤回该api调用实体调用该aef上所有api的授权。
[0223]
可选地，该授权撤回通知消息携带以下信息中的至少一种：api标识，aef标识，特定值，或者撤回原因值。
[0224]
具体地，当授权撤回通知消息用于指示上述1)时，授权撤回通知消息可以携带该特定 api标识；或者，
[0225]
当授权撤回通知消息用于指示上述2)时，授权撤回通知消息可以携带aef标识，该aef 标识用于指示该aef，或者，授权撤回通知消息携带特定值，或者授权撤回通知消息携带特定值和aef标识，该特定值和该aef标识的组合通知撤回该api调用实体对该aef上所有 api的授权。
[0226]
其中，该授权撤回通知消息可以触发ccf向其他与api调用实体有api调用关系的aef 执行授权请求的流程，实现对api调用实体的api调用的授权的集中管理。该授权撤回通知消息具体可以为撤回api调用授权通知(revoke api invoker authorization notify)消息。
[0227]
603、aef向api调用实体发送授权撤回指示消息。
[0228]
相应地，api调用实体接收该授权撤回指示消息，进一步地，该api调用实体可以根据该授权撤回指示消息更新调用api的授权信息。在一种实现方式中，授权撤回指示消息可以触发api调用实体重定向到api调用实体向ccf请求新的api调用请求页面，或者重定向到api调用实体与ccf进行安全认证和鉴权的页面，强制api调用实体必须先获取api调用的最新授权信息，或者强者api重新认证自己为合法用户之后，才能执行后续的api调用。
[0229]
可选地，该授权撤回指示消息携带以下信息中的至少一种：api标识，aef标识，特定值，或者撤回原因值。api标识，aef标识，特定值，以及撤回原因值。
[0230]
其中，授权撤回指示消息可以用于指示：
[0231]
1)撤回该api调用实体调用某一特定api的授权；或者，
[0232]
2)撤回该api调用实体调用该aef上所有api的授权。
[0233]
具体地，当授权撤回指示消息用于指示上述1)时，授权撤回指示消息可以携带该特定 api标识；或者，
[0234]
当授权撤回指示消息用于指示上述2)时，授权撤回指示消息可以携带aef标识，该aef 标识用于指示该aef，或者，授权撤回指示消息携带特定值，或者，授权撤回指示消息携带特定值和aef标识，该特定值和该aef标识的组合指示撤回该api调用实体调用该aef上所有api的授权。
[0235]
上述通过aef向api调用实体发送授权撤回指示消息，以指示撤回该api调用实体调用 api的授权，以便于该api调用实体能够根据其获得新的调用api的授权信息，避免使用失效的授权信息发起api调用请求造成的调用被拒绝或者调用失败，避免不必要的信息交互，不但能够节省资源，还能够提高效率。
[0236]
其中，该授权撤回指示消息具体可以为撤回api调用授权通知(revoke api invokerauthorization notify)消息。
[0237]
可替换地，步骤603也可以为：ccf向api调用实体发送授权撤回指示消息，例如，在接收到授权撤回通知消息后，向api调用实体发送授权撤回指示消息。此外，可选地，在步骤601之前还可以包括：aef获取该api调用实体的授权撤回相关信息。
[0238]
需要指出的是，步骤602和603均为可选步骤，可以两个步骤均执行，也可以只执行其中一个，也可以均不执行，不予限制。
[0239]
可选地，上述方法还包括：
[0240]
604、api调用实体从ccf获得调用api的授权。
[0241]
其中，上述步骤604中的api可以与上述步骤中的api相同，例如，属于上述步骤中的 api相同，或与上述步骤中的api部分相同，也可以不同，不予限制。
[0242]
6041、api调用实体发送获得api授权请求消息。
[0243]
其中，该获得api授权请求消息用于获得调用api的授权，该消息可以包含api调用实体的标识，可选地，还包括该api标识。
[0244]
6042、ccf对api调用实体进行认证。
[0245]
具体地，步骤6042中可以包括检查用户是否是有权限调用所请求的api，若有权限调用所请求的api，则认证成功。
[0246]
6043、ccf根据api调用实体的签约信息，向api调用实体发送调用api的授权信息。
[0247]
在一个示例中，ccf可以根据api调用实体的签约信息，如api调用实体的标识和时间，生成一个随机字符串,或者令牌(token),或者更新本地的本地维护的api调用实体与 api调用的映射关系表，然后将调用api的授权信息发送给api调用实体。
[0248]
其中，调用api的授权信息可以用于指示api调用实体具备权限调用或访问该api的信息，具体可以是ccf生成并发送给api调用实体的随机字符串或token，或者是ccf本地维护的api调用实体与api之间的映射关系表。
[0249]
本实施例提供的方法，通过aef根据api调用实体的授权撤回相关信息，撤回该api 调用实体调用api的授权，并向ccf发送授权撤回通知消息，完善了调用api的授权管理，使得调用api的授权能够及时被撤回，避免了已经不具备调用api的授权(换言之，授权已经失效或过期)的api调用实体调用api而造成的资源浪费。例如，api调用实体使用原有的授权调用api，aef执行api调用但是最终失败，浪费了aef的处理资源。此外，避免了 aef执行已
经不具备调用api的授权的api调用实体对api的调用，提升了capif系统的工作效率。
[0250]
如图7所示，本技术的实施例提供又一种授权撤回的方法，该方法可以应用于图1所示的框架中，具体如下所述。
[0251]
701、aef接收来自ccf的授权撤回通知消息。
[0252]
其中，授权撤回通知消息携带api调用实体的标识，可以参见上述实施例中的相关描述，不再赘述。
[0253]
702、aef根据授权撤回通知消息，更新api调用实体调用api的授权信息。
[0254]
在一个示例中，授权撤回通知消息携带api调用实体的标识，aef可以更新与该api调用实体相关的所有api的授权信息，例如，记录该api调用实体不具备调用任何api的权限，具体可以通过更新黑名单或白名单来实现，不予限制。
[0255]
在另一个示例中，授权撤回通知消息携带api调用实体的标识和api标识，aef可以更新该api标识对应的api的授权信息。例如，黑名单是基于api的，则可以在黑名单中该 api标识对应的api的相关内容中增加该api调用实体的标识，不予限制。
[0256]
本实施例提供的方法，通过aef接收来自ccf的授权撤回通知消息，并根据授权撤回通知消息，更新api调用实体调用api的授权信息，使得aef能够及时获知api调用实体的授权信息，避免了api调用实体使用原有的授权调用api时，aef仍旧执行api调用，浪费了aef的处理资源。
[0257]
如图8所示，本技术的实施例提供又一种授权撤回的方法，该方法可以应用于图1所示的框架中，具体如下所述。
[0258]
801、api调用实体接收来自第一实体的授权撤回指示消息。
[0259]
其中，第一实体可以为aef或ccf，不予限制。
[0260]
此外，授权撤回指示消息可以参见上述实施例中的相关描述，不再赘述。
[0261]
802、api调用实体根据授权撤回指示消息，更新调用api的授权信息。
[0262]
在一个示例中，api调用实体可以根据授权撤回指示消息，记录调用api的授权信息，例如，记录
[0263]
进一步地，上述方法还可以包括：
[0264]
803、api调用实体根据本地保存的调用api的授权信息，向aef发送api调用请求消息。
[0265]
其中，api调用请求消息可以参见上述实施例中的相关描述，不再赘述。
[0266]
需要指出的是，本技术中提及的“记录”可以替换为保存，此外，当上述更新动作的执行主体内未保存更新相关的信息时，更新可以替换为保存，不予限制。
[0267]
本实施例提供的方法，通过api调用实体接收来自第一实体的授权撤回指示消息，并根据授权撤回指示消息，更新调用api的授权信息，使得api调用实体能够及时获知其授权信息，避免了api调用实体由于无法知道自己调用某api的的授权信息已经被无效/撤回，依然使用原有的授权调用api，造成了aef执行api调用但是最终失败，浪费了aef的处理资源；此外，api调用实体由于无法知道自己的授权无效或过期，仍然使用原有的授权尝试调用api而造成的api调用实体的处理资源浪费。
[0268]
如图9所示，本技术的实施例提供了一种装置，该装置可以为第一实体或位于所述第一实体内，例如，一个或多个芯片，或片上系统，该装置可以用于执行图2所述实施中第一
实体的动作，也可以用于执行图4所示实施例中ccf的动作，还可以用于执行图5所示实施例中aef的动作，不予限制。
[0269]
上述装置具体可以包括：接收单元901和处理单元902，具体如下所述。
[0270]
接收单元901，用于接收来自第二实体的授权撤回请求消息，所述授权撤回请求消息携带api调用实体的标识；
[0271]
处理单元902，用于根据接收单元901接收的所述授权撤回请求消息，向所述第二实体发送授权撤回响应消息。
[0272]
其中，所述授权撤回请求消息还可以携带以下信息中的至少一种：api标识，aef标识，特定值，或者撤回原因值；其中，所述撤回原因值用于指示授权撤回的原因。
[0273]
可选地，处理单元901还用于：
[0274]
所述授权撤回请求消息还携带api标识，撤回所述api调用实体调用所述api标识对应的api的授权；或者，
[0275]
所述授权撤回请求消息还携带api标识和aef标识，撤回所述api调用实体调用所述 aef标识对应的aef上所述api标识对应的api的授权。
[0276]
可选地，所述授权撤回请求消息未携带api标识，处理单元902还用于：
[0277]
撤回所述api调用实体调用所述api调用实体对应的ccf上所有api的授权；或者，
[0278]
所述授权撤回请求消息还携带aef标识，撤回所述api调用实体调用所述aef标识对应的aef上所有api的授权；或者，
[0279]
所述授权撤回请求消息还携带特定值，撤回所述api调用实体调用所述api调用实体对应的ccf上所有api的授权。
[0280]
可选地，上述装置还包括：
[0281]
发送单元903，用于向所述api调用实体发送授权撤回指示消息。
[0282]
其中，所述授权撤回指示消息可以携带以下信息中的至少一种：api标识，aef标识，特定值，或者撤回原因值。
[0283]
可选地，所述第一实体为aef，所述第二实体为所述api调用实体对应的ccf；或者，所述第一实体为所述api调用实体对应的ccf，所述第二实体为aef。
[0284]
可选地，所述第一实体为所述api调用实体对应的ccf，所述第二实体为aef，所述处理单元还用于：
[0285]
在所述撤回所述api调用实体调用所述api调用实体对应的ccf上所有api的授权之后，向所述ccf对应的aef发送授权撤回通知消息，所述授权撤回通知消息携带所述api 调用实体的标识。
[0286]
上述实施例提供的装置，通过接收来自第二实体的授权撤回请求消息，所述授权撤回请求消息携带api调用实体的标识；并根据所述授权撤回请求消息，向所述第二实体发送授权撤回响应消息，完善了调用api的授权管理，使得调用api的授权能够及时被撤回，避免了已经不具备调用api的授权(换言之，授权已经失效或过期)的api调用实体调用api而造成的资源浪费。例如，api调用实体使用原有的授权调用api，aef执行api调用但是最终失败，浪费了aef的处理资源。此外，避免了aef执行已经不具备调用api的授权的api 调用实体对api的调用，提升了capif系统的工作效率。
[0287]
如图10所示，本技术的实施例提供了另一种装置，该装置可以为第二实体或位于
第二实体内，例如，一个或多个芯片，或片上系统，该装置可以用于执行图3所述实施中第二实体的动作，也可以用于执行图4所示实施例中aef的动作，还可以用于执行图5所示实施例中 ccf的动作，不予限制。
[0288]
该装置具体可以包括：发送单元1001和接收单元1002，具体如下所述。
[0289]
发送单元1001，用于向第一实体发送授权撤回请求消息，所述授权撤回请求消息携带 api调用实体的标识；
[0290]
接收单元1002，用于接收来自所述第一实体的授权撤回响应消息，所述授权撤回响应消息用于指示授权撤回成功或失败。
[0291]
可选地，所述装置还包括：
[0292]
处理单元1003，用于根据所述api调用实体的授权撤回相关信息，通过所述发送单元向所述第一实体发送所述授权撤回请求消息。
[0293]
可选地，所述授权撤回相关信息可以包括api调用失败的次数，处理单元1003还用于：
[0294]
当所述api调用失败的次数超过阈值时，通过所述发送单元向所述第一实体发送所述授权撤回请求消息。
[0295]
可选地，所述授权撤回请求消息还携带以下信息中的至少一种：api标识，aef标识，特定值，或者撤回原因值，所述撤回原因值用于指示授权撤回的原因。
[0296]
可选地，所述第一实体为aef，所述第二实体为ccf；或者，所述第一实体为ccf，所述第二实体为aef。
[0297]
可选地，所述第二实体为aef，所述第一实体为ccf；
[0298]
接收单元1001，还用于接收来自所述api调用实体的api调用请求消息；
[0299]
发送单元1002，还用于当所述api调用实体不具备调用所述api调用请求消息用于请求调用的api的授权时，向所述api调用实体发送api调用拒绝消息。
[0300]
可选地，发送单元1002还用于：向所述api调用实体发送授权撤回指示消息。
[0301]
上述实施例提供的装置，通过向第一实体发送授权撤回请求消息，所述授权撤回请求消息携带api调用实体的标识；接收来自所述第一实体的授权撤回响应消息，所述授权撤回响应消息用于指示授权撤回成功或失败，完善了调用api的授权管理，使得调用api的授权能够及时被撤回，避免了已经不具备调用api的授权(换言之，授权已经失效或过期)的api 调用实体调用api而造成的资源浪费。例如，api调用实体使用原有的授权调用api，aef 执行api调用但是最终失败，浪费了aef的处理资源。此外，避免了aef执行已经不具备调用api的授权的api调用实体对api的调用，提升了capif系统的工作效率。
[0302]
如图11所示，本技术的实施例提供又一种装置，该装置可以为aef或位于afe内，例如，一个或多个芯片，或片上系统，该装置可以用于执行图7所示实施例中的方法，该装置可以包括接收单元1101和处理单元1102，具体如下所述。
[0303]
接收单元1101，用于接收来自ccf的授权撤回通知消息；
[0304]
处理单元1102，用于根据授权撤回通知消息，更新api调用实体调用api的授权信息。
[0305]
如图12所示，本技术的实施例提供又一种装置，该装置可以为api调用实体或位于api 调用实体内，例如，一个或多个芯片，或片上系统，该装置可以用于执行图8所示实施例
中的方法，该装置可以包括接收单元1201和处理单元1202，具体如下所述。
[0306]
接收单元1201，用于接收来自第一实体的授权撤回指示消息。
[0307]
处理单元1202，用于根据授权撤回指示消息，更新调用api的授权信息。
[0308]
其中，第一实体可以是aef或ccf，不予限制。
[0309]
上述实施例提供的装置，通过接收来自第一实体的授权撤回指示消息，并根据授权撤回指示消息，更新调用api的授权信息，使得api调用实体能够及时获知其授权信息，避免了 api调用实体由于无法知道自己调用某api的的授权信息已经被无效/撤回，依然使用原有的授权调用api，造成了aef执行api调用但是最终失败，浪费了aef的处理资源；此外， api调用实体由于无法知道自己的授权无效或过期，仍然使用原有的授权尝试调用api而造成的api调用实体的处理资源浪费。
[0310]
如图13所示，本技术的实施例提供又一种装置，该装置可以为aef或位于aef内，例如，一个或多个芯片，或片上系统，该装置可以用于执行图6所示实施例中aef的动作，该装置可以包括处理单元1301和发送单元1302，具体如下所述。
[0311]
处理单元1301，用于根据api调用实体的授权撤回相关信息，撤回该api调用实体调用 api的授权；
[0312]
发送单元1302，用于向ccf发送授权撤回通知消息；
[0313]
发送单元1302，还用于向api调用实体发送授权撤回指示消息。
[0314]
上述实施例提供的装置，通过实时监控api调用实体的状态，实现了对api调用实体进行授权撤回。
[0315]
需要指出的是，本技术涉及的接收单元可以替换为通信接口，发送单元可以替换为通信接口，该通信接口可以采用有线或无线通信，当上述提及的装置为芯片或片上系统时，上述提及的通信接口可以是i/o口，也可以为总线接口；此外，接收单元替换的通信接口与发送单元替换的通信接口可以相同，也可以不同，不予限制。处理单元可以替换为一个或多个处理器，例如，可能是中央处理器(英文：central processing unit，cpu)，也可以是特定集成电路(英文：application specific integrated circuit，asic)，或者是被配置成实施本发明实施例的一个或多个集成电路。例如：一个或多个微处理器(英文：digital singnal processor，dsp)，或，一个或者多个现场可编程门阵列(英文：field programmable gate array，fpga)，不予限制。
[0316]
如图14所示，本实施例提供了又一种装置，可以包括处理器1401和通信接口1402，处理器1401与存储器耦合，处理器1401用于调用存储器中的程序，以执行上述各实施例中涉及的各装置的动作，例如，第一实体，aef，ccf，或api调用实体等。
[0317]
处理器1401，可以为一个或多个，具体参见上述相关描述。
[0318]
通信接口1402，用于处理器1401与存储器进行通信。
[0319]
可选地，装置包括存储器1403，该存储器1403与处理器1401耦合，具体可以为一个或多个，可以是只读存储器(read-only memory，rom)或可存储静态信息和指令的其它类型的静态存储设备，随机存取存储器(random access memory，ram)或者可存储信息和指令的其它类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasableprogrammable read-only memory，eeprom)、只读光盘(compact disc read-only memory， cd-rom)或其它光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟
等)、磁盘存储介质或者其它磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质，但不限于此。
[0320]
其中，存储器1403与处理器1401之间可以通过通信接口1402进行通信，不予限制。
[0321]
本技术实施例提供了一种程序，该程序在被处理器执行时用于执行上述各实施例中涉及的装置的方法。
[0322]
本技术实施例提供了一种计算机可读存储介质，包括上述程序。
[0323]
本技术实施例提供了一种系统，包括：第一实体和第二实体。其中，第一实体可以用于执行图2所示实施例中的动作，第二实体可以用于执行图3所示实施例中的动作。进一步地，上述系统还可以包括api调用实体，该api调用实体可以用于执行图8所示实施例中相应的动作，不再赘述。
[0324]
本技术实施例提供了又一种系统，包括：aef和ccf。该aef和ccf可以用于执行图 6所示实施例中相应的动作。
[0325]
结合本技术公开内容所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器(ram)、闪存、只读存储器(rom)、可擦除可编程只读存储器 (eprom)、电可擦可编程只读存储器(eeprom)、寄存器、硬盘、移动硬盘、只读光盘 (cd-rom)或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于asic中。另外，该asic可以位于核心网接口设备中。当然，处理器和存储介质也可以作为分立组件存在于核心网接口设备中。
[0326]
另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。
[0327]
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本技术可借助软件加必需的通用硬件的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘，硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述的方法。
技术特征：1.一种系统，其特征在于，包括第一实体和第二实体；所述第二实体，用于向所述第一实体发送授权撤回请求消息，所述授权撤回请求消息携带应用软件编程接口api调用实体的标识；所述第一实体，用于接收来自所述第二实体的所述授权撤回请求消息；所述第一实体，还用于根据所述授权撤回请求消息，向所述第二实体发送授权撤回响应消息，所述授权撤回响应消息用于指示授权撤回成功或失败；所述第二实体，还用于接收来自所述第一实体的所述授权撤回响应消息。2.根据权利要求1所述的系统，所述第一实体还用于：所述授权撤回请求消息还携带应用软件编程接口api标识，撤回所述api调用实体调用所述api标识对应的api的授权；或者，所述授权撤回请求消息还携带api标识和api开放功能aef标识，撤回所述api调用实体调用所述aef标识对应的aef上所述api标识对应的api的授权。3.根据权利要求1所述的系统，所述授权撤回请求消息未携带api标识，所述第一实体还用于：撤回所述api调用实体调用所述api调用实体对应的通用api框架核心功能ccf上所有api的授权；或者，所述授权撤回请求消息还携带aef标识，撤回所述api调用实体调用所述aef标识对应的aef上所有api的授权；或者，所述授权撤回请求消息还携带特定值，撤回所述api调用实体调用所述api调用实体对应的ccf上所有api的授权。4.根据权利要求1-3中任一项所述的系统，所述第一实体还用于：向所述api调用实体发送授权撤回指示消息。5.根据权利要求1-4中任一项所述的系统，所述第二实体还用于：根据所述api调用实体的授权撤回相关信息，向所述第一实体发送所述授权撤回请求消息。6.根据权利要求5所述的系统，所述授权撤回相关信息包括api调用失败的次数，所述第二实体还用于：当所述api调用失败的次数超过阈值时，向所述第一实体发送所述授权撤回请求消息。7.根据权利要求1-6中任一项所述的系统，所述授权撤回指示消息携带以下信息中的至少一种：api标识，aef标识，特定值，或者撤回原因值；其中，所述撤回原因值用于指示授权撤回的原因。8.根据权利要求1-7中任一项所述的系统，所述第一实体为aef，所述第二实体为所述api调用实体对应的ccf；或者，所述第一实体为所述api调用实体对应的ccf，所述第二实体为aef。9.根据权利要求8所述的系统，所述第一实体为所述api调用实体对应的ccf，所述第二实体为aef，所述第一实体还用于：向所述ccf对应的aef发送授权撤回通知消息，所述授权撤回通知消息携带所述api调用实体的标识。10.根据权利要求8所述的系统，所述第二实体为aef，所述第一实体为ccf，所述第二实
体还用于：接收来自所述api调用实体的api调用请求消息；当所述api调用实体不具备调用所述api调用请求消息用于请求调用的api的授权时，向所述api调用实体发送api调用拒绝消息。11.根据权利要求8或10所述的系统，所述第二实体还用于：向所述api调用实体发送授权撤回指示消息。12.一种程序，其特征在于，所述程序在被处理器执行时，用于实现权利要求1至11中任一项所述的系统内第一实体所具有的功能。13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括权利要求12所述的程序。14.一种程序，其特征在于，所述程序在被处理器执行时，用于实现权利要求1至11中任一项所述的系统内第二实体所具有的功能。15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括权利要求14所述的程序。
技术总结本申请公开了一种系统、程序以及计算机可读存储介质，涉及通信领域，该系统中的第一实体接收来自第二实体的授权撤回请求消息，所述授权撤回请求消息携带API调用实体的标识；所述第一实体根据所述授权撤回请求消息，向所述第二实体发送授权撤回响应消息。该方法完善了调用API的授权管理，使得调用API的授权能够及时被撤回，避免了已经不具备调用API的授权的API调用实体调用API而造成的资源浪费。例如，API调用实体使用原有的授权调用API，AEF执行API调用但是最终失败，浪费了AEF的处理资源。此外，避免了AEF执行已经不具备调用API的授权的API调用实体对API的调用，提升了CAPIF系统的工作效率。的工作效率。的工作效率。
技术研发人员：葛翠丽 杨艳梅
受保护的技术使用者：华为技术有限公司
技术研发日：2018.01.15
技术公布日：2022/7/5
