我有一个作为ASP MVC应用程序编写的Web服务，它基本上使用滚动cookie作为其身份验证机制。因此，有人通过https将他们的用户名和密码发送给服务，然后验证他们并向他们发送包含令牌，用户标识符和时间戳的cookie，如HTTPONLY和SECURE。然后，只要用户需要访问需要身份验证的页面，就会发送cookie并通过时间戳和针对用户的令牌进行验证，假设通过它然后发出新的时间戳并将其发送回用户。
这种方法迄今为止起作用，虽然CSRF仍有可能（通过滚动时间戳减少）和一些其他漏洞，但是当前项目团队愿意忍受的风险是，有一个很大的技术债务卡寻找更好的方法，但这是另一个讨论，因为我们的主要目标是无国籍服务，因此它可以轻松扩展。
无论如何，一方面，现在的问题是我们被要求向服务中的其他第三方公开数据。然而，他们不会像使用浏览器的普通用户那样使用这些数据，而是在任何类型的平台上使用某种应用程序。所以现在我想知道基于应用程序的消费者是否有更好的方法来验证自己，因为目前他们需要发送http请求进行身份验证，然后获取返回的cookie，并将其发送给受限制的请求。然而，其他第三方需要在他们想要从我们的系统获取数据时继续处理这个cookie，这对他们来说似乎有点痛苦。
那么还有另一种我看不到的方法吗？因为我可以看到保持无状态的两种方式是每次都在查询字符串上发送一些令牌，这又需要它们进行身份验证和存储，并且会使查询字符串不那么干净。另一种方式是我们目前使用cookie作为状态机制。
答案 0 :(得分：3)
如果您真的关心保持API RESTful，那么在查询字符串上发送凭据肯定是禁忌，因为在REST中，整个URI是资源的不透明标识符，并且使用cookie是不必要的耦合。服务和HTTP。验证的正确方法是协议允许和标准化的任何方式，因此，在您的情况下，通过WWW-Authenticate和Authorization标头。客户端应在每个请求的Authorization：Basic标头中发送用户名和密码（当然，总是使用SSL）。
如果您确实想在使用username：password验证客户端后使用令牌，则可以在同一标头中将其作为自定义授权方案接受。例如，像：
Authorization: MyCompany apitoken="12k9023nd02890382n8902"
每当您对RESTful方式做什么产生疑问时，只需考虑您正在使用的协议的标准。这是REST背后的约束之一。每当你必须记录一些替代标准化功能的东西时，你做错了。如果标准不足以满足您的需求，可以添加一些东西，例如带有令牌的自定义身份验证方案。