如何在 HTTP 服务中进行身份验证？
我们目前有一个具有用户帐户功能的网站，但我们希望提供一个 API，通过为常见任务提供 API，允许用户管理其帐户/通过其他设备/网站执行操作。
目前，为了安全起见，网站登录是通过 HTTPS 完成的，然后使用 PHP 会话进行管理，并采取适当的安全措施来防止会话劫持等。
我们如何在 API 中提供此功能？
如何在不执行 POST 的情况下提交登录？ （大概 GET 是通过 API 调用执行此操作的唯一方法）。 正在发出如下 URL： https://www.example.com/login/ user-foo@password=bar 安全吗？ https 设置是否在通过网络发送 URL 之前进行？
如果我能解决这个问题，那么我会让登录返回一个访问令牌。 第一个请求应包含此令牌，响应应返回一个新令牌，用于第二个请求，依此类推......
这可行吗？
We currently have a website that has user account functionality, but we are looking to provide an API to allow users to manage their accounts/perform actions via other devices/websites, by providing an API for common tasks.
Currently the website login is done via HTTPS for security, and then managed using PHP sessions with suitable security measures to guard against session hijacking etc.
How would we provide this functionality in an API?
How is it possible to submit a login without doing a POST? (As presumably GET is the only way to do this via an API call). Is isuing a URL like: https://www.example.com/login/user-foo@password=bar secure? Does the https setup happen before the URL is sent over the wire?
If I can sort that out then I would have the login return an access token. The first request should include this token, and the response should return a new token, for use on the second request and so on....
Would this work?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以使用基本 www 身份验证。 它基本上是一个标头，其中包含用户名+密码。 这样做的好处是它是无状态的（您不需要单独的登录过程），并且得到很好的支持。 实现起来也非常简单。 只要您通过 https 提供服务，安全性就很好。
将凭据放在 URL 中并不好，因为它最终可能会出现在日志中。
是的，https是在http协议之前建立的。 恶意者唯一能够看到的是端点的 IP 地址。
You can use basic www-authentication. It's basically a header, which contains username+password. The good thing about this, is that it's stateless (you don't need a separate login process), and it's very well supported. It's also quite simple to implement. As long as you serve it over https, the security is fine.
It's not good to put the credentials in the URL, since it might end up in a log.
Yes, https is established before the http protocol. The only thing a malicious person would be able to see, is the IP addresses of the endpoints.
使用标准，例如 OAuth？ 如果您允许这样做，那么您的用户可以根据需要保留经过身份验证的令牌。
或者，如果您可以在收到某些 GET 请求时重定向到登录，则可能根本不需要任何身份验证。例如：任何站点都可以链接到 向 Twitter 添加推文。 未登录时，Twitter 首先会重定向到登录页面。 推荐网站甚至不需要知道 Twitter 用户名。
（是的：在发送 URL 之前，基于服务器的 IP 地址建立了 HTTPS。）
Use a standard, such as OAuth? If you allow for that, then your user can keep the authenticated token as long as they wish.
Alternatively, you may not need any authentication at all, if you could redirect to a login when some GET request comes in. For example: any site can link to an URL to add a tweet to Twitter. When not signed in, Twitter will first redirect to the login page. The referring site does not even need to know the Twitter username.
(And yes: HTTPS is established, based on the IP address of the server, before the URL is sent.)
您可以通过要求调用者设置标头来在 REST API 中执行身份验证。 即他们设置了一个“X-YourApp-API-Key”标头，然后您可以读取并使用该标头进行身份验证。 这使您不仅可以验证 POST 和 GET 方法，还可以验证 PUT、HEAD 和 DELETE，以便您拥有完整的 REST 方法。
如果您的所有调用都通过 HTTPS，那么这本身就很好。 如果您想通过 HTTPS 进行身份验证，然后通过常规 HTTP 进行后续调用，您需要实现类似于 OAuth 的功能，并且会出现问题明确请求的令牌。
You can perform authentication in a REST API by requiring a header to be set by the caller. i.e. They set an "X-YourApp-API-Key" header that you then read and use to authenticate. This allows you to authenticate not just POST and GET methods, but PUT, HEAD, and DELETE so you have the full complement of REST methods.
This by itself is fine if all of your calls are via HTTPS. If you want to authenticate over HTTPS and then have subsequent calls via regular HTTP you need to implement something that works like OAuth and issues a token for the in-the-clear requests.
您是否考虑过通过 SSL 使用 SOAP ？ 理论上，您应该能够通过 SOAP 对用户进行身份验证。
Have you thought about using SOAP over SSL? In theory, you should be able to authenticate an user over SOAP.