1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 角色
你是一个经验丰富的软件架构师。

# 背景
在引入开源API网关APISIX的前提下，需要对开放的API做统一鉴权，从接口调用安全方面考虑，项目决定使用API签名做认证。

# 问题
针对每次api调用都需要做签名认证的场景，以下两种方案哪个更合适？
方案一：在APISIX上直接扩展自定义插件做签名认证。
方案二：提供外部签名认证服务，使用forward-auth访问签名认证服务。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

对于API签名认证的实现，选择哪种方案取决于几个关键因素，包括但不限于系统的复杂度、性能要求、安全性需求以及团队的开发和运维能力。下面我将分析两种方案的优缺点，帮助你做出决策。

### 方案一：在APISIX上直接扩展自定义插件做签名认证

#### 优点：
- **集成紧密**：直接在APISIX中实现签名验证可以确保所有通过网关的请求都被一致地处理，无需额外的网络跳转。
- **性能**：由于签名验证是在请求到达目标服务之前完成的，这通常会比方案二更快，因为避免了额外的服务调用延迟。
- **简化部署与维护**：减少外部依赖，使得整个系统更加简洁，易于管理和维护。

#### 缺点：
- **开发与维护成本**：需要有熟悉APISIX插件开发的人员来实现和维护该功能。
- **可扩展性**：如果签名算法或鉴权逻辑变得复杂，可能需要更频繁地更新插件代码，这可能影响APISIX的稳定性。

### 方案二：提供外部签名认证服务，使用forward-auth访问签名认证服务

#### 优点：
- **独立性**：认证服务可以独立于APISIX进行升级和维护，不会直接影响到网关的运行。
- **灵活性**：更容易支持复杂的鉴权逻辑或与其他身份管理系统（如OAuth, SAML）集成。
- **可审计性**：可以更方便地记录和审计鉴权过程，因为鉴权服务可以专门设计用于日志记录和监控。

#### 缺点：
- **性能开销**：每次API调用都会增加一次网络往返时间，可能会导致响应时间变长。
- **系统复杂度**：需要管理额外的服务，增加了部署和运维的复杂度。

### 结论
如果你的系统对性能要求非常高，且希望保持APISIX配置的简单性，方案一可能更适合。然而，如果你预计鉴权逻辑会随着时间而演变，或者需要高度定制化的鉴权流程，方案二提供了更好的灵活性和可扩展性。

考虑到APISIX本身已经支持forward-auth插件，这为实现方案二提供了便利，降低了开发自定义插件的必要性。此外，如果团队对微服务架构和分布式系统的运维有足够经验，那么额外的复杂度可能不是主要障碍。

最后，建议先进行一个小规模的测试或概念验证（POC），以评估两种方案在实际环境中的表现，从而做出最终决策。