保护 API:SSL &HTTP 基本身份验证与签名 [英] Securing an API: SSL & HTTP Basic Authentication vs Signature
问题描述
在为我们的 Web 应用程序设计 API 时，我们将使用它们的子域作为用户名"并生成 API 密钥/共享密钥.首先，可以使用子域作为用户名吗?我没有看到生成另一个密钥的好处.
When designing an API for our web app, we'll use the their subdomain as the 'username' and generate an API key/shared secret. Firstly, is it ok to use the subdomain as the username? I don't see the benefit of generating another key.
不同的 API 似乎只做两件事之一:
Different APIs seem to do one of two things:
- 使用带有 SSL 的 HTTP 基本身份验证
在每个请求中，用户名设置为子域，密码设置为 API 密钥.因为我们使用的是 SSL，所以这应该是安全的，不会被欺骗.
In every request the username is set to the subdomain and the password to the API key. Since we're using SSL then this should be safe from spoofing.
值得注意的 API:Google Checkout、新鲜书、GitHub, Zendesk
Notable APIs: Google Checkout, Freshbooks, GitHub, Zendesk
- 使用共享秘密创建请求签名
通常通过对键/值对进行排序并使用带有共享密钥的 HMAC-SHA1 来生成签名来实现.然后将签名与请求一起发送并在另一端进行验证.
Normally achieved by ordering the key/value pairs and using HMAC-SHA1 with the shared secret to generate the signature. The signature is then sent with the request and verified at the other end.
值得注意的 API:Google Checkout、亚马逊 AWS
Notable APIs: Google Checkout, Amazon AWS
PS:没错，Google Checkout 两者都支持
PS: thats no mistake, Google Checkout supports both
刚刚了解到 OAuth 2 正在放弃签名以支持通过 SSL 发送用户名/密码.
Just read that OAuth 2 is dropping signatures in favour of sending a username/password via SSL.
任何人对选择什么有任何意见:SSL 与签名?
Any opinions from anyone on what to pick: SSL vs Signature?
推荐答案
根据我的研究，基于 SSL 的 HTTP 基本身份验证是完全安全的.
HTTP Basic Authentication over SSL is perfectly secure from my research.
毕竟，使用 SSL(现在严格来说是 TLS)意味着传输层是加密的，我们可以放心地假设通过它传递的任何信息都是安全的并且没有被篡改.
After all, using SSL (strictly TLS now) means the transport layer is encrypted and we can safely assume any information passed over this is secure and has not been tampered with.
因此在不生成签名的情况下传递用户名和密码就足够了.
Therefore passing the username and password without generating a signature is sufficient.
这篇关于保护 API:SSL &HTTP 基本身份验证与签名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
