保护 HTTP API

Question

我需要保护一个面向公众的 HTTP API我无法在 API 服务器上接触代码。

HTTP API 有多个最终用户，他们将使用非交互式客户端（通常是后端服务）来使用它。需要明确的是，客户端拥有它将访问的资源，因此必须提供给用户，因为授权逻辑需要与最终用户绑定。

我正在考虑使用OAuth2 和Resource Owner Password Credentials Grant 然后使用提供的访问令牌获取JWT，客户端可以将其呈现给 HTTP 代理，该代理在将请求传递给 HTTP API 服务器之前对其进行解析。

这是我设想的流程：

 +----------+                                  +---------------+
 |          |>--(A)---- Resource Owner ------->|               |
 |          |         Password Credentials     | Authorization |
 | Client   |                                  |     Server    |
 |          |<--(B)---- Access Token ---------<|               |
 |          |    (w/Refresh Token)             |---------------|
 |          |                                  |               |
 |          |>—-(C)---- Request JWT ——-------->| JWT Service   |
 |          |         (w/Access Token)         |               |
 |          |                                  |               |
 |          |<--(D)---- JWT ------------------<|               |
 |          |                                  |               |
 +----------+                                  +---------------+
       v
       |
       |
       |                                       +---------------+
       |                                       |               |
       |                                       |     HTTP      |
       --(E)---- HTTP Request w/JWT ---------->|     Proxy     |
                                               |               |
                                               |      (F)      | 
                                               |               |
                                               +---------------+
                                                       v
                                                       |
                                                      (G)
                                                       |
                                                       v 
                                               +---------------+
                                               |               |
                                               |     HTTP      |
                                               |      API      |
                                               |               |
                                               +---------------+
 
 (A), (B), (C) Get an access token using the Password Grant flow.
 (D) Use access token to get a JWT.
 (E) Attach JWT to HTTP request and send it to the HTTP Proxy.
 (F) Check that JWT is valid.
 (G) Pass request to the HTTP API Server.    
 

有没有其他人解决过类似的用例并愿意提供一些启示或进行讨论？

Answer 1

我对这个答案投了反对票，所以我最好解释一下自己。

我不是建议“只编写自己的安全库”的人，但我确实对 oauth+api 客户端（尤其是 oauth2）例外。

为什么不用 Oauth2？

1. 与传统身份验证方案相比，额外的跃点和额外的系统组件，
2. 很有可能无论你做什么，使用其他编程语言的人可能没有与你正在使用的任何东西兼容的客户端库，people make money making oauth interoperable and simple
   • 想一想：没有人赚钱，即基本身份验证“简单，兼容 1000 多个提供商并且正常工作”（引用 oauth.io），这是因为基本身份验证只适用于每个“ provider”，而 oauth2 有点糟糕、复杂、不可互操作的框架——这就是为什么我们称基本身份验证为“协议”的一部分，我们称 oauth(1) 为协议，但我们将 oauth2 称为 框架
3. 想想维护非交互式客户端的含义：
   1. 您在整个集群中只有一个不记名令牌，
   2. 因此您将需要一个分布式键值对存储或数据库表来保存它
   3. 您需要捕获特定错误，这意味着承载有 过期了，
   4. 在这种情况下，您需要无缝地请求 再次承载并重试请求（不会丢失请求）。
   5. 这里的问题是，在繁忙的站点上，这可能会在 在 100 个线程上并行
   6. 因此，您需要一个分布式锁定机制来正确执行此操作 - Redis 互斥锁是我在以下情况下的首选毒药 有人用 oauth api 向我打招呼
   7. 那个 + 祝你测试那个复杂的部分好运 分布式竞争条件逻辑，以及当你打破你的背去做 它（嗨 webmock）然后你仍然不时遇到随机的非确定性故障，因为并发之神遇到了 VCR/webmock 不能很好处理的一些条件组合
4. 这个，或者只是 SHA512 一个秘密以及一个 nonce 和 HTTP 正文

According to the lead author of the Oauth2 project:（我的重点）

所有在邮件列表、会议中、在 特别设计委员会，并在后台渠道导致 规范未能实现其两个主要目标 — 安全和 互操作性。事实上，妥协之一是重命名它 从一个协议到一个框架，另一个添加免责声明 警告该规范不像产生可互操作的 实现。

与 OAuth 1.0 相比，2.0 规范更加复杂， 互操作性较差、有用性较差、不完整且大多数 重要的是，不太安全。

需要明确的是，OAuth 2.0 掌握在具有深度的开发人员手中 对网络安全的理解可能会导致安全 执行。然而，在大多数开发者手中 —  近两年的经验 — 2.0 可能会产生 不安全的实现。

...

在现实世界中，Facebook 仍然在一年后的第 12 轮草案中运行 半年前，完全没有理由更新他们的 执行。毕竟，一个更新的 2.0 客户端可以使用 Facebook 的实施不太可能与其他任何人一起使用 提供者，反之亦然。 OAuth 2.0 几乎没有提供任何代码 可重用性。

2.0 提供的是授权协议的蓝图。作为 定义，它在很大程度上是无用的，必须将配置文件放入工作 解决方案 —— 这就是企业之道。 WS-* 方式。 2.0提供 销售咨询服务和集成的全新前沿 解决方案。

该怎么做？

除非您要创建更大的生态系统，否则 Oauth 通常是矫枉过正。

更简单的解决方案是 DIY，将a custom authorization header 定义为：

authentication_id api_client_id nonce digest

即

FooApp-SHA512-fixed 4iuz43i43uz chc42n8chn823 fshi4z73h438f4h34h348h3f4834h7384

地点：

1. authentication_id 是一个固定字符串，描述了正在使用的认证类型，
2. api_client_id 是标识 API 客户端的公共信息（我假设 API 有超过 1 个客户端，或者在某个时候它将有超过 1 个客户端） - API 客户端 ID 允许您匹配 API客户端与 API 客户端的secret
3. nonce 只是一个随机字符串
4. secret 是一个只有您和客户端知道的随机字符串，客户端应将其视为密码（即不要将其提交给版本控制）
5. digest 是 api_client_id + nonce + secret 的 SHA512 hex/base64 摘要（您也可以添加连接 HTTP 正文，除非正文很大，否则我会添加 HTTP 正文 - 例如使用文件上传）

如果客户端通过身份验证，只需将请求转发到后端 API 服务并将其响应返回给客户端，否则会呈现错误。

Answer 2

OAuth2 有很多优点...

它有一个清晰的流程和多种类型的资助，可以用来满足不同的需求。

另一个优点是有一些库可以处理 OAuth2 的复杂性，例如 Identity Server：https://identityserver.github.io/Documentation/

无论这对您的项目是否矫枉过正，只有您才能回答这个问题。许多声称 OAuth2 很复杂的人并没有真正花足够的时间来理解它。

我建议您不要依赖任何类型的自建安全模型，因为这是导致系统崩溃的原因。 OAuth2 库已经过大量用户和公司的实战测试。

很多提供 api 的公司都是通过 OAuth2 实现的。

因此，归根结底，如果您确实想使用它，请进行研究，了解它然后实施它。

至于您的实际问题，是的，我已经构建了具有大量用户的类似系统，使用了各种赠款，一切都运行良好。只要您花足够的时间了解自己的所作所为，就没有什么好害怕的……