我知道这似乎是一个琐碎的问题，但我找不到答案，至少可以使我安心。
如果移动应用程序正在与服务器通信，则通常他们会登录并获得访问令牌，该令牌可用于将来的会话中的任何后续请求。
为什么不随每个请求（而不是访问令牌）通过HTTPS传递用户名和密码。访问令牌将需要与数据库一起验证，用户名/密码的组合也需要进行验证。如果他们做同样的事情，为什么还要付出更多的访问令牌呢？我知道我错过了一些东西，但我无法弄清楚
答案 0 :(得分：1)
我认为答案是关于安全性的。
总是建议使用访问令牌代替用户名和密码，因为：
访问令牌（在大多数服务中）可以很容易地从您的帐户生成，阻止，监视其使用情况和统计信息，可以设置为过期，可以具有受限权限等等...当然，您可以将其删除。用户名和密码是主用户，可以控制访问令牌。
访问令牌更安全，这是最重要的。如果您在网络应用程序（或其他应用程序）中使用用户名和密码，并且该应用程序被黑客入侵（这种情况经常发生），或者有人查看其源代码，甚至某些日志系统都保存了请求参数-那么您的用户名和密码可以会被第三方查看，并且您的所有帐户都可能遭到黑客入侵（如果您拥有相同的用户/密码，则可能也会被黑客入侵）。访问令牌消除了所有这些风险。
关于速度-我认为USER＆PW的授权在速度方面没有任何显着优势。
答案 1 :(得分：1)
您是对的，因为访问令牌的验证方式几乎与用户名和密码相同。在访问令牌有效期间，它与用户名和密码相当。在某些情况下（取决于您的威胁模型），甚至可以通过每个请求发送用户名和密码，也许不是从移动应用程序发送，而是例如通过适当的控件在服务器之间进行请求。
但是，您主要不希望在移动应用程序的每个请求中都发送密码，因为那样一来，您就必须存储它。
密码（实际上是用户）的问题是密码被重用。密码是很有价值的目标，因为相同的密码可能会在多个服务上使用。因此，您将其交换为寿命较短的访问令牌，如果该令牌被盗，则对用户的风险较小。而且，您无法轻易撤消密码-强迫用户更改密码是一件麻烦的事。撤销被盗的凭证很容易。
这也是极不可能的，但是有时TLS中存在漏洞-并非很常见，但在过去几年中有一些漏洞。此类漏洞可能允许攻击者解密通过https发送的某些流量，例如，openssl之前存在一个漏洞，攻击者可以提取部分服务器内存，并可能保留发送的所有用户。如果它只是一个访问令牌，而不是实际的密码，那就更好了。
另一点是，有时（在OAuth流程中）您的应用甚至无法访问实际密码。当您的用户使用第三方身份提供商（例如Facebook）登录时，他们不希望您的应用接收其Facebook密码。他们只是去Facebook，将其凭证交换为访问令牌，然后您只看到可以根据需要与Facebook验证的令牌。但是您实际上从未获得用户的facebook密码。当然，这仅在身份提供者是第三方时有效。