我的理解是 RESTful 服务应该是完全无状态的。每次调用该服务时，我都必须传递它正常运行所需的所有信息。
然而，当涉及到身份验证时，我对它应该如何工作感到相当困惑，特别是在会话管理方面。
我正在使用基本身份验证，第一次发出请求时，客户端会受到挑战（或者我可以从头开始传递标头中的身份验证信息）。但是一旦用户通过了身份验证，只要会话还活着，服务器就不会再挑战这个客户端了。
这意味着我需要为当前用户提供一些退出机制（终止他/她的会话）。
看起来这样做的正确方法是以某种方式更改我的配置，以便每个请求都受到身份验证的挑战，但我不知道这如何与会话管理一起使用。
你可以找到很多关于 REST 安全性的问题，甚至还有关于如何实现不同身份验证模型的书籍。但是我还没有找到关于如何处理会话管理、登录和注销的好答案。所以要么我做错了什么，要么我误解了一些重要的事情。
我将不胜感激有关如何正确处理此问题的任何想法或指导。
我将 Jersey 2.4 与 Tomcat 7 一起使用。
如果您使用 HTTP Basic 进行身份验证，则客户端第一次受到质询只是因为未从客户端发送 Authorization 标头。一旦它被发送并且服务器发送了 401 以外的其他内容，客户端会缓存这些凭据并在每个请求中重新发送它们。
您不应该在无状态应用程序中创建会话，不仅因为它们不被使用，而且因为它们需要管理开销（甚至是空的）。然而，servlet 体系结构不能阻止代码创建会话，例如当代码调用httpServletRequest.getSession()或时httpServletRequest.getSession(true)。因此，您需要确保不使用任何执行此操作的代码（或框架）。
有趣的是，Tomcat 仍然会生成一个 JSESSIONID cookie 供客户端使用，并且在容器的大多数配置下，您无法关闭它。但是，如果没有创建会话，则 cookie 基本上会被忽略（并且每个请求都会生成一个新的 JSESSIONID cookie）。
而且，因为应用程序是无状态的，所以没有登录或注销的概念。所有身份验证都是根据请求完成的。
请注意，根据您的特定应用程序，实用主义可能胜过纯粹的 RESTful。在某些情况下，“一点点”服务器状态确实是为应用程序提供某些类型安全性的唯一方法（例如跨站点请求伪造，任何带有随机数的东西等）
如果您正在执行 RESTful Web 服务，则不应处理会话。首次连接 API 时，您需要通过身份验证检查才能获得身份验证密钥。此密钥是您的 API 将如何识别其用户的方式。
您不应使会话无效，也不应强制用户重新进行身份验证。