老实说，我在这里看到了很好的答案，但让我有点困扰的是，当有人将整个无状态概念推向极端，使其变得教条化时。这让我想起了那些只想拥抱纯OO的Smalltalk老粉丝，如果某个东西不是对象，那么你就错了。放过我

RESTful方法应该让你的生活更轻松，减少会议的开销和成本，尽量遵循它，因为这是一件明智的事情，但一旦你遵循一个纪律（任何纪律/准则）到了极致，它不再提供其预期的好处，那么你就错了。当今一些最好的语言同时具备函数式编程和面向对象。

如果解决问题的最简单方法是将身份验证密钥存储在cookie中并通过HTTP标头发送，那么就这样做吧，不要滥用它。请记住，当会话变得沉重和庞大时，会话是不好的，如果所有会话都由一个包含密钥的短字符串组成，那么有什么大不了的？

我愿意接受评论中的更正，但我只是认为（到目前为止）避免在我们的服务器中保存一本大字典的哈希值，这没有什么意义。

2019年2月16日更新

下面前面提到的方法本质上是OAuth2.0的“资源所有者密码凭据”授予类型。这是一种简单的起床和跑步方式。然而，使用这种方法，组织中的每个应用程序最终都将拥有自己的身份验证和授权机制。建议采用“授权代码”授权类型。此外，在下面我先前的回答中，我建议使用浏览器localStorage来存储身份验证令牌。然而，我开始相信饼干是实现这一目的的正确选择。在StackOverflow的回答中，我详细介绍了我的原因、授权代码授予类型实现方法、安全考虑等。

我认为以下方法可用于REST服务身份验证：

创建一个登录RESTful API以接受用户名和密码进行身份验证。使用HTTP POST方法在传输过程中防止缓存和SSL安全成功认证后，API返回两个JWT-一个访问令牌（有效期更短，例如30分钟）和一个刷新令牌（有效性更长，例如24小时）客户端（一个基于web的UI）将JWT存储在本地存储中，并且在随后的每个API调用中都会传递“Authorization：Bearer#access token”标头中的访问令牌API通过验证签名和到期日期来检查令牌的有效性。如果令牌有效，请检查用户（它将JWT中的“sub”声明解释为用户名）是否可以通过缓存查找访问API。如果用户被授权访问API，则执行业务逻辑如果令牌过期，API将返回HTTP响应代码400客户端在收到400/401时，调用另一个REST API，并在“Authorization：Bearer#refresh token”标头中使用刷新令牌来获取新的访问令牌。收到带有刷新令牌的呼叫时，通过检查签名和到期日期来检查刷新令牌是否有效。如果刷新令牌有效，则从DB刷新用户的访问权限缓存，并返回新的访问令牌和刷新令牌。如果刷新令牌无效，则返回HTTP响应代码400如果返回了新的访问令牌和刷新令牌，请转到步骤2。如果返回HTTP响应代码400，则客户端假定刷新令牌已过期，并向用户请求用户名和密码要注销，请清除本地存储

使用这种方法，我们每30分钟就要执行一次昂贵的操作，即加载具有用户特定访问权限详细信息的缓存。因此，如果取消了访问或授予了新的访问权限，则需要30分钟才能反映或注销，然后登录。

这就是实现这一点的方法：使用OAuth 2.0进行登录。

您可以使用Google以外的其他身份验证方法，只要它支持OAuth。

用于保护任何web应用程序的有效提示

如果你想保护你的应用程序，那么你应该首先使用HTTPS而不是HTTP，这样可以确保你和用户之间建立一个安全的通道，防止嗅探来回发送给用户的数据，并有助于对交换的数据保密。

您可以使用JWT（JSON Web令牌）来保护RESTful API，与服务器端会话相比，这有很多好处，好处主要是：

1-更具可扩展性，因为您的API服务器不必为每个用户维护会话（当您有多个会话时，这可能是一个很大的负担）

2-JWT是独立的，具有定义用户角色的声明，例如，他可以访问的内容，并在日期和到期日发布（之后JWT将无效）

3-更易于跨负载平衡器处理&如果您有多个API服务器，因为您不必共享会话数据，也不必配置服务器将会话路由到同一服务器，只要JWT请求命中任何服务器，就可以对其进行身份验证和授权

4-减少了数据库的压力，也不必为每个请求不断存储和检索会话id和数据

5-如果您使用强密钥签署JWT，JWT不会被篡改，因此您可以信任随请求发送的JWT中的声明，而无需检查用户会话&无论他是否获得授权，您只需检查JWT，然后您就可以知道该用户可以做什么。

许多库提供了在大多数编程语言中创建和验证JWT的简单方法，例如：在node.js中，最流行的是jsonwebtoken

由于REST API通常旨在使服务器保持无状态，因此JWT与这一概念更为兼容，因为每个请求都使用自包含的授权令牌（JWT）发送，而服务器无需跟踪用户会话，而会话使服务器保持有状态，从而记住用户及其角色，然而，会话也被广泛使用并有其优点，如果需要，可以搜索。

需要注意的一点是，您必须使用HTTPS将JWT安全地交付给客户机，并将其保存在安全的地方（例如，本地存储）。

您可以通过此链接了解有关JWT的更多信息

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

关于这个话题，这里的好心人已经说得够多了。但这是我的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，你就做好了自己的工作。