设计 Web API：如何进行身份验证？
我正在设计一个网络 API。 我需要让用户验证自己的身份。 我有点犹豫是否让用户以明文形式传递他们的用户名/密码..类似于： api.mysite.com/auth.php?user=x&pass=y
我读到的另一个选项是 Base64 编码用户名/密码，然后发送 HTTP 请求。 那么这是否意味着在服务器端；我会 _GET['user'] 和 _GET['password'] 然后以某种方式解码它们？
这就是 twitter 所做的吗： http://apiwiki.twitter.com/REST+API+文档#身份验证？
I am designing a web api. I need to let the user authenticate themselves. I am a little hesistant to let the user pass in their username/password in cleartext.. something like: api.mysite.com/auth.php?user=x&pass=y
Another option i read about was Base64 encoding the username/password and then sending a HTTP request. So does that mean that on the server side;I would _GET['user'] and _GET['password'] and then somehow decode them?
Is that what twitter does: http://apiwiki.twitter.com/REST+API+Documentation#Authentication ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
Base64 根本没有任何保护。 使用 SSL 实现真正的安全。
Base64 is no protection at all. Use SSL for real security.
正如 truppo 提到的，首先使用 SSL。
许多 Web 服务所做的是提供“身份验证”服务，该服务返回一个令牌，稍后使用，并且可以以明文形式使用，因为它仅在有限的时间内有效。 当它过期时，客户端只需进行另一次身份验证。
这样做的主要好处是减少了 SSL 请求的数量，从而减轻了服务器的负载。
As mentioned by truppo, first use SSL.
What many web services do is have an "authenticate" service that returns a token that is then used later, and can be used in plaintext, since it's only valid for a limited amount of time. When it expires, the client simply does another authenticate.
The key benefit of this is that it reduces the number of SSL requests, which lightens the load on the server.
就在本周，IETF 发布了新草案 讨论 HTTP 中各种身份验证机制的安全属性。 您应该在那里找到有用的信息。
就我个人而言，我建议至少阅读 摘要式身份验证并分析它是否适合您。
使用 SSL 也可能是一种选择。 然而，它也以牺牲性能、可缓存性等为代价解决了其他问题。 它对有效负载数据保密。 如果这是一个要求，那么这就是你要走的路。
Just this week the IETF published a new draft discussing security properties of the various authentication mechanisms in HTTP. You should find helpful information there.
Personally I'd recommend at least to read about digest authentication and analyze if that's suitable for you.
Using SSL might also be an option. However, it also addresses additional issues at the expense of performance, cachability and others. It keeps the payload data confidential. If this is a requirement, then it's your way to go.
如果这是一个网络服务，您最好使用更安全的身份验证形式。 例如，在 LiveJournal 协议中：挑战-响应。
If this is a webservice, you'd better use more secure form of authentication. Look for example, at the LiveJournal protocol: Challenge-Response.
请不要对 api 使用常规用户名/密码身份验证。 人们确实不应该被迫将来自外部服务的凭据放入混搭服务中。
请考虑使用 oauth http://oauth.net/ 或至少一些基于挑战-响应的系统，如尤金建议的。
一种简单的方法是让访客服务生成一个连接到他的应用程序和用户的令牌。 如果您投入一些工作，您甚至可以确保令牌创建安全，只允许具有某些私钥/公钥机制的外部服务。
用户必须在您的应用程序中授权此令牌，然后访客服务才能使用它进行身份验证。
Please do not use regular usename/password authentication for the api. People really shouldn't be forced to put credentials from foreign services in a mashup service.
Please consider using oauth http://oauth.net/ or at least some challenge-response based system, like Eugene suggested.
One easy way would be to let the guest-service generate a token which is connected to his app and a user. If you put in some work you could even make the tokencreation secure to have only allowed foreign services with some private/public-key mechanisms.
The user has to authorize this token in your app before the guest service can use it to get authenticated.
我发现这篇文章令人大开眼界。
简而言之：每个用户使用一对 API 密钥。 一种用于客户端身份验证，一种用于参数签名。
I've found this article eye-opening.
In short: use a pair of API keys per user. One is for client authentication, one for parameters signing.