rest - 基于 token 的 REST API 身份验证

Question

我有一个由轻量级 Node.js API 支持的移动应用程序。我最近开始探索集成使用基于 token 的身份验证的第三方 API 服务。此 API 专为从我的服务器端 Node.js 代码调用而设计，因为直接从我的移动应用程序调用它会暴露我的敏感用户名/密码信息。其他只能在服务器端调用的类似 API(例如 Stripe)需要使用随每个请求传入的 key 进行身份验证。这种方法对我来说更有意义，因为您不会真正想到服务器“登录”到另一个 API。

所以，这是我关于访问基于 token 的 API 的问题:

1. 调用此 API 的最佳方法是什么？ token 的生命周期为 1 小时。我是否应该 1) 将 token 保存在数据库中，并且对于每个请求，从数据库中提取 token ，检查它是否仍然有效，然后向第三方 API 发出请求？或者，2) 每次我需要向 API 发出请求时请求一个新 token ？

2. 使用基于 token 的身份验证有什么好处？由于没有登录的概念并且请求之间不需要维护状态，使用具有基本身份验证的简单 key 不是更容易吗？

Answer 1

我将从#2 开始:

What is the benefit of using token based authentication? Since there isn't a concept of logging in and no state needs to be maintained between requests, wouldn't it be easier to use a simple secret key with basic auth?

基本身份验证用户名和密码:

1. 也是一个 token 。
2. 实际上并没有“登录”。它以同样的方式是无状态的，因为用户名和密码会随每个请求一起传递。

因此，在这种情况下，您所描述的 token 与密码之间的区别在于 token 的生命周期。听起来您可能实际上有 2 个 token 。一个执行请求(访问 token )，另一个请求新的访问 token (如果它们已过期)(刷新 token )。

为什么要这样做？一种想法是刷新 token 是最危险的 token ，因为如果访问 token 以某种方式泄漏，它只会在有限的时间内有效。通过将它们分开，您基本上可以减少潜在攻击向量的数量。在一个一切都是安全的世界里，这可能没有什么真正的区别，但我们并不生活在这个世界上。

访问 token 可能会泄漏到日志中，或者通过其他方式意外暴露。刷新 token 被暴露的可能性较低。

一些 API 还在一些签名的 json 负载 (jwt) 中转换访问 token ，因此他们不需要检查他们的数据存储的有效性。如果发生安全更改(新密码、入侵检测)，这些服务可能会使刷新 token 过期，但不会使访问 token 过期。

但是，是的，这是一个有点棘手的话题。没有明确的攻击向量可以通过创建两个 token 来阻止，但它是纵深防御。