HTTP基本认证，而不是TLS客户端认证
下面的答案来自这个问题。
获奖答案实际上并没有解决这个问题。 它仅在数据传输的上下文中提到SSL，实际上并不包含身份验证。
您确实在询问有关安全认证REST API客户端的问题。 除非您使用TLS客户端身份验证，否则SSL本身不适用于REST API的可行身份验证机制。 没有客户端身份验证的SSL仅对服务器进行身份验证，这与大多数REST API无关。
如果您不使用TLS客户端身份验证，则需要使用类似基于摘要的身份验证方案（如Amazon Web Service的自定义方案）或OAuth甚至HTTP基本身份验证（但仅限于SSL）。
所以考虑我会使用HTTPS没有客户端认证我的问题在这里是海报说，如果我们不使用客户端SSL认证服务器并不真正知道与谁交谈。 我在这里理解的是，如果我使用身份验证令牌进行访问，以根据服务器对客户端进行身份验证。 然后服务器不知道谁发送令牌， 即使该令牌与我的服务器数据库中的用户ID配对。
首先
1 - 这是一个真正的问题？ 如果我特别使用Https？（不使用TLS客户端身份验证）
2-最重要的是，假设这是一个重要的安全缺陷; Http基本认证如何在这里提供海报帮助？ Http基本身份验证只是在头中发送编码的用户名密码。 所以当客户收到一个令牌时（ 在发送他的用户名密码后返回），那么对于其余的请求，他将在这个头中使用这个令牌而不是密码，并且突然间一切都好？
Still Server不知道请求来自哪里，可能服务器有一个有效的令牌，在其数据库中有一个匹配的用户，但是不知道谁是真正发送它的。 （虽然我仍然很难看到这个令牌会被https盗用并被其他人使用！）
每当我提出这个问题时，我会得到答复..“呃..你发送一个令牌，但服务器不知道谁发送的令牌，不是很安全”，所以我明白这一点，因为浏览器保持一种认证，服务器知道在哪里请求来自正确的地方，那么我可以确定带有该标记的配对用户（从我的数据库中检查）是“真正正确的”
或者，也许这里讲的是不正确的
[海报]说，如果我们不使用客户端SSL认证服务器并不真正知道它与谁交谈。
这不是我所说的:)这就是我所说的：
除非您使用TLS客户端身份验证，否则SSL本身不适用于REST API的可行身份验证机制。
独自成为这里的关键词。 也：
如果您不使用TLS客户端身份验证，则需要使用类似基于摘要的身份验证方案（如Amazon Web Service的自定义方案）或OAuth甚至HTTP基本身份验证（但仅限于SSL）。
换句话说，TLS客户端身份验证是对REST API客户端进行身份验证的一种方式。 因为最初的SO问题是关于SSL的具体问题，所以我提到TLS客户端身份验证是唯一的“内置”身份验证形式，如果您仅依赖于TLS。 因此，如果您使用的是TLS，并且您没有使用TLS客户端身份验证，则必须使用其他形式的身份验证来验证您的客户端。
有很多方法可以对REST客户端进行身份验证。 TLS客户端认证只是其中的一个（TLS唯一的“内置”，通常非常安全）。 但是，TLS是网络级别的协议，大多数人认为对于许多最终用户来说配置过于复杂。 因此，大多数REST API产品都选择了一种更容易使用的应用程序级协议，如HTTP，因为它对大多数人来说都更容易使用（例如，只需设置HTTP标头）。
因此，如果您要使用HTTP标头路由，则必须使用标头值来验证REST客户端。
在HTTP认证中，你有一个头部， Authorization和它的值（头部名称是非常不幸的，因为它通常用于认证，而不是经常用于访问控制，也就是授权）。 Authorization标头值是服务器用来执行验证的值，它由（通常）三个标记组成
一个常见的HTTP认证方案是Basic方案，这是非常... ...基本:)。 特定于计划的文本值仅为以下计算值：
String concatenated = username + ":" + raw_password;
String schemeSpecificTextValue = base_64_encode(concatenated.toCharArray());
所以你可能会看到相应的标题如下所示：
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
服务器知道如何解析这个值。 它说：“嘿，我知道Basic计划，所以我将采取尾随的文本值，base64解码它，然后我会有用户名和提交的密码。然后，我可以看到这些值是否符合我的存储“。
这基本上是Basic认证。 由于此方案特别包含提交的原始密码base64编码，因此除非您使用TLS连接，否则它不被视为安全。 TLS保证（大部分）窥探者的眼睛不能拦截标题（例如通过数据包检查）并查看密码是什么。 这就是为什么你不应该使用HTTP基本认证，除非它是通过TLS连接。 始终 - 即使在公司内部网环境中。
当然还有其他更安全的HTTP身份验证方案。 一个示例是使用基于摘要的身份验证的任何方案。
基于摘要的身份验证方案更好，因为其方案文本值不包含提交的密码。 相反，计算某些数据（通常是其他标题字段和值）的基于密码的哈希值，并将结果放入Authorization标头值中。 服务器使用本地存储的密码计算相同的基于密码的哈希。 如果服务器的计算值与请求的标头值匹配，则服务器可以认为请求已通过验证。
这就是为什么这种技术更安全：只传输散列 - 而不是原始密码本身。 这意味着即使通过明文（非TLS）连接，也可以使用这种技术来验证请求（但如果请求数据本身并不敏感，那么您只需要这样做）。
一些基于摘要的认证方案：
对于REST，Stormpath和Amazon的安全性比OAuth 1.0a更高，因为它们始终验证请求实体的有效负载。 OAuth 1.0a仅对application/x-www-form-urlencoded内容执行此操作，这与使用application/xml或application/json有效内容（这些似乎是目前大多数REST API）的REST API无关。
有趣的是，OAuth2并非基于消化 - 它使用了我认为不太安全的东西，称为“持票人令牌”，这在我看来是OAuth 2的各种问题的症状。
最后，是的，这是一个无耻的插件，但如果你不想担心这个问题，只需使用Stormpath（许多用例都是免费的）。 我们自动化这些东西，所以你的应用程序不需要。
当我们谈论“验证用户”时，我们真正的意思是“检查用户知道别人应该知道的东西”。 这个“东西”可能是密码，证书，硬件安全令牌，甚至用户的视网膜模式，但是在所有情况下，我们真正检查的信息是访问，而不是用户的身份（无论是真的手段）本身。
重点在于，原则上，所有这些验证者都可能被盗取并用于冒充用户。 一个密码可以被记录下来，一张证书可以从存储在其上的磁盘复制，一个硬件令牌可能被盗（可能被反向设计和克隆），甚至用户的视网膜图案原则上可以被扫描，记录和伪造。 我们所能做的最好的就是在每种情况下尽可能地使这个“非常困难”。
也许我误解了这个问题。
您引用的答案对我说，如果您不使用某种形式的身份验证，无论是客户端证书，HTTP BASICAUTH还是其他内容，服务器都不知道与谁通信。
（也许这对您的应用程序没问题，也许不是，只有您可以回答。）
换句话说，如果你使用某种形式的认证，服务器确实知道它与谁进行通信; 它正在与经过身份验证的凭证所属的“人员”进行通信。
在这种情况下，身份验证是通过某些证书建立身份的过程。
身份验证不保证凭证未被盗用。 SSL保证（我不会说它“保证”）证书在客户端和服务器之间传输时是安全的。
当您使用GMail时，您使用的是SSL，Google如何知道它与您交谈？
链接地址: http://www.djcxy.com/p/71269.html上一篇: HTTP Basic Authentication instead of TLS client certification
下一篇: How should I format my REST API when dealing with different types of GET