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

Question

我知道这似乎是一个琐碎的问题，但我找不到答案，至少可以使我安心。

如果移动应用程序正在与服务器进行通信，则通常他们会登录并获得访问令牌，可将其用于会话的其余部分以及将来的任何请求。

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

Answer 1

我认为答案是关于安全性的。

始终建议使用访问令牌代替用户名和密码，因为：

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

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

• 关于速度-我认为USER＆PW的授权在速度方面没有任何显着优势。

Answer 2

没错，访问令牌的验证方式几乎与用户名和密码相同。 在访问令牌有效期间，它与用户名和密码相当。 在某些情况下（取决于您的威胁模型），甚至可以随每个请求发送用户名和密码，也许不是从移动应用程序发送，而是例如通过适当的控件在服务器之间发送请求。

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

密码（或实际上是用户）的问题在于它们已被重用。 密码是很有价值的目标，因为相同的密码可能会在多个服务上使用。 因此，您将其交换为寿命较短的访问令牌，如果该令牌被盗，则对用户的风险较小。 而且，您无法轻易撤消密码-强迫用户更改密码是一件麻烦的事。 撤销被盗的凭证很容易。

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

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