CN117641358A

CN117641358A - 通信方法和通信装置

Info

Publication number: CN117641358A
Application number: CN202210972025.2A
Authority: CN
Inventors: 胡力; 吴�荣
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-08-12
Filing date: 2022-08-12
Publication date: 2024-03-01
Also published as: WO2024032226A1

Abstract

本申请实施例提供了一种通信方法和通信装置。该方法包括：API调用者向授权功能网元发送授权请求消息，API调用者接收来自授权功能网元的具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；API调用者向API开放功能网元AEF发送第一API调用请求消息，用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括目标用户的标识和第一令牌。本申请所揭示的方法，能够避免用户隐私暴露，减少网络功能面临的潜在的安全风险。

Description

通信方法和通信装置

技术领域

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

背景技术

当前，在第三代合作伙伴项目(3rd generation partnership project，3GPP)标准能力放开架构中，提供了一种3GPP对外提供服务的方法。例如，应用功能(applicationfunction，AF)网元可以请求3GPP网络对一些信息进行处理，这些信息可以是属于网络的数据，也可以是属于用户的数据。例如，AF可以请求3GPP对外发送用户的位置信息。然而，在这个过程中，用户的隐私信息可能被非法暴露。

发明内容

本申请提供一种通信方法和通信装置，能够避免用户隐私暴露，减少移动通信网络中网络功能面临的潜在的安全风险。

第一方面，提供了一种通信方法，该方法可以由应用软件编程接口(applicationprogramming interface，API)调用者执行，或者，也可以由用于API调用者的芯片或电路执行，本申请对此不作限定。为了便于描述，下面以由API调用者执行为例进行说明。

该方法包括：应用软件编程接口API调用者(API Invoker)向授权功能网元(例如，(authorization function，AuF))发送授权请求消息，授权请求消息包括目标用户的标识；API调用者接收来自授权功能网元的授权响应消息，授权响应消息包括具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；API调用者向API开放功能网元(API exposing function，AEF)发送第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括目标用户的标识和第一令牌。

根据本申请提供的方案，API Invoker可以主动从AuF获得更细粒度的用户授权的token，并使用该token接入AEF，从而使可以AEF授权API Invoker访问某个API并处理某个用户的数据。本申请所揭示的方法，在对用户数据进行处理时引入用户是否授权的考量，能够避免用户的隐私信息被暴露，减少移动通信网络中网络功能面临的潜在的安全风险。

结合第一方面，在第一方面的某些实现方式中，在API调用者向授权功能网元发送授权请求消息之前，API调用者向AEF发送第二API调用请求消息，第二API调用请求消息用于请求调用目标API以操作目标用户的数据，第二API调用请求消息包括目标用户的标识；API调用者接收来自AEF的授权指示；其中，API调用者向授权功能网元发送授权请求消息，包括：API调用者根据授权指示，向授权功能网元发送授权请求消息。

基于上述方案，AEF向API Invoker提供授权指示，使得API调用者确定请求调用目标API以操作目标用户的数据需要用户的授权，进而基于接收到的授权指示向授权功能网元发起授权请求。在API调用流程中引入目标用户的授权，能够避免用户隐私信息的暴露，减少通信网络中潜在的安全风险。

结合第一方面，在第一方面的某些实现方式中，授权指示包括授权功能网元的地址；其中，API调用者接收来自AEF的授权指示，包括：API调用者接收来自AEF的第二API调用响应消息，第二API调用响应消息包括授权指示。

基于上述方案，API调用者可以通过授权指示中携带的授权功能网元的地址，向授权功能网元发送授权请求消息。

结合第一方面，在第一方面的某些实现方式中，在API调用者向授权功能网元发送授权请求消息之前，API调用者向通用API框架核心功能网元(common API framework corefunction，CCF)发送第二请求消息，第二请求消息用于请求用于将API调用者注册到CCF，或者用于API调用者发现目标API；API调用者接收来自CCF的授权指示；其中，API调用者向授权功能网元发送授权请求消息，包括：API调用者根据授权指示，向授权功能网元发送授权请求消息。

基于上述方案，CCF向API Invoker提供授权指示，使得API调用者确定请求调用目标API以操作目标用户的数据需要用户的授权，进而基于接收到的授权指示向授权功能网元发起授权请求。在API调用流程中引入目标用户的授权，能够避免用户隐私信息的暴露，减少通信网络中潜在的安全风险。

结合第一方面，在第一方面的某些实现方式中，授权指示包括授权功能网元的地址；其中，API调用者接收来自CCF的授权指示，包括：API调用者接收来自CCF的第二API调用响应消息，第二API调用响应消息包括授权指示。

应理解，这里来自CCF的第二API调用响应消息，即为响应第二请求消息的消息。

结合第一方面，在第一方面的某些实现方式中，第二API调用响应消息为重定向请求消息。

基于上述方案，API调用者在接收到重定向请求消息后，根据重定向请求消息中携带的授权指示，确定授权功能网元的地址，进而向授权功能网元发送授权请求消息，该实现方式中API调用者可以不清楚授权指示信息的具体含义。

结合第一方面，在第一方面的某些实现方式中，授权指示还包括原因值，原因值用于指示请求操作目标用户的数据需要目标用户的授权。

基于上述方案，API调用者通过授权指示中携带的原因值以及授权功能网元的地址，可以确定需要向授权功能网元获取目标用户的授权，进而向授权功能网元发送授权请求消息，该实现方式中API调用者是清楚授权指示信息的具体含义的，使得API调用者更有针对性地请求获取用户的授权。

结合第一方面，在第一方面的某些实现方式中，授权指示包括原因值，原因值用于指示请求操作目标用户的数据需要目标用户的授权；其中，API调用者根据授权指示，向授权功能网元发送授权请求消息，包括：API调用者根据原因值，确定授权功能网元的地址；API调用者根据授权功能网元的地址，向授权功能网元发送授权请求消息。

基于上述方案，API调用者通过授权指示中携带的原因值可以确定请求操作目标用户的数据需要目标用户的授权，进而根据原因值找到授权功能网元的地址，并向授权功能网元发送授权请求消息。

结合第一方面，在第一方面的某些实现方式中，API调用者根据原因值，确定授权功能网元的地址，包括：API调用者根据原因值，从预配置的地址列表中获取授权功能网元的地址。

基于上述方案，API调用者通过授权指示中携带的原因值可以确定请求操作目标用户的数据需要目标用户的授权，进而从预配置的地址列表中找到对应的授权功能网元的地址，并向授权功能网元发送授权请求消息。

结合第一方面，在第一方面的某些实现方式中，授权指示还包括授权类型，授权请求消息还包括响应类型；其中，在API调用者根据授权指示，向授权功能网元发送授权请求消息之前，API调用者根据授权类型确定响应类型。

基于上述方案，API调用者通过授权指示中携带的授权类型，确定向授权功能网元发送的授权请求消息中携带的响应类型，可以使得在API调用流程中更加针对性地进行用户的授权，某种程度上可以保证网元之间信息交互的一致性，降低网络潜在风险和干扰。

结合第一方面，在第一方面的某些实现方式中，第一API调用请求消息还包括第二令牌，第二令牌用于指示API调用者具有调用目标API的权限，第二令牌包括API调用者的标识和目标API的标识；其中，在API调用者向AEF发送第一API调用请求消息之前，API调用者向通用API框架核心功能网元CCF发送第一请求消息，第一请求消息用于请求获取调用目标API的权限，第一请求消息包括API调用者的标识和目标API的标识；API调用者接收来自CCF的第二令牌。

基于上述方案，API调用者可以在请求调用目标API以操作目标用户的数据时，携带第一令牌和第二令牌，即实现API调用者可以被授权具有调用(或者访问)目标API的权限，同时可以被授权具有调用目标API以操作目标用户的数据的权限，能够确保此次API调用流程的完整性和安全性，对于保护用户的隐私安全提供了双层保障，减少潜在的通信风险。

结合第一方面，在第一方面的某些实现方式中，第一令牌包括还包括以下一项或者多项：超时时间；API调用者的标识；目标API的标识；签名者。

基于上述方案，通过在第一令牌中提供更多的声明信息，能够进一步确保此次API调用的安全性，为保护用户隐私信息不被泄露提供多层保障，有利于降低网络通信的风险。

结合第一方面，在第一方面的某些实现方式中，授权请求消息还包括：目标API的标识；和/或目标用户的标识。

基于上述方案，通过在授权请求消息中携带目标API的标识；和/或目标用户的标识，使得API调用者的调用请求更有针对性，便于后续授权功能网元生成的第一令牌中具有更多的声明内容信息，有利于在API调用流程中为目标用户提供更安全的保护措施，避免用户个人数据被泄露等风险的存在。

第二方面，提供了一种通信方法，该方法可以由API开放功能网元AEF执行，或者，也可以由用于API开放功能网元的芯片或电路执行，本申请对此不作限定。为了便于描述，下面以由API开放功能网元执行为例进行说明。

该方法包括：AEF接收来自API调用者的第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括具有完整性保护的第一令牌和目标用户的标识，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；AEF根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限；根据确定结果，AEF确定是否向API调用者提供访问目标用户的数据的权限。

根据本申请提供的方案，在API调用流程中，AEF通过验证更细粒度的、用于用户授权的第一令牌，可以确定API调用者是否具有操作目标用户的数据的权限；并且进一步地，AEF可以根据确定结果确定是否向API调用者提供访问目标用户的数据的权限。基于AEF对于API调用请求的多层验证，能够避免用户的隐私信息被暴露，减少移动通信网络中网络功能面临的潜在的安全风险。

结合第二方面，在第二方面的某些实现方式中，AEF根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限，包括：AEF根据授权功能网元的凭证，对第一令牌的完整性保护进行验证，授权功能网元为生成第一令牌的网元；在第一令牌的完整性保护验证通过的情况下，AEF判断第一令牌中携带的目标用户的标识，是否与第一API调用请求消息中携带的目标用户的标识相同。

基于上述方案，AEF首先通过授权功能网元的凭证可以实现对第一令牌的完整性保护的验证。进一步地，AEF再判断第一令牌中携带的目标用户的标识，是否与第一API调用请求消息中携带的目标用户的标识相同。通过双重验证来确保第一令牌的真实性和准确性，进而为后续接受API调用者所请求的操作目标用户的数据提供安全保障，避免对用户的隐私造成泄露，以及增加潜在的风险。

结合第二方面，在第二方面的某些实现方式中，第一令牌还包括签名者；其中，在AEF根据授权功能网元的凭证，对第一令牌进行完整性验证之前，方法还包括：AEF根据签名者，获取授权功能网元的凭证。

基于上述方案，通过对第一令牌签名，能够确定该用户授权的真实性和可靠性，便于后续AEF验证第一令牌是确定该用户同意授权操作目标用户的个人数据这一信息是否真实有效，避免中途被其他网元恶意篡改造成对目标用户的侵害，以及产生潜在的风险。

结合第二方面，在第二方面的某些实现方式中，第一令牌还包括API调用者的标识，第一API调用请求消息还包括API调用者的标识，AEF根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限，还包括：AEF判断第一令牌中携带的API调用者的标识，是否与第一API调用请求消息中携带的API调用者的标识相同。

基于上述方案，分别在第一令牌以及第一API调用请求消息中携带API调用者的标识，AEF通过判断两个API调用者的标识是否相同，进而可以确认该第一令牌是否有效，防止第一令牌中途被恶意篡改，降低目标用户的个人信息被泄露的风险。

结合第二方面，在第二方面的某些实现方式中，第一令牌还包括目标API的标识，第一API调用请求消息还包括目标API的标识，AEF根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限，还包括：AEF判断第一令牌中携带的目标API的标识，是否与第一API调用请求消息中携带的目标API的标识相同。

基于上述方案，分别在第一令牌以及第一API调用请求消息中携带目标API的标识，AEF通过判断两个目标API的标识是否相同，进而可以确认该第一令牌是否有效，防止第一令牌中途被恶意篡改，降低目标用户的个人信息被泄露的风险。同时，通过验证目标API的标识还可以进一步确定是否授权API调用者具有调用目标API的权限。

结合第二方面，在第二方面的某些实现方式中，第一API调用请求消息还包括第二令牌；其中，在确定API调用者是否具有操作目标用户的数据的权限之前，AEF根据第二令牌，确定API调用者具有调用目标API的权限。

基于上述方案，通过在第一API调用请求消息中携带第二令牌，并在验证第二令牌通过的情况下确定API调用者具有调用目标API的权限。该实现方式对于API调用者的调用请求提供多层验证，确保API调用请求操作的用户数据的安全可靠性。

结合第二方面，在第二方面的某些实现方式中，第二令牌还包括目标API的标识，第一API调用请求消息还包括目标API的标识；其中，AEF根据第二令牌，确定API调用者具有调用目标API的权限，包括：AEF确定第二令牌中携带的目标API的标识，与第一API调用请求消息中携带的目标API的标识相同。

基于上述方案，AEF通过判断第二令牌，以及第一API调用请求消息中携带的两个A目标API的标识是否相同，进而可以确认该API调用者是否可以被授权调用目标API。基于该实现方式加入对第二令牌的验证，能够降低目标用户的个人信息被泄露的风险，提供API调用流程的双重保险，安全性更高。

结合第二方面，在第二方面的某些实现方式中，在AEF接收来自API调用者的第一API调用请求消息之前，AEF接收来自API调用者的第二API调用请求消息，第二API调用请求消息用于请求调用目标API以操作目标用户的数据，第二API调用请求消息包括目标用户的标识；AEF向API调用者发送授权指示，授权指示用于指示请求操作目标用户的数据需要目标用户的授权。

结合第二方面，在第二方面的某些实现方式中，授权指示包括授权功能网元的地址；其中，AEF向API调用者发送授权指示，包括：AEF向API调用者发送第二API调用响应消息，第二API调用响应消息包括授权指示。

结合第二方面，在第二方面的某些实现方式中，第二API调用响应消息为重定向请求消息。

结合第二方面，在第二方面的某些实现方式中，授权指示包括原因值，原因值用于指示请求操作目标用户的数据需要目标用户的授权。

结合第二方面，在第二方面的某些实现方式中，在AEF向API调用者发送授权指示之前，AEF确定请求操作目标用户的数据需要目标用户的授权。

基于上述方案，AEF在确定请求操作目标用户的数据需要目标用户的授权的情况下，向API调用者发送授权指示，用于指示请求操作目标用户的数据需要目标用户的授权。

结合第二方面，在第二方面的某些实现方式中，AEF确定请求操作目标用户的数据需要目标用户的授权，包括：AEF向统一数据管理功能网元UDM发送获取请求消息，获取请求消息用于请求获取目标用户的用户同意信息；AEF接收来自UDM的响应消息；AEF根据响应消息，确定请求操作目标用户的数据需要目标用户的授权。

基于上述方案，AEF基于UDM的响应消息可以确定请求操作目标用户的数据需要目标用户的授权，进而向API调用者发送授权指示，用于向授权功能网元进行用户的授权。

结合第二方面，在第二方面的某些实现方式中，在AEF向UDM发送获取请求消息之前，AEF确定AEF没有保存有目标用户的用户同意信息，用户同意信息指示目标用户同意操作目标用户的数据。

基于上述方案，AEF在确保本地未存储有目标用户的用户同意信息的情况下，再向UDM请求获取目标用户的用户同意信息，能够避免造成不必要的信令开销，减少交互次数。

结合第二方面，在第二方面的某些实现方式中，AEF向通用API框架核心功能网元CCF发送第三请求消息，第三请求消息用于请求获取API调用者调用目标API的访问策略，第三请求消息包括API调用者的标识和目标API的标识；其中，根据确定结果，AEF确定是否向API调用者提供访问目标用户的数据的权限，包括：在API调用者具有操作目标用户的数据的权限，且访问策略指示允许API调用者调用目标API的情况下，AEF向API调用者提供访问目标用户的数据的权限。

需要说明的是，上述AEF向CCF发送第三请求消息，请求获取API调用者调用目标API的访问策略，以及上述API调用者向CCF发送第一请求消息，请求获取访问目标API的第二令牌，这两种实现方式是并列方案。当然，本申请也不排除API调用者向CCF请求获取第二令牌后，向AEF发送第一API调用请求消息，AEF在判断API是否具有访问目标API的权限的时候，再次向CCF请求获取API调用者调用目标API的访问策略，通过访问策略以及第二令牌双重验证，能够保证API调用流程的更安全性。

基于上述方案，AEF可以向CCF请求获取访问目标API的访问策略，进而确定是否允许API调用者调用目标API。同时，基于API调用者具有操作目标用户的数据的权限的情况下，AEF可以确定是否向API调用者提供访问目标用户的数据的权限。通过考虑目标API的调用权限，以及操作目标用户的数据的权限，能够保证API调用者的调用请求的可靠性，保障目标用户的数据的安全性，降低目标用户的个人数据在通信网络中的潜在风险。

结合第二方面，在第二方面的某些实现方式中，在API调用者具有操作目标用户的数据的权限的情况下，AEF向统一数据管理功能UDM发送签约信息更新消息，签约信息更新消息用于更新目标用户的用户同意信息，用户同意信息用于指示目标用户同意操作目标用户的数据。

基于上述方案，在API调用者具有操作目标用户的数据的权限的情况下，AEF可以更新UDM上的签约信息，以减少AuF请求RO授权的次数，在保障目标用户的个人数据的安全性的基础上，减少信令开销。

第三方面，提供了一种通信方法，该方法可以由授权功能网元(authorizationfunction，AuF)执行，或者，也可以由用于AuF的芯片或电路执行，本申请对此不作限定。为了便于描述，下面以由AuF执行为例进行说明。

该方法包括：授权功能网元接收来自应用软件编程接口API调用者的授权请求消息，授权请求消息包括目标用户的标识；在确定目标用户同意API调用者操作目标用户的数据的情况下，授权功能网元生成具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；授权功能网元向API调用者发送授权响应消息，授权响应消息包括第一令牌。

根据本申请提供的方案，授权功能网元在确定目标用户同意API调用者操作目标用户的数据的情况下，向API Invoker提供更细粒度的用户授权的token，便于后续使用该token接入AEF，从而使可以AEF授权API Invoker访问某个API并处理某个用户的数据。本申请所揭示的方法，在对用户数据进行处理时引入用户是否授权的考量，能够避免用户的隐私信息被暴露，减少移动通信网络中网络功能面临的潜在的安全风险。

结合第三方面，在第三方面的某些实现方式中，授权请求消息还包括目标API的标识和目标用户的标识，授权功能网元生成具有完整性保护的第一令牌，包括：授权功能网元根据API调用者的标识、目标API的标识和目标用户的标识生成声明；授权功能网元根据声明生成签名；授权功能网元根据声明和签名生成具有完整性保护的第一令牌。

基于上述方案，授权功能网元基于授权请求消息中携带的API调用者的标识、目标API的标识和目标用户的标识，以及在用户同意授权操作目标用户的数据的情况下，生成第一令牌，确保第一令牌的完整性、真实性以及有针对性，能够降低后续操作用户的个人数据造成对用户隐私信息的暴露风险。

结合第三方面，在第三方面的某些实现方式中，第一令牌包括还包括以下一项或者多项：超时时间；API调用者的标识；目标API的标识；签名者。

结合第三方面，在第三方面的某些实现方式中，授权请求消息还包括：目标API的标识；和/或目标用户的标识。

第四方面，提供了一种通信方法，该方法可以由通用API框架核心功能网元(Common API Framework Core Function，CCF)执行，或者，也可以由用于CAPIF核心功能网元的芯片或电路执行，本申请对此不作限定。为了便于描述，下面以由CAPIF核心功能网元执行为例进行说明。

该方法包括：通用应用软件编程接口API框架核心功能网元CCF接收来自API调用者的第二请求消息，第二请求消息用于请求用于将API调用者注册到CCF，或者用于API调用者发现目标API；CCF向API调用者发送授权指示。

根据本申请提供的方案，CCF向API Invoker提供授权指示，使得API调用者确定请求调用目标API以操作目标用户的数据需要用户的授权，进而基于接收到的授权指示向授权功能网元发起授权请求。在API调用流程中引入目标用户的授权，能够避免用户隐私信息的暴露，减少通信网络中潜在的安全风险。

结合第四方面，在第四方面的某些实现方式中，授权指示包括授权功能网元的地址；其中，CCF向API调用者发送授权指示，包括：CCF向API调用者第二响应消息，第二响应消息包括授权指示。

结合第四方面，在第四方面的某些实现方式中，第二响应消息为重定向请求消息。

结合第四方面，在第四方面的某些实现方式中，授权指示还包括原因值，原因值用于指示请求操作目标用户的数据需要目标用户的授权。

结合第四方面，在第四方面的某些实现方式中，CCF接收来自API调用者的授权请求消息，授权请求消息包括API调用者的标识、目标API的标识以及目标用户的标识；CCF向授权功能网元发送授权请求消息；CCF接收来自授权功能网元的授权响应消息，授权响应消息包括具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；CCF向API调用者发送授权响应消息。

基于上述方案，CCF作为中间节点，转发AuF与API Invoker之间的消息，可以在减少API Invoker与AuF交互信令的基础上实现更细粒度的授权，即授权API Invoker访问某个API并处理某个用户的数据。

结合第四方面，在第四方面的某些实现方式中，在CCF向授权功能网元发送授权请求消息之前，CCF根据预配置的地址列表，确定授权功能网元的地址；CCF根据授权功能网元的地址，向授权功能网元发送授权请求消息。

基于上述方案，CCF在确定请求操作目标用户的数据需要目标用户的授权的情况下，可以找到目标API对应的授权功能网元的地址，并向授权功能网元发送授权请求消息。

结合第四方面，在第四方面的某些实现方式中，CCF接收来自API调用者的第一请求消息，第一请求消息用于请求获取调用目标API的权限，第一请求消息包括API调用者的标识和目标API的标识；CCF向API调用者发送第二令牌，第二令牌用于指示API调用者具有调用目标API的权限，第二令牌包括API调用者的标识和目标API的标识。

基于上述方案，CCF通过向API调用者下发第二令牌，指示API调用者具有调用目标API的权限。进一步地，便于后续API调用者在请求调用目标API以操作目标用户的数据时，携带第一令牌和第二令牌，即实现API调用者可以被授权具有调用(或者访问)目标API的权限，同时可以被授权具有调用目标API以操作目标用户的数据的权限，对于保护用户的隐私安全提供了双层保障，减少潜在的通信风险。

结合第四方面，在第四方面的某些实现方式中，CCF接收来自AEF的第三请求消息，第三请求消息用于请求获取API调用者调用目标API的访问策略，访问策略用于指示是否允许API调用者调用目标API，第三请求消息包括API调用者的标识和目标API的标识；CCF向AEF发送访问策略。

基于上述方案，CCF可以向AEF发送访问目标API的访问策略，指示是否允许API调用者调用目标API。通过考虑目标API的调用权限，以及操作目标用户的数据的权限，能够保证API调用请求的可靠性，保障目标用户的数据的安全性，降低目标用户的个人数据在通信网络中的潜在风险。

第五方面，提供了一种通信方法，该方法可以由授权功能网元执行，或者，也可以由用于授权功能网元的芯片或电路执行，本申请对此不作限定。为了便于描述，下面以由授权功能网元执行为例进行说明。

该方法包括：授权功能网元接收来自应用软件编程接口API开放功能网元AEF的授权请求消息，授权请求消息包括API调用者的标识和目标用户标识；在确定目标用户授权API调用者操作目标用户的数据的情况下，授权功能网元向AEF发送获取授权响应消息，获取授权响应消息包括授权结果，授权结果用于指示目标用户是否授权API调用者操作目标用户的数据。

根据本申请提供的方案，在API调用流程中，可以在不影响API Invoker的基础上实现更细粒度的授权，即授权API Invoker访问某个API并处理某个用户的数据。授权功能网元通过向AEF发送授权结果，用于AEF确定API调用者是否具有操作目标用户的数据的权限，避免用户的隐私信息被暴露，减少移动通信网络中网络功能面临的潜在的安全风险。

第六方面，提供了一种通信方法，该方法可以由API开放功能网元(API exposingfunction，AEF)执行，或者，也可以由用于API开放功能网元的芯片或电路执行，本申请对此不作限定。为了便于描述，下面以由API开放功能网元执行为例进行说明。

该方法包括：应用软件编程接口API开放功能网元AEF向授权功能网元发送授权请求消息，授权请求消息包括API调用者的标识和目标用户的标识；AEF接收来自授权功能网元的授权响应消息，授权响应消息包括授权结果，授权结果用于指示目标用户是否授权API调用者操作目标用户的数据。

根据本申请提供的方案，在API调用流程中，可以在不影响API Invoker的基础上实现更细粒度的授权，即授权API Invoker访问某个API并处理某个用户的数据。AEF通过接收来自授权功能网元的授权结果，可以确定API调用者是否具有操作目标用户的数据的权限，避免用户的隐私信息被暴露，减少移动通信网络中网络功能面临的潜在的安全风险。

结合第六方面，在第六方面的某些实现方式中，在AEF向API调用者发送授权指示之前，AEF确定请求操作目标用户的数据需要目标用户的授权。

示例性的，AEF可以根据本地配置的API列表确定目标API的调用需要目标用户的授权。可选地，API列表可以是AEF预配置的，也可以是其他网元为AEF配置的，本申请对此不作具体限定。

可选地，API列表还可以对应授权功能网元的地址，即AEF根据目标API获得授权功能网元的地址。

结合第六方面，在第六方面的某些实现方式中，AEF确定请求操作目标用户的数据需要目标用户的授权，包括：AEF向统一数据管理功能网元UDM发送获取请求消息，获取请求消息用于请求获取目标用户的用户同意信息；AEF接收来自UDM的响应消息；AEF根据响应消息，确定请求操作目标用户的数据需要目标用户的授权。

可选地，该响应消息可以用于指示UDM未保存有目标用户的用户同意信息，或者可以用于指示请求操作目标用户的数据需要该目标用户的授权等。

结合第六方面，在第六方面的某些实现方式中，在AEF向UDM发送获取请求消息之前，AEF确定AEF没有保存有目标用户的用户同意信息，用户同意信息指示目标用户同意操作目标用户的数据。

需要说明的是，AEF没有保存有目标用户的用户同意信息，可以理解为AEF本地未存储目标用户的UE上下文，也可以理解为本地存储的目标用户的UE上下文中未保存目标用户的用户同意信息。

结合第六方面，在第六方面的某些实现方式中，AEF向授权功能网元发送授权请求消息，包括：AEF根据预配置的地址列表，确定授权功能网元的地址；AEF根据授权功能网元的地址，向授权功能网元发送授权请求消息。

基于上述方案，AEF根据地址列表可以找到目标API对应的授权功能网元的地址，并向授权功能网元发送授权请求消息。

结合第六方面，在第六方面的某些实现方式中，在API调用者具有操作目标用户的数据的权限的情况下，AEF向统一数据管理功能UDM发送签约信息更新消息，签约信息更新消息用于更新目标用户的用户同意信息，用户同意信息用于指示目标用户同意操作目标用户的数据。

示例性的，签约信息更新消息包括以下一项或者多项：目标用户的标识；数据处理目的，数据处理目的是根据API得到的；API调用者的标识；超时时间；用户同意结果。

基于上述方案，在API调用者具有操作目标用户的数据的权限的情况下，AEF可以更新UDM上的签约信息以减少AuF请求RO授权的次数，在授权API Invoker访问某个API并处理某个用户的数据的情况下，保障用户数据的安全性的同时可以减少信令开销。

第七方面，提供了一种API调用者。该网元包括：处理网元，用于生成授权请求消息；收发单元，用于向授权功能网元发送授权请求消息，授权请求消息包括API调用者的标识；收发单元，还用于接收来自授权功能网元的授权响应消息，授权响应消息包括具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；收发单元，还用于向API开放功能网元AEF发送第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括目标用户的标识和第一令牌。

该收发单元可以执行前述第一方面中的接收和发送的处理，处理单元可以执行前述第一方面中除了接收和发送之外的其他处理。

第八方面，提供了一种API开放功能网元AEF。该网元包括：收发单元，用于接收来自API调用者的第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括具有完整性保护的第一令牌和目标用户的标识，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；处理单元，用于根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限；处理单元，还用于根据确定结果，AEF确定是否向API调用者提供访问目标用户的数据的权限。

该收发单元可以执行前述第二面或第六方面中的接收和发送的处理，处理单元可以执行前述第二方面或第六方面中除了接收和发送之外的其他处理。

第九方面，提供了一种授权功能网元。该网元包括：收发单元，用于接收来自应用软件编程接口API调用者的授权请求消息，授权请求消息包括API调用者的标识；处理单元，用于在确定目标用户同意API调用者操作目标用户的数据的情况下，授权功能网元生成具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；收发单元，还用于向API调用者发送授权响应消息，授权响应消息包括第一令牌。

该收发单元可以执行前述第三面或第五方面中的接收和发送的处理，处理单元可以执行前述第三方面或第五方面中除了接收和发送之外的其他处理。

第十方面，提供了一种CAPIF核心功能网元。该网元包括：收发单元，用于接收来自API调用者的第二请求消息，第二请求消息用于请求用于将API调用者注册到CCF，或者用于API调用者发现目标API；收发单元，还用于向API调用者发送授权指示。

该收发单元可以执行前述第四方面中的接收和发送的处理，处理单元可以执行前述第四方面中除了接收和发送之外的其他处理。

第十一方面，提供了一种通信装置，包括收发器、处理器和存储器，该处理器用于控制收发器收发信号，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得该通信装置执行上述第一方面至第六方面及其任一种可能实现方式中的方法。

可选地，所述处理器为一个或多个，所述存储器为一个或多个。

可选地，所述存储器可以与所述处理器集成在一起，或者所述存储器与处理器分离设置。

可选地，该通信装置还包括，发射机(发射器)和接收机(接收器)。

第十二方面，提供了一种通信系统，包括API调用者、授权功能网元、API开放功能网元和CAPIF核心功能网元。

第十三方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序或代码，所述计算机程序或代码在计算机上运行时，使得所述计算机执行上述第一方面至第六方面及其任一种可能实现方式中的方法。

第十四方面，提供了一种芯片，包括至少一个处理器，所述至少一个处理器与存储器耦合，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得安装有该芯片系统的通信装置执行上述第一方面至第六方面及其任一种可能实现方式中的方法。

其中，该芯片可以包括用于发送信息或数据的输入电路或者接口，以及用于接收信息或数据的输出电路或者接口。

第十五方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码被通信装置运行时，使得所述通信装置执行上述第一方面至第六方面及其任一种可能实现方式中的方法。

附图说明

图1是适用本申请的网络架构的一例示意图。

图2是适用本申请的网络架构的另一例示意图。

图3是本申请实施例提供的通信方法300的流程示例图。

图4是本申请实施例提供的通信方法400的流程示例图。

图5是本申请实施例提供的通信方法500的流程示例图。

图6是本申请实施例提供的通信方法600的流程示例图。

图7是本申请实施例提供的通信方法700的流程示例图。

图8是本申请实施例提供的一种通信装置的结构示意图。

图9是本申请实施例提供的另一种通信装置的结构示意图。

具体实施方式

下面将结合附图，对本申请中的技术方案进行描述。

本申请提供的技术方案可以应用于各种通信系统，例如：新无线(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网络通常包括但不限于第五代移动通信(5th-generation，5G)网络、第四代移动通信(4th-generation，4G)网络，以及未来的其他通信系统，例如(6th-generation，6G)网络等。

为了方便描述，本申请实施例中将以PLMN或5G网络为例进行说明。

图1的(a)是适用本申请的网络架构的一例示意图，以3GPP标准化过程中定义的非漫游场景下，基于服务化架构SBA的5G网络架构为例。如图所示，该网络架构可以包括三部分，分别是终端设备部分、数据网络(data network，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部分可以包括但不限于如下网络功能(Network Function，NF)：用户面功能(user plane function，UPF)130、网络开放功能(network exposure function，NEF)131、网络功能存储库功能(network function repository function，NRF)132、策略控制功能(policy control function，PCF)133、统一数据管理功能(unified data management，UDM)134、统一数据存储库功能(unified data repository，UDR)135、网络数据分析功能(network data analytics function，NWDAF)136、认证服务器功能(AuthenticationServer Function，AUSF)137、接入与移动性管理功能(access and mobility managementfunction，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接入运营商网络的接入控制和移动性管理，例如包括移动状态管理，分配用户临时身份标识，认证和授权用户等功能。

10、SMF 139是由运营商网络提供的控制面网络功能，负责管理终端设备110的协议数据单元(protocol data unit，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的(a)中Nnef、Nnrf、Npcf、Nudm、Nudr、Nnwdaf、Nausf、Namf、Nsmf、N1、N2、N3、N4，以及N6为接口序列号。示例性的，上述接口序列号的含义可参见3GPP标准协议中定义的含义，本申请对于上述接口序列号的含义不做限制。需要说明的是，图中的各个网络功能之间的接口名称仅仅是一个示例，在具体实现中，该系统架构的接口名称还可能为其他名称，本申请对此不作限定。此外，上述各个网元之间的所传输的消息(或信令)的名称也仅仅是一个示例，对消息本身的功能不构成任何限定。

为方便说明，本申请实施例中将网络功能(如NEF 131…SMF139)统称/简称为NF，即本申请实施例中后文所描述的NF可替换为任一个网络功能。另外，图1的(a)仅示意性地描述了部分网络功能，后文所描述的NF不局限于图1的(a)中示出的网络功能。

应理解，上述应用于本申请实施例的网络架构仅是从服务化架构的角度描述的网络架构，适用本申请实施例的网络架构并不局限于此，任何能够实现上述各个网元的功能的网络架构都适用于本申请实施例。

还应理解，图中所示的AMF、SMF、UPF、NEF、AUSF、NRF、PCF、UDM可以理解为核心网中用于实现不同功能的网元，例如可以按需组合成网络切片。这些核心网网元可以各自独立的设备，也可以集成于同一设备中实现不同的功能，本申请对于上述网元的具体形态不作限定。

还应理解，上述命名仅为便于区分不同的功能而定义，不应对本申请构成任何限定。本申请并不排除在5G网络以及未来其它的网络中采用其他命名的可能。例如，在6G网络中，上述各个网元中的部分或全部可以沿用5G中的术语，也可能采用其他名称等。

图1的(b)是适用本申请的网络架构的另一例示意图，例如CAPIF架构。如图所示，该网络架构包括API调用者、CCF、AEF、AuF、资源拥有者客户端(resource owner client)、资源拥有者(resource owner，RO)等，下面对各个网元的功能进行简单说明。

1、API调用者(API Invoker)：通常由与PLMN运营商签订服务协议的第三方应用程序提供商提供。API Invoker可以是AF，也可以是UE。主要用于提供API调用者身份和API调用者鉴权所需的其他信息，支持鉴权；支持与CAPIF的相互认证；在访问服务API之前获得授权；发现服务API信息；调用服务API。

2、CCF：主要用于根据API调用者鉴权所需的身份和其他信息对API调用者进行鉴权；支持与API调用者的相互认证；在访问服务API之前为API调用者提供授权；发布、存储和支持服务API信息的发现；根据PLMN运营商配置的策略控制业务API访问；存储服务API调用的日志，并将服务API调用日志提供给授权实体；根据服务API调用日志计费；监控服务API调用；加入新的API调用者和退出API调用者；存储CAPIF和业务API相关的策略配置；支持访问日志进行审计(例如检测滥用)；支持在CAPIF对接中使用另一个CAPIF核心函数发布、发现服务API信息。

3、AEF：AEF是服务API的提供者，也是服务API与API调用者的服务通信入口。在3GPP网络中，AEF可以是NEF。主要用于根据CAPIF核心函数提供的API调用者鉴权所需的身份和其他信息，对API调用者进行鉴权；验证CAPIF核心职能提供的授权；记录CAPIF核心函数的服务API调用。

4、AuF：用于获得用户授权。AuF可以在成功认证资源拥有者后向客户端提供接入令牌，以提供用户授权。

5、资源拥有者客户端：发起请求的客户端，通常是浏览器，编辑器，网络爬虫或其他资源所有者所使用的工具。

6、RO：能够授予对受保护资源的访问权限的实体。资源所有者可以是个人。在申请中，可以是3GPP的签约者。

为便于理解本申请实施例，首先对本申请中涉及到的术语或技术做简单说明。

1、用户同意信息：本申请中涉及的用户同意信息用于指示用户对某些数据操作是否同意。具体地，用户同意信息包括两个部分数据处理目的和用户同意结果，其中，数据处理目的用于指示对数据操作的目的。

例如，对数据操作的目的包括但不限于：模型训练、数据分析、数据共享、非地面网络位置查询、RAN数据分析、或RAN数据模型训练等等。数据处理目的可以用于指示对数据操作的目的是模型训练、数据分析、或数据共享。

可选地，数据处理目的还可以称为数据使用目的、数据获取目的等，本申请中信息(或消息)的名称不做任何限定，能够实现相应的功能即可。

用户同意结果用于指示是否同意该数据操作的目的，例如，granted代表同意，notgranted代表不同意。还例如，1代表同意，0代表不同意。

示例性地，本申请中用户同意信息还可以包括网络标识。该网络标识用于标识支持用户同意或者不同意数据操作的目的网络，例如，该网络标识可以是公共陆地移动网络PLMN ID。

2、完整性保护(Integrity protection)

完整性保护是指通过物理手段或密码学方法来确保信息在生成、传输、存储过程中，以及之后没有被篡改或没有被未经授权的修改。

其中，通过密码学方法对信息进行完整性保护可以有多种方式。例如，使用非对称密钥中的私钥(private key)对信息进行数字签名，或者使用单向函数(如哈希函数Hash)，以对称密钥(共享密钥)及信息作为输入参数，用来生成消息认证码(messageauthentication code，MAC)、或者不使用密钥而单独使用单向函数(如哈希函数Hash)，以信息作为输入参数，用来生成哈希值Hash value。

现有的3GPP架构下，AF可以请求获得3GPP网络处理一些3GPP的信息。这些信息可以包含对于网络数据的处理，也可以包含用户数据的处理。特别对于用户数据的处理，AF应该需要获得用户的授权。例如，AF可以请求3GPP对外发送用户的位置信息，如果未获得用户的授权，可能会暴露了用户的隐私信息。因此，亟需一种方法来使AF在请求3GPP网络处理用户数据前，获得用户的授权。

下面结合图2介绍对API调用者到AEF调用特定的API的方案进行说明。

图2的(a)是CAPIF基于TLS with OAuth token中的Oauth 2.0client_credential的CCF授权API Invoker到AEF调用特定的API的流程，具体包括如下多个步骤。

S211，API调用者(API Invoker)向CCF发送注册请求消息#1。

对应的，CCF接收来自API调用者的注册请求消息#1。

其中，该注册请求消息#1包含注册信息和登记API。

示例性的，注册信息包含API Invoker的信息，例如登记细节、注册需求等。登记API包含需要登记的API列表。

S212，CCF向API调用者发送注册响应消息#1。

对应的，API调用者接收来自CCF的注册响应消息#1。

其中，该注册响应消息#1包含注册状态、已登记信息以及Service API信息。

示例性的，注册状态用于指示注册的结果为成功或者失败。已登记信息包含APIInvoker ID，以及授权及认证方法。其中，API Invoker ID由CCF为API Invoker分配，授权及认证方法用于指示使用何种授权及认证方法，授权及认证方法包含TLS-PSK、PKI和TLSwith OAuth token。在该实现方式中，假设授权及认证方法为TLS with OAuth token。Service API信息用于指示已登记的API的信息，包含以下一项或者多项：服务API名称、AEF位置、IP地址或域名、端口号和协议等。

S213，API调用者向CCF发送发现服务请求消息#1。

对应的，CCF接收来自API调用者的发现服务请求消息#1。

其中，该发现服务请求消息#1包含API Invoker ID和请求信息。

示例性的，请求信息包含发现某些API的标准，例如偏好的AEF位置、协议等。

S214，CCF向API调用者发送发现服务响应消息#1。

对应的，API调用者接收来自CCF的发现服务响应消息#1。

其中，该发现服务响应消息#1包含service API信息，service API信息响应于步骤S213所请求的API，其信元与步骤S213中的信元相同。

S215，API调用者向CCF发送获得授权请求消息#1。

对应的，CCF接收来自API调用者的获得授权请求消息#1。

其中，该获得授权请求消息#1包含API Invoker ID、服务API名称，以及授权方式，该授权方式指示使用客户端凭证client_credential模式的Oauth方式。

应理解，由于步骤S212中CCF选择的授权及认证方法为TLS with OAuth token，则API Invoker需要向CCF发送获得授权请求消息#1。

S216，CCF向API调用者发送获得授权响应消息#1。

对应的，API调用者接收来自CCF的获得授权响应消息#1。

其中，该获得授权响应消息#1包含token#1，token#1包含声明和签名。声明包含以下内容：超时时间，API Invoker ID，service API ID。签名为CCF对token#1的数字签名。

示例性的，CCF根据本地策略确认API Invoker可访问API name授权后，向APIInvoker发送获得授权响应消息#1。

S217，API调用者向AEF发送API调用请求消息#1。

对应的，AEF接收来自API调用者的API调用请求消息#1。

其中，API调用请求消息#1包含API Invoker ID，service API ID以及token#1。

S218，AEF根据API调用请求消息#1校验token#1。

其中，具体校验token#1的实现方式包括如下验证内容：

(1)AEF校验token#1的签名。AEF通过预配置的CCF的凭证(如证书)，校验token#1的签名。

(2)AEF校验token#1的声明部分：AEF判断token#1声明中的API Invoker ID是否和消息中的API Invoker ID一致；或者，AEF判断token#1声明中的service API ID是否和消息中请求的service API ID一致；或者，AEF根据超时时间判断当前token#1是否已超时。

S219，AEF向API Invoker发送API调用响应消息#1。

对应的，API Invoker接收来自AEF的调用响应消息#1

示例性的，若上述步骤S218中的判断通过，则AEF同意API调用请求，并向APIInvoker发送调用响应消息#1。反之，若判断不通过，则拒绝API调用请求息。

图2的(b)是CAPIF基于TLS-PSK或PKI的基于access control policy的CCF授权API Invoker到AEF调用特定的API的流程，具体包括如下多个步骤。

S221，API调用者(API Invoker)向CCF发送注册请求消息#11。

对应的，CCF接收来自API调用者的注册请求消息#11。

其中，该注册请求消息#11包含注册信息和登记API。

S222，CCF向API调用者发送注册响应消息#11。

对应的，API调用者接收来自CCF的注册响应消息#11。

其中，该注册响应消息#11包含注册状态、已登记信息以及Service API信息。

在该实现方式中，假设授权及认证方法为TLS-PSK或PKI。

S223，API调用者向CCF发送发现服务请求消息#11。

对应的，CCF接收来自API调用者的发现服务请求消息#11。

其中，该发现服务请求消息#11包含API Invoker ID和请求信息。

S224，CCF向API调用者发送发现服务响应消息#11。

对应的，API调用者接收来自CCF的发现服务响应消息#11。

需要说明的是，步骤S221-S224的具体实现方式与上述步骤S211-S214类似，为了简洁，此处不再赘述。

S225，API Invoker与CCF建立传输层安全协议(transport layer security，TLS)连接。

应理解，由于步骤S222中CCF选择的授权及认证方法为TLS-PSK或PKI方法，APIInvoker与CCF需要通过不同的方式建立TLS连接。本申请对建立TLS连接的具体实现方式不作具体限定。

S226，API Invoker向AEF发送API调用请求消息#11。

对应的，AEF接收来自API Invoker的API调用请求消息#11。

其中，API调用请求消息#1包含API Invoker ID以及service API ID。

S227，AEF向CCF发送获得接入控制策略请求消息#11。

对应的，CCF接收来自AEF的获得接入控制策略请求消息#11。

其中，该获得接入控制策略请求消息#11包含AEF ID、API Invoker ID，以及service API ID。

S228，CCF向AEF发送获得接入控制策略响应消息#11。

对应的，AEF接收来自CCF的获得接入控制策略响应消息#11。

其中，该获得接入控制策略响应消息#11包含接入控制策略信息。

示例性的，接入控制策略信息包含API Invoker ID对请求service API ID允许的访问策略，例如最多调用次数、每秒允许调用次数、允许调用时间等。

S229，AEF控制API Invoker对API的调用。

示例性的，AEF根据接收到的接入控制策略控制API Invoker对API的调用。

S220，AEF向API Invoker发送API调用响应消息#11。

对应的，API Invoker接收来自AEF的API调用响应消息#11。

图2的(c)是通用的基于OAuth2.0的授权码(authorization code grant)模式的授权流程，具体包括如下多个步骤。

S231，客户端(Client)向用户代理(User agent)输入信息#a。

对应的，用户代理接收来自客户端的信息#a。

其中，信息#a包括授权服务器(authorization server，AuS)统一资源定位符(Uniform Resource Locator，URL)，重定向URL，范围(scope)以及响应类型(responsetype)。

示例性的，用户在某app 1上勾选了使用app 2登录，并点击登录，Client因此向User agent发送的AuS URL为app 2的AuS的URL，redirect URL为app 1的URL，scope为授权范围，例如授权使用头像和手机号资源，响应类型为code，即授权码模式。

S232，用户代理向AuS发送授权请求消息#a。

对应的，AuS接收来自用户代理的授权请求消息#a。

其中，授权请求消息#a包括redirect URL，scope以及response type。responsetype为code。

需要说明的是，用户代理可以根据AuS URL确定AuS的地址。

S233，AuS与资源拥有者RO之间进行认证。

可选地，AuS通过用户代理与RO之间进行认证。

可选地，若AuS与RO之前已做过认证，且AuS仍保存有通过认证的信息，则AuS可跳过与RO的认证过程。

对应的，若用户代理为浏览器时，AuS向用户代理返回请求认证网页，用户代理向RO展示请求认证网页。

对应的，若用户代理为应用客户端时，AuS向用户代理返回请求认证的提示消息，用户代理向RO展示请求认证的消息。

示例性的，app 2部署的AuS要求用户输入用户名及密码。若用户代理已有相关认证信息，则该步骤可省略。

S234，AuS向用户代理发送用户同意请求消息#a，用户代理向RO发送用户同意请求消息#a。

对应的，RO接收来自用户代理的用户同意请求消息#a，用户代理接收来自AuS的用户同意请求消息#a。

S235，RO向用户代理发送用户同意响应消息#a，用户代理向AuS发送用户同意响应消息#a。

对应的，AuS接收来自用户代理的用户同意响应消息#a，用户代理接收来自RO的用户同意响应消息#a。

示例性的，用户点击同意或不同后，用户代理向AuS返回响应授权内容，AuS因此获得了用户的授权。

S236，AuS向用户代理发送授权响应消息#a，用户代理向客户端发送授权响应消息#a。

对应的，客户端接收来自用于代理的授权响应消息#a，用户代理接收来自的授权响应消息#a。

其中，授权响应消息#a包括redirect URL及code。

示例性的，在获得用户授权后，AuS生成授权码code，并向用户代理发送授权响应消息#a。

S237，客户端通过后端应用向AuS发送接入token请求消息#a。

AuS通过后端应用接收来自客户端的接入token请求消息#a。

其中，该接入token请求消息#a用于请求获取token。该接入token请求消息#a包含code、授权类型＝”授权码(authorization code)”，client ID及redirect URL。

S238，AuS向客户端返回接入token(access token)响应消息#a。

对应的，客户端接收来自AuS的返回接入token响应消息#a。

其中，该接入token响应消息#a包含access token。

S239，客户端通过后端应用向RO Server发送接入请求消息#a。

对应的，RO Server通过后端应用接收来自客户端的接入请求消息#a。

其中，该接入请求消息#a包含access token。

S230，RO Server校验access token。

S240，RO Server向客户端返回接入响应消息#a。

对应的，客户端接收来自RO Server的接入响应消息#a。

其中，接入响应消息#a包括客户端所请求的资源。

示例性的，客户端根据redirect URL及返回的资源向用户展示网页。此时，用户可以看到使用自己的app 2的头像登录的app 1的网页。

图2的(d)是通用的基于OAuth2.0的隐式(implict grant)模式的授权流程。该授权流程与授权码模式类似，主要面向client仅为前端应用的场景。具体包括如下多个步骤。

S241，客户端向用户代理输入信息#aa。

对应的，用户代理接收来自客户端的信息#aa。

其中，信息#aa包括AuS URL，redirect URL，scope以及response type。

示例性的，用户在某app 1上勾选了使用app 2登录，并点击登录，Client因此向User agent发送的AuS URL为app 2的AuS的URL，redirect URL为app 1的URL，scope为授权范围，例如授权使用头像和手机号资源，响应类型为token。

S242，用户代理向AuS发送授权请求消息#aa。

对应的，AuS接收来自用户代理的授权请求消息#aa。

其中，授权请求消息#aa包括redirect URL，scope以及response type。responsetype为token。

S243，AuS与资源拥有者RO之间进行认证。

对应的，AuS向用户代理返回请求授权网页，用户代理向RO展示请求授权网页。

S244，AuS向用户代理发送用户同意请求消息#aa，用户代理向RO发送用户同意请求消息#aa。

对应的，RO接收来自用户代理的用户同意请求消息#aa，用户代理接收来自AuS的用户同意请求消息#aa。

S245，RO向用户代理发送用户同意响应消息#aa，用户代理向AuS发送用户同意响应消息#aa。

对应的，AuS接收来自用户代理的用户同意响应消息#aa，用户代理接收来自RO的用户同意响应消息#aa。

需要说明的是，步骤S242-S245的具体实现方式与上述步骤S232-S235类似，为了简洁，此处不再赘述。

S246，AuS向用户代理发送接入token响应消息#aa，用户代理向客户端发送token响应消息#aa。

对应的，客户端接收来自用户代理的token响应消息#aa，用户代理接收来自AuS的token响应消息#aa。

其中。token响应消息#aa包括access token。

S247，客户端通过后端应用向RO Server发送接入请求消息#aa。

对应的，RO Server通过后端应用接收来自客户端的接入请求消息#aa。

其中，该接入请求消息#a包含access token。

S248，RO Server校验access token。

S249，RO Server向客户端返回接入响应消息#aa。

对应的，客户端接收来自RO Server的接入响应消息#aa。

需要说明的是，步骤S247-S249的具体实现方式与上述步骤S239、S230和S240类似，为了简洁，此处不再赘述。

综上所述，当前API Invoker可被授权访问特定的API，但是不能实现API Invoker被授权访问特定API的特定用户的数据，用户未被引入进来。也就是说，如果未获得用户的授权，AF在请求3GPP网络处理用户数据时可能会暴露用户的隐私信息。

有鉴于此，本申请提供一种通信方法和通信装置，通过API Invoker主动获得更细粒度的用户授权的token(token包含用户标识)，并使用该token接入AEF，从而使可以AEF授权API Invoker访问某个API并处理某个用户的数据。本申请所揭示的方法能够避免用户隐私暴露，减少移动通信网络中网络功能面临的潜在的安全风险。

为了便于理解本申请实施例，作出以下几点说明：

第一，在本申请中，如果没有特殊说明以及逻辑冲突，不同的实施例之间的术语和/或描述具有一致性、且可以相互引用，不同的实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。

第二，在本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。在本申请的文字描述中，字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a、b和c中的至少一项(个)，可以表示：a，或，b，或，c，或，a和b，或，a和c，或，b和c，或，a、b和c。其中a、b和c分别可以是单个，也可以是多个。

第三，在本申请中，“第一”、“第二”以及各种数字编号(例如，#1、#2等)指示为了描述方便进行的区分，并不用来限制本申请实施例的范围。例如，区分不同的消息等，而不是用于描述特定的顺序或先后次序。应理解，这样描述的对象在适当情况下可以互换，以便能够描述本申请的实施例以外的方案。

第四，在本申请中，“当……时”、“在……的情况下”以及“如果”等描述均指在某种客观情况下设备会做出相应的处理，并非是限定时间，且也不要求设备在实现时一定要有判断的动作，也不意味着存在其它限定。

第五，在本申请中，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

第六，在本申请中，“用于指示”可以包括用于直接指示和用于间接指示。当描述某一指示信息用于指示A时，可以包括该指示信息直接指示A或间接指示A，而并不代表该指示信息中一定携带有A。

本申请涉及的指示方式应理解为涵盖可以使得待指示方获知待指示信息的各种方法。待指示信息可以作为整体一起发送，也可以分成多个子信息分开发送，而且这些子信息的发送周期和/或发送时机可以相同，也可以不同，本申请对具体的发送方法不作限定。

本申请中的“指示信息”可以是显式指示，即通过信令直接指示，或者根据信令指示的参数，结合其他规则或结合其他参数或通过推导获得。也可以是隐式指示，即根据规则或关系，或根据其他参数，或推导获得。本申请对此不作具体限定。

第七，在本申请中，“协议”可以是指通信领域的标准协议，例如可以包括5G协议、NR协议以及应用于未来的通信系统中的相关协议，本申请对此不做限定。“预配置”可以包括预先定义。例如，协议定义。其中，“预先定义”可以通过在设备中预先保存相应的代码、表格或其他可用于指示相关信息的方式来实现，本申请对于其具体的实现方式不做限定。

第八，在本申请中，“存储”可以是指保存在一个或者多个存储器中。所述一个或者多个存储器可以是单独的设置，也可以是集成在编码器或者译码器、处理器、或通信装置中。所述一个或者多个存储器，也可以是一部分单独设置，一部分集成在译码器、处理器、或通信装置中。存储器的类型可以是任意形式的存储介质，本申请并不对此限定。

第九，在本申请中“通信”还可以描述为“数据传输”、“信息传输”、“数据处理”等。“传输”包括“发送”和“接收”，本申请对此不作限定。

第十，在本申请中，“操作目标用户的数据”以及“访问目标用户的数据”可以表示相同的意思，即API调用者具有使用目标用户的数据的权限；类似地，“授权类型”和“授权方式”可以替换，用于指示授权的方式，例如授权码模式，或者隐式模式，本申请对具体的名称不作具体限定。

下面将结合附图详细说明本申请提供的技术方案。

图3是本申请实施例提供的通信方法300的流程示意图。如图3所示，该方法包括如下多个步骤。

S310,API调用者(API Invoker)向授权功能网元(例如AuF)发送授权请求消息。

对应的，授权功能网元接收来自API调用者的授权请求消息。

其中，授权请求消息用于请求获取目标用户的授权，授权请求消息包括目标用户的标识。

可选地，授权请求消息还包括：目标API的标识(Service API ID)；和/或API调用者的标识(API Invoker ID)。

应理解，API Invoker ID用于标识API Invoker。

示例性的，API Invoker可以是UE，也可以是AF，本申请对此不作具体限定。

需要说明的是，目标用户可以理解为资源拥有者RO，二者的名称可以替换使用，本申请对此不作具体限定。

示例性的，目标用户的标识用于标识用户，例如包括但不限于用户的用户永久标识(subscription permanent identifier，SUPI)、用户隐藏标识符(subscriptionconcealed identifier，SUCI)、通用公共用户标识(generic public subscriptionidentifier，GPSI)、永久设备标识符(permanent equipment identifier，PEI)或(mobilesubscriber international ISDN/PSTN number，MSISDN)，ISDN即是综合业务数字网(integrated service digital Network)，PSTN即是公共交换电话网(public switchedtelephone ntwork)等。MSISDN可以理解为用户对外可以公开的身份标识，比如用户的电话号码等。

应理解，目标API用于指示需要进行授权的API。Service API ID用于指示APIInvoker期望调用的API的标识，API指示了用于指示对于用户个人数据的具体操作方式，例如收集、读取、分析、共享等。

示例性的，Service API ID可以包括但不限于：定位Nnef_Location、获取Nnef_UEIdentifier_Get、订阅分析Nnwdaf_AnalyticsSubscription_Subscribe等消息。

例如，某一服务器通过API调用请求消息#A向AEF调用请求UE标识的API，例如Nnef_UEIdentifier_Get，其输入user information设置为某个UE的IP地址或域名，AF ID设置为讨论服务器的ID，该动作代表该服务器请求获得IP地址或域名对应的用户(UE)的标识信息。则该API调用请求消息#A指示了该服务器对用户的个人数据(即身份信息)采取读取的操作。

可选地，授权请求消息还包括响应类型，和/或范围指示信息。其中，响应类型用于指示当前的授权方式，例如code指示授权码模式，token指示隐式模式。范围指示信息用于指示授权的范围，例如可以包含Service API ID以及目标用户的标识。

示例性的，该授权请求消息可以是OAuth2.0的Authorization Request消息。

在一种可能的实现方式中，API调用者根据授权指示，向授权功能网元发送授权请求消息。

其中，授权指示用于指示请求操作目标用户的数据需要目标用户的授权。

作为示例而非限定，授权指示可以来自AEF。即在API调用者向授权功能网元发送授权请求消息之前，该方法还包括S301-S303：

S301，API调用者向AEF发送第二API调用请求消息。

对应的，AEF接收来自API调用者的第二API调用请求消息。

其中，第二API调用请求消息用于请求调用目标API以操作目标用户的数据，第二API调用请求消息包括目标用户的标识；

可选地，第二API调用请求消息还包括目标API的标识，和/或API调用者的标识。

可选地，第二API调用请求消息可以本身就携带目标API的信息。

示例性的，该第二API调用请求消息可以是Service API Invocation Request消息。

S302，AEF确定请求操作目标用户的数据需要目标用户的授权。

在一种示例中，AEF确定本地没有保存有目标用户的用户同意信息，用户同意信息指示目标用户同意操作目标用户的数据。

示例性的，AEF可以根据本地配置的API列表，确定目标API的调用需要目标用户的授权。其中，API列表里面的API都是需要用户同意的API。可选地，API列表可以是AEF预配置的，也可以是其他网元为AEF配置的，本申请对此不作具体限定。

可选地，API列表还可以对应授权功能网元的地址，即AEF根据目标API获得授权功能网元的地址，便于后续AEF可以向AuF请求获取目标用户的授权。

可选地，AEF可以在确定本地未获取目标用户的用户同意信息之后，向UDM发送获取请求消息，减少不必要的信令开销。

应理解，用户同意信息包括数据处理目的以及用户同意结果。其中，数据处理目的用于指示对用户个人数据操作的目的，例如包含模型训练，数据分析，数据共享等。用户同意结果用于指示用户是否同意该数据的使用目的，例如granted代表同意，not granted代表不同意。用户标识2是由用户标识1转化而来的，同样表征该目标用户UE，只是针对不同的网元交互进行的转化。

可选地，若AEF已经具备UE的用户同意信息，且用户同意信息指示同意该APIInvoker调用该Service API以操作用户的个人数据，则AEF可以直接执行步骤S309。F的地址，并向AuF请求获取用户的授权。例如，通过在授权指示#1中携带比特“1”指示APIInvoker对用户个人数据进行操作需要用户的授权；

(2)AuF地址(如IP地址或域名)。其中，AuF地址可以是提前预配置在AEF上的，例如AEF本地预配置的API列表中每个API对应一个AuF地址，则AEF可以根据Service API ID确定API Invoker需要寻找的AuF的地址；

(3)授权方式，用于指示授权的具体方法，例如OAuth 2.0的授权码模式、隐式模式等。

(4)原因值(cause value)，用于指示请求操作目标用户的数据需要目标用户的授权。示例性的，原因值可以是cause#1，用于指示API调用者需要获取目标用户的授权，才可以操作目标用户的个人数据。

在一种示例中，AEF向API调用者发送第二API调用响应消息，第二API调用响应消息包括授权指示#1。

可选地，第二API调用响应消息还包括目标API的标识，和/或目标用户的标识。其中，Service API ID用于指示需要进行授权的API，目标用户的标识用于指示需要进行授权的目标用户。

可选地，第二API调用响应消息为重定向请求消息。示例性的，该重定向请求消息#A可以是状态码为302的HTTP消息。

作为示例而非限定，授权指示可以来自CCF。即在API调用者向授权功能网元发送授权请求消息之前，该方法还包括S304-S305：

S304，API调用者向CCF发送第二请求消息。

对应的，CCF接收来自API调用者的第二请求消息。

其中，第二请求消息用于请求用于将API调用者注册到CCF或者用于API调用者发现API。

示例性的，第二请求消息可以是注册请求消息或发现服务请求消息。例如，该第二请求消息可以是Onboard Service Request消息，或者Discovery Service Request消息。

S305，CCF向API调用者发送授权指示#2。

对应的，API调用者接收来自CCF的授权指示#2。

其中，授权指示#2包括授权功能网元的地址。

在一种示例中，CCF向API调用者发送第二响应消息(即，第二API调用响应消息的一例)，第二响应消息包括授权指示#2。

可选地，第二响应消息还包括目标API的标识，和/或目标用户的标识。

可选地，第二响应消息为注册响应消息或发现服务响应消息。例如，该第二响应消息可以是Onboard Service Response消息，或者Discovery Service Response消息。

可选地，第二API调用响应消息为重定向请求消息。

示例性的，该重定向请求消息可以是状态码为302的HTTP消息。例如，该重定向请求消息要求API调用者执行临时重定向(moved temporarily)，则API调用者应当继续向AuF地址发送请求。

示例性的，该授权指示#2可以包括以下一项或者多项：

(1)明示的指示，即该授权指示#2用于指示API Invoker确定AuF的地址，并向AuF请求获取用户的授权。例如，通过在授权指示#2中携带比特“1”指示API Invoker对用户个人数据进行操作需要用户的授权；

(4)原因值，用于指示请求操作目标用户的数据需要目标用户的授权。

在另一种示例中，授权指示#2包括原因值，原因值用于指示请求操作目标用户的数据需要目标用户的授权。

可选地，该第二响应消息还包括Service API ID，和/或目标用户的标识。其中，Service API ID用于指示需要进行授权的API，目标用户的标识用于指示需要进行授权的目标用户。

可选地，第二响应消息为重定向请求消息。示例性的，该重定向请求消息可以是状态码为302的HTTP消息。

因此，基于上述步骤S303中的授权指示#1，或者步骤S305中的授权指示#2，API调用者可以确定AuF的地址，并向AuF发送授权请求消息。

示例性的，若授权指示包含(1)明示的指示，此时API Invoker可以根据本地预配置的AuF地址列表，确定Service API ID对应的AuF地址，并向AuF请求获取用户的授权；又例如，若授权指示包含(2)AuF的地址，此时API Invoker可以直接根据该AuF地址，向AuF发送授权请求消息#A。

可选地，API Invoker可以根据授权指示#1或授权指示#2中的(3)授权方式确定响应类型。该响应类型可以携带在授权请求消息中。例如，若授权方式为OAuth 2.0的授权码模式，则响应类型应为code；若授权方式为OAuth2.0的隐式模式，则响应类型应为token。

可选地，API调用者根据授权指示#1或者授权指示#2中的(4)原因值，确定授权功能网元的地址；进一步地，API调用者根据授权功能网元的地址，向授权功能网元发送授权请求消息。

可选地，API调用者根据授权指示#1或者授权指示#2中的原因值，从配置的地址列表中获取授权功能网元的地址。示例性的，API调用者通过原因值，例如cause#1确定请求操作目标用户的个人数据需要获取目标用户的授权，进而根据地址列表找到对应的AuF的地址，或者根据AEF发送的AuF的地址，向AuF进行授权。

可选地，在API调用者根据授权指示，向授权功能网元发送授权请求消息之前，API调用者根据授权类型确定响应类型。

在该实现方式中，API调用者根据授权指示确定向AuF请求获取用户的授权，可以实现面向特定API的用户授权控制，提升了用户授权的灵活性。

可选地，CCF可以作为中间节点进行转发，向AuF获得用户授权。该实现方式中API调用者无需根据授权指示向AuF发送授权请求消息，能够减少API的信令开销。

S311，API调用者向CCF发送授权请求消息。

对应的，CCF接收来自API调用者的授权请求消息。

基于上述步骤S303中的授权指示#1，或者步骤S305中的授权指示#2，API调用者可以确定响应类型，并向CCF发送授权请求消息。

可选地，若授权指示包含(1)明示的指示，此时API Invoker可以根据本地预配置的响应类型，确定Service API ID对应的响应类型，并向CCF请求获取用户的授权。例如，若收到明示的指示，则API invoker设置响应类型为code或token。

可选地，API调用者根据授权指示#1或者授权指示#2中的(4)原因值，确定授权响应类型。例如，若收到原因值用于指示请求操作目标用户的数据需要目标用户的授权，则API invoker设置响应类型为code或token。

S312，CCF向授权功能网元发送授权请求消息。

对应的，授权功能网元接收来自CCF的授权请求消息。

其中，授权请求消息包括API调用者的标识、目标API的标识以及目标用户的标识。

在一种示例中，在CCF向授权功能网元发送授权请求消息之前，CCF根据可以根据地址列表，确定授权功能网元的地址；并根据授权功能网元的地址，向授权功能网元发送授权请求消息。

示例性的，该地址列表用于指示目标API的标识与授权功能网元的地址的映射关系。

可选地，该地址列表可以是CCF本地配置的，可以是CCF预配置的，也可以是其他网络功能网元为CCF配置的本身其对此不作具体限定。

S320，AuF在确定目标用户同意API调用者操作目标用户的数据的情况下，授权功能网元生成具有完整性保护的第一令牌。

其中，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识。

需要说明的是，AuF确定目标用户同意API调用者操作目标用户的数据的具体实现方式可参见上述图2的(c)中步骤S233-S235；或者，也可以参见上述图2的(d)中步骤S243-S245。为了简洁，此处不再赘述。

可选地，第一令牌还包括以下一项或者多项：超时时间；API调用者的标识；目标API的标识；签名者。

其中，签名者用于指示签名的实体，以使得AuF可根据不同签名者选择不同的证书校验第一令牌。例如，签名者可以用于指示对第一令牌进行签名的网元的标识，或者用于指示生成第一令牌的网元的标识，又或者用于指示授权功能网元的标识，本申请对此不作具体限定。例如，签名者可以是AuF ID或CAPIF ID，也可以是AuF类型或CAPIF类型，也可以是以下任一项：授权码、隐式、客户端凭证、用户密码凭证授权，还可以是用户授权或网络功能授权。

可选地，第一令牌还包括以下一项或者多项：第一令牌的生成时间、第一令牌的有效时长、第一令牌的有效的截止时间等。

可选地，第一令牌还包括其他参数，例如允许使用的资源、网络切片信息等，本申请对此不作具体限定。

可选地，授权功能网元首先根据上述参数生成声明；然后根据声明生成签名；最后根据声明和签名生成具有完整性保护的第一令牌。

需要说明的是，基于目标用户的标识信息生成第一令牌，可以实现更细粒度的授权，即使得API调用者可以被授权具有访问目标API以操作目标用户的个人数据的权限。

S330，授权功能网元向API调用者发送授权响应消息。

对应的，API调用者接收来自授权功能网元的授权响应消息。

其中，授权响应消息包括具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；

示例性的，若用户同意信息指示用户同意授权API Invoker调用Service API以操作用户数据，则授权响应消息包括具有完整性保护的第一令牌。反之，若用户同意信息指示用户拒绝授权API Invoker调用Service API以操作用户数据，则授权响应消息包括失败指示信息，失败指示信息用于指示用户未授权API Invoker调用Service API以操作用户数据。

示例性的，该授权响应消息可以是OAuth2.0的Authorization Response消息。

在一种可能的实现方式中，API调用者接收来自授权功能网元的授权响应消息，还可以通过CCF作为中间节点进行转发，对应下面步骤S331和S332。

S331，授权功能网元向CCF发送授权响应消息。

对应的，CCF接收来自授权功能网元的授权响应消息。

S332，CCF向API调用者发送授权响应消息。

对应的，API调用者接收来自授权功能网元的授权响应消息。

其中，授权响应消息包括具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识。

接下来，API调用者基于上述步骤S330或S305获得的第一令牌，可以向AEF发送第一API调用请求消息，用于请求调用目标API以操作目标用户的个人数据。

S340，API调用者向AEF发送第一API调用请求消息。

对应的，AEF接收来自API调用者的第一API调用请求消息。

其中，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括目标用户的标识和第一令牌。

可选地，第一API调用请求消息还包括目标API的标识(Service API ID)，和/或API调用者的标识(API Invoker ID)。

可选地，第一API调用请求消息可以本身就携带目标API的信息。

示例性的，该第一API调用请求消息可以是Service API Invocation Request消息。

在一种示例中，第一API调用请求消息还包括第二令牌，第二令牌用于指示API调用者具有调用目标API的权限，第二令牌包括API调用者的标识和目标API的标识。

可选地，在API调用者向AEF发送第一API调用请求消息之前，API调用者可以向CCF请求获取第二令牌，即该方法还包括下面步骤S306-S307：

S306，API调用者向CCF发送第一请求消息。

对应的，CCF接收来自API调用者的第一请求消息。

其中，第一请求消息用于请求获取调用目标API的权限，第一请求消息包括API调用者的标识和目标API的标识。

示例性的，第一请求消息可以是注册API Invoker请求消息或发现服务请求消息。例如，该第一请求消息可以是Onboard API Invoker Request消息，或者DiscoveryService Request消息。

S307，CCF向API调用者发送第二令牌。

对应的，API调用者接收来自CCF的第二令牌。

其中，第二令牌包括目标API的标识。

可选地，第二令牌还包括以下至少一项：API调用者的标识；超时时间，签名。

可选地，第二令牌还包括以下一项或者多项：第二令牌的生成时间、第二令牌的有效时长、第二令牌的有效的截止时间等。

基于接收到的第二令牌，AEF可以判断API调用者具有调用目标API的权限，即该方法还包括步骤S308。

S308，可选地，AEF根据第二令牌，确定API调用者具有调用目标API的权限。

可选地，AEF可以分别校验第二令牌的签名、API调用者的标识、目标API的标识、超时时间等。

示例性的，AEF可以通过预配置的CCF的凭证(如证书)，校验第二令牌的签名。

进一步地，基于签名验证通过的情况下，AEF继续校验第二令牌中的信息部分。

示例性的，AEF通过判断第二令牌中携带的目标API的标识，与第一API调用请求消息中携带的目标API的标识相同，确定API调用者具有调用目标API的权限。

可选地，AEF判断第二令牌中携带的API Invoker ID是否和API调用请求消息中的API Invoker ID一致。

可选地，AEF根据第二令牌中携带的超时时间判断当前token是否已超时。

可选地，AEF根据第二令牌的有效时长为5h，第二令牌的生成时间为2:30，AEF接收到API调用请求消息的时间为10:30，则AEF确定该第二令牌已经失效，进而拒绝APIInvoker访问目标API的请求。

可选地，AEF根据第二令牌的有效截止时间为12:30，AEF接收到API调用请求消息的时间为12:00，在第二令牌中携带的签名和具体信息内容验证通过的情况下，可以接受API Invoker的目标API调用请求。

可选地，AEF通常可以在判断API调用者是否具有调用目标API的权限之后，再进一步的判断API调用者是否具有操作目标用户的数据的权限。也就是说，本申请对步骤S308和步骤S350的执行顺序不作限定。

S350，AEF根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限。

应理解，第一令牌包括声明和签名两部分，因此AEF需要根据声明和签名两部分，确定API调用者是否具有操作目标用户的数据的权限，具体实现方式包括下面两个步骤。

步骤一：AEF验证第一令牌的签名。

在一种示例中，AEF根据授权功能网元的凭证，对第一令牌的完整性保护进行验证，授权功能网元为生成第一令牌的网元。

可选地，授权功能网元的凭证可以是AEF预配置的。

可选地，在AEF根据授权功能网元的凭证，对第一令牌进行完整性验证之前，AEF可以根据签名者获取授权功能网元的凭证。

可选地，第一令牌还包括签名者。例如，AEF可以根据签名者，获取授权功能网元的凭证。

示例性的，若签名者是AuF ID或CAPIF ID，AEF可以预配置签名者对应的凭证，即AEF可获得签名者是AuF ID或CAPIF ID对应的凭证，进而校验第一令牌的签名；又例如，若签名者是AuF或CAPIF，AEF可以预配置不同签名者类型对应的凭证，即AEF可获得AuF或CAPIF对应的凭证，进而校验第一令牌的签名；若签名者是以下任一项：授权码、隐式、客户端凭证、用户密码凭证，AEF可以预配置不同签名者类型对应的凭证，即授权码、隐式，或用户密码凭证可以使用AuF的凭证，客户端凭证可以使用CAPIF的凭证；若签名者是用户授权或网络功能授权，AEF预配置不同签名者类型对应的凭证，即用户授权可以使用AuF的凭证，网络功能授权可以使用CAPIF的凭证。

基于此，当AEF使用预配置的凭证成功地验证该第一令牌的签名时，说明该第一令牌没有被篡改过。否则，验证失败，AEF可以拒绝API Invoker对目标API的调用请求。

应理解，当第一令牌的签名验证通过后，AEF将继续进行步骤二声明部分的验证，即对于第一令牌的内容信息进行验证。

步骤二：AEF验证第一令牌的声明中的信息内容。

其中，声明包括目标用户的标识。

在一种示例中，AEF判断第一令牌中携带的目标用户的标识，是否与第一API调用请求消息中携带的目标用户的标识相同。

可选地，声明还包括以下至少一项：超时时间；API调用者的标识；目标API的标识等。

可选地，AEF判断第一令牌中携带的API调用者的标识，是否与第一API调用请求消息中携带的API调用者的标识相同。

可选地，AEF判断第一令牌中携带的目标API的标识，是否与第一API调用请求消息中携带的目标API的标识相同。

可选地，声明中还可以包括以下一项或者多项：第一令牌的生成时间、第一令牌的有效时长、第一令牌的有效的截止时间等。

示例性的，第一令牌的有效时长为12h，第一令牌的生成时间为2:30，AEF接收到API调用请求消息#B的时间为12:30，则AEF在第一令牌的签名和具体信息内容验证通过的情况下，可以接受API Invoker的API调用请求。再例如，第一令牌的有效截止时间为12:30，AEF接收到API调用请求消息#B的时间为12:00，则AEF在第一令牌的签名和具体信息内容验证通过的情况下，可以接受API Invoker的API调用请求等。

需要说明的是，只有上述两个步骤都验证通过后，AEF可以确定API调用者具有操作目标用户的数据的权限。否则，AEF可以确定API调用者不具有操作目标用户的数据的权限。

S360，AEF根据确定结果，确定是否向API调用者提供访问目标用户的数据的权限。

需要说明的是，基于第一令牌的校验结果(例如，第一令牌验证成功的情况下)，进一步确定是否向API调用者提供访问目标用户的数据的权限，可以通过两种方法，例如校验第二令牌，确定API调用者是否具有访问目标API的权限；或者；AEF向CCF校验访问控制列表，请求获取API调用者调用目标API的访问策略。

可选地，在API调用者具有操作目标用户的数据的权限，且访问策略指示允许API调用者调用目标API的情况下，AEF向API调用者提供访问目标用户的数据的权限。

可选地，用于指示允许API调用者调用目标API的访问策略可以是从AEF获得的。

示例性的，AEF向CCF发送第三请求消息，并接收来自CCF的访问策略。

其中，该第三请求消息用于请求获取API调用者调用目标API的访问策略，第三请求消息包括API调用者的标识和目标API的标识，访问策略用于指示是否允许API调用者调用目标API。

基于上述步骤S360的判断，AEF可以向API调用者提供访问目标用户的数据的权限。即，该方法还包括步骤S309。

S309，AEF向API调用者发送第一API调用响应消息。

对应的，API调用者接收来自AEF的第一API调用响应消息。

其中，该第一API调用响应消息用于返回API Invoker ID调用目标API以操作用户数据的结果。例如，授权API Invoker ID具有调用目标API以操作用户数据的权限。

示例性的，若某一服务器通过API调用请求消息#B向AEF调用请求UE标识的API，例如Nnef_UEIdentifier_Get，其输入user information设置为某个UE的IP地址或域名，AFID设置为讨论服务器的ID，则AEF将返回API调用响应消息#B，该消息中包含该UE的外部标识，例如GPSI。

可选地，在API调用者具有操作目标用户的数据的权限的情况下，AEF可以向UDM发送签约信息更新消息，用于更新目标用户的用户同意信息，用户同意信息用于指示目标用户同意操作目标用户的数据。

其中，该签约信息更新请求消息用于更新UE的用户同意信息，该签约信息更新消息可以包括以下一项或多项：用户标识，数据处理目的，API Invoker ID，超时时间，用户同意结果。

应理解，数据处理目的是根据Server API ID转化而来，用户同意结果可以根据步骤S420的用户同意信息#A获得。

该实现方式中，通过AEF更新UDM上的UE签约信息，可以减少AuF请求RO授权的次数。

本申请提供的方案，API Invoker通过从授权功能网元获得更细粒度的用户授权的第一令牌，并使用该第一令牌接入AEF，从而使可以AEF授权API Invoker访问某个API并处理某个用户的数据。该方法在对用户数据进行处理时引入用户是否授权的考量，能够避免用户的隐私信息被暴露，减少移动通信网络中网络功能面临的潜在的安全风险。

考虑到当前技术方案仅限于NF之间进行授权，粒度仅为NF1授权NF2访问某个API。该实现方式引入AuF以及更细粒度的token，从而在授权过程中引入了用户，粒度可以达到NF1授权NF2访问某个API并调用某个用户的数据，接下来结合图4对获得用户授权的方法进行具体说明。

图4是本申请实施例提供的通信方法400的流程示例图。如图4所示，该方法包括如下多个步骤。

S401，可选地，API调用者(API Invoker)向AEF发送API调用请求消息#A(即，第二API调用请求消息的一例)。

对应的，AEF接收来自API调用者的API调用请求消息#A。

示例性的，该API调用请求消息#A用于请求调用Service API(即，目标API的一例)以操作用户的个人数据，该API调用请求消息#A包括API调用者的标识(API Invoker ID)。

其中，API Invoker ID用于标识API Invoker。Service API ID用于指示APIInvoker期望调用的API的标识，API指示了对于用户个人数据的具体操作方式，例如收集、读取、分析、共享等。

需要说明的是，这里的用户可以理解为资源拥有者(resource owner)，二者的名称可以替换使用，本申请对此不作具体限定。

示例性的，API Invoker可以是UE，也可以是AF。在3GPP网络中，AEF可以是NEF，AEF是Service API的提供者，也是API Invoker的服务通信入口，本申请对此不作限制。

可选地，该API调用请求消息#A还包括用户标识1(即，目标用户的标识的一例)，和/或目标API的标识(Service API ID)。

其中，用户标识1可以包括但不限于SUPI、SUCI、GPSI、PEI或MSISDN。

可选地，该API调用请求消息#A本身携带Service API ID。例如，该API调用请求消息#A可以包括但不限于：定位Nnef_Location、获取Nnef_UEIdentifier_Get、订阅分析Nnwdaf_AnalyticsSubscription_Subscribe等消息。

应理解，本申请中对于用户标识1的具体形式不做限定，能够用于标识该用户即可。本申请中对于API调用请求消息(或信息)的名称不做任何的限定，能够实现相应的功能即可。

S402，可选地，AEF判断当前API调用是否需要用户同意，生成重定向请求消息#A(即，重定向请求消息的一例)。

其中，重定向请求消息#A用于指示API Invoker向AuF请求获取用户的授权。

示例性的，AEF可以根据本地配置信息判断当前的API是否需要用户同意。例如，本地配置信息可以是一个API列表，该API列表中的所有API都是需要用户同意的API。

可选地，该API列表还可以与AuF地址对应，即每个API对应一个AuF地址，则AEF可以根据该API列表确定Service API对应的AuF地址。

在一种示例中，在确定API Invoker调用当前的Service API需要用户同意，且AEF不具备用户标识1对应的UE上下文，或者用户标识1对应的UE上下文中未保存有UE的用户同意信息的情况下，AEF可以生成重定向请求消息#A。

在另一种示例中，在确定API Invoker调用当前的Service API需要用户同意，且AEF从UDM未成功获取该UE的用户同意信息的情况下，AEF可以生成重定向请求消息#A。例如，AEF向UDM发送签约信息获取请求消息，用于请求获取该UE的签约信息。该签约信息获取请求消息包含用户标识2。对应的，UDM向AEF发送的签约信息获取响应消息中不包含UE的用户同意信息。

可选地，该签约信息获取请求消息可以为Nudm_SDM_Get Request消息，该签约信息获取响应消息可以为Nudm_SDM_Get Response消息。

基于此，AEF需要通知API Invoker，寻找AuF进行用户的授权。

可选地，若AEF已经具备UE的用户同意信息，且用户同意信息指示同意该APIInvoker调用该Service API以操作用户的个人数据，则AEF可以直接执行步骤S470。

S403，可选地，AEF向API调用者发送重定向请求消息#A。

对应的，API调用者接收来自AEF的重定向请求消息#A。

其中，该重定向消息#A包括授权指示。

示例性的，该授权指示可以包括以下一项或者多项：

(1)明示的指示，即该授权指示用于指示API Invoker确定AuF的地址，并向AuF请求获取用户的授权。例如，通过在授权指示中携带比特“1”指示API Invoker对用户个人数据进行操作需要用户的授权；

可选地，该重定向消息#A还包括Service API ID，和/或用户标识1。其中，ServiceAPI ID用于指示需要进行授权的API。

示例性的，该重定向请求消息#A可以是状态码为302的HTTP消息。

可选地，步骤S403可替换为：AEF向API调用者发送授权指示，该授权指示包括原因值，原因值用于指示请求操作目标用户的数据需要目标用户的授权。

可选地，API调用者根据原因值，确定授权功能网元的地址；API调用者根据授权功能网元的地址，向授权功能网元发送授权请求消息。

可选地，API调用者根据原因值，从预配置的地址列表中获取授权功能网元的地址。

S410，API调用者向AuF发送授权请求消息#A(即，授权请求消息的一例)。

对应的，AuF接收来自API调用者的授权请求消息#A。

其中，该授权请求消息#A用于请求获取用户的授权，该授权请求消息#A包括用户标识1(即，目标用户的标识的一例)。

可选地，该授权请求消息#A还包括Service API ID，和/或API Invoker ID。

可选地，Service API ID，和/或用户标识1是从重定向消息#A中获得的。

可选地，该授权请求消息#A还包括响应类型，和/或范围指示信息。其中，响应类型用于指示当前的授权方式，例如code指示授权码模式，token指示隐式模式。范围指示信息用于指示授权的范围，例如可以包含Service API ID以及用户标识1。

在一种可能的实现方式中，API Invoker根据步骤S403的重定向请求消息#A向AuF发送授权请求消息#A。

示例性的，API Invoker根据授权指示确定AuF的地址进行授权。例如，若授权指示包含(1)明示的指示，此时API Invoker可以根据本地预配置的AuF地址列表，确定ServiceAPI ID对应的AuF地址，并向AuF请求获取用户的授权；又例如，若授权指示包含(2)AuF的地址，此时API Invoker可以直接根据该AuF地址，向AuF发送授权请求消息#A。

可选地，API Invoker可以根据授权指示中的(3)授权方式确定响应类型。该响应类型可以携带在授权请求消息#A中。例如，若授权方式为OAuth 2.0的授权码模式，则响应类型应为code，若授权方式为OAuth2.0的隐式模式，则响应类型应为token。

示例性的，该授权请求消息#A可以是OAuth2.0的Authorization Request消息。

S420，AuF与RO客户端进行交互，以获取用户同意信息#A。

其中，若当前的授权方式为OAuth2.0的授权码模式，该步骤的具体实现方式可参见上述图2的(c)中步骤S233-S235；或者，若当前的授权方式为OAuth2.0的隐式模式，也可以参见上述图2的(d)中步骤S243-S245。为了简洁，此处不再赘述。

S430，AuF确定授权响应消息#A(即，授权响应消息的一例)。

示例性的，基于步骤S420，若用户同意信息#A指示用户同意授权API Invoker调用Service API以操作用户数据，则授权响应消息#A包括具有完整性保护的token，该token包括用户标识1。反之，若用户同意信息#A指示用户拒绝授权API Invoker调用Service API以操作用户数据，则授权响应消息#A包括失败指示信息，该失败指示信息用于指示用户未授权API Invoker调用Service API以操作用户数据。

S440，AuF向API调用者发送授权响应消息#A。

对应的，API调用者接收来自AuF的授权响应消息#A。

S404，可选地，API调用者向AuF发送接入token请求消息#A。

对应的，AuF接收来自API调用者的接入token请求消息#A。

S405，可选地，AuF向API调用者发送接入token响应消息#A。

对应的，API调用者接收来自AuF的接入token响应消息#A。

其中，接入token响应消息#A包括具有完整性保护的token，token包括用户标识1。

需要说明的是，上述步骤S404和S405的具体实现方式可参见上述图2的(c)中步骤S237-S238。为了简洁，此处不再赘述。

应理解，针对步骤S430和S405，具有完整性保护的token的签名可以是AuF对token的数字签名。示例性的，token还可以包括声明(claims)，声明中包括以下一项或者多项：超时时间，API Invoker ID，service API ID，签名者。其中，签名者用于指示签名的实体，以使得AuF可根据不同签名者选择不同的证书校验token。例如，签名者可以是AuF ID或CAPIFID，也可以是AuF类型或CAPIF类型，也可以是以下任一项：授权码、隐式、客户端凭证、用户密码凭证授权，还可以是用户授权或网络功能授权。

可选地，声明中还可以包括以下一项或者多项：token的生成时间、token的有效时长、token的有效的截止时间等。

可选地，声明中还可以包括其他参数，例如允许使用的资源、网络切片信息等，本申请对此不作具体限定。

可选地，针对上述步骤S420-S405，具体实现方式可以参考上述图2的(c)所示的基于OAuth2.0的授权码(authorization code grant)模式的授权方式进行授权。针对上述步骤S420-S440，具体实现方式可以参考上述图2的(d)所示的基于OAuth2.0的隐式(implictgrant)模式的授权方式进行授权。为了简洁，此处不再过多赘述。

S450，API调用者向AEF发送API调用请求消息#B(即，第一API调用请求消息的一例)。

对应的，AEF接收来自API调用者的API调用请求消息#B。

其中，API调用请求消息#B包括用户标识1(即，目标用户的标识的一例)，以及具有完整性保护的token(即，第一令牌的一例)。其中，token包括用户标识1。

可选地，API调用请求消息#B包括API Invoker ID，和/或Service API ID。

可选地，该token包括以下一项或者多项：超时时间，API Invoker ID，ServiceAPI ID，签名者。

可选地，签名者可以不放在token的声明中，而携带在API调用请求消息#B。

S460，AEF验证token。

其中，AEF验证token的具体实现方式包括如下两个步骤：

步骤一，AEF校验token的签名，即对token的完整性保护进行验证。

在一种可能的实现方式中，AEF根据预配置的AuF的凭证(如证书)，校验token的签名。

示例性的，AEF根据签名者(可以携带在token的声明中，也可以携带在API调用请求消息#B)确定使用何种凭证校验Token的签名。例如，若签名者是AuF ID或CAPIF ID，AEF可以预配置签名者对应的凭证，即AEF可获得签名者是AuF ID或CAPIF ID对应的凭证，进而校验token的签名；又例如，若签名者是AuF或CAPIF，AEF可以预配置不同签名者类型对应的凭证，即AEF可获得AuF或CAPIF对应的凭证，进而校验token的签名；若签名者是以下任一项：授权码、隐式、客户端凭证、用户密码凭证，AEF可以预配置不同签名者类型对应的凭证，即授权码、隐式，或用户密码凭证可以使用AuF的凭证，客户端凭证可以使用CAPIF的凭证；若签名者是用户授权或网络功能授权，AEF预配置不同签名者类型对应的凭证，即用户授权可以使用AuF的凭证，网络功能授权可以使用CAPIF的凭证。

基于此，当AEF使用预配置的凭证成功地验证该token的签名时，说明该token未被篡改过。否则，验证失败，AEF可以拒绝API Invoker对目标API的调用请求。

应理解，当token的签名验证通过后，AEF将继续进行步骤二声明部分的验证，即对于第一令牌的内容信息进行验证。

步骤二：AEF校验token的声明。

示例性的，AEF可以判断API调用请求消息#B中的用户标识1是否与token中的用户标识1一致。

可选地，AEF判断API调用请求消息#B中的API Invoker ID是否与token中的APIInvoker ID一致；或者，AEF判断API调用请求消息#B中的Service API ID是否与token中的Service API ID一致；或者，AEF根据token中的超时时间与当前的时间对比，判断token是否仍然有效，等等。

可选地，该token通常在有效期内可以被API Invoekr重复使用。

可选地，声明中还可以包括以下一项或者多项：token的生成时间、token的有效时长、token的有效的截止时间等。例如，token的有效时长为12h，token的生成时间为2:30，AEF接收到API调用请求消息#B的时间为12:30，则AEF在token的签名和具体信息内容验证通过的情况下，可以接受API Invoker的API调用请求。再例如，token的有效截止时间为12:30，AEF接收到API调用请求消息#B的时间为12:00，则AEF在token的签名和具体信息内容验证通过的情况下，可以接受API Invoker的API调用请求等。

进一步地，当上述步骤一和步骤二验证通过后，AEF可以接受API Invoker的API调用请求，即AEF执行下面步骤S470和S406。若上述判断不通过，则AEF可以拒绝API Invoker的API调用请求。

S470，AEF向API调用者发送API调用响应消息#B。

对应的，API调用者接收来自AEF的API调用响应消息#B。

其中，该API调用响应消息#B用于返回API Invoker ID调用目标API以操作用户数据的结果。例如，授权API Invoker ID具有调用目标API以操作用户数据的权限。

S406，可选地，AEF向UDM发送签约信息更新请求消息#A。

对应的，UDM接收来自AEF的签约信息更新请求消息#A。

其中，该签约信息更新请求消息#A用于更新UE的用户同意信息，该签约信息更新消息#A可以包括以下一项或多项：用户标识2，数据处理目的，API Invoker ID，超时时间，用户同意结果。

应理解，用户标识2根据用户标识1转化而来，可以为SUPI，数据处理目的是根据Server API ID转化而来，用户同意结果可以根据步骤S420的用户同意信息#A获得。

本申请所揭示的方法，通过引入AuF生成更细粒度的token(包括用户标识1)，使得在授权过程中考虑用户同意信息，粒度可以达到NF1授权NF2访问某个API并调用某个用户的数据。相比于现有技术中只限于NF之间进行授权，粒度仅为NF1授权NF2访问某个API，该实现方式在处理用户数据时需要用户的授权，保护用户的隐私信息，能够避免用户隐私暴露，减少移动通信网络中网络功能面临的潜在的安全风险。

图5是本申请实施例提供的通信方法500的流程示例图。与上述方法400不同之处在于，该实现方式通过CCF向API Invoker提供需要进行用户授权的信息，并且将调用API的token与操作用户个人数据的token解耦。如图5所示，该方法包括如下多个步骤。

S501，API调用者向CCF发送注册请求消息#AA，或者发现请求消息#AA(即，第二请求消息的一例)。

对应的，CCF接收来自API调用者的注册请求消息#AA，或者发现请求消息#AA。

其中，该注册请求消息#AA，或者发现请求消息#AA包括用户标识1(即，目标用户的一例)和Server API ID(即，目标API的标识的一例)。该注册请求消息#AA，或者发现请求消息#AA的具体含义可参考上述步骤S211或S213中的消息的具体含义，该注册请求消息#AA用于将API调用者注册到CCF，该发现请求消息#AA用于API调用者发现目标API。

S502，CCF向API调用者发送注册响应消息#AA，或者发现响应消息#AA(即，第二API调用响应消息的一例)。

对应的，API调用者接收来自CCF的注册响应消息#AA，或者发现响应消息#AA。

其中，该注册响应消息#AA，或者发现响应消息#AA包括授权指示。该注册响应消息#AA，或者发现响应消息#AA的具体含义可参考上述步骤S212或S214中的消息的具体含义.

示例性的，该授权指示可以包括以下一项或者多项：

可选地，该注册响应消息#AA，或者发现响应消息#AA还包括Service API ID，和/或用户标识1。其中，Service API ID用于指示需要进行授权的API。

S503，可选地，API调用者根据授权指示向CCF发送获取授权请求消息#AA(即，第一请求消息的一例)。

对应的，CCF接收来自API调用者的获取授权请求消息#AA。

其中，该获取授权请求消息#AA用于请求获取调用Service API的权限，该获取授权请求消息#AA包括API Invoker ID和Service API ID。

S504，可选地，CCF向API调用者发送获取授权响应消息#AA。

对应的，API调用者接收来自CCF的获取授权响应消息#AA。

其中，该获取授权响应消息#AA包括token1(即，第二令牌的一例)，token1用于指示API Invoker具有访问Service API的权限。

S505，API调用者根据授权指示确定请求AuF进行授权。

应理解，基于步骤S502中的授权指示，对于特定Service API ID，APIInvoker需要额外请求AuF进行用户的授权。因此，当API Invoker准备调用特定Service API ID，且该Service API ID具有对应的授权指示时，API Invoker应根据授权指示确定AuF的地址进行授权。

示例性的，API Invoker根据授权指示确定AuF的地址进行授权。例如，若授权指示包含(1)明示的指示，此时API Invoker可以根据预配置的AuF地址，向AuF请求获取用户的授权；又例如，若授权指示包含(2)AuF的地址，则API Invoker根据该AuF的地址，向AuF请求获取用户的授权。

可选地，API Invoker根据授权指示中的(3)授权方式可以确定使用何种响应类型，例如，若授权方式为OAuth 2.0的授权码模式，则响应类型应为code，若授权方式为OAuth2.0的隐式模式，则响应类型应为token等。

S506，API调用者向AuF发送授权请求消息#AA(即，授权请求消息的一例)。

对应的，AuF接收来自API调用者的授权请求消息#AA。

其中，该授权请求消息#AA用于请求获取用户的授权，该授权请求消息#AA包括用户标识1(即，目标用户的标识的一例)。

可选地，该授权请求消息#AA还包括Service API ID，和/或API Invoker ID。

可选地，该授权请求消息#AA还包括响应类型，和/或范围指示信息。其中，响应类型用于指示当前的授权方式，例如code指示授权码模式，token指示隐式。范围指示信息用于指示授权的范围，可以包括Service API ID和用户标识1。

示例性的，该授权请求消息#AA可以是OAuth2.0的Authorization Request消息。

S507，可选地，AuF判断当前API调用是否需要用户同意。

示例性的，AuF可以根据本地配置信息判断当前的API是否需要用户同意。例如，本地配置信息可以是一个API列表，该API列表中的所有API都是需要用户同意的API。

在一种示例中，在确定API Invoker调用当前的Service API需要用户同意，且AuF不具备用户标识1对应的UE上下文，或者用户标识1对应的UE上下文中未保存有UE的用户同意信息的情况下，AuF确定需要向RO客户端进行授权。

在另一种示例中，在确定API Invoker调用当前的Service API需要用户同意，且AuF从UDM未成功获取该UE的用户同意信息的情况下，AuF确定需要向RO客户端进行授权。

S508，AuF与RO客户端交互，以获取用户同意信息#AA。

S509，AuF确定授权响应消息#AA。

示例性的，基于步骤S508，若用户同意信息#AA指示用户同意授权API Invoker调用Service API以操作用户数据，则授权响应消息#AA包括具有完整性保护的token2(即，第一令牌的一例)，该token2包括用户标识1。反之，若用户同意信息#AA指示用户拒绝授权APIInvoker调用Service API以操作用户数据，则授权响应消息#AA包括失败指示信息，失败指示信息用于指示用户未授权API Invoker调用Service API以操作用户数据。

S510，可选地，AEF向UDM发送签约信息更新请求消息#AA。

对应的，UDM接收来自AEF的签约信息更新请求消息#AA。

其中，该签约信息更新请求消息#AA用于更新UE的用户同意信息，该签约信息更新消息#AA可以包括以下一项或多项：用户标识2，数据处理目的，API Invoker ID，超时时间，用户同意结果。

应理解，用户标识2根据用户标识1转化而来，可以为SUPI，数据处理目的是根据Server API ID转化而来，用户同意结果可以根据步骤S508的用户同意信息#AA获得。

该实现方式中，通过AuF更新UDM上的UE签约信息，可以减少AuF请求RO授权的次数。

S511，AuF向API调用者发送授权响应消息#AA(即，授权响应消息的一例)。

对应的，API调用者接收来自AuF的授权响应消息#AA。

其中，该授权响应消息#AA包括具有完整性保护的token2，token2包括用户标识1。

S512，可选地，API调用者向AuF发送接入token请求消息#AA。

对应的，AuF接收来自API调用者的接入token请求消息#AA。

S513，可选地，AuF向API调用者发送接入token响应消息#AA。

对应的，API调用者接收来自AuF的接入token响应消息#AA。

其中，该接入token响应消息#AA包括具有完整性保护的token2，token2包括用户标识1。

需要说明的是，上述步骤S512和S513的具体实现方式可参见上述图2的(c)中步骤S237-S238。为了简洁，此处不再赘述。

S514，API调用者向AEF发送API调用请求消息#AA(即，第一API调用请求消息的一例)。

对应的，AEF接收来自API调用者的API调用请求消息#AA。

其中，该API调用请求消息#AA包括用户标识1(即，目标用户的一例)，以及具有完整性保护的token2。其中，token2包括用户标识1。

可选地，API调用请求消息#AA包括以下一项或者多项：API Invoker ID，ServiceAPI ID，token1。

可选地，该token2包括以下一项或者多项：超时时间，API Invoker ID，ServiceAPI ID，签名者。其中，签名者可以不放在token2的声明中，而放在API调用请求消息#AA上。

S515，AEF验证token2。

其中，AEF校验token2的具体实现方式可参考上述方法400中步骤S460。为了简洁，此处不再赘述。

可选地，AEF还根据API调用请求消息#AA校验token1，以确定CCF授权API Invoker访问Service API(即，目标API)。具体校验token1的实现方式可参考上述图2的(a)步骤S218。为了简洁，此处不再赘述。

需要说明的是，在上述两个token(包括token1和token2)都校验成功后，AEF将授权该API Invoker调用该Service API以操作用户的个人数据，即执行步骤S516。否则，则AEF将拒绝API Invoker的调用请求。

S516，AEF向API调用者发送API调用响应消息#AA。

对应的，API调用者接收来自AEF的API调用响应消息#AA。

其中，该API调用响应消息#AA用于返回API Invoker ID调用目标API以操作用户数据的结果。例如，授权API Invoker ID具有调用目标API以操作用户数据的权限。

本申请所揭示的方法，结合CCF向API Invoker提供需要进行目标API授权的token1，以及通过AuF生成更细粒度的token2，使得在授权过程中考虑用户同意信息，达到AEF授权API Invoker访问某个API并调用某个用户的数据。该实现方式在处理用户数据时需要用户的授权，保护用户的隐私信息，能够避免用户隐私暴露，减少移动通信网络中网络功能面临的潜在的安全风险。

图6是本申请实施例提供的通信方法600的流程示例图。与上述方法500不同之处在于，该实现方式中，CCF作为中间节点转发AuF与API Invoker之间的消息交互，可以在减少API Invoker与AuF交互信令的基础上实现更细粒度的授权，即授权API Invoker访问某个API并处理某个用户的数据。如图6所示，该方法包括如下多个步骤。

S601，API调用者向CCF发送注册请求消息#Aa，或者发现请求消息#Aa(即，第二请求消息的一例)。

S602，CCF向API调用者发送注册响应消息#Aa，或者发现响应消息#Aa(即，第二API调用响应消息的一例)。

其中，该注册响应消息#Aa，或者发现响应消息#Aa包括授权指示。

S603，API调用者根据授权指示确定请求AuF进行授权。

应理解，基于步骤S502中的授权指示，对于特定Service API ID，API Invoker需要额外请求AuF进行用户的授权。因此，当API Invoker准备调用特定Service API ID，且该Service API ID具有对应的授权指示时，API Invoker应根据授权指示确定AuF的地址进行授权。

其中，步骤S601-S603的具体实现方式可参考上述方法500中步骤S501-S502，以及步骤S505，为了简洁，此处不再赘述。

S604，API调用者向CCF发送授权请求消息#Aa(即，第二请求消息的一例)。

对应的，CCF接收来自API调用者的授权请求消息#Aa。

其中，该授权请求消息#Aa用于请求获取用户的授权，该授权请求消息#Aa包括Service API ID，以及用户标识1。

可选地，该授权请求消息#Aa还包括API Invoker ID。

S605，CCF向AuF发送授权请求消息#Aa。

对应的，AuF接收来自CCF的授权请求消息#Aa。

可选地，CCF可以提前预配置AuF的地址，例如API Service ID与AuF的映射关系，CCF可以根据Service API ID获得AuF的地址，进而根据AuF的地址，向AuF发送授权请求消息#Aa。

S606，AuF与RO客户端交互，以获取用户同意信息#Aa。

S607，AuF确定授权响应消息#Aa。

示例性的，基于步骤S606，若用户同意信息#Aa指示用户同意授权API Invoker调用Service API以操作用户数据，则授权响应消息#Aa包括具有完整性保护的token(即，第一令牌的一例)，该token包括用户标识1。反之，若用户同意信息#Aa指示用户拒绝授权APIInvoker调用Service API以操作用户数据，则授权响应消息#Aa包括失败指示信息，失败指示信息用于指示用户未授权API Invoker调用Service API以操作用户数据。

S608，AuF向CCF发送授权响应消息#Aa。

对应的，CCF接收来自AuF的授权响应消息#Aa。

其中，该授权响应消息#Aa包括token#1。

S609，CCF向API调用者发送授权响应消息#Aa(即，授权响应消息的一例)。

对应的，API调用者接收来自CCF的授权响应消息#Aa。

其中，该授权响应消息#Aa包括具有完整性保护的token 2。

可选地，该token#2可以和token#1相同。

可选地，该token#2可以是由CCF生成的。CCF在接收到步骤S608的token#1后，确定生成token#2。

其中，token#2包括声明(claims)和签名，签名可以是CCF对token的数字签名。示例性的，声明中包括以下一项或者多项：超时时间，API Invoker ID，service API ID，用户标识1。

S610，可选地，CCF向UDM发送签约信息更新请求消息#Aa。

对应的，UDM接收来自AEF的签约信息更新请求消息#Aa。

应理解，用户标识2根据用户标识1转化而来，可以为SUPI，数据处理目的是根据Server API ID转化而来，用户同意结果可以根据步骤S606的用户同意信息#Aa获得。

该实现方式中，通过CCF更新UDM上的UE签约信息，可以减少AuF请求RO授权的次数。

S613，API调用者向AEF发送API调用请求消息#Aa(即，第一API调用请求消息的一例)。

对应的，AEF接收来自API调用者的API调用请求消息#Aa。

其中，API调用请求消息#Aa包括token#2和用户标识1。

S614，AEF验证token#2。

示例性的，若token#2为token#1，则AEF可参考步骤S460进行验证token#2。

若token#2为CCF生成，则AEF校验token#2的实现方式包括如下验证内容：

(1)AEF校验token#2的签名。AEF通过预配置的CCF的凭证(如证书)，校验token#2的签名。

(2)AEF校验token#2的声明部分.

示例性的，AEF可以判断API调用请求消息#Aa中的用户标识1是否与token中的用户标识1一致。

可选地，AEF判断API调用请求消息#Aa中的API Invoker ID是否与token中的APIInvoker ID一致；或者，AEF判断API调用请求消息#Aa中的Service API ID是否与token中的Service API ID一致；或者，AEF根据token中的超时时间与当前的时间对比，判断token是否仍然有效，等等。

可选地，该token通常在有效期内可以被API Invoekr重复使用。

S615，AEF向API调用者发送API调用响应消息#Aa。

对应的，API调用者接收来自AEF的API调用响应消息#Aa。

示例性的，若某一服务器通过API调用请求消息#Aa向AEF调用请求UE标识的API，例如Nnef_UEIdentifier_Get，其输入user information设置为某个UE的IP地址或域名，AFID设置为讨论服务器的ID，则AEF将返回API调用响应消息#Aa，该消息中包含该UE的外部标识，例如GPSI。

本申请所揭示的方法，基于图2的(a)中的token，并引入CCF作为中间节点转发APIInvoker和AuF之间的消息，可以在减少API Invoker与AuF交互信令的基础上实现更细粒度的授权，使得在授权过程中考虑用户同意信息，达到AEF授权API Invoker访问某个API并调用某个用户的数据。同时，使用CCF代替AuF生成token的方式，可以减少AEF对于凭证的配置数量，而不需要配置AuF的凭证，同时也可以复用当前现有的token，不需要定义新的token，从而减少标准协议改动。该实现方式在处理用户数据时需要用户的授权，保护用户的隐私信息，能够避免用户隐私暴露，减少移动通信网络中网络功能面临的潜在的安全风险。

图7是本申请实施例提供的通信方法700的流程示例图。与上述方法600不同之处在于，该实现方式仅在AEF与AuF上进行升级，可以在不影响API Invoker的基础上实现更细粒度的授权，即授权API Invoker访问某个API并处理某个用户的数据。如图7所示，该方法包括如下多个步骤。

S710，API调用者向AEF发送API调用请求消息#α。

对应的，AEF接收来自API调用者的API调用请求消息#α。

示例性的，该API调用请求消息#α用于请求调用Service API以操作用户的个人数据，该API调用请求消息#α包括API调用者的标识。

可选地，该API调用请求消息#α还包括用户标识1，和/或Service API ID。

可选地，该API调用请求消息#α本身携带Service API ID。例如，该API调用请求消息#A可以包括但不限于：定位Nnef_Location、获取Nnef_UEIdentifier_Get、订阅分析Nnwdaf_AnalyticsSubscription_Subscribe等消息。

S720，AEF判断当前API调用是否需要用户同意，并生成获取授权请求消息#α。

在一种示例中，在确定API Invoker调用当前的Service API需要用户同意，且AEF不具备用户标识1对应的UE上下文，或者用户标识1对应的UE上下文中未保存有UE的用户同意信息的情况下，AEF确定需要向AuF进行用户授权。

在另一种示例中，在确定API Invoker调用当前的Service API需要用户同意，且AEF从UDM未成功获取该UE的用户同意信息的情况下，AEF确定需要向AuF进行用户授权。

可选地，若AEF已经具备UE的用户同意信息，且用户同意信息指示同意该APIInvoker调用该Service API以操作用户的个人数据，则AEF可以直接执行步骤S791。

S730，AEF向AuF发送获取授权请求消息#α。

对应的，AuF接收来自AEF的获取授权请求消息#α。

其中，该获取授权请求消息#α包括API Invoker ID，用户标识2，以及service APIID。其中，用户标识2是从用户标识1获得的，AEF可以通过用户标识1去其他网元获得用户标识2，以使得用户标识2可被AuF识别并确定RO的地址，即执行步骤S740-S760。

S740，可选地，AuF与RO客户端之间进行认证。

可选地，若AuF已有相关用户的认证信息，则该步骤可省略。

其中，具体的认证方式可参考现有标准中定义的认证方式，为了简洁，此处不再赘述。

S750，可选地，AuF向RO客户端发送用户同意请求消息#α。

对应的，RO客户端接收来自AuF的用户同意请求消息#α。

示例性的，基于上述步骤S740的认证成功后，AuF向RO发送用户同意请求消息#α，该用户同意请求消息#α可以包括Client ID和scope等内容。

S760，可选地，RO客户端向AuF发送用户同意响应消息#α。

对应的，AuF接收来自RO客户端的用户同意响应消息#α。

示例性的，在用户点击同意或不同意后，RO可以向AuF返回用户同意响应消息#α。

其中，上述步骤S750-S760的具体实现方式可参见上述图2的(c)中步骤S234-S235；或者，也可以参见上述图2的(d)中步骤S244-S245。为了简洁，此处不再赘述。

S770，AuF向AEF发送获取授权响应消息#α。

对应的，AEF接收来自AuF的获取授权响应消息#α。

其中，该获取授权响应消息#α包含授权结果，即用于指示用户是否同意APIInvoker调用Service API以操作用户的个人数据。

其中，授权结果是AuF根据用户同意响应消息#a的内容获得的。例如，若用户点击同意，则授权结果为授权，若用户点击不同意，则授权结果为不授权。

S780，可选地，AEF向UDM发送签约信息更新请求消息#α。

对应的，UDM接收来自AEF的签约信息更新请求消息#α。

可选地，若授权结果用于指示用户授权，则AEF向UDM发送签约信息更新消息#α，该签约信息更新消息#α用于更新UE的用户同意信息。

其中，该签约信息更新消息#α可以包含以下一项或多项：用户标识2、数据处理目的、API Invoker ID、超时时间、用户同意结果。应理解，用户标识2是从用户标识1转化而来，可以为SUPI；数据处理目的由Server API ID转化而来；用户同意结果根据步骤S760获得。该实现方式中，通过AEF更新UDM上的UE签约信息，可以减少AuF请求RO授权的次数。

S790，AEF根据授权结果确定是否授权。

示例性的，若步骤S770中的授权结果指示用户已授权，则AEF可以执行步骤S791。若授权结果指示用户不授权，则AEF可以拒绝API Invoker的API调用请求。

S791，AEF向API调用者发送API调用响应消息#α。

对应的，API调用者接收来自AEF的API调用响应消息#α。

其中，该API调用响应消息#α用于授权API Invoker ID具有调用目标API以操作用户数据的权限。例如，授权API Invoker ID具有调用目标API以操作用户数据的权限。

本申请所揭示的方法，可以在不影响API Invoker的基础上实现更细粒度的授权，即授权API Invoker访问某个API并处理某个用户的数据，使得在授权过程中考虑用户同意信息，达到AEF授权API Invoker访问某个API并调用某个用户的数据。该实现方式在处理用户数据时需要用户的授权，保护用户的隐私信息，能够避免用户隐私暴露，减少移动通信网络中网络功能面临的潜在的安全风险。

上文结合图1至图7，详细描述了本申请的通信方法侧实施例，下面将结合图8和图9，详细描述本申请的通信装置侧实施例。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。

图8是本申请实施例提供的通信装置的示意性框图。如图8所示，该设备1200可以包括收发单元1210和处理单元1220。收发单元1210可以与外部进行通信，处理单元1220用于进行数据处理。收发单元1210还可以称为通信接口或收发单元。

在一种可能的设计中，该设备1200可实现对应于上文方法实施例中的API调用者执行的步骤或者流程，其中，处理单元1220用于执行上文方法实施例中API调用者的处理相关的操作，收发单元1210用于执行上文方法实施例中API调用者的收发相关的操作。

示例性的，收发单元1210，用于向授权功能网元发送授权请求消息，授权请求消息包括API调用者的标识；

收发单元1210，还用于接收来自授权功能网元的授权响应消息，授权响应消息包括具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；

收发单元1210，还用于向API开放功能网元AEF发送第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括目标用户的标识和第一令牌。

在另一种可能的设计中，该设备1200可实现对应于上文方法实施例中的API开放功能网元执行的步骤或者流程，其中，收发单元1210用于执行上文方法实施例中API开放功能网元的收发相关的操作，处理单元1220用于执行上文方法实施例中API开放功能网元的处理相关的操作。

示例性的，收发单元1210，用于接收来自API调用者的第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括具有完整性保护的第一令牌和目标用户的标识，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；

处理单元1220，用于根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限；

处理单元1220，还用于根据确定结果，确定是否向API调用者提供访问目标用户的数据的权限。

在又一种可能的设计中，该设备1200可实现对应于上文方法实施例中的授权功能网元执行的步骤或者流程，其中，收发单元1210用于执行上文方法实施例中授权功能网元的收发相关的操作，处理单元1220用于执行上文方法实施例中授权功能网元的处理相关的操作。

示例性的，收发单元1210，用于接收来自应用软件编程接口API调用者的授权请求消息，授权请求消息包括API调用者的标识；

处理单元1220，用于在确定目标用户同意API调用者操作目标用户的数据的情况下，授权功能网元生成具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；

收发单元1210，还用于向API调用者发送授权响应消息，授权响应消息包括第一令牌。

在又一种可能的设计中，该设备1200可实现对应于上文方法实施例中的CCF执行的步骤或者流程，其中，收发单元1210用于执行上文方法实施例中CCF的收发相关的操作，处理单元1220用于执行上文方法实施例中CCF的处理相关的操作。

示例性的，收发单元1210，用于接收来自API调用者的第二请求消息，第二请求消息用于请求调用目标API以操作目标用户的数据，第二请求消息包括目标用户的标识和目标API的标识；收发单元1210，还用于向API调用者发送授权指示。

应理解，这里的设备1200以功能单元的形式体现。这里的术语“单元”可以指应用特有集成电路(application specific integrated circuit，ASIC)、电子电路、用于执行一个或多个软件或固件程序的处理器(例如共享处理器、专有处理器或组处理器等)和存储器、合并逻辑电路和/或其它支持所描述的功能的合适组件。在一个可选例子中，本领域技术人员可以理解，设备1200可以具体为上述实施例中的发送端，可以用于执行上述方法实施例中与发送端对应的各个流程和/或步骤，或者，设备1200可以具体为上述实施例中的接收端，可以用于执行上述方法实施例中与接收端对应的各个流程和/或步骤，为避免重复，在此不再赘述。

上述各个方案的设备1200具有实现上述方法中发送端所执行的相应步骤的功能，或者，上述各个方案的设备1200具有实现上述方法中接收端所执行的相应步骤的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块；例如收发单元可以由收发机替代(例如，收发单元中的发送单元可以由发送机替代，收发单元中的接收单元可以由接收机替代)，其它单元，如处理单元等可以由处理器替代，分别执行各个方法实施例中的收发操作以及相关的处理操作。

此外，上述收发单元还可以是收发电路(例如可以包括接收电路和发送电路)，处理单元可以是处理电路。在本申请的实施例，图8中的装置可以是前述实施例中的接收端或发送端，也可以是芯片或者芯片系统，例如：片上系统(system on chip，SoC)。其中，收发单元可以是输入输出电路、通信接口。处理单元为该芯片上集成的处理器或者微处理器或者集成电路。在此不做限定。

图9示出了本申请实施例提供的通信装置2000。如图9所示，该设备2000包括处理器2010和收发器2020。其中，处理器2010和收发器2020通过内部连接通路互相通信，该处理器2010用于执行指令，以控制该收发器2020发送信号和/或接收信号。

可选地，该设备2000还可以包括存储器2030，该存储器2030与处理器2010、收发器2020通过内部连接通路互相通信。该存储器2030用于存储指令，该处理器2010可以执行该存储器2030中存储的指令。

在一种可能的实现方式中，设备2000用于实现上述方法实施例中的API调用者对应的各个流程和步骤。

示例性的，收发器2020，用于向授权功能网元发送授权请求消息，授权请求消息包括API调用者的标识；

收发器2020，还用于接收来自授权功能网元的授权响应消息，授权响应消息包括具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；

收发器2020，还用于向API开放功能网元AEF发送第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括目标用户的标识和第一令牌。

在另一种可能的实现方式中，设备2000用于实现上述方法实施例中的授权功能网元对应的各个流程和步骤。

示例性的，收发器2020，用于接收来自应用软件编程接口API调用者的授权请求消息，授权请求消息包括API调用者的标识；

处理器2010，用于在确定目标用户同意API调用者操作目标用户的数据的情况下，授权功能网元生成具有完整性保护的第一令牌，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；

收发器2020，还用于向API调用者发送授权响应消息，授权响应消息包括第一令牌。

在又一种可能的实现方式中，设备2000用于实现上述方法实施例中的AEF对应的各个流程和步骤。

示例性的，收发器2020，用于接收来自API调用者的第一API调用请求消息，第一API调用请求消息用于请求调用目标API以操作目标用户的数据，第一API调用请求消息包括具有完整性保护的第一令牌和目标用户的标识，第一令牌用于指示API调用者具有访问目标用户的数据的权限，第一令牌包括目标用户的标识；

处理器2010，用于根据第一令牌，确定API调用者是否具有操作目标用户的数据的权限；

处理器2010，还用于根据确定结果，确定是否向API调用者提供访问目标用户的数据的权限。

在又一种可能的实现方式中，设备2000用于实现上述方法实施例中的CCF对应的各个流程和步骤。

示例性的，收发器2020，用于接收来自API调用者的第二请求消息，第二请求消息用于请求调用目标API以操作目标用户的数据，第二请求消息包括目标用户的标识和目标API的标识；

收发器2020，还用于向API调用者发送授权指示。

应理解，设备2000可以具体为上述实施例中的发送端或接收端，也可以是芯片或者芯片系统。对应的，该收发器2020可以是该芯片的收发电路，在此不做限定。具体地，该设备2000可以用于执行上述方法实施例中与发送端或接收端对应的各个步骤和/或流程。

可选地，该存储器2030可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。存储器的一部分还可以包括非易失性随机存取存储器。例如，存储器还可以存储设备类型的信息。该处理器2010可以用于执行存储器中存储的指令，并且当该处理器2010执行存储器中存储的指令时，该处理器2010用于执行上述与发送端或接收端对应的方法实施例的各个步骤和/或流程。

在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。

应注意，本申请实施例中的处理器可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。本申请实施例中的处理器可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

可以理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rateSDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(directrambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

根据本申请实施例提供的方法，本申请还提供一种计算机程序产品，该计算机程序产品包括：计算机程序代码，当该计算机程序代码在计算机上运行时，使得该计算机执行上述所示实施例中的方法。

根据本申请实施例提供的方法，本申请还提供一种计算机可读介质，该计算机可读介质存储有程序代码，当该程序代码在计算机上运行时，使得该计算机执行上述所示实施例中的方法。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims

1.一种通信方法，其特征在于，包括：

应用软件编程接口API调用者向授权功能网元发送授权请求消息，所述授权请求消息包括目标用户的标识；

所述API调用者接收来自所述授权功能网元的授权响应消息，所述授权响应消息包括具有完整性保护的第一令牌，所述第一令牌用于指示所述API调用者具有访问所述目标用户的数据的权限，所述第一令牌包括所述目标用户的标识；

所述API调用者向API开放功能网元AEF发送第一API调用请求消息，所述第一API调用请求消息用于请求调用目标API以操作所述目标用户的数据，所述第一API调用请求消息包括所述目标用户的标识和所述第一令牌。

2.根据权利要求1所述的方法，其特征在于，在所述API调用者向授权功能网元发送授权请求消息之前，所述方法还包括：

所述API调用者向所述AEF发送第二API调用请求消息，所述第二API调用请求消息用于请求调用所述目标API以操作所述目标用户的数据，所述第二API调用请求消息包括所述目标用户的标识；

所述API调用者接收来自所述AEF的授权指示；其中，

所述API调用者向授权功能网元发送授权请求消息，包括：

所述API调用者根据所述授权指示，向所述授权功能网元发送所述授权请求消息。

3.根据权利要求2所述的方法，其特征在于，所述授权指示包括所述授权功能网元的地址；

其中，所述API调用者接收来自所述AEF的授权指示，包括：

所述API调用者接收来自所述AEF的第二API调用响应消息，所述第二API调用响应消息包括所述授权指示。

4.根据权利要求1所述的方法，其特征在于，在所述API调用者向授权功能网元发送授权请求消息之前，所述方法还包括：

所述API调用者向通用API框架核心功能网元CCF发送第二请求消息，所述第二请求消息用于请求用于将所述API调用者注册到所述CCF，或者用于所述API调用者发现所述目标API；

所述API调用者接收来自所述CCF的授权指示；

其中，所述API调用者向授权功能网元发送授权请求消息，包括：

5.根据权利要求4所述的方法，其特征在于，所述授权指示包括所述授权功能网元的地址；

其中，所述API调用者接收来自所述CCF的授权指示，包括：

所述API调用者接收来自所述CCF的第二API调用响应消息，所述第二API调用响应消息包括所述授权指示。

6.根据权利要求3或5所述的方法，其特征在于，所述第二API调用响应消息为重定向请求消息。

7.根据权利要求3或5所述的方法，其特征在于，所述授权指示还包括原因值，所述原因值用于指示请求操作所述目标用户的数据需要所述目标用户的授权。

8.根据权利要求2或4所述的方法，其特征在于，所述授权指示包括原因值，所述原因值用于指示请求操作所述目标用户的数据需要所述目标用户的授权；其中，

所述API调用者根据所述授权指示，向所述授权功能网元发送所述授权请求消息，包括：

所述API调用者根据所述原因值，确定所述授权功能网元的地址；

所述API调用者根据所述授权功能网元的地址，向所述授权功能网元发送所述授权请求消息。

9.根据权利要求8所述的方法，其特征在于，所述API调用者根据所述原因值，确定所述授权功能网元的地址，包括：

所述API调用者根据所述原因值，从预配置的地址列表中获取所述授权功能网元的地址。

10.根据权利要求2至9中任一所述的方法，其特征在于，所述授权指示还包括授权类型，所述授权请求消息还包括响应类型；

其中，在所述API调用者根据所述授权指示，向所述授权功能网元发送所述授权请求消息之前，所述方法还包括：

所述API调用者根据所述授权类型确定所述响应类型。

11.根据权利要求1至10所述的方法，其特征在于，所述第一API调用请求消息还包括第二令牌，所述第二令牌用于指示所述API调用者具有调用所述目标API的权限，所述第二令牌包括所述API调用者的标识和所述目标API的标识；

其中，在所述API调用者向AEF发送第一API调用请求消息之前，所述方法还包括：

所述API调用者向通用API框架核心功能网元CCF发送第一请求消息，所述第一请求消息用于请求获取调用所述目标API的权限，所述第一请求消息包括所述API调用者的标识和所述目标API的标识；

所述API调用者接收来自所述CCF的所述第二令牌。

12.根据权利要求1至11中任一项所述的方法，其特征在于，所述第一令牌包括还包括以下一项或者多项：

超时时间；

所述API调用者的标识；

所述目标API的标识；

签名者。

13.根据权利要求1至12中任一项所述的方法，其特征在于，所述授权请求消息还包括：

所述目标API的标识；和/或，所述目标用户的标识。

14.一种通信方法，其特征在于，包括：

应用软件编程接口API开放功能网元AEF接收来自API调用者的第一API调用请求消息，所述第一API调用请求消息用于请求调用目标API以操作目标用户的数据，所述第一API调用请求消息包括具有完整性保护的第一令牌和所述目标用户的标识，所述第一令牌用于指示所述API调用者具有访问所述目标用户的数据的权限，所述第一令牌包括所述目标用户的标识；

所述AEF根据所述第一令牌，确定所述API调用者是否具有操作所述目标用户的数据的权限；

根据确定结果，所述AEF确定是否向所述API调用者提供访问所述目标用户的数据的权限。

15.根据权利要求14所述的方法，其特征在于，所述AEF根据所述第一令牌，确定所述API调用者是否具有操作所述目标用户的数据的权限，包括：

所述AEF根据授权功能网元的凭证，对所述第一令牌的完整性保护进行验证，所述授权功能网元为生成所述第一令牌的网元；

在所述第一令牌的完整性保护验证通过的情况下，所述AEF判断所述第一令牌中携带的所述目标用户的标识，是否与所述第一API调用请求消息中携带的所述目标用户的标识相同。

16.根据权利要求15所述的方法，其特征在于，所述第一令牌还包括签名者；

其中，在所述AEF根据授权功能网元的凭证，对所述第一令牌进行完整性验证之前，所述方法还包括：

所述AEF根据所述签名者，获取所述授权功能网元的凭证。

17.根据权利要求15或16所述的方法，其特征在于，所述第一令牌还包括所述API调用者的标识，所述第一API调用请求消息还包括所述API调用者的标识，所述AEF根据所述第一令牌，确定所述API调用者是否具有操作所述目标用户的数据的权限，还包括：

所述AEF判断所述第一令牌中携带的所述API调用者的标识，是否与所述第一API调用请求消息中携带的所述API调用者的标识相同。

18.根据权利要求17所述的方法，其特征在于，所述第一令牌还包括所述目标API的标识，所述第一API调用请求消息还包括所述目标API的标识，所述AEF根据所述第一令牌，确定所述API调用者是否具有操作所述目标用户的数据的权限，还包括：

所述AEF判断所述第一令牌中携带的所述目标API的标识，是否与所述第一API调用请求消息中携带的所述目标API的标识相同。

19.根据权利要求14至18中任一项所述的方法，其特征在于，所述第一API调用请求消息还包括第二令牌；

其中，在确定所述API调用者是否具有操作所述目标用户的数据的权限之前，所述方法还包括：

所述AEF根据所述第二令牌，确定所述API调用者具有调用所述目标API的权限。

20.根据权利要求19所述的方法，其特征在于，所述第二令牌还包括所述目标API的标识，所述第一API调用请求消息还包括所述目标API的标识；

其中，所述AEF根据所述第二令牌，确定所述API调用者具有调用所述目标API的权限，包括：

所述AEF确定所述第二令牌中携带的所述目标API的标识，与所述第一API调用请求消息中携带的所述目标API的标识相同。

21.根据权利要求14至20任一项所述的方法，其特征在于，在AEF接收来自API调用者的第一API调用请求消息之前，所述方法还包括：

所述AEF接收来自所述API调用者的第二API调用请求消息，所述第二API调用请求消息用于请求调用所述目标API以操作所述目标用户的数据，所述第二API调用请求消息包括所述目标用户的标识；

所述AEF向所述API调用者发送授权指示，所述授权指示用于指示请求操作所述目标用户的数据需要所述目标用户的授权。

22.根据权利要求21所述的方法，其特征在于，所述授权指示包括所述授权功能网元的地址；

其中，所述AEF向所述API调用者发送授权指示，包括：

所述AEF向所述API调用者发送第二API调用响应消息，所述第二API调用响应消息包括所述授权指示。

23.根据权利要求22所述的方法，其特征在于，所述第二API调用响应消息为重定向请求消息。

24.根据权利要求21或22所述的方法，其特征在于，所述授权指示包括原因值，所述原因值用于指示请求操作所述目标用户的数据需要所述目标用户的授权。

25.根据权利要求8至24中任一项所述的方法，其特征在于，在所述AEF向所述API调用者发送授权指示之前，所述方法还包括：

所述AEF确定请求操作所述目标用户的数据需要所述目标用户的授权。

26.根据权利要求25所述的方法，其特征在于，所述AEF确定请求操作所述目标用户的数据需要所述目标用户的授权，包括：

所述AEF向统一数据管理功能网元UDM发送获取请求消息，所述获取请求消息用于请求获取所述目标用户的用户同意信息；

所述AEF接收来自所述UDM的响应消息；

所述AEF根据所述响应消息，确定请求操作所述目标用户的数据需要所述目标用户的授权。

27.根据权利要求26所述的方法，其特征在于，在所述AEF向所述UDM发送获取请求消息之前，所述方法还包括：

所述AEF确定所述AEF没有保存有所述目标用户的用户同意信息，所述用户同意信息指示所述目标用户同意操作所述目标用户的数据。

28.根据权利要求14至27中任一项所述的方法，其特征在于，所述方法还包括：

所述AEF向通用API框架核心功能网元CCF发送第三请求消息，所述第三请求消息用于请求获取所述API调用者调用所述目标API的访问策略，所述第三请求消息包括所述API调用者的标识和所述目标API的标识；

其中，所述根据确定结果，所述AEF确定是否向所述API调用者提供访问所述目标用户的数据的权限，包括：

在所述API调用者具有操作所述目标用户的数据的权限，且所述访问策略指示允许所述API调用者调用所述目标API的情况下，所述AEF向所述API调用者提供访问所述目标用户的数据的权限。

29.根据权利要求14至28中任一项所述的方法，其特征在于，所述方法还包括：

在所述API调用者具有操作所述目标用户的数据的权限的情况下，所述AEF向统一数据管理功能UDM发送签约信息更新消息，所述签约信息更新消息用于更新所述目标用户的用户同意信息，所述用户同意信息用于指示所述目标用户同意操作所述目标用户的数据。

30.一种通信方法，其特征在于，包括：

授权功能网元接收来自应用软件编程接口API调用者的授权请求消息，所述授权请求消息包括目标用户的标识；

在确定所述目标用户同意所述API调用者操作所述目标用户的数据的情况下，所述授权功能网元生成具有完整性保护的第一令牌，所述第一令牌用于指示所述API调用者具有访问所述目标用户的数据的权限，所述第一令牌包括所述目标用户的标识；

所述授权功能网元向所述API调用者发送授权响应消息，所述授权响应消息包括所述第一令牌。

31.根据权利要求30所述的方法，其特征在于，所述授权请求消息还包括目标API的标识和所述目标用户的标识，所述授权功能网元生成具有完整性保护的第一令牌，包括：

所述授权功能网元根据所述API调用者的标识、所述目标API的标识和所述目标用户的标识生成声明；

所述授权功能网元根据所述声明生成签名；

所述授权功能网元根据所述声明和所述签名生成所述具有完整性保护的第一令牌。

32.根据权利要求30或31所述的方法，其特征在于，所述第一令牌包括还包括以下一项或者多项：

超时时间；

所述API调用者的标识；

所述目标API的标识；

签名者。

33.根据权利要求30至32中任一项所述的方法，其特征在于，所述授权请求消息还包括：

所述目标API的标识；和/或，所述目标用户的标识。

34.一种通信方法，其特征在于，包括：

通用应用软件编程接口API框架核心功能网元CCF接收来自API调用者的第二请求消息，所述第二请求消息用于请求用于将所述API调用者注册到所述CCF，或者用于所述API调用者发现目标API；

所述CCF向所述API调用者发送授权指示。

35.根据权利要求34所述的方法，其特征在于，所述授权指示包括授权功能网元的地址；

其中，所述CCF向所述API调用者发送授权指示，包括：

所述CCF向所述API调用者第二响应消息，所述第二响应消息包括所述授权指示。

36.根据权利要求35所述的方法，其特征在于，所述第二响应消息为重定向请求消息。

37.根据权利要求35所述的方法，其特征在于，所述授权指示还包括原因值，所述原因值用于指示请求操作所述目标用户的数据需要所述目标用户的授权。

38.根据权利要求34至37中任一项所述的方法，其特征在于，所述方法还包括：

所述CCF接收来自所述API调用者的授权请求消息，所述授权请求消息包括所述API调用者的标识、所述目标API的标识以及所述目标用户的标识；

所述CCF向授权功能网元发送所述授权请求消息；

所述CCF接收来自所述授权功能网元的授权响应消息，所述授权响应消息包括具有完整性保护的第一令牌，所述第一令牌用于指示所述API调用者具有访问所述目标用户的数据的权限，所述第一令牌包括所述目标用户的标识；

所述CCF向所述API调用者发送所述授权响应消息。

39.根据权利要求38所述的方法，其特征在于，在所述CCF向授权功能网元发送所述授权请求消息之前，所述方法还包括：

所述CCF根据预配置的地址列表，确定所述授权功能网元的地址；

所述CCF根据所述授权功能网元的地址，向所述授权功能网元发送所述授权请求消息。

40.根据权利要求34至39所述的方法，其特征在于，所述方法还包括：

所述CCF接收来自所述API调用者的第一请求消息，所述第一请求消息用于请求获取调用所述目标API的权限，所述第一请求消息包括所述API调用者的标识和所述目标API的标识；

所述CCF向所述API调用者发送第二令牌，所述第二令牌用于指示所述API调用者具有调用所述目标API的权限，所述第二令牌包括所述API调用者的标识和所述目标API的标识。

41.根据权利要求34至40中任一项所述的方法，其特征在于，所述方法还包括：

所述CCF接收来自AEF的第三请求消息，所述第三请求消息用于请求获取所述API调用者调用所述目标API的访问策略，所述访问策略用于指示是否允许所述API调用者调用所述目标API，所述第三请求消息包括所述API调用者的标识和所述目标API的标识；

所述CCF向所述AEF发送所述访问策略。

42.一种通信装置，其特征在于，包括：处理器，所述处理器与存储器耦合；所述处理器，用于执行所述存储器中存储的计算机程序，以使得所述装置执行如权利要求1至41中任一项所述的方法。

43.一种计算机可读存储介质，其特征在于，包括：所述计算机可读存储介质上存储有计算机程序，当所述计算机程序运行时，使得所述计算机执行如权利要求1至41中任一项所述的方法。