首先也是最重要的，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标准，可以识别并锁定不正确使用被盗密钥的人或代理。如果要求代理使用证书，则绑定变得非常紧密。一个聪明且行动迅速的小偷可以逃跑，但他们会留下更多的面包屑。

这当然不是关于“会话密钥”，因为它通常用于指在REST的所有约束条件下执行的无会话身份验证。每个请求都是自我描述的，携带足够的信息，可以在没有任何服务器端应用程序状态的情况下自行授权请求。

最简单的方法是从RFC 2617中的HTTP内置认证机制开始。

如何在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，这是除了任何身份验证方案之外所必需的。

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分钟才能反映或注销，然后登录。

用于保护任何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的更多信息