8

我们正在构建一个只能从一组已知服务器访问的 REST API。我的问题是，如果没有任何基于浏览器的客户端直接访问，需要什么安全机制。

目前拥有：

  • 显然是通过 HTTPS
  • 启用 HTTP 身份验证，API 使用者有密钥和密码

是否有必要：

  • 创建一些更改密钥，例如md5(timestamp + token)为请求形成并在端点验证？
  • 使用 OAuth（2 腿身份验证）？
4

4 回答 4

2

没关系 - 是否来自浏览器。

是否有必要：

创建一些更改密钥，例如为请求形成并在端点验证的 md5(timestamp + token)？

使用 oauth（2 腿授权）？

使用 OAuth，它解决了这两个问题。OAuth 的使用很好，因为：

  • 你不是在重新发明轮子

  • 已经有很多依赖于技术堆栈的库和方法

您还可以使用 JWT 令牌在服务之间传递一些带有自定义声明的安全上下文。

作为参考，您可以查看不同的提供商如何解决问题。例如，Azure Active Directory 代表此目的流 https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-on-behalf-of-flow

在您的服务之间使用 OAuth2/OpenID Connect 不是强制性的，还有其他协议和替代方案，甚至是自定义的。一切都取决于哪些关系是服务，或者它们都处于完全信任的环境中。

您可以使用任何您喜欢的东西，但主要思想是不要在服务之间共享敏感信息，例如服务帐户凭据或用户凭据。

如果 REST API 安全是主要要求 - OAuth2/OpenID Connect 可能是最佳选择，如果您只需要以最简单的方式在完全信任环境中安全（在身份验证意义上）调用 - Kerberos，如果您需要它们之间的加密自定义隧道对于传输中的数据加密 - 其他选项，如 VPN。实现某些自定义是没有意义的，因为如果您有服务 A 和服务 B，并且希望确保它们之间的调用经过身份验证，那么为了避免耦合和共享敏感信息，您将始终需要一些中央服务 C 作为身份提供者. 因此，如果您从 tis pov 考虑，OAuth2/OIDC 并不过分

于 2012-08-26T18:14:25.900 回答
0

无论您的 API 使用者是 Web 浏览器还是您无法控制的服务器，都不会改变安全状况。

如果您使用的是 HTTPS 并且客户端已经拥有密钥/密码，那么不清楚任何其他机制可以防止哪种攻击。

无论如何，客户端的任何妥协都会暴露一切。

于 2012-08-26T17:58:08.383 回答
0

首先 - 用户代理（例如浏览器）是否参与呼叫很重要。

如果只有 S2S 调用，那么 1 路 SSL HTTPS（用于网络加密）和某种签名机制（SHA-256）应该足以保证您的安全。

但是，如果您在 api 响应中返回敏感信息，最好接受 2 路 ssl HTTPS 连接（以验证客户端）。

OAuth2 不会在服务器到服务器调用中添加任何值（在没有用户同意且没有任何用户代理存在的情况下发生）。

于 2021-04-22T12:53:40.640 回答
0

对于服务器之间的身份验证：

验证

已知服务器：

  • 使用带有X.509 客户端证书的TLS（带有相互身份验证的 TLS）。
  • 使用通用 CA（证书颁发机构）颁发客户端证书。这样，服务器只需要在信任库中拥有 CA 证书或公钥，并且可以为其他客户端/服务器颁发新的客户端证书，而无需更新信任库。

开放的服务器集：

  • 使用由中央机构颁发的API 密钥。服务器需要在每个请求上验证这些密钥（并且可能会在短时间内将密钥的哈希值与验证结果一起缓存）。

身份传播

  • 如果请求是在非技术用户的上下文中执行的，则使用JWT（或 SAML）进行用户主体和声明的身份传播（在安全代理/WAF/IAM 处授权，并发出由身份验证服务器签名的 JWT）。
  • 否则，用户主体是指技术用户，可以从客户端证书（X.509 DName）中提取或返回成功的身份验证响应（API 密钥案例）。
于 2021-04-22T13:16:58.313 回答