用于认证应用程序接口(API)调用者的方法和系统与流程

本公开涉及蜂窝通信领域，并且更具体地，涉及使用通用应用程序接口框架(capif)认证应用程序接口(api)调用者(invoker)。

背景技术：

为了满足第四代(4g)通信系统商业化后增加的无线数据业务需求，已经努力开发改进的第五代(5g)通信系统或准5g通信系统。为此，5g通信系统或准5g通信系统被称为超4g网络通信系统或后lte系统。

为了实现高数据传输速率，正在考虑在毫米波频带(例如，60ghz频带)中实施5g通信系统。在5g通信系统中，讨论了诸如波束形成、大规模mimo、全维mimo(fd-mimo)、阵列天线、模拟波束形成和大规模天线的技术，以减轻毫米波频带中的传播路径损耗并增加传播传输距离。

此外，已经开发了诸如演进小小区、高级小小区、云无线电接入网络(云ran)、超密集网络、设备到设备通信(d2d)、无线回程、移动网络、协作通信、协调多点(comp)和干扰消除的技术来改进5g通信系统中的系统网络。

此外，5g系统已经开发了诸如混合fsk和qam调制(fqam)和滑动窗口叠加编码(swsc)的高级编码调制(acm)方案，以及诸如滤波器组多载波(fbmc)、非正交多址(noma)和稀疏码多址(scma)的高级接入技术。

技术实现要素：

技术问题

目前，通用应用程序接口(api)框架(capif)接口(capif-1、capif-1e、capif-2和capif-2e)的安全方面和相应的安全信息流是开放的。因此，需要各种安全方法来支持多于一种认证方法和安全接口建立方法/过程，因为capif将支持具有不同体系结构和性能要求的大量服务。鉴于上述问题，需要一种用于认证api调用者的系统和方法。

解决方案

各种实施例提供了一种用于使用通用应用程序接口框架(capif)来认证api调用者的系统和方法。

此外，各种实施例提供了一种系统和方法，用于在从至少一个api调用者接收到在capif-2e接口上访问至少一个服务api的连接请求时，由capif核心功能(ccf)通过capif-1e接口与至少一个api调用者建立安全连接。

此外，各种实施例提供了一种系统和方法，用于由ccf确定至少一种安全方法，该至少一种安全方法将由至少一个api调用者用于至少一个api调用者的capif-2e接口安全(c2eis)，以在capif-2e接口上访问至少一个服务api。

此外，各种实施例提供了一种系统和方法，用于基于所确定的至少一种安全方法为至少一个api调用者启用c2eis。

因此，本文的实施例提供了一种用于使用通用应用程序接口框架(capif)来认证应用程序接口(api)调用者的方法和系统。该方法包括在接收到来自至少一个api调用者的在capif-2e接口上访问至少一个服务api的连接请求时，由capif核心功能(ccf)与至少一个api调用者建立安全连接，其中，建立ccf和至少一个api调用者之间的安全连接是基于通过capif-1e接口的ccf和至少一个api调用者之间的相互认证的。此外，该方法包括：由ccf确定至少一种安全方法，该至少一种安全方法将由至少一个api调用者用于至少一个api调用者的capif-2e接口安全(c2eis)，用于在capif-2e接口上访问至少一个服务api，其中，该至少一种安全方法包括传输层安全-预共享密钥(tls-psk)、tls-公钥基础设施(tls-pki)、互联网密钥交换版本2(ikev2)、互联网协议安全(ipsec)和oauth2.0中的至少一个。该方法还包括由api暴露功能(aef)基于所确定的至少一种安全方法为至少一个api调用者启用c2eis。c2eis包括认证、接口保护和授权中的至少一个。

在实施例中，由ccf基于所述api调用者订阅的服务的类型、aef和api调用者之间的接口类型、所需的安全tls会话的长度、访问场景、api调用者的能力、aef的能力、api调用者的偏好以及至少一个api调用者和ccf之间的协商中的至少一个，确定该至少一种安全方法，并向api调用者指示该至少一种安全方法。在实施例中，还由ccf向aef指示所确定的至少一种安全方法，无论是经请求的还是未经请求的，以在capif-2e接口上执行所确定的安全方法。

在实施例中，由aef基于所确定的至少一种安全方法为至少一个api调用者启用c2eis，包括:如果所确定的至少一种安全方法是tls-psk，则使用从ccf接收的预共享密钥(psk)，通过capif-2e接口与至少一个api调用者建立安全传输层安全(tls)连接，其中，psk是在通过capif-1e接口在ccf和至少一个api调用者之间建立安全tls连接之后，由至少一个api调用者和ccf中的至少一个导出的。此外，通过capif-3接口从ccf接收至少一个api调用者的授权权利。此外，基于从ccf接收的至少一个api调用者的授权权利，授权至少一个api调用者访问至少一个服务api。

在实施例中，由aef基于所确定的至少一种安全方法为至少一个api调用者启用c2eis，包括：如果所确定的至少一种安全方法是tls-pki，则使用基于客户端和服务器证书的相互认证通过capif-2e接口建立与至少一个api调用者的安全tls连接。此外，通过capif-3接口从ccf接收至少一个api调用者的授权权利。此外，基于从ccf接收的至少一个api调用者的授权权利，授权至少一个api调用者访问至少一个服务api。

在实施例中，由aef基于所确定的至少一种安全方法为至少一个api调用者启用c2eis，包括：如果所确定的至少一种安全方法是oauth(开放授权:基于令牌的认证和授权)，则使用基于证书的相互认证通过capif-2e接口建立与至少一个api调用者的安全tls连接。此外，从至少一个api调用者接收服务api访问请求以及访问令牌，其中，访问令牌是在通过capif-1e接口在ccf和至少一个api调用者之间建立安全tls连接之后，在从至少一个api调用者接收到基于oauth的访问令牌请求时由ccf生成的。此外，基于从至少一个api调用者接收的访问令牌，授权至少一个api调用者访问至少一个服务api。

在实施例中，由aef基于所确定的至少一种安全方法为至少一个api调用者启用c2eis，包括：如果所确定的至少一种安全方法是oauth2.0，则使用基于服务器证书的认证通过capif-2e接口建立与至少一个api调用者的安全tls连接。此外，从至少一个api调用者接收服务api访问请求以及访问令牌，其中，访问令牌是在通过capif-1e接口在ccf和至少一个api调用者之间建立安全tls连接之后，在从至少一个api调用者接收到基于oauth2.0的访问令牌请求时由ccf生成的。此外，基于从至少一个api调用者接收的访问令牌，授权至少一个api调用者访问至少一个服务api。

因此，本文的实施例提供了一种用于使用通用应用程序接口框架(capif)来认证应用程序接口(api)调用者的系统。该系统包括：capif核心功能(ccf)，被配置成在接收到来自至少一个api调用者的在capif-2e接口上访问至少一个服务api的连接请求时，建立与至少一个api调用者的安全连接，其中，建立ccf和至少一个api调用者之间的安全连接是基于通过capif-1e接口的ccf和至少一个api调用者之间的相互认证的。此外，ccf被配置成：确定至少一种安全方法，该至少一种安全方法将由至少一个api调用者用于至少一个api调用者的c2eis，用于在capif-2e接口上访问至少一个服务api，其中该至少一种安全方法包括传输层安全-预共享密钥(tls-psk)、tls-公钥基础设施(tls-pki)、互联网密钥交换版本2(ikev2)、互联网协议安全(ipsec)、应用层保护、本地授权机制和oauth2.0中的至少一个。此外，该系统包括：api暴露功能(aef)，被配置成基于所确定的至少一种安全方法为至少一个api调用者启用c2eis。在实施例中，至少一种安全方法是基于api调用者订阅的服务的类型、aef和api调用者之间的接口细节、访问场景、所需的安全传输层安全(tls)会话的长度、api调用者的能力、aef的能力、api调用者的偏好以及至少一个api调用者和ccf之间的协商中的至少一个来确定的。

当结合以下描述和附图考虑时，本文的示例实施例的这些和其他方面将被更好地领会和理解。然而，应当理解，以下描述虽然指示了示例性实施例及其许多特有细节，但是是通过说明而非限制的方式给出的。在不脱离本文的示例实施例的精神的情况下，可以在示例性实施例的范围内进行许多改变和修改，并且本文的示例性实施例包括所有这样的修改。

本公开的效果不限于上述效果。此外，根据以下描述，可以清楚地理解本公开的技术特征所预期的潜在效果。

在进行下面的详细描述之前，阐述贯穿本专利文档使用的某些词语和短语的定义可能是有利的:术语“包括”和“包含”以及其派生词，意味着包括但不限制；术语“或”是包含性的，意味着和/或；短语“与……相关联”和“与之相关联”及其派生词可以意味着包括、包括在……内、与……互连、包含、包含在……内、连接到……或与……连接、耦合到……或与……耦合、与……可通信、与……合作、交错、并置、靠近、结合到……或与……结合、具有……、具有……的属性等；并且术语“控制器”意味着控制至少一个操作的任何设备、系统或其部分，这样的设备可以用硬件、固件或软件或者它们中的至少两个的某种组合来实施。应该注意，与任何特定控制器相关联的功能可以是集中式的或者分布式的，无论在本地还是远程地。

而且，如下所述的各种功能可以通过一个或多个计算机程序来实施或者由一个或多个计算机程序支持，所述计算机程序中的每一个由计算机可读程序代码形成并且具体实现在计算机可读介质中。术语“应用”和“程序”是指被适配以便以合适的计算机可读程序代码来实施的一个或多个计算机程序、软件组件、指令集、程序、功能、对象、类、实例、相关数据、或者它们的一部分。短语“计算机可读程序代码”包括任何类型的计算机代码，包括源代码、目标代码、和可执行代码。短语“计算机可读介质”包括能够被计算机访问的任何类型的介质，诸如只读存储器(rom)、随机存取存储器(ram)、硬盘驱动器、光盘(cd)、数字视频盘(dvd)、或者任何其它类型的存储器。“非瞬时性”计算机可读介质排除传输瞬时性电信号或者其它信号的有线的、无线的、光学的、或者其它的通信链路。非瞬时性计算机可读介质包括数据能够在其中能够永久地存储的介质以及数据能够在其中被存储并稍后被重写的介质，诸如可再写光盘或者可擦存储器设备。

遍及本专利文档提供了某些词语和短语的定义。本领域普通技术人员将理解，在许多实例中，即使不是在大多数实例中，这样的定义适用于这样定义的词语和短语的先前的使用以及将来的使用。

附图说明

这里的实施例在附图中示出，遍及附图，相似的附图标记指示各附图中的对应部分。从参考附图的以下描述，将更好地理解本文的实施例，在附图中:

图1示出了根据本文公开的实施例的系统图，该系统图示出了用于认证和授权api调用者的通用应用程序接口框架(capif)功能安全机制；

图2示出了根据本文公开的实施例的序列图，该序列图示出了用于使用预共享密钥(psk)通过capif-1e、capif-2e和capif-3参考点认证和授权api调用者的安全信道建立；

图3示出了根据本文公开的实施例的序列图，该序列图示出了用于使用基于证书的相互认证通过capif-2e和capif-3参考点认证和授权api调用者的安全信道建立；

图4示出了根据本文公开的实施例的序列图，该序列图示出了用于使用基于oauth的访问令牌通过capif-1e和capif-2e参考点认证和授权api调用者的安全信道建立；

图5示出了根据本文公开的实施例的序列图，该序列图示出了在服务api调用之前，用于在api调用者和api暴露功能(aef)之间的认证的过程流程；

图6示出了根据本文公开的实施例的序列图，该序列图示出了非ccf(基于第三方的)认证过程；

图7示出了根据本文公开的实施例的序列图，该序列图示出了由ccf确定用于aef对api调用者的认证和授权以及用于它们之间的安全通信的机制的场景；

图8示出了根据本文公开的实施例的序列图，该序列图示出了api调用者使用由ccf确定和指示的传输层安全预共享密钥(tls-psk)方法调用北向(northbound)api/服务api；和

图9示出了根据本文公开的实施例的序列图，该序列图示出了api调用者使用由ccf确定和指示的访问令牌方法调用北向api/服务api。

具体实施方式

本文的示例性实施例及其各种特征和有利的细节参考附图中示出的和以下描述中详细描述的非限制性实施例来更全面地解释。省略了对众所周知的组件和处理技术的描述，以免不必要地模糊本文的实施例。本文的描述仅仅旨在帮助理解本文的示例性实施例可以被实践的方式，并且进一步使本领域技术人员能够实践本文的示例性实施例。因此，本公开不应被解释为限制本文的示例实施例的范围。本领域技术人员将理解，本公开的原理可以在任何适当布置的系统或设备中实施。

在下文中，将参考附图描述各种实施例。然而，应该理解的是，并不打算将本公开限制于本文公开的特定形式；相反，本公开应被解释为覆盖实施例的各种修改、等同物和/或替代物。在描述附图时，相似的附图标记可以用来表示相似的构成元件。

如本文使用的，表述“具有”、“可以具有”、“包括”或“可以包括”是指存在对应的特征(例如，数字、功能、操作或构成元件(诸如组件))，并且不排除一个或多个附加特征。

在本公开中，表述“a或b”、“a或/和b中的至少一个”或“a或/和b中的一个或多个”可以包括所列项目的所有可能组合。例如，表述“a或b”、“a和b中的至少一个”或“a或b中的至少一个”可以包括(1)至少一个a，(2)至少一个b，或(3)至少一个a和至少一个b两者。

在各种实施例中使用的表述“第一”、“第二”、“所述第一”或“所述第二”可以修饰各种组件，而不管其顺序和/或重要性，但不限制对应的组件。例如，第一用户设备和第二用户设备指示不同的用户设备，尽管它们都是用户设备。例如，第一元件可以被称为第二元件，并且类似地，第二元件可以被称为第一元件，而不脱离本公开的范围。

应该理解，当元件(例如，第一元件)被称为(可操作地或可通信地)“连接”或“耦合”到另一个元件(例如，第二元件)时，它可以直接连接或直接耦合到另一个元件，或者任何其他元件(例如，第三元件)可以插入它们之间。相反，可以理解，当元件(例如，第一元件)被称为“直接连接”或“直接耦合”到另一个元件(第二元件)时，没有元件(例如，第三元件)插入它们之间。

如本文所用，表述“被配置成”可以与表述“适合”、“具有…的能力”、“被设计成”、“适配于”、“制造成”或“能够”可互换地使用。术语“被配置成”可能不一定意味着以硬件“专门设计为”。可替换地，在一些情况下，表述“被配置成…的设备”可以意味着该设备与其他设备或组件一起“能够…”。例如，短语“适配于(或配置成)执行a、b和c的处理器”可以意味着仅用于执行对应操作的专用处理器(例如，嵌入式处理器)，或者可以通过运行存储在存储器设备中的一个或多个软件程序来执行对应操作的通用处理器(例如，中央处理单元(cpu)或应用处理器(ap))。

在本公开中使用的术语仅仅用来描述特有实施例，并且并不旨在限制本公开。单数表述可以包括复数表述，除非它们在上下文中绝对不同。除非另外定义，否则本文使用的所有术语(包括技术术语和科学术语)具有与本公开所属领域的技术人员通常理解的含义相同的含义。如一般使用的词典中定义的那些术语的术语可以被解释为具有等同于相关技术领域中的上下文含义的含义，并且将不被解释为具有理想的或者过于正式的含义，除非在本公开中清楚地定义。在一些情况下，即使在本公开中定义的术语也不应被解释为排除实施例。

本文的实施例实现了一种用于使用通用应用程序接口框架(capif)来认证应用程序接口(api)调用者的方法和系统。该方法包括在从至少一个api调用者接收到在capif-2e接口上访问至少一个服务api的连接请求时，由capif核心功能(ccf)建立与至少一个api调用者的安全连接，其中，建立ccf和至少一个api调用者之间的安全连接是基于通过capif-1e接口的ccf和至少一个api调用者之间的相互认证的。此外，该方法包括由ccf确定和指示至少一种安全方法，该至少一种安全方法将由至少一个api调用者用于至少一个api调用者的c2eis(即，认证、接口保护和授权)，用于在capif-2e接口上访问至少一个服务api，其中该至少一种安全方法包括传输层安全-预共享密钥(transportlayerssecurity-pre-sharedkey,tls-psk)、tls-公钥基础设施(tls-publickeyinfrastructure,tls-pki)、ikev2、ipsec和oauth中的至少一个。该方法还包括由api暴露功能(aef)基于所确定的至少一种安全方法为至少一个api调用者启用c2eis。现在参考附图，并且更具体地参考图1至图9，示出了示例性实施例，其中，贯穿附图相似的附图标记一致地表示对应的特征。

图1示出了根据本文公开的实施例的系统100图，该系统100图示出了用于认证、保护接口和授权api调用者102的capif功能安全机制。

系统100包括一个或多个api调用者102、104、capif核心功能(ccf)106、应用程序接口暴露功能(aef)108、api发布功能110和api管理功能112。在实施例中，一个或多个api调用者102、104可以是计算机、膝上型电脑、移动电话、个人数字助理(pad)和服务器或试图访问aef108以获得一个或多个服务api的任何其他设备中的至少一个，但不限于此。在实施例中，一个或多个api调用者可以被配置成调用网络上存在的一个或多个服务api。ccf106是功能实体，其可以被配置成累积服务api的所有通用方面。ccf106可以被配置用于认证、监视、日志记录授权、发现，这对所有服务api是通用的。aef108是可以被配置用于将一个或多个服务api暴露给api调用者(即，102和104)的实体。api调用者102可以具有与aef108的直接连接，以调用服务api。然而，api调用者102可能不具有与api发布功能110和api管理功能112的直接连接。api发布功能110可以被配置成在ccf106上发布服务api的库。此外，api管理功能112可以被配置成管理与日志记录的管理和存储在ccf106中的日志的审计相关的功能。

在实施例中，存在于公共陆地移动网络(plmn)信任域中的api调用者104被运营商信任，并且存在于plmn信任域之外的api调用者102可能不被运营商信任。被运营商信任的api调用者104可以不经受任何安全检查。然而，存在于plmn信任域之外的api调用者102可能经受更高级别的安全检查。

此外，系统100包括一个或多个接口/参考点。一个或多个接口包括capif-1、capif-1e、capif-2、capif-2e、capif-3、capif-4和capif-5接口。这些接口在第三代合作伙伴计划(3gpp)ts23.222标准中定义，以及capif功能在3gppts23.222标准中定义。capif-1、capif-2、capif-3、capif-4和capif-5接口存在于公共陆地移动网络(plmn)信任域内，而capif-1e和capif-2e接口存在于ccf106和api调用者102之间以及aef108接入点和api调用者102之间，所述api调用者102存在于plmn信任域之外。capif-1、capif-2、capif-3、capif-4和capif-5接口的安全支持传输层安全(tls)，如在3gppts23.222标准中定义。

存在于plmn信任域内和plmn信任域之外的api调用者(即102、104)两者都需要认证和授权。为了认证和授权存在于plmn信任域之外的api调用者102，ccf106必须与aef108协作，并利用capif-1e、capif-2e和capif-3接口以打通(onboard)来在授予(grant)对capif服务/服务api的访问之前对api调用者102进行认证和授权。当api调用者104在plmn信任域内时，与aef108协作的ccf106可以在授予对capif服务的访问之前，经由capif-1、capif-2和capif-3接口来执行对api调用者104的认证和授权。

capif-1/1-e在api调用者102和ccf106之间。此外，系统100基于api调用者102的身份和凭证或者呈现有效的安全令牌来认证api调用者102。api调用者和ccf之间存在相互认证。此外，在访问一个或多个服务api之前，系统100为api调用者提供授权。对于在api调用者102和aef108之间的capif-2/2e，系统100基于api调用者102的身份和凭证或者呈现有效的安全令牌(oauth)来认证api调用者102。此外，在访问服务api之前，系统100为api调用者102提供授权。此外，在访问服务api时，存在对api调用者的授权和验证。此外，系统100基于plmn运营商配置的策略来控制服务api访问。capif-1e和capif-2e是参考点，其中api调用者102位于plmn信任域之外。

本文的实施例提供了一种用于使用capif认证api调用者的方法和系统100，该方法包括在从至少一个api调用者102接收到在capif-2e接口上访问至少一个服务api的连接请求时，由ccf106建立与至少一个api调用者102的安全连接。在ccf106和至少一个api调用者102之间建立的安全连接是基于通过capif-1e接口的ccf104和至少一个api调用者102之间的相互认证的。此外，该方法包括由ccf106确定至少一种安全方法，该至少一种安全方法将由至少一个api调用者102用于至少一个api调用者102的c2eis(即，认证、接口保护和授权)，以在capif-2e接口上访问至少一个服务api。该至少一种安全方法包括传输层安全-预共享密钥(tls-psk)、tls-公钥基础设施(tls-pki)、互联网密钥交换版本2(internetkeyexchangeversion2,ikev2)、互联网协议安全(ipsec)、应用层保护、本地授权机制和oauth中的至少一种。此外，该方法包括由aef108基于所确定的至少一种安全方法为至少一个api调用者102启用c2eis。在实施例中，至少一种安全方法是基于api调用者102订阅的服务类型、aef108和api调用者102之间的类型接口、访问场景、所需的安全传输层安全(tls)会话的长度、api调用者102的能力、aef108的能力、api调用者102的偏好以及至少一个api调用者102和ccf106之间的协商中的至少一个来确定的。在实施例中，无论是经请求的还是未经请求的，ccf106都向aef108指示所确定的至少一种安全方法，以在capif-2e接口上执行所确定的安全方法。

在实施例中，由aef108基于所确定的至少一种安全方法为至少一个api调用者102启用c2eis，包括:如果所确定的至少一种安全方法是tls-psk，则使用从ccf106接收的psk，通过capif-2e接口在aef108和至少一个api调用者102之间建立安全tls连接，其中，在通过capif-1e接口在ccf106和至少一个api调用者102之间建立安全tls连接之后，由至少一个api调用者102和ccf106中的至少一个导出psk。此外，通过capif-3接口从ccf接收至少一个api调用者的授权权利。此外，基于从ccf106接收到的至少一个api调用者102的授权权利，授权至少一个api调用者102访问至少一个服务api。

在实施例中，api调用者102发现/识别以直接联系aef108以获取服务api，然后api调用者102直接发起与aef108的认证。然后，将在api调用者102和aef108之间执行基于客户端和服务器证书的相互认证，以在ccf106的帮助下建立安全tls连接。这里，api调用者102由ccf106或者在服务发现期间预先配置或提供(provision)，并且获得特定服务api所需的信息。这里，假设所确定的用于服务的安全方法和相关的有效安全凭证对于api调用者102是可用的，则需要直接与aef108做出请求，而无需联系ccf106。此外，aef108可以不依赖于ccf来认证api调用者(例如，如果认证api调用者102的根证书106是预先提供的/可用于aef108)。在api调用者102和aef108之间在capif-2e上成功建立了安全tls连接之后。aef108通过capif-3参考点从ccf106请求api调用者102的授权权利。此外，ccf106通过capif-3用api调用者102的授权权利进行响应。此外，在通过capif-2e接口建立安全tls连接时，api调用者102调用适用的3gpp北向api/服务api。此外，aef108基于api调用者102的授权权利给予api调用。

在实施例中，由aef108基于所确定的至少一种安全方法为至少一个api调用者启用c2eis，包括：如果所确定的至少一种安全方法是tls-pki，则使用基于客户端和服务器证书的相互认证通过capif-2e接口建立与至少一个api调用者102的安全tls连接。此外，通过capif-3接口从ccf106接收至少一个api调用者102的授权权利。此外，基于从ccf106接收到的至少一个api调用者102的授权权利，授权至少一个api调用者102访问至少一个服务api。

在实施例中，由aef108基于所确定的至少一种安全方法为至少一个api调用者102启用c2eis，包括：如果所确定的至少一种安全方法是oauth，则使用基于证书的相互认证和基于服务器侧证书的认证中的至少一种，通过capif-2e接口在aef108和至少一个api调用者102之间建立安全tls连接。此外，从至少一个api调用者102接收服务api访问请求以及访问令牌，其中，访问令牌是在通过capif-1e接口在ccf106和至少一个api调用者102之间建立安全tls连接之后，在从至少一个api调用者102接收到基于oauth的访问令牌请求时由ccf106生成的。此外，基于从至少一个api调用者102接收的访问令牌，授权至少一个api调用者102访问至少一个服务api。

在实施例中，为capif提出的安全方面和相关信息流适用于其他参考点，如为机器类型通信定义的t8接口和为第五代(5g)系统定义的基于服务的体系结构。

图1示出了系统100的示例性单元，但是应当理解，其他实施例不限于此。在其他实施例中，系统100可以包括更少或更多数量的单元。此外，单元的标签或名称仅用于说明的目的，但是并不限制本文的实施例的范围。一个或多个单元可以被组合以在系统100中执行相同或基本相似的功能。

图2示出了根据本文公开的实施例的序列图，该序列图示出了用于使用psk通过capif-1e、capif-2e和capif-3参考点认证和授权api调用者102的安全信道建立。

根据图2，本文的实施例建立了用于认证api调用者102的专用安全连接/会话。可以使用两种不同的方法，诸如基于psk的方法和基于证书的方法，来建立api调用者102和aef108之间的专用安全连接。建立的专用安全会话可以用于所有的api调用和响应。为了建立专用安全会话，在ccf106和api调用者102之间通过capif-1e接口成功地相互认证之后，可以导出psk。此外，psk可以用于通过capif-2e接口在api调用者102和aef108之间建立安全连接(例如，tls或ipsec)。capif-1e安全机制可以用于“引导(bootstrap)”用于认证capif-2e的安全tls连接的密钥。在没有psk的情况下，可以使用在api调用者102和aef108之间的基于证书的相互认证来通过capif-2e接口建立安全tls会话。

图2示出了用于使用psk建立安全信道的在api调用者102、ccf106和aef108之间的高级安全信息流(针对访问场景:api调用者102在服务api调用之前访问aef108)。安全信息通过capif-1e、capif-2e和capif-3参考点进行交换，具体步骤如下。

在步骤1，该方法包括通过capif-1e接口在api调用者102和ccf106之间建立安全tls会话/连接。该方法允许api调用者102和ccf106通过capif-1e接口建立api调用者102和ccf106之间的安全tls会话/连接。可以基于api调用者102和ccf106之间的相互认证，在api调用者102和ccf106之间建立安全tls会话。相互认证可以是基于证书的相互认证(即，基于客户端(即，api调用者102)和服务器(即，ccf106)证书的相互认证)。

在步骤2，该方法包括通过capif-1e接口导出psk。该方法允许api调用者102和ccf106导出psk。在成功建立安全tls会话之后，可以基于tls会话的主密钥(mastersecret)、aef108的特有参数、会话参数和其他可能的参数来导出psk。在实施例中，在ccf106处的psk的导出可以被延迟，直到从aef108接收到对psk的请求。在实施例中，psk对于特定的aef108是特有的(psk绑定到aefid)。aefid至少在capif内是唯一的标识符。aefpsk＝kdf(tlssessionmaster_secret(会话主密钥)、tls会话参数、aefid、<其他潜在参数>)。kdf是密钥导出函数。aefpsk和psk术语在本文档中可互换使用。

在步骤3a，该方法包括发起与aef108的安全信道建立(tls-psk)请求。该方法允许api调用者102发起与aef108的tls-psk请求。在api调用者102处导出psk时，api调用者102发起与aef108的安全信道建立请求。在实施例中，在api调用者102和aef108之间建立安全tls连接之前，api调用者102可以随时导出psk。

在步骤3b，该方法包括通过capif-3参考点从ccf106请求从api调用者108导出的psk。该方法允许aef108通过capif-3参考点向ccf106请求从api调用者102导出的psk。

在步骤3c，该方法包括通过capif-3参考点从ccf106接收psk。该方法允许aef108通过capif-3参考点从ccf106接收psk。ccf106可以被配置成在接收到来自aef108的请求时，通过capif-3参考点用导出的psk进行响应。在实施例中，ccf106可以导出psk并在通知消息中将其发送到aef108，而无需来自aef108的任何请求(solicitation)。在这种情况下，可以省略图2所示的步骤3b和3c以减少时延。

在步骤3d，该方法包括使用psk在api调用者102和aef108之间建立安全tls连接。该方法允许aef108使用psk在api调用者102和aef108之间建立安全tls连接。在api调用者102和aef108之间的安全tls连接可以通过capif-2e接口建立。

在步骤4，该方法包括通过capif-3参考点从ccf106请求api调用者102的授权权利。该方法允许aef108通过capif-3参考点从ccf106请求api调用者102的授权权利。

在步骤5，该方法包括通过capif-3从ccf106接收api调用者102的授权权利。该方法允许aef108通过capif-3接口从ccf106接收api调用者102的授权权利。

在步骤6，该方法包括api调用者102通过安全的capif-2e接口用aef调用适用的3gpp北向api/服务api。

在步骤7，该方法包括基于从ccf106接收到的至少一个api调用者102的授权权利，授权至少一个api调用者102访问至少一个服务api。该方法允许aef108基于从ccf108接收到的至少一个api调用者102的授权权利，授权至少一个api调用者102访问至少一个服务api。aef108基于api调用者102的授权权利给予api调用。

图3示出了根据本文公开的实施例的序列图，该序列图示出了使用基于证书的相互认证通过capif-2e和capif-3参考点对api调用者102的认证和授权的安全信道建立。

本文的实施例允许通过capif-2e和capif-3参考点交换安全信息。

在步骤1a，api调用者102发现/识别以直接联系aef108以获取服务api，然后api调用者102直接发起与aef108的认证。此外，将在api调用者102和aef108之间执行基于客户端和服务器证书的相互认证，以在ccf106的帮助下建立安全tls连接(步骤1b)。在此场景下，api调用者由ccf106或者在服务发现期间预先配置或提供，并且获得特定服务api所需的信息。这里，api调用者102可以直接请求与aef的连接，而不需要联系ccf106(或者在联系ccf106之后)。在capif-2e上成功建立安全tls连接之后(即，在api调用者102和aef108之间)，aef108通过capif-3参考点从ccf106请求api调用者102的授权权利。此外，ccf106通过capif-3参考点用api调用者102的授权权利进行响应。此外，在通过capif-2e接口建立安全tls连接时，api调用者102调用适用的3gpp北向api/服务api。此外，aef108基于api调用者的授权权利给予api调用。

图4示出了根据本文公开的实施例的序列图，该序列图示出了使用基于oauth的访问令牌通过capif-1e和capif-2e参考点对api调用者102的认证和授权的安全信道建立。本文的实施例通过capif-1e接口建立安全信道。capif-2e参考点使用访问令牌来授权和给予对aef108的api调用者102的服务api调用。

图4示出了在api调用者102、ccf106和aef108之间的高级安全信息流。安全信息能够通过capif-1e、capif-2e和capif-3参考点进行交换。该方法基于oauth2.0授权框架。参照oauth2.0，ccf106映射到授权和令牌协议端点。此外，api调用者102映射到资源所有者、客户端和重定向端点，以及aef108映射到资源服务器。使用访问令牌通过capif-1e和capif-2e参考点对api调用者102的认证和授权的说明是基于假设:客户端端点类型被注册为机密，授权授予类型是客户端凭证，访问令牌是承载类型(rfc6750)并且基于jwt(jsonweb令牌)。

在步骤1，该方法包括由api调用者102和ccf108通过capif-1e接口基于基于证书的相互认证建立安全tls会话。该方法允许api调用者102和ccf106基于基于证书的相互认证来建立安全tls会话。

在步骤2，该方法包括使用https请求从ccf106请求访问令牌。该方法允许api调用者102使用https请求从ccf106请求访问令牌。在通过capif-1e成功建立安全tls会话之后，api调用者102使用https请求从ccf106请求访问令牌。https请求包含授予类型“client_credentials(客户端_凭证)”、范围(请求的权限集)、api调用者客户端标识符以及在向ccf106注册期间生成和共享的密钥。

在步骤3，该方法包括针对有效凭证、请求类型和所请求的范围，验证来自api调用者102的授予请求。该方法允许ccf106针对有效凭证、请求类型和所请求的范围，验证来自api调用者102的授予请求。

在步骤4，该方法包括生成访问令牌。该方法允许ccf106生成访问令牌。在由ccf106成功授予请求验证后，可以生成访问令牌。生成的访问令牌可以被编码为如在ietfrfc7519中定义的jsonweb令牌。访问令牌可以包括如在ietfrfc7515中定义的jsonweb数字签名简档。此外，访问令牌通过重定向统一资源标识符(uri)共享，其中uri是在向ccf106注册期间由api调用者102给定的。

在步骤5，该方法包括通过capif-2e接口基于服务器证书使用aef108端点的单向认证来建立与aef108的安全tls连接。该方法允许api调用者102通过capif-2e接口基于服务器证书使用aef108端点的单向认证来建立与aef108的安全tls连接。

在步骤6，该方法包括通过capif-2e接口向aef108发送对3gpp北向api/服务api的访问请求/调用以及访问令牌(对于访问场景:api调用者102在服务api调用时访问aef108)。该方法允许api调用者102通过capif-2e接口向aef108发送对3gpp北向api/服务api的访问请求/调用以及访问令牌。从ccf106接收的访问令牌可以与api调用请求一起发送。令牌作为“承载”属性值放在https请求(api调用)的“授权”报头下。

在步骤7，该方法包括基于作为访问令牌一部分的签名来证实访问令牌。该方法允许aef108基于作为访问令牌一部分的签名来证实访问令牌。有效的签名，根据访问令牌中的授权权限验证api调用者的请求。

在步骤7，在成功验证访问令牌和api调用者102的授权权利时，调用所请求的服务api，并将适当的结果作为响应发送给api调用者102。

在实施例中，各种因素和要求可以影响适当的安全方法(即，psk和oauth.2.0)的适用性。然而，业务要求需要可能是用于选择安全方法的常见因素，但是在决定安全方法时实施方式可以使用以下标准。

(即基于psk的)方法1的选择标准:该方法允许建立专用安全会话。由于(在会话开始期间进行授权)而建立了专用的安全tls会话，这可以用于多个api调用，避免对每个调用请求进行授权验证。可以基于以下标准/场景选择此方法:

1.如果安全tls信道会话需要活动达长的持续时间(如12小时或更长)，则api调用者102在一段时间内将这些会话用于api调用，而不为每个请求建立安全tls连接。

2.如果需要在短的持续时间内快速爆发api调用(如5分钟内500次调用)，则api调用者102可以使用此方法来建立与aef108的专用安全tls会话，并避免对每个调用请求进行授权验证。

3.如果api调用者102或capif-2e参考点或aef108有严格的要求，如要被最小化的消息交换的大小、最小化的功耗等。那么api调用者102可以选择此方法。

方法2(即oauth)的选择标准:该方法基于oauth2.0，并且提供了用于安全异步api调用请求和响应的框架。可以基于以下标准/场景选择此方法:

如果api调用是稀疏的，并且对安全会话的需求是短暂的，那么可以选择oauth2.0。

如果aef108上的可用资源不足以在认证之后维持安全tls会话，例如，由于网络负载或认证和授权功能作为单独的网络实体被卸载。那么可以选择oauth2.0。

安全方法(基于psk的或者oauth或者基于pki的等)可以基于访问场景、所请求的服务的特性和对所请求的服务的约束、接口细节(诸如ip地址/端口)、参考点的状态、实体的能力等来确定和选择。

图5示出了根据本文公开的实施例的序列图，该序列图示出了在服务api调用之前，在api调用者102和aef108之间的认证的过程流程。

本文的实施例允许api调用者102直接联系aef108，并与aef108进行认证(不需要与ccf106执行的先决条件)。如果已经执行了服务发现，则api调用者102请求ccf106提供根证书机构(ca)的(一个或多个)根证书，以验证api调用者102为后续api调用发现的aef108的(一个或多个)aef证书。ca可以由运营商托管，或者由运营商信任。可替换地，ccf106提供ca的(一个或多个)根证书的列表，以在服务发现时或授权时或在认证期间或作为独立/排他消息交换(请求-响应)，向api调用者102验证具有(已订阅的)对应aef108细节的(一个或多个)aef证书。

在实施例中，在服务发现过程期间，响应于api调用者102服务发现请求，由ccf106向api调用者102提供关于aef108的细节。aef108的细节包括安全参数(如，认证方法、用于验证aef证书的ca的根证书、令牌、安全证书(令牌)的寿命)和访问方法(基于capif(在服务请求之前用ccf认证)，使用tls-psk或tls-证书或基于访问令牌或tls-公钥加密)，基于第三方令牌)。在另一个实施例中，api调用者102可以在服务发现请求中包括其对认证方法的偏好(例如，基于服务请求的可预见频率)。在接收到来自api调用者102的请求时，ccf106考虑api调用者102的偏好和其他标准来决定认证方法。响应于该请求，ccf106向api调用者102指示所选择的认证方法。在实施例中，指示(选择的认证方法和参考点保护(接口安全))被包括在安全tls连接请求/协议中。

根据图5，在调用北向api/服务api之前，api调用者102向aef108认证。在这种场景下，可以使用基于安全psk的或基于证书的安全连接建立方法。基于psk的或基于证书的方法示出了用于api调用者102向aef108认证并建立tls会话以保护后续api调用的过程。

图6示出了根据本文公开的实施例的序列图，该序列图示出了非ccf(基于第三方的)认证过程。本文的实施例提供了非ccf(基于第三方的)认证过程，以保护api调用者102和aef108之间的接口。在此场景下，api调用者由ccf106或者在服务发现期间预先配置或提供，获得特定服务api所需的信息。此外，该请求需要在不联系ccf106的情况下(或者在联系ccf106之后)直接向aef108提出。

图7示出了根据本文公开的实施例的序列图，该序列图示出了由ccf确定用于aef108对api调用者102的认证和授权以及用于它们之间的安全通信的机制的场景。

在步骤1，api调用者102和ccf106使用基于客户端和服务器证书的相互认证建立例如tls的安全通信信道。

在步骤2，api调用者102发送安全方法请求至ccf106。至ccf106的请求包括api调用者id、aef108的细节，诸如服务细节、接口细节、北向api细节以及api调用者102的优选安全方法。

在步骤3，ccf106选择将由aef108用来认证和授权api调用者102的安全方法。该选择考虑了在步骤2中从api调用者102接收的信息。

在实施例中，ccf106为所有被请求的aef的每个被请求接口选择基于psk的、基于pki的、基于oauth2.0的、基于ikev2的、基于ipsec的、基于应用层安全的、基于类似这样的安全方法中的至少一种。

在实施例中，可以基于以下参数中的至少一个来决定认证方法:api调用者102订阅的服务的类型，接口细节(诸如，ip地址/端口)，aef108和api调用者102之间的协议，何时请求访问特定服务(何时订阅多个服务)，基于基于时间的场景(订阅的api)，基于对tls会话存活多长时间的需要，api调用者的能力，aef108的能力，基于来自api调用者102的请求(基于用户输入、使用时间、先前已知的请求数量)，特定方法由ccf106(每个aef或每个api调用者)选择，并指示给api调用者102。

在实施例中，由aef108对api调用者102进行安全通信、认证和授权的方法与aef108的服务api接口细节相关联，即，如果服务需要，托管在相同(或不同)aef108的两个或更多个api接口上的相同服务api可以具有对应于每个api接口的不同安全方法。当确定安全方法时，ccf106将这些信息考虑在内。

在步骤4，ccf106向api调用者102发送安全方法响应，指示每个aef108(或(一个或多个)aef的每个服务api接口)的所选择的安全方法、与所选择的安全方法相关的任何安全信息(例如，用于直接建立tls和/或ipsec和/或经由ikev2建立ipsec等的预共享密钥)。api调用者102将在与(一个或多个)aef108的随后通信建立中使用这个选择的安全方法。

图8示出了根据本文公开的实施例的序列图，该序列图示出了api调用者102使用由ccf106确定和指示的tls-psk方法调用北向api/服务api。

ccf106可以向api调用者102发送认证响应。此外，api调用者102向aef108发送具有认证的服务api调用请求。此外，获得用于认证的api调用者102信息。此外，aef基于psk识别验证和认证。此外，aef向api调用者102给出服务api调用响应。

图9示出了根据本文公开的实施例的序列图，该序列图示出了api调用者102使用由ccf106确定和指示的访问令牌方法调用北向api/服务api。

根据图9，ccf106基于来自api调用者102的认证请求向api调用者102共享认证响应。此外，api调用者102向aef-2108给出具有认证信息的服务api调用请求。此外，aef-2108可以被配置成接收用于认证的api调用者102信息。此外，aef-2108基于由api调用者102呈现的令牌来执行身份验证和认证，并且在api调用者102和aef108之间建立安全tls连接。此外，基于身份验证和认证，aef-2108提供服务api调用响应。

本文公开的实施例可以通过运行在至少一个硬件设备上并执行网络管理功能来控制元件的至少一个软件程序来实现。图1所示的元件可以是硬件设备或硬件设备和软件模块的组合中的至少一个。例如，本文公开的实施例可以在5g核心网络中的管理网络暴露功能(nef)的网络实体中实施，并且该网络实体可以被实施为包括收发器和处理器的服务器，该处理器被配置成处理公开的与nef相关的过程。

特有实施例的前述描述将如此充分地揭示本文实施例的一般性质，以至于其他人可以通过应用当前知识，在不脱离一般概念的情况下容易地修改和/或改编这样的特有实施例，因此，这样的改编和修改应该并且旨在被理解为在所公开的实施例的等同物的意义和范围内。应当理解，本文使用的措辞或术语是为了描述的目的，而不是为了限制。因此，尽管已经根据实施例描述了本文的实施例，但是本领域技术人员将认识到，本文的实施例可以以本文描述的实施例的精神和范围内的修改来实践。