决定使用 REST API 安全性

信息安全 tls oauth 休息 授权 节点.js
2021-08-20 19:03:09

我开发了一个 API。我很困惑,我已经阅读了几天的文章。实际上我的问题与这些很接近,但并不准确(可能是它们的组合);
保护将从不同客户端访问
的 REST API 为极少数客户端提供安全的无登录 REST API

我需要为我的 API 提供安全性。API 将由客户端 3rd 方应用程序使用。我在下面附上了一个模式。

我该怎么办?

带有 SSL\TLS 的 HTTP-Basic、带有 SSL\TLS 的 HTTP-Digest、OAuth 2.0 或其他应该是什么?

图式

编辑(2015-03-25):
这部分被放弃了。查看下面的“编辑(2015-04-01)”

我决定实施 SSL + OAuth 2.0(资源所有者密码凭证授予)。如果您认为该场景不方便,请告知我。

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      v
      |    Resource Owner
     (A) Password Credentials
      |
      v
 +---------+                                  +---------------+
 |         |>--(B)---- Resource Owner ------->|               |
 |         |         Password Credentials     | Authorization |
 | Client  |                                  |     Server    |
 |         |<--(C)---- Access Token ---------<|               |
 |         |    (w/ Optional Refresh Token)   |               |
 +---------+                                  +---------------+

        Figure 5: Resource Owner Password Credentials Flow

图 5 所示的流程包括以下步骤:

(A) 资源所有者向客户端提供其用户名和密码。

(B) 客户端通过包含从资源所有者收到的凭据,从授权服务器的令牌端点请求访问令牌。发出请求时,客户端向授权服务器进行身份验证。

(C) 授权服务器对客户端进行身份验证并验证资源所有者凭据,如果有效,则颁发访问令牌。

编辑(2015-04-01):

我已经实现了 OAuth 2.0 Client Credentials现在我正在寻找如何为客户端 API 请求实现 SSL 证书。

客户端凭证授权类型必须仅由机密客户端使用。

 +---------+                                  +---------------+
 |         |                                  |               |
 |         |>--(A)- Client Authentication --->| Authorization |
 | Client  |                                  |     Server    |
 |         |<--(B)---- Access Token ---------<|               |
 |         |                                  |               |
 +---------+                                  +---------------+

                 Figure 6: Client Credentials Flow

图 6 所示的流程包括以下步骤:

(A) 客户端向授权服务器进行身份验证,并从令牌端点请求访问令牌。

(B) 授权服务器对客户端进行身份验证,如果有效,则颁发访问令牌。

2个回答

关于您概述的选项,我想说的是,带有 SSL 的 HTTP Auth 是一个更简单但不太灵活的选项,而 Oauth2 更复杂,但在您可以实现的目标方面具有更大的灵活性。

一个示例,正如您在 ASCII 艺术图中所指出的,使用 OAuth2 可以创建一个令牌,该令牌可用于代替密码来验证请求。这可能比 HTTP Basic/Digest 更具优势,因为这意味着您不必在客户端存储用户密码,只需存储令牌即可。

所以一般来说,如果你能很好地实现 OAuth2,我会说去吧......

如果 OAuth 2.0 令牌被泄露,您只需关心令牌的 TTL。

如果 HTTP 基本身份验证标头遭到破坏,则凭据不会过期。您将需要手动更改您的 client_id 和 secret,如果您甚至知道或认为它们已被盗用的话。您可能每次都需要更改客户端代码以适应这种情况。

这两个选项之间的主要区别在于 OAuth 2.0 令牌铸造涉及交换 client_id 和 secret 的 1 个关键步骤。在 HTTP Basic Auth 中,每个 API 调用都涉及相同的交换。

从这个角度来看,OAuth 2.0 是一个更安全的选择。