API设计：HTTP基本身份验证与API令牌

Question

我目前正在为Web应用程序的公共Web API前面创建一个身份验证系统。鉴于每个用户帐户都有一个API密钥，并且每个请求都必须经过身份验证，我有两种选择：

1. 使用HTTP基本身份验证like GitHub does。

   请求必须发送到URL

   http://api.example.com/resource/id
   with basic authentication
   username: token
   password: the api key
   

2. 将API令牌作为查询字符串参数传递。

   请求必须发送到URL

   http://api.example.com/resource/id?token=api_key
   

还有第三个选项是在URI中传递令牌，但老实说我不喜欢这个解决方案。

您会采用哪种解决方案？为什么？

Answer 1

最好的选择可能是在标题中使用API​​密钥（例如“授权：令牌MY_API_KEY”）而不是作为网址参数：

优于HTTP Basic Auth：

• 更方便，因为您可以轻松过期或重新生成令牌，而不会影响用户的帐户密码。
• 如果受到攻击，则漏洞仅限于API，而不是用户的主帐户
• 每个帐户可以有多个密钥（例如，用户可以并排使用“测试”和“生产”密钥。）

与URL中的API密钥相比的优势：

• 通过防止用户无意中使用其中嵌入的凭据共享URL来提供额外的安全措施。 （此外，URL可以在诸如服务器日志之类的东西中结束）

Answer 2

很多时候我不得不考虑如何在API上验证用户/请求，并在比较更多解决方案之后，我最终使用Amazon's solution我不需要的地方，或者我不能使用OAuth。此解决方案基于签名，防止“中间人”问题，因为基本身份验证和传递简单令牌正在发送纯文本数据。是的，你可以添加ssl，但这会增加系统的复杂性......

Answer 3

我认为HTTP Basic Auth应该没问题，只是为了满足非常简单的需求。

完整（和最终）解决方案IMHO将实施 OAuth 提供商。 它并不复杂，它是一个简单的协议，为您提供了很大的灵活性。 此外，它似乎是当前的趋势，因为许多大型玩家实施它并且得到了许多图书馆的支持。

Answer 4

我更喜欢使用令牌解决方案。如果您没有拥有自己的用户名和密码的实际用户，那么您感觉就像使用Basic Auth构造而非预期。这不一定是错的，但不是那么干净，IMO。它还消除了使用自定义标头的需要，我认为它使双方的实现更容易和更清洁。我要问的下一个问题是你是应该使用双因素身份验证还是需要管理会话。