为什么客户端机器会将用户名/密码保留为 cookie，而不将其包含在帖子内容本身中？

在帖子内容、localStorage 或 sessionStorage 中保留用户名/密码（或相关的令牌）会将此内容暴露给 XSS 攻击。请看这篇文章。即使这篇文章是关于令牌的，同样的原则也适用于任何凭据（包括用户名/密码）。更多关于这里的参考资料。如果您将此类信息存储在 httpOnly cookie 中，则该内容对 JavaScript 不可用，因此理论上不会受到 XSS 攻击。一旦您在 cookie 中获得了凭据，您就会面临 CSRF 攻击，您需要对其进行处理。

对您的链接问题的回答是正确的。

我会为令牌添加另一个好处：到期。如果用户名/密码凭证被盗，可能很难检测到。令牌将在某个时候过期，用户需要重新登录才能获得新的令牌。这限制了可以使用被盗令牌在服务器上进行身份验证的时间范围。如果是用户名/密码凭据，则没有此类限制或更大（密码过期策略通常为一个月或更长时间，其中令牌可以设置为在几分钟或几天内过期）

用户名密码

• 随每个 API 请求发送凭据并不是一个好主意。即使您通过 ssl/tls 发送凭据（不提供端到端安全隧道，已知漏洞！！），客户端很有可能成为 MITM（Lan/Wifi 级别、ISP 级别、国家级别）攻击的受害者.

• 用户名（姓名，电子邮件）/密码（不太复杂）很容易猜到。绝对不希望您的用户输入超过 21 个字符的密码，对吗？为了更好的用户体验！

基于令牌

• 1 个令牌（到期时间直到用户注销）与用户名/密码相同

• 您应该尝试实施 Oauth、JWT 或自定义访问/刷新令牌方案。如果您错误地实施，这种方法本身不会提供更多的安全性。

使用令牌，您可以为用户提供更灵活的会话管理透明度。

前任：-

• 终止远程会话（过期令牌！）
• 更新当前会话（通过刷新令牌更新访问令牌！）
• 跟踪所有活动会话
• 令牌（随机+长度）不容易暴力破解。

我不会在这里谈论可扩展性和其他好处。但是，是的，您可以使用基于令牌的方法来扩展您的服务 :-) 开放 em 以供第 3 方消费。