api请求的访问令牌与用户名/密码

Question

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

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

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

Answer 1

我认为答案就是安全和保障。

始终建议使用访问令牌而不是用户名和密码，因为：

• 访问令牌（在大多数服务中）可以轻松生成、阻止、监控您帐户的使用情况和统计​​信息，可以设置为过期、可以具有受限权限等等......当然，您可以完全删除它。用户名和密码是主人，他可以控制访问令牌。

• 正如我所说，访问令牌更安全，这是最重要的。如果您在网络应用程序（或其他）中使用用户名和密码，并且该应用程序被黑客攻击（这种情况经常发生），或者有人查看其源代码，甚至某些日志系统保存了请求参数 - 那么您的用户名和密码可以被第三者查看，您的所有帐户都可能被黑客攻击（如果您拥有相同的用户/密码，其他帐户也可能被黑客攻击）。访问令牌消除了所有这些风险。

• 关于速度 - 我不认为使用 USER & PW 授权在速度上有任何显着的优势。

Answer 2

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

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

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

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

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