25

我正在使用 Spring、Spring Security 编写一个 Web 应用程序（REST API）。现在我有基本身份验证和使用用户名、密码和角色的非常简单的授权。我想改进安全层，但我没有这方面的经验。

当我查看邮递员以获取可能的身份验证方法并在谷歌上搜索时，我看到有以下选项：

  • API 密钥
  • 不记名令牌
  • 基本认证
  • 摘要认证
  • OAuth 1.0
  • OAuth 2.0
  • 鹰认证
  • AWS 签名
  • NTLM 身份验证

Digest、Hawk、AWS 和 NTLM 似乎是非常具体的案例，所以我省略了它们。

我只听说过一些关于 API 密钥、Bearer Token 和 OAuth 1.0\2.0 的一般信息，但是 OAuth 1.0 似乎已经过时了（我的意思是，存在 2.0 版是有原因的）。

因此，我似乎有 3 种可能的变体：

  • API 密钥
  • 不记名令牌
  • OAuth 2.0

我的假设正确吗？现代 Web 应用程序中最广泛使用的安全层案例是什么？

我不要求每个案例的完整描述，只是一般性建议，也许是一些链接\资源来看看。

我应该专注于什么？

你看到我的描述\解释中有哪些错误？

4

2 回答 2

24

就 Web 应用程序而言，Web 应用程序请求应该具有状态，会话是最常见的具有状态的方式。

当我们认为REST API 的请求最好是无状态的时，但是要验证和识别用户或客户端，有很多方法可以作为 OP 提到的。

下面解释了 REST API 中一些最常见的身份验证方式

1.基本认证

在基本身份验证中，用户发送由 base64 编码器编码的凭据。
凭证在 Authorization 标头中发送，带有基本前缀，如下所示。
"Basic "+ encodeUsingBase64(username+":"+password)

如果您的 REST API 受基本身份验证保护，则不属于应用程序的用户（不存在于服务器数据库中的用户）无法访问受保护的资源。

理想情况下，基本身份验证仅适用于应用程序用户

2. JWT/不记名令牌

JSON Web 令牌 (JWT) 是一个开放标准 (RFC 7519)，其中服务器与客户端共享数字签名令牌，应用程序用户和非应用程序用户都可以使用它，服务器端逻辑从有效负载中提取用户信息令牌并使用它的数据库条目进行验证以进行授权。在这里，JWT 用例不受限制，某些实现负载也可以包含授权信息。单点登录是当今广泛使用 JWT 的一项功能。

与基本身份验证相比

  • 基本身份验证是一个身份验证步骤，其中将在每个请求中发送完整的凭据（包括密码）。

  • JWT 是一个后认证步骤，经过身份验证的用户会收到一个不包含密码信息的签名令牌。

3. API 密钥

它没有标准，它可能是随机生成的字符串发给 API 的用户。不同发行人的用例会有所不同。这里讨论得很好

4.Oauth2.0

Oauth2 是一个不同的类别。总而言之，它不是保护所有应用程序 API ，而是提供user resource对.third party applicationsconsent of user

它主要有4个部分。让我们以 Facebook 为例
1. 授权服务器 [Facebook]
2. 资源服务器 [Facebook 和资源将成为您的个人资料]
3. 客户端 [堆栈溢出、Quora、Candy Crush、Subway Surfer 等]
4. 资源所有者 [您（如果经过身份验证） )]

资源服务器可能由安全和不安全的 API 组成。访问安全 API 的客户端需要授权服务器颁发的 access_token。发出的 access_token 是一个随机字符串，也与关联的用户 scope( read, read_profile_info, write) 一起存储在授权服务器数据库中。

read此处资源所有者（您）同意授权服务器将范围（ ，read-profile等）的 access_token 授予post-to-my-timeline客户端（Quora，，StackOverflow等Candy-Crush）

oauth2.0的优势
  1. 收到的 access_token 将同时具有身份验证和授权。因此，为 access_token 提供特定范围会很有帮助。
    （比如堆栈溢出访问基本的个人资料信息，糖果粉碎访问更多信息，包括代表您发布的范围）
  2. access_token 的生命周期， refresh_token 的 grant_type。
    访问令牌的生命周期有限。如果客户端应用程序需要在单个访问令牌的生命周期之外访问资源，它可以获得刷新令牌。刷新令牌允许客户端应用程序获取新的访问令牌。
    授权类型：（授权码、隐式、密码、客户端凭据、刷新令牌）
笔记：

Oauth2 Auth 服务器不仅适用于 facebook 和 Google 等应用程序，而且您的应用程序可以设置 oauth2 服务器，并且您可以根据订阅/许可为您的客户提供不同范围的 access_token（将您的 API 与其应用程序集成）。

5.摘要认证

我还没有研究过摘要认证。有关更多详细信息，请参阅此线程

传输层安全要点

SSL

上述任何身份验证都与传输层安全性 (SSL) 有关，以确保您在后续请求中传递的凭据/令牌不会被捕获为纯文本。

X.509（优于 SSL）

SSL 证书由服务器发送给客户端。（任何向服务器发出请求的客户端都会收到 SSL 副本。没有限制，任何客户端都可以接收 SSL 证书）。

但在 X.509 客户端证书的情况下，使用服务器 SSL 证书创建，并与客户端秘密共享。客户端使用 X.509 证书与服务器通信。这里需要注意的一点是，对于不同的客户端，将生成不同的客户端证书来识别每个客户端。X.509 确保的是

  • 安全性（没有客户端证书的人无法访问 API）

  • 身份（服务器可以根据证书主题识别客户端）

于 2019-10-16T01:43:42.990 回答
2

基本和摘要式身份验证

在每个请求中，登录凭据将与请求标头一起发送。在基本身份验证中，用户名和密码（登录凭据）未加密。摘要式身份验证使用加密密码。因此digest Authentication比

基本认证

用户名和密码使用“:”符号（“username:password”）连接，在此字符串使用 base64 编码并与请求标头一起发送之后。这种方法易于实现，速度更快，并且被所有浏览器支持。问题是 base64 不是一种加密方法，因此这种方法的安全性很差，有人可以轻松获得登录凭据。

摘要式身份验证

散列密码与标头中的随机值一起发送。Nonce 值是服务器生成的随机值。此方法比基本身份验证方法更安全。此外，容易受到中间人的攻击。由于无法使用 bcrypt，因此服务器上的密码不那么可靠。

基于会话的身份验证

每个请求都不需要用户提供用户名或密码。凭据验证后，服务器创建一个会话并存储在内存中。此外，将会话 ID 返回给浏览器，浏览器将会话 ID 存储为 cookie。

基于令牌的身份验证

此方法不使用 cookie，而是使用令牌对用户进行身份验证。令牌不必保存在服务器中。JSON Web Token (JWT) 是使用最广泛的令牌。JWT 包含三个部分。标头、有效负载和签名。根据令牌在客户端计算机上的保存方式，存在不同的攻击。此外，代币不可撤销。只能在过期前使用。

OAuth 和 OpenID

这是一种单点登录身份验证形式。用户可以使用来自社交网络的现有详细信息，而不是专门为网站创建帐户，并且此方法使用基于会话的身份验证。主要优点是比其他方法的安全性，但这取决于另一个第三方应用程序。没有您设置的 OpenID 提供商帐户的用户将无法使用您的应用程序。

于 2021-05-27T08:13:55.357 回答