Rest 如何在不影响数据库的情况下进行身份验证？

下面的一条评论最近激起了我的兴趣。为清楚起见，我将完整引用评论：

我的回答中没有任何内容暗示了一种基于对每个请求的数据库访问的解决方案，如果您认为是这样的话，那么您在理解这种规模的身份验证和授权时就失败了。身份验证可以隐含在状态中，您认为facebook对其RESTAPI的每个请求都进行“数据库访问”吗？还是谷歌？提示：没有

---

我试图思考如何在不检查用户提供的值与集中保存的值的情况下进行身份验证，即使用户希望知道要向用户显示哪些数据，结果却是空白。我坦率地承认，就我而言，理解这种规模的身份验证和授权是一种失败。因此，我的问题是：像Facebook和Google这样的网站是如何做到这一点的？

一种方法是基于声明的身份验证。它简化了，解释也有点松散，归结起来就是这样

• 未经身份验证的用户被重定向到单独的身份验证服务器，而不是服务器应用程序对用户本身进行身份验证

• 身份验证服务器以其想要的任何方式（登录+密码、证书、域成员资格等）验证用户，并创建一个带有相关用户信息（用户id、名称、角色等）的签名“文档”，然后将用户重定向回附有文档的服务器应用程序

• 服务器应用程序验证文档的签名，如果它信任该签名，它可以使用文档内容来假定用户是谁，而不是访问数据库

• 通常，服务器应用程序以cookie/会话或类似方式缓存文档，以便下次对应用程序的访问不必通过身份验证服务器跳转

---

通过这种方式，服务器应用程序不需要关心用户是如何通过身份验证的，只需要关心它是否信任身份验证服务器的判断。如果身份验证服务器（可能是客户端，除非它是浏览器）添加了Facebook登录支持，服务器应用程序将自动“只工作”新的登录类型。

所以不是没有检查数据库，而是从不同的数据库处理身份验证？据我所知，您的答案是，用户提供的值仍然会与数据库中集中保存的值进行检查，但这主要是为了负载平衡而在不同的服务器上进行的。是吗？@GarryCairns不同之处在于，在登录时，数据库会被查询一次以生成索赔文档，之后，不再需要通过数据库访问来了解所需的用户数据，而是使用索赔文档（或由其创建的会话）来查找索赔文档。如果您只使用一台服务器，那么在登录时从数据库中读取一次用户数据并将结果放入会话中，就可以获得几乎相同的效果，这样您就不需要数据库访问来获取（例如）用户名。我有点晚了，但希望您仍在那里进一步讨论！今天我想到了类似的事情，将凭证打包成JSON，编写它们的脚本（当然只有服务器知道密钥），然后将它们返回给用户，但我担心的是会失去对这些文档的控制。我的意思是，只要有无身份验证的访问（他们都准备好了持有已签名的文档），就不会有数据库查询，因此，如果用户决定注销（因为有人可能拥有此文档），文档仍然有效。快速过期时间应该解决它吗？