每次发出请求时，使用 REST Web 服务而不是通过 HTTPS/加密发送用户名和密码时，使用身份验证令牌的价值是什么？
我知道，例如 OAUTH 有一些好处，因为您不需要将密码泄露给第三方，您可以将令牌传递给您不想共享用户名/密码的受信任的第三方......等等
但除了这些我当然不需要的特殊好处之外，为什么我要使用令牌而不是每次都发送用户名/密码。
这可能是为了让客户的生活更轻松，并且不必每次都发送用户名/密码。好吧，但是现在客户必须记住我的令牌并在每次请求时向我发送令牌。因此，现在它不会记住/发送用户名/密码，而是对令牌执行相同的操作！所以客户端实现代码不会少。
那么这里的真正价值是什么？
这真的取决于场景——如果不了解更多关于 API 的信息很难说清楚——但是“身份验证令牌”的使用远非普遍，你说得对，许多 API 不需要（也不使用）它们。许多 API 只需要在每个请求中发送一个 API 密钥（通常通过 HTTPS 以防止其被拦截），或者需要一个 API 密钥来识别用户，还需要一个带有“密钥”的数字签名来证明用户的身份（请参阅使用大多数 API 时，为什么它们需要两种类型的身份验证，即密钥和秘密？）。
用户名/密码在公共 API 中不经常使用，因为它们不够灵活，并且不能在用户身份和应用程序身份之间提供足够的“分离”。例如，您注册为开发人员以使用 Flickr API 并创建一个使用该 API 的 iPhone 应用程序——您真的希望将您的开发人员用户名/密码内置到应用程序中吗？如果您稍后更改密码怎么办？如果您想开发 5 个应用程序并分别跟踪它们的使用情况并能够随时关闭任何应用程序而不影响其他应用程序怎么办？
但是，对于您真正只想识别人类用户而不是应用程序的情况（例如，只为您自己的应用程序提供服务的私有 API 后端，而不是公共 API），在大多数情况下，我没有发现任何问题使用您的建议，即每个请求通过 HTTPS 的用户名/密码。哦，顺便说一句，身份验证令牌具有“可限制”的附加优势（可以在特定时间到期，只能限制某些操作等），但显然这仅在非常特定的场景中有用。
另外：正如上面用户“Dan”所指出的，当设计一个需要在每个请求（或任何请求，即使它只是登录请求）中发送用户名/密码的 API 时，要小心你是如何做的。如果您使用的是浏览器默认支持的技术（例如 HTTP Basic Auth），那么您将阻止自己将 API 安全地暴露给跨域用户（即很可能永远无法从浏览器直接安全地调用您的 API ，即来自 AJAX/Flash/Silverlight 代码）。
这是一个复杂的话题，在这里无法完全解释，但请记住，如果您的 API 依赖于浏览器可以记住的任何安全凭证，然后“静默”地注入每个请求（例如 HTTP 基本身份验证、cookies），那么使用任何跨域技术（CORS、JSONP、crossdomain.xml 等）启用对该 API 的跨域访问是不安全的。
我可以回答这个问题的最好方法是指向描述 REST 安全性的这个页面。它属于restlet wiki，不属于Jersey，但它可以应用于Jersey，因为它们都是REST 实现。
这是从我提供的链接中提取的：
“对于最大的阻力，服务器可以向客户端提供应用程序级授权令牌，服务器可以验证的不透明值属于正确的经过身份验证的用户。
这样的令牌对于第三方来说应该是难以计算的，例如用户身份凭证的服务器加盐 MD5 或 SHA1 散列。
要击败 XSRF，需要通过用户代理不会随每个请求自动返回的方式传输此应用程序级令牌。例如，它可以在表单的 HTML 中作为隐藏字段发送，并通过 POST 在编码的表单实体中返回。”