[海报]说如果我们不使用客户端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报头值是什么是由服务器使用以执行认证，并且它的三个令牌组成（通常）
- HTTP身份验证方案名称，后跟
- 空格（几乎总是空格），后跟
- 方案特定的文本值。
一种常见的HTTP身份验证方案是该
Basic方案，它非常…好…基本:)。特定于方案的文本值只是以下计算值：
String concatenated = username + ":" + raw_password;String schemeSpecificTextValue = base_64_enpre(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-urlenpred与使用
application/xml或
application/json有效负载的REST
API不相关的内容（如今看来是大多数REST API）执行此操作。
有趣的是，OAuth2 不是 基于摘要的-它使用了我认为不太安全的东西，称为“承载者令牌”，我认为这是OAuth 2
各种问题的征兆。
最后，是的，这是一个无耻的插件，但是如果您不想担心这些东西，只需使用Stormpath（许多用例都是免费的）。我们会自动执行这些操作，因此您的应用程序不必这样做。
