简单的 REST 身份验证策略？
我正在设计一个可供多个客户端、Web、移动设备、第三方等使用的 Web 服务。我正在将 REST 视为一种可能的解决方案，并且正在考虑身份验证的情况。
我试图让事情变得简单和高效。根据记录，我使用的是 Node.js。
据我所知，出于可扩展性的原因，不建议进行会话。
对于每次通过 https 的请求传递用户名和密码有何看法？
例如：
http://myservice/users/list?username=authorized&password=mypass< /a>
这种方法有严重的缺点吗？它是否会打开安全漏洞、跨站点脚本？
一般来说，对于 Web 服务有更好的解决方案吗？
I am designing a web service which can be used by multiple clients, web, mobile, 3rd party, etc. I am looking at REST as a possible solution and I am considering the case of authentication.
I am trying to keep things simple and performant. For the record, I am using Node.js.
I understand that sessions are not advised for scalability reasons.
What are the opinions of passing username and password on every request over https?
For example:
http://myservice/users/list?username=authorized&password=mypass
Are there severe disadvantages to this approach? Does it open a security hole, cross-site scripting?
Is there a better solution for a web service in general?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你不应该在 URL 中使用明文信息（它可以在
浏览器历史记录，没有混淆，并且也在像 apache 这样的常见日志模式内）。
相反，请使用 HTTP 标头：
优点：
如果您不这样做如果没有 SSL，您应该使用随机数方法。查看 HTTP-digest 以获得一些想法。如果您不需要识别特定用户（例如移动设备最终用户），您可以完全重用 HTTP -摘要。
为了安全设置尽可能重用。制定自定义身份验证方案很困难，因为存在许多安全陷阱。
You should never use cleartext information inside URL (it can be visible in
browser history, not obfuscated and also inside usual log-pattern like apache).
Instead use HTTP headers for that:
The advantages:
In case you don't have SSL in place you should use nonce approach. Have a look at HTTP-digest to get some ideas. In case you don't need to identify specific users (like mobile-device end-users) you can completely reuse HTTP-digest.
For security setup reuse as much as possible. It is tough to come up with a custom authentication scheme, because there are many security pitfalls.
您需要一个随机数。
否则，如果您使用 SSL，应该会很好。
You need a nonce.
Otherwise, you should be good if you're using SSL.