HTTP基本认证而不是TLS客户端认证

Question

下面的答案来自这个问题。

授予的答案实际上并没有解决所有问题。它仅在数据传输的上下文中提及SSL，实际上并未涵盖身份验证。

您真的在问有关安全认证REST API客户端的问题。除非您使用TLS客户端身份验证，否则单独使用SSL并不是REST
API可行的身份验证机制。没有客户端身份验证的SSL仅对服务器进行身份验证，这与大多数REST API无关。

如果您不使用TLS客户端身份验证，则需要使用基于摘要的身份验证方案（例如Amazon Web Service的自定义方案）或OAuth甚至HTTP
Basic身份验证（但仅通过SSL）。

因此，考虑到我将 在不使用 客户 端认证的情况下 使用 HTTPS， 我的问题是发帖人说，如果我们不使用 客户端SSL认证
服务器，则实际上并不知道与谁交谈。我在这里了解的是，如果我使用身份验证令牌来访问以对服务器进行客户端身份验证。然后，服务器不知道谁在发送令牌， 即使
该令牌与我的服务器数据库中的用户ID配对 也是 如此。

首先

1-这是一个真正的问题吗？如果我特别使用Https？（不使用TLS客户端身份验证）

2-最重要的是，假设这是一个重要的安全漏洞；如海报所述，Http基本身份验证如何提供帮助？Http基本身份验证仅在标头中发送编码的用户名密码。因此，当客户收到令牌（
在发送用户名密码后作为回报）时 ，对于其余请求，他将在此标头中使用此令牌代替密码，突然之间一切都好了吗？

Still Server不知道请求来自何处，也许服务器在其数据库中具有与匹配用户的有效令牌，但不知道是谁真正 发送了请求
。（尽管我仍然很难看到令牌会被https窃取并被其他人使用！）

每当我提出这个主题时，我都会得到答复。“好吧。您发送了令牌，但是服务器不知道是谁发送了令牌，不是很安全”，所以我理解这一点，因为浏览器保留了某种身份验证证书，服务器知道了哪里请求来自正确的位置，然后我可以确定与该令牌配对的用户（从我的数据库中检查过）“确实正确”

也许这里所说的不正确

Answer 1

[海报]说如果我们不使用客户端SSL认证服务器，则它并不真正知道与谁交谈。

那不是我说的:)这就是我说的：

除非您使用TLS客户端身份验证，否则单独使用SSL并不是REST API可行的身份验证机制。

单单 是这里的关键词。也：

如果您不使用TLS客户端身份验证，则需要使用基于摘要的身份验证方案（例如Amazon Web Service的自定义方案）或OAuth甚至HTTP
Basic身份验证（但仅通过SSL）。

换句话说，TLS客户端认证是认证REST API客户端的 一种
方法。因为最初的SO问题是专门针对SSL的，所以我提到TLS客户端authc是唯一的“内置”身份验证形式，如果您仅依赖TLS。因此，如果您使用的是TLS，并且您未使用TLS客户端身份验证，则
必须 使用另一种身份验证形式对客户端进行身份验证。

有很多认证REST客户端的方法。TLS客户端身份验证只是其中之一（TLS的唯一“内置”身份验证，通常非常安全）。但是，TLS是一种 网络
级协议，大多数人认为TLS 太复杂，以至于许多最终用户无法配置。因此，大多数REST API产品都选择了易于使用的 应用程序
级别协议（例如HTTP），因为它对大多数人来说更易于使用（例如，仅设置HTTP标头）。

因此，如果要使用HTTP标头路由，则必须使用标头值来认证REST客户端。

在HTTP身份验证中，您有一个标头，Authorization及其值（标头名称很不幸，因为它通常用于身份验证，而不是经常用于访问控制（即授权））。的Authorization报头值是什么是由服务器使用以执行认证，并且它的三个令牌组成（通常）

1. HTTP身份验证方案名称，后跟
2. 空格（几乎总是空格），后跟
3. 方案特定的文本值。

一种常见的HTTP身份验证方案是该Basic方案，它非常…好…基本:)。特定于方案的文本值只是以下计算值：

String concatenated = username + ":" + raw_password;
String schemeSpecificTextValue = base_64_encode(concatenated.toCharArray());

因此，您可能会看到相应的标题如下：

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

服务器知道如何解析该值。它说：“嘿，我知道这个Basic方案，所以我要获取尾随的文本值，用base64 对其进行解码
，然后我将获得用户名和提交的密码。然后我可以查看这些值是否与我存储的值匹配。”

这本质上是Basic身份验证。由于此方案特别包含提交的以base64编码的 原始 密码，因此 除非 您使用TLS连接， 否则
它不被认为是安全的。TLS保证（主要是）窥探不会截获标头（例如，通过数据包检查）并查看密码是什么。这就是为什么除非通过TLS连接，否则 永远不要
使用HTTP Basic身份验证的原因。 始终 -即使在公司Intranet环境中。

当然，还有其他甚至更安全的HTTP身份验证方案。一个示例是使用基于摘要的身份验证的任何方案。

基于摘要身份验证方案更好，因为他们的方案文本值并 没有
包含在提交的密码。而是计算某些数据（通常是其他标头字段和值）的基于密码的哈希并将结果放入Authorization标头值中。服务器使用其本地存储的密码计算相同的基于密码的哈希。如果服务器的计算值与请求的标头值匹配，则服务器可以认为请求已通过身份验证。

这就是为什么这种技术更安全的原因：仅传输哈希，而不传输原始密码本身。这意味着即使在明文（非TLS）连接上也可以使用此技术对请求进行身份验证（但是，如果请求数据本身当然不敏感，则只希望这样做）。

一些基于摘要的身份验证方案：

• OAuth 1.0a，又名RFC 5849。
• HTTP摘要访问身份验证（由浏览器本地使用）。
• Stormpath的自定义方案（完整披露，我是Stormpath的CTO）。
• Amazon AWS的自定义方案。

与OAuth 1.0a相比，Stormpath和Amazon的REST安全性更高，因为它们 始终 对请求实体有效负载进行身份验证。OAuth
1.0a仅针对application/x-www-form- urlencoded与使用application/xml或application/json有效负载的REST
API不相关的内容（如今看来是大多数REST API）执行此操作。

有趣的是，OAuth2 不是 基于摘要的-它使用了我认为不太安全的东西，称为“承载者令牌”，我认为这是OAuth 2
各种问题的征兆。

最后，是的，这是一个无耻的插件，但是如果您不想担心这些东西，只需使用Stormpath（许多用例都是免费的）。我们会自动执行这些操作，因此您的应用程序不必这样做。