REST服务上的身份验证令牌有什么意义

Question

使用REST Web服务时，在每次发出请求时都使用身份验证令牌，而不是通过HTTPS /加密发送用户名和密码，这有什么价值？

我知道，例如OAUTH具有一些好处，因为您不需要向第三方透露密码，您可以将令牌传递给您不想共享用户名/密码的受信任的第三方。

但是除了我在我的情况下当然不需要的特殊好处之外，为什么我还是使用令牌而不是每次发送用户名/密码。

这可能使客户的生活变得轻松，并且不必每次都发送用户名/密码。好的，但是现在客户必须记住我的令牌，并在每次请求时将令牌发送给我。因此，现在无需记住/发送用户名/密码，而是对令牌执行相同的操作！因此，客户端实现代码不会少。

那么，这里的真正价值是什么？

Answer 1

它确实取决于场景-
在不了解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 BasicAuth，Cookie），那么使用任何跨域技术（CORS，JSONP，crossdomain.xml等）来启用对该API的跨域访问都是不安全的。