api - api请求的访问 token 与用户名/密码

Question

我知道这似乎是一个微不足道的问题，但我找不到至少能让我安心的答案。

如果移动应用程序正在与服务器进行通信，那么通常他们会登录并获得访问 token ，他们可以在任何 future 请求的剩余 session 中使用该 token 。

为什么不只是在每个请求中通过 HTTPS 传递用户名和密码而不是访问 token 。访问 token 需要通过数据库进行验证，用户名/密码的组合也是如此。如果他们做同样的事情，为什么还要付出访问 token 的额外努力？我知道我错过了一些东西，但我无法弄清楚

Answer 1

您是对的，访问 token 的验证方式与用户名和密码几乎相同。在访问 token 有效期间，它几乎等同于用户名和密码。在某些情况下(取决于您的威胁模型)，甚至可以在每个请求中发送用户名和密码，可能不是来自移动应用程序，而是例如在服务器到服务器请求中，使用适当的控制。

但是，您不想在来自移动应用程序的每个请求中发送密码，主要是因为这样您就必须存储它。

密码(或实际上是用户)的问题在于它们会被重复使用。密码是一个有值(value)的目标，因为同一个密码很可能被用于多个服务。因此，您可以将它换成一个生命周期较短的访问 token ，如果被盗，您的用户面临的风险较小。而且您不能轻易撤销密码 - 强制用户更改密码很麻烦。撤销访问权很容易。

也不太可能，但有时 TLS 中存在漏洞 - 不常见，但在过去几年中出现过一些。此类漏洞可能允许攻击者解密通过 https 发送的某些流量，或者例如，不久前 openssl 中存在一个漏洞，允许攻击者提取部分服务器内存，可能保存用户发送的任何内容。如果它只是一个访问 token ，而不是实际的密码，那就更好了。

另一点是有时(在 OAuth 流程中)您的应用程序甚至不允许访问实际密码。当您的用户使用第 3 方身份提供商(例如 facebook)登录时，他们不希望您的应用收到他们的 facebook 密码。他们只是去 facebook，将他们的凭据交换为访问 token ，并且您只能看到可以根据需要通过 facebook 验证的 token 。但是您实际上从未获得用户的 Facebook 密码。当然，这仅在身份提供者是第三方时才有效。