API AuthN/AuthZ和API网关

Question

我已经使用NGINX+在API级别实现了身份验证，现在我担心它背后的API是否仍然需要使用APIs或JWT进行身份验证？什么是最佳做法？

我的观点是，有人可能有意或无意地进入内部网络，然后使用那些大范围开放的API(不进行身份验证)。但是，另一方面，我有一个问题:在API网关级别上进行身份验证的目的是什么？

Answer 1

Authentication

在Nginx +配置中，您有如下所示

upstream servername{
   # IP where the upstream API is hosted
}
server {
  listen xxx;
  location /endpoint/{
     # authentication related settings
     ...
     proxy_pass # The IP defined in upstream block
  }
}

location块指定从定义的/endpoint/开始的对URL的任何请求都必须经过身份验证。身份验证成功后，Nginx将请求转发给后端服务器。

在API网关级别上进行身份验证的目的是什么？

API网关集中了对后端服务的外部访问，它提供了不需要深入了解内部领域的功能：

• 路由到不同版本的内部API (在Nginx中，它是由类似location ^~ /1.0/的东西设置的)
• 通过验证令牌进行身份验证(在Nginx中，如果使用JWT，则定义auth_jwt_key_file来告诉Nginx如何验证签名元素)
• 每个API客户端的API速率限制(在Nginx中，它由limit_req_zone和limit_req设置)
• 将令牌代理到API端点，而无需在API本身中实现令牌处理和身份验证过程。

Authorization

我担心它背后的API是否仍然需要使用API密钥或JWT进行身份验证？

API的内部访问是通过授权来管理的。API网关将身份验证步骤中的令牌转发到API端点，该令牌将有关请求者和客户的信息都作为声明(在客户机应用程序中记录人员的情况下)。

实现授权的最简单方法是创建内部策略配置，其中它指定客户端名称和允许的方法(例如identity: client1, permissions: PUT/GET)，因此API只是通过检查从API网关转发的令牌是否与策略匹配来验证用户访问。对于内部服务或内部用户，需要将它们添加到策略配置中，以便向特定的API端点发送请求。

另一种应用访问策略的方法是使用授权服务器。有关身份验证和授权工作流的详细信息，请参阅这里。

备注

(1) Nginx还支持使用map进行访问控制(例如显示这里)，以简化API端点的处理，但是仍然需要内部授权。

(2)您可能对其他API网关用例感兴趣，请看一下谷歌云和AWS。它们支持身份和访问管理(IAM)来控制对API的访问，它包括网关中的身份验证、授权和访问控制(AAA)。策略应用和执行过程与我在“内部策略配置”上描述的类似。