如何在RESTful客户机-服务器架构中处理身份验证是一个有争议的问题。

通常，在SOA over HTTP世界中，可以通过以下方式实现：

HTTPS上的HTTP基本身份验证；Cookie和会话管理；HTTP报头中的令牌（例如OAuth 2.0+JWT）；使用其他签名参数查询身份验证。

您将不得不调整，甚至更好地混合这些技术，以最好地匹配您的软件架构。

每个身份验证方案都有自己的PRO和CON，这取决于您的安全策略和软件架构的目的。

HTTPS上的HTTP基本身份验证

大多数web服务都使用基于标准HTTPS协议的第一个解决方案。

GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

它很容易实现，默认情况下在所有浏览器上都可以使用，但也有一些已知的缺点，比如浏览器上显示的糟糕的身份验证窗口，它将持续存在（这里没有类似LogOut的功能）、服务器端的额外CPU消耗、，以及用户名和密码（通过HTTPS）传输到服务器的事实（在键盘输入期间，只让密码留在客户端，并作为安全散列存储在服务器上，应该更安全）。

我们可以使用摘要式身份验证，但它也需要HTTPS，因为它容易受到MiM或Replay攻击，并且是HTTP特有的。

通过Cookie进行会话

老实说，在服务器上管理的会话并不是真正无状态的。

一种可能是维护cookie内容中的所有数据。而且，根据设计，cookie是在服务器端处理的（事实上，客户端甚至不尝试解释cookie数据：它只是在每次连续请求时将其返回给服务器）。但是这个cookie数据是应用程序状态数据，所以客户端应该在一个纯无状态的世界中管理它，而不是服务器。

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

cookie技术本身是HTTP链接的，因此它不是真正的RESTful，应该是独立于协议的，IMHO。它容易受到MiM或Replay攻击。

通过令牌（OAuth2）授予

另一种方法是在HTTP标头中放置令牌，以便对请求进行身份验证。例如，OAuth 2.0就是这样做的。请参阅RFC 6749：

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

简而言之，这与cookie非常相似，并存在相同的问题：不是无状态的，依赖于HTTP传输细节，并且存在许多安全漏洞，包括MiM和Replay，因此只能通过HTTPS使用。通常，JWT用作令牌。

查询身份验证

查询身份验证包括通过URI上的一些附加参数对每个RESTful请求进行签名。请参阅本参考文章。

在本文中定义如下：

所有REST查询都必须通过签名查询参数进行身份验证按小写字母顺序使用专用凭据排序作为签名令牌。签名应在URL编码查询字符串。

这种技术可能与无状态体系结构更为兼容，也可以通过轻会话管理（使用内存会话而不是DB持久性）来实现。

例如，这里有一个来自上面链接的通用URI示例：

GET /object?apiKey=Qwerty2010

应按如下方式发送：

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

要签名的字符串是/object？apikey＝Qwerty2010&timestamp＝1261496500，签名是使用API密钥的私有组件的该字符串的SHA256哈希。

服务器端数据缓存始终可用。例如，在我们的框架中，我们在SQL级别而不是URI级别缓存响应。因此，添加此额外参数不会破坏缓存机制。

有关基于JSON和REST的客户机服务器ORM/SOA/MVC框架中RESTful身份验证的一些详细信息，请参阅本文。由于我们不仅允许通过HTTP/1.1进行通信，而且还允许通过命名管道或GDI消息（本地）进行通信，因此我们尝试实现真正的RESTful身份认证模式，而不依赖HTTP特定性（如标头或cookie）。

稍后注意：在URI中添加签名可能被视为不好的做法（例如，因为它会出现在http服务器日志中），因此必须进行缓解，例如通过适当的TTL来避免重播。但如果你的http日志被破坏，你肯定会有更大的安全问题。

在实践中，即将推出的OAuth 2.0 MAC令牌认证可能是对“令牌授权”当前方案的巨大改进。但这仍然是一项正在进行的工作，与HTTP传输有关。

结论

值得总结的是，REST不仅是基于HTTP的，即使在实践中，它也主要通过HTTP实现。REST可以使用其他通信层。因此，RESTful身份验证不仅仅是HTTP身份验证的同义词，无论谷歌如何回答。它甚至根本不应该使用HTTP机制，而是应该从通信层抽象出来。如果您使用HTTP通信，由于Let's Encrypt倡议，没有理由不使用适当的HTTPS，这是除了任何身份验证方案之外所必需的。

关于这个话题，这里的好心人已经说得够多了。但这是我的2美分。

有两种交互模式：

人对机器（HTM）机器对机器（MTM）

机器是共同的分母，表示为RESTAPI，参与者/客户端要么是人，要么是机器。

现在，在真正的RESTful架构中，无状态的概念意味着所有相关的应用程序状态（意味着客户端状态）都必须随每个请求一起提供。通过相关，这意味着RESTAPI处理请求和提供适当响应所需的一切。

当我们在人对机器应用程序的上下文中考虑这一点时，正如Skrebel在上面指出的那样，“基于浏览器”，这意味着在浏览器中运行的（web）应用程序将需要将其状态和相关信息及其向后端REST API发出的每个请求一起发送。

考虑一下：您有一个数据/信息平台公开的RESTAPI资产。也许您有一个自助BI平台来处理所有数据立方体。但您希望您的（人类）客户通过（1）web应用程序、（2）移动应用程序和（3）某些第三方应用程序访问此应用程序。最后，即使是MTM链也会导致HTM-right。因此，人类用户仍然处于信息链的顶端。

在前两个案例中，您有一个人机交互的案例，信息实际上是由人类用户使用的。在最后一种情况下，您有一个使用RESTAPI的机器程序。

身份验证的概念适用于所有领域。您将如何设计它，以便以统一、安全的方式访问REST API？在我看来，有两种方式：

途径1：

首先，没有登录。每个请求都执行登录客户端发送其标识参数+特定请求每个请求的参数REST API接收它们，转身，ping用户存储（无论是什么）并确认授权如果建立了身份验证，则为请求提供服务；否则，拒绝具有适当的HTTP状态代码对所有REST API中的每个请求重复上述步骤目录

路线-2：

客户端以身份验证请求开始登录REST API将处理所有此类请求它接受auth参数（API密钥、uid/pwd或任何您select），并根据用户存储（LDAP、AD或MySQL DB等）验证身份验证如果已验证，则创建一个身份验证令牌并将其交还给客户/呼叫方然后，调用者将此身份验证令牌+请求特定参数与对其他业务REST API的每个后续请求，直到注销或租约到期

显然，在Way-2中，RESTAPI需要一种方法来识别和信任令牌的有效性。Login API执行了身份验证，因此，目录中的其他REST API需要信任“代客密钥”。

当然，这意味着需要在RESTAPI之间存储和共享身份验证密钥/令牌。这个共享的、可信的令牌存储库可以是本地/联合的，允许其他组织的REST API相互信任。

但我跑题了。

关键是，需要维护和共享一个“状态”（关于客户端的身份验证状态），以便所有RESTAPI都能创建一个信任圈。如果我们不这样做，即Way-1，我们必须接受必须对任何/所有传入的请求执行身份验证。

执行身份验证是一个资源密集型过程。想象一下，针对每个传入的请求，对用户存储执行SQL查询，以检查uid/pwd匹配。或者，加密并执行哈希匹配（AWS风格）。在架构上，我怀疑每个RESTAPI都需要使用一个通用的后端登录服务来执行此操作。因为，如果你不这样做，那么你就会到处乱扔授权码。一团糟。

所以层数越多，延迟就越大。

现在，选择Way-1并向HTM申请。您的（人类）用户真的关心您是否必须在每个请求中发送uid/pwd/hash或其他内容吗？不，只要你不打扰她，每秒都会抛出auth/login页面。如果你这样做的话，祝你有客户。所以，你要做的是将登录信息存储在客户端的某个位置，在浏览器中，一开始就存储，并随每个请求一起发送。对于（人类）用户，她已经登录，并且“会话”可用。但事实上，她的每一个请求都经过了认证。

与路线2相同。你的（人类）用户永远不会注意到。所以没有造成伤害。

如果我们将Way-1应用于MTM怎么办？在这种情况下，由于它是一台机器，我们可以要求它在每次请求时都提交身份验证信息，从而让这个家伙见鬼去。没人在乎！在MTM上执行Way-2不会引起任何特殊反应；这是一台该死的机器。它可以不在乎！

所以，问题是什么适合你的需要。无国籍需要付出代价。付出代价，继续前进。如果你想成为一个纯粹主义者，那么也要为此付出代价，然后继续前进。

最终，哲学无关紧要。真正重要的是信息发现、展示和消费体验。如果人们喜欢你的API，你就做好了自己的工作。

我怀疑那些热情高喊“HTTP认证”的人是否曾尝试过用REST制作基于浏览器的应用程序（而不是机器对机器的web服务）（无意冒犯-我只是认为他们从未面临过复杂的问题）。

我在RESTful服务上使用HTTP身份验证时发现的问题是：

用户通常会收到一个难看的浏览器制作的登录框，这对用户非常不友好。您不能添加密码检索、帮助框等。注销或以其他名称登录是一个问题-浏览器将一直向站点发送身份验证信息，直到您关闭窗口超时很困难

这里有一篇非常有见地的文章，逐点解决了这些问题，但这导致了许多特定于浏览器的javascript黑客、变通方法等。因此，它也不向前兼容，因此在发布新浏览器时需要不断维护。我不认为这是一个干净清晰的设计，而且我觉得这是一项额外的工作，很头疼，因为这样我才能热情地向朋友展示我的REST徽章。

我认为饼干是解决方案。但是等等，饼干是邪恶的，不是吗？不，他们不是，饼干经常被使用的方式是邪恶的。cookie本身只是一条客户端信息，就像您浏览时浏览器会跟踪的HTTP身份验证信息一样。这段客户端信息在每次请求时都会被发送到服务器，就像HTTP身份验证信息一样。从概念上讲，唯一的区别是，这段客户端状态的内容可以由服务器作为其响应的一部分来确定。

通过使用以下规则使会话成为RESTful资源：

会话将密钥映射到用户id（可能还有超时的最后一个操作时间戳）如果会话存在，则意味着密钥有效。登录意味着发布到/会话，新密钥设置为cookie注销意味着删除/会话/｛key｝（要记住，我们是一个浏览器，HTML5还有很长的路要走）通过在每次请求时将密钥作为cookie发送并检查会话是否存在和有效来完成身份验证

现在，与HTTP身份验证的唯一区别是，身份验证密钥由服务器生成，并发送给客户端，客户端继续发送该密钥，而不是客户端根据输入的凭据计算该密钥。

converter42补充道，当使用https（我们应该这样做）时，cookie必须设置其安全标志，这样身份验证信息就不会通过非安全连接发送。说得好，我自己都没看到。

我觉得这是一个足够好的解决方案，但我必须承认，我还不够安全专家来识别这个方案中的潜在漏洞-我所知道的是，数百个非RESTful web应用程序使用基本相同的登录协议（PHP中的$_SESSION，Java EE中的HttpSession等），就像接受语言可以用于访问翻译资源等。我觉得这是一样的，但也许其他人不是这样？你们觉得呢，伙计们？

首先也是最重要的，RESTful web服务是无状态的（或者换句话说，无会话的）。因此，RESTful服务没有也不应该包含会话或cookie的概念。在RESTful服务中进行身份验证或授权的方法是使用RFC 2616 HTTP规范中定义的HTTP授权头。每个请求都应该包含HTTP授权头，并且请求应该通过HTTPs（SSL）连接发送。这是在HTTPRESTful web服务中进行身份验证和验证请求授权的正确方法。我已经为Cisco Systems的Cisco PRIME Performance Manager应用程序实现了RESTful web服务。作为web服务的一部分，我还实现了身份验证/授权。

使用公钥基础结构（其中密钥的注册涉及适当的绑定）可确保公钥以确保不可抵赖的方式绑定到分配给其的个人

看见http://en.wikipedia.org/wiki/Public_key_infrastructure . 如果您遵循正确的PKI标准，可以识别并锁定不正确使用被盗密钥的人或代理。如果要求代理使用证书，则绑定变得非常紧密。一个聪明且行动迅速的小偷可以逃跑，但他们会留下更多的面包屑。

@skrevel（http://www.berenddeboer.net/rest/authentication.html )讨论了一种复杂但真正失败的身份验证方法。

您可以尝试访问该页面（该页面应仅对经过身份验证的用户可见）http://www.berenddeboer.net/rest/site/authenticated.html没有任何登录凭据。

（很抱歉，我无法对答案发表评论。）

我会说REST和身份验证根本不混合。REST表示无状态，但“已验证”是一种状态。不能在同一层同时使用它们。如果你是一个RESTful的拥护者，并且不赞成状态，那么你必须使用HTTPS（即将安全问题留给另一层）。