REST API：基于令牌的简单身份验证-安全吗？

Question

我有一个REST API，我正在寻找一种简单的方法来进行基于令牌的安全身份验证。由于我已经阅读过OAuth之类的协议非常复杂，因此我想实现一种更简单的方法。有哪些常用方法？接下来的过程的安全性如何？

1. 客户端输入电子邮件和密码->将其发送到REST API（通过HTTPS）
2. API验证用户
3. 如果登录数据正确，则该API会生成一个唯一的API令牌，将其保存在数据库中供用户使用，然后将其发送回客户端
4. 令牌存储在客户端Web存储中
5. 对于以下请求，客户端必须每次发送令牌，API每次必须检查令牌
6. 注销时，令牌将从Web存储和数据库中删除（当用户再次登录时会生成一个新令牌）。

这种方法是否存在巨大的安全性问题？还是可行？

非常感谢

Answer 1

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

定制实施问题

您所描述的基本上是一个普通的旧会话。这里的“令牌”只是一个会话ID。Web应用程序已经以这种方式工作了很长时间。存在避免会话固定，会话ID弱或不安全等问题的已知高质量实现，会话管理漏洞列表很长。如果您自己尝试实现它，那么正确和安全地实现它并不容易。因此，如果您打算以这种方式进行操作，则只需使用已知的良好实现即可。

XSS问题

但是有一个区别，您要将“令牌”（会话ID）存储在“ webstorage”中，该令牌基本上可以是localStorage，sessionStorage或WebSQL之一。传统的会话管理有很好的理由将会话ID存储在cookie中-可以更好地保护cookie免受跨站点脚本（XSS）的侵害。如果会话cookie标记为httpOnly，则Javascript将无法访问它，它将仅由浏览器发送回同一台服务器（实际上是起源）。其他任何存储都无法做到这一点，这意味着，如果您的站点中存在XSS漏洞（同一来源的任何页面），则用户令牌可能被盗。这比使用httpOnly cookie的安全性要差得多。

在现代Web应用程序中，这是很多时候公认的风险。这主要是在您要将同一令牌发送到多个服务器（源）时发生的。使用httpOnly cookie不可能做到这一点。但是，如果将令牌存储在数据库中，那么出于架构原因，您可能不想这样做。

CSRF问题-已阻止

还要注意，尽管这种设计在头中发送令牌几乎可以在默认情况下防止跨站点请求伪造（CSRF）。因此，好处是您不必太在意CSRF，但这是以牺牲XSS的代价为代价的，在大多数情况下，这超过了此好处。

有状态性问题

最后一点，这不是安全性，但是使用您的设计，您的API将是有状态的，它将为每个客户端存储一个状态。这不是很好，因为正如您正确说过的那样，您将必须去数据库检查每个单个请求的令牌（否则您就可以进入缓存和类似复杂性来源的困境）。然后想象一下，如果您的服务需要在多个服务器上运行并具有多个数据库副本实例的负载平衡，那么会发生什么情况。因此，现代API设计的目标是无状态-客户端不存储任何状态。这就是（真实）令牌身份验证的亮点，令牌不需要存储到数据库，它们本身就是真实的。那就是基于令牌的身份验证真正有意义的地方，而不是在简单的情况下（普通的会话ID也可以做到），