api身份验证_api上下文中的身份验证

api身份验证

APIs are becoming a main interface for interacting with many things, from enterprise services, public services offered over the internet to physical devices. As there can be a large number of APIs deployed within an organization and there can many consumers for those APIs, properly authenticating all parties involved in API based interactions is a major step of API security. This article looks at different authentication scenarios related to APIs and possible implementation approaches.

API正在成为与许多事物进行交互的主要接口，从企业服务，互联网提供的公共服务到物理设备。 由于组织内可能部署了许多API，并且这些API的使用方很多，因此正确验证基于API的交互中涉及的所有各方是API安全的重要步骤。 本文介绍了与API和可能的实现方法有关的不同身份验证方案。

First, let’s look at main entities involved in a simple API deployment (Figure 1). We have a set of services that need to be exposed as APIs. These services can be back end services deployed in on-premise data centers, service offered by a device or cloud services. Then we have client applications that need to consume services. These can be mobile applications, web applications, IoT devices, partner systems, etc. Some client applications will be used by human users (e.g. mobile apps and web apps) and some may not have an associated human user (e.g. IoT devices). API layer sits in between client applications and services, forming a proxy for all service requests. Details about organization’s users are stored in its identity provider (IDP). API layer uses IDP to authenticate users and access user information. IDP can be built into the API layer or can be an external IDP.

首先，让我们看一下简单API部署中涉及的主要实体(图1)。 我们有一组服务需要公开为API。 这些服务可以是部署在本地数据中心中的后端服务，由设备提供的服务或云服务。 然后，我们有需要使用服务的客户端应用程序。 这些可以是移动应用程序，Web应用程序，IoT设备，合作伙伴系统等。某些客户端应用程序将由人类用户使用(例如，移动应用程序和Web应用程序)，而某些客户端应用程序可能没有关联的人类用户(例如IoT设备)。 API层位于客户端应用程序和服务之间，形成所有服务请求的代理。 有关组织用户的详细信息存储在其身份提供程序(IDP)中。 API层使用IDP验证用户身份并访问用户信息。 IDP可以内置在API层中，也可以是外部IDP。

As human users, devices and systems access services via APIs, API layer can identify who is accessing services. Moving the authentication part to the API layer can also free up services from performing such tasks in most cases. Furthermore, API layer can provide a single authentication experience to all users by hiding possibly heterogeneous authentication mechanisms required for back end services.

当人类用户，设备和系统通过API访问服务时，API层可以识别谁在访问服务。 在大多数情况下，将身份验证部分移至API层还可以使服务免于执行此类任务。 此外，API层可以通过隐藏后端服务所需的异构身份验证机制为所有用户提供单一身份验证体验。

身份验证方案 (Authentication scenarios)

In the following sections, we examine different authentication scenarios related to APIs.

在以下各节中，我们研究与API相关的不同身份验证方案。

Scenario 1:

方案1：

Figure 2: API consumption by internal users

图2：内部用户使用的API

Assume that a company named HMart is developing a web portal for its employees to access company’s facilities (Figure 2). This web portal needs to invoke APIs of multiple systems such as HR system, building management system, parking slot allocation system, etc. In this scenario, the client application is HMart portal. Application users are HMart’s employees, whose details are stored in HMart IDP. Therefore, in this scenario, it is possible and useful to authenticate both the client application and users.

假设一家名为HMart的公司正在开发一个供其员工访问公司设施的Web门户(图2)。 该Web门户需要调用多个系统的API，例如HR系统，建筑物管理系统，停车位分配系统等。在这种情况下，客户端应用程序是HMart门户。 应用程序用户是HMart的员工，其详细信息存储在HMart IDP中。 因此，在这种情况下，对客户端应用程序和用户进行身份验证是可能且有用的。

Scenario 2:

方案2：

Figure 3: API consumption by external users

图3：外部用户使用的API

Assume that there is a partner company named DDStore, which has an online shopping app. HMart is a supplier of DDStore. DDStore’s shopping app needs to access HMart product catalog via an API (Figure 3). In this case, DDStore shopping app is used by its customers and this customer data is stored in a DDStore IDP. Usually, HMart only needs to know that DDStore shopping app is accessing its APIs, rather than knowing each customer who is using the shopping app. Furthermore, DDStore would not be willing to share its customer data with HMart. Therefore, in this scenario, it is sufficient to authenticate only the client applic