【问题标题】:How to implement a stateless REST API如何实现无状态的 REST API
【发布时间】:2011-04-21 08:31:29
【问题描述】:

我正在开发一个可供编写移动应用程序的开发人员使用的 REST API。用户将能够使用 3rd 方服务(Google、Twitter 等)来验证自己,这主要由 OAuth 处理(取决于相关服务)。我们在客户端应用程序和 API 服务器之间使用 2-legged OAuth(其中消费者密钥/秘密是特定于应用程序的,当应用程序在那里注册时,开发人员会从我们的站点获取它)。

我的问题是如何处理以无状态方式跟踪用户身份验证。我没有在每个请求中发送的用户凭据。我可以在用户登录时创建一个唯一的 session_id,然后在对 REST API 的每个请求中都需要它。我的问题还有其他解决方案吗?从无状态 REST API 的角度来看,使用唯一的 session_id 来识别用户是否会导致任何问题?

【问题讨论】:

标签: api rest stateless


【解决方案1】:

免责声明:我无论如何都不是安全专家。

不要称它为 session_Id。将其称为身份验证令牌并使用您自己的身份验证方案将 Authorization HTTP 标头传递给它。有关示例,请参见 Google AuthSub

不要将此身份验证令牌用于识别用户并确定他们是否有权执行请求之外的任何事情。不要将任何状态与令牌相关联,也不要根据它检索用户偏好。

【讨论】:

  • 只是为了验证我对此的理解,会话令牌仍然需要服务器端的会话状态?即会话的生命周期由服务器管理,并且在服务器端会话超时后令牌变得无效?我正在寻找一种方法来实现类似的目标,同时在服务器上没有“会话”的概念。
  • 这也是我很不明白的地方。每个人都在谈论安全和无状态,但无论如何都必须在服务器上举行用户会话。
  • @gambo 为什么?我构建的 RESTful 服务是安全的,我没有任何用户会话的概念。
  • 但是例如您正在从客户端登录,服务器正在检查并为您提供 authtoken(无论它看起来如何)。每次您向服务器发出一些请求时,都会发送此 authToken。因此,如果有人获得您的请求标头,那么完整的 rest api 是可以访问的,不是吗? authtoken 什么时候失效?对于我需要检查的每个请求,例如哪个用户在这个令牌后面,并做一些更多的安全检查,比如他是否有权编辑资源中的这个条目。
  • @gambo 有一些验证令牌的方法可能需要服务器保持某种状态,以便有效地验证令牌。至于有人窃取令牌并重新使用它。这是一个合理的担忧,一些代币计划对此有对策。正如我所说,我不是安全专家,所以我脑子里有很多细节。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-06-12
  • 2020-05-16
  • 1970-01-01
  • 2020-12-24
  • 2021-01-01
相关资源
最近更新 更多