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

OAuth2有许多优点......

它有明确的流程和多种类型的拨款，可以用来满足不同的需求。

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

无论您的项目是否过度，只有您可以回答这个问题。很多人声称OAuth2是一个复杂的避风港，并且真的花了很多时间来尝试理解它。

我建议你不要依赖任何类型的自助安全模型，因为这是导致系统瘫痪的原因。 OAuth2库已被许多用户和公司进行了战斗测试。

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

所以，最重要的是，如果你想使用它，做你的研究，理解它然后实现它。

至于你的实际问题，是的，我已经建立了类似的系统，有很多用户，使用各种拨款，一切都运作良好。只要你花了足够的时间知道自己得到了什么，就没什么好害怕的......

Answer 2

我对这个答案的评价很低，所以我最好自己解释一下。

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

为什么不是Oauth2？

额外的啤酒花＆amp;与传统认证方案相比，额外的系统组件，
无论你做什么，使用其他编程语言的人可能没有与你正在使用的任何东西兼容的客户端库，people make money making oauth interoperable and simple
- 想一想：没有人赚钱，即基本身份验证“简单，与1000个提供商兼容，只是工作”（引用oauth.io），这是因为基本身份验证适用于每一个“提供者“和oauth2有点糟糕，复杂，不可互操作的框架 - 这就是为什么我们将基本身份验证称为”协议“的一部分，我们将oauth（1）称为协议，但我们将oauth2称为框架
想一想维护非交互式客户端的含义：
1. 整个群集中只有一个承载令牌，
2. 所以你需要一个分布式键值存储或数据库表来保存它
3. 您需要捕获承载者所具有的特定错误已过期，
4. 在这种情况下，您将需要无缝地请求再次承载并重试请求（不丢失请求）。
5. 这里的问题是，在繁忙的网站上这可能会开始发生在100多个线程上并行
6. 所以，你需要一个分布式锁定机制才能做到正确 - redis互斥是我选择的毒药有人用oauth api问候我
7. 那个+好运测试那块复杂的东西分布式竞争条件逻辑，当你挣扎回来做它（你好webmock）然后你仍然会不时得到随机的非确定性故障，因为并发之神遇到了VCR / webmock无法正常处理的某些条件组合
这个，或者只是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

其中：

authentication_id是一个固定字符串，用于描述正在使用的身份验证类型，

api_client_id是标识API客户端的公共信息（我假设API有多个客户端，或者某个时候它将有多个客户端） - API客户端ID是允许的您要将API客户端与API客户端secret
相匹配
nonce只是一个随机字符串

secret是一个只有您自己知道的随机字符串，客户端和客户端应将其视为密码（即不将其提交给版本控制）

digest是api_client_id + nonce + secret的SHA512十六进制/ base64摘要（您还可以添加连接HTTP正文，我会添加HTTP除非身体很大，否则身体 - 例如文件上传）

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

保护HTTP API

2 个答案:

为什么不是Oauth2？

该怎么做？