api - REST API : Simple token-based authentication - security?

Question

我有一个 REST API，我正在寻找一种简单的方法来进行基于 token 的安全身份验证。因为我读过像 OAuth 这样的协议(protocol)非常复杂，所以我想实现一种更简单的方法。常见的做法有哪些？那么以下程序的安全性如何？

客户端输入电子邮件和密码 -> 将其发送到 REST API(通过 HTTPS)

API验证用户

如果登录数据正确，API 会生成一个唯一的 API token ，将其保存在数据库中供用户使用，然后将其发送回客户端

token 存储在客户端网络存储

对于以下请求，客户端每次都必须发送 token ，API每次都必须检查 token

注销时，从网络存储和数据库中删除 token (用户再次登录时会生成一个新 token )

这种方法是否存在巨大的安全问题？或者这可行吗？

非常感谢

Answer 1

简短的回答是这种方法的概念没有重大的安全问题，但实现是关键，这可能是我最重要的一点。

自定义实现问题

您所描述的基本上是一个普通的旧 session 。这里的“ token ”只是一个 session ID。 Web 应用程序多年来一直以这种方式工作。有一些已知的高质量实现可以避免 session 固定、弱或不安全的 session id 生成等，还有一长串 session 管理漏洞。如果您尝试自己实现它，那么要正确和安全地实现它并不容易。因此，如果您打算这样做，只需使用已知的良好实现即可。

XSS 问题

但是有一点不同，您希望将“ token ”( session ID)存储在“webstorage”中，基本上可以是 localStorage、sessionStorage 或 WebSQL 之一。传统的 session 管理将 session ID 存储在 cookie 中是有充分理由的 - cookie 可以更好地防止跨站点脚本 (XSS)。如果 session cookie 被标记为 httpOnly，Javascript 将无法访问它，它只会被浏览器发送回同一服务器(实际上是源服务器)。这对于任何其他存储都是不可能的，这意味着如果您的网站(同一来源的任何页面)中存在 XSS 漏洞，则可能会窃取用户 token 。这比使用 httpOnly cookie 安全得多。

在现代 Web 应用程序中，这在很多时候是公认的风险。这主要发生在您想将相同的 token 发送到多个服务器(源)时。使用 httpOnly cookie 是不可能的。但是，如果您的 token 存储到数据库中，那么出于架构原因，如果不是其他原因，您可能无论如何都不想这样做。

CSRF 问题 - 已阻止

另请注意，尽管这种设计，在 header 中发送 token 几乎默认情况下可以防止跨站点请求伪造(CSRF)。所以好处是你不必(太多)关心 CSRF，但这是以 XSS 影响为代价的，在大多数情况下，这超过了这种好处。

状态问题

最后一点，这不是安全问题，但是使用您的设计，您的 API 将是有状态的，它将为每个客户端存储一个状态。这不是很好，因为正如您所说的那样，您将不得不去数据库检查每个请求的 token (或者您可以进入缓存的兔子洞和类似的复杂性来源)。然后想象一下，如果您的服务需要负载平衡，在多台服务器上运行，并具有多个数据库副本实例，会发生什么情况。因此，现代 API 设计旨在实现无状态 - 不为客户端存储状态。这就是(真正的) token 认证大放异彩的地方， token 不需要存储到数据库中，它们本身就是真实的。这就是基于 token 的身份验证真正有意义的地方，而不是在简单的场景中，普通的 session id 也可以，而且会更安全。