在使用 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基本身份验证，cookie），那么使用任何跨域技术（CORS， JSONP，跨域.xml等）。
我能回答这个问题的最好方法是将您指向此描述REST安全性的页面。它属于 restlet wiki，而不是 Jersey，但它可以应用于 Jersey，因为它们都是 REST 实现。
这是从我提供的链接中提取的：
“为了获得最大的阻力，服务器可以向客户端提供应用程序级授权令牌，这是服务器可以验证的不透明值是否属于经过身份验证的正确用户。
这样的令牌应该很难被第三方计算，例如，用户身份凭证的服务器盐MD5或SHA1哈希。
要击败 XSRF，需要通过用户代理不会在每个请求中自动返回的方式来传输此应用程序级令牌。例如，它可以在表单的HTML中作为隐藏字段发送，并通过编码表单实体中的POST返回。
