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