我为什么喜欢基本身份验证(2015)

我在过去几年中注意到的一个令人不安的趋势是，越来越多的API服务正在慢慢放弃对HTTP基本身份验证(又名：基本身份验证)的支持，转而支持OAuth。

这是一件坏事，因为OAuth(尽管很受欢迎)对构建API服务的人和使用它们的开发人员来说都是一个巨大的痛苦。

OAuth是复杂的、被误解的、被广泛误用的，并且缺乏通用的实现。它肯定有它的用处，但在很多情况下会让人感觉不堪重负。

另一方面，Basic Auth非常简单，非常容易理解，自20世纪90年代以来在每种语言和框架中都得到了很好的支持。

您有一个API密钥对：一个API密钥ID和一个API密钥Secret。它们中的每一个都是随机生成的字符串(通常是UUID)。

要根据API服务进行身份验证，您只需将凭据放入HTTP Authorization头中。

下面的示例显示了如何使用cURL在命令行上使用基本身份验证：

>；>；>；从请求导入GET>；>；api_key_id='；xxx'；>；>；api_key_secret='；yyy'；>；>；Resp=get('；https://api.someapi.com/v1/blah'；，AUTH=(api_key_id，api_key_secret)>；>；>；打印响应.json()

如果这还不够，下面的一些Node.js代码也说明了这一点：

Var Request=REQUIRED('；REQUEST'；)；var api_key_id='；xxx'；；var api_key_secret='；yyy'；；Request({url：'；https://api.someapi.com/v1/blah'；，AUTH：{'；USER'；：api_key_id，'；PASS'；：API_KEY_SECRET}}，function(err，resp，body){console.log(Body)；})；

所有基本身份验证允许您(在较高抽象级别)指定您的凭据。就这样。

注：是的，我知道从技术上讲，它比这个稍微复杂一些。有Base64编码，有HTTP Authorization报头格式，等等，但是为了便于讨论，我省略了这些，因为它在这个上下文中并不重要。

Basic Auth非常适合开发人员，因为它简单、直观、易于使用。

假设您正在与API服务集成，您所要做的就是创建一个apiKey对，然后开始发出请求！

如果您不小心公布了您的API密钥对，并且它被泄露了，您该怎么办？Well…。您只需创建另一个API密钥对，将其放入您的应用程序代码中，然后删除旧的！

与OAuth不同，获取访问令牌不需要任何中间步骤：您只需要API密钥。

与其花费大量时间来计算您需要授予哪些权限和范围、设置重定向URI、Web服务器以及所有这些只会使问题复杂化的废话，您只需将该死的APIkey放入HTTP Authorization头和BAM中，狗屎就行了。

因为它非常简单，所以您可以更快地完成大量工作和测试。

提供程序更改其实现。几乎每一个OAuthProvider都无数次改变了他们的实现，打破了成千上万的开发者应用程序。

用于访问您的数据的复杂工作流。OAuth2有4种不同的授权类型，每种类型都有不同的用途和用途。

每次我使用Twilio这样的服务时，都会提醒我使用BasicAuth是多么方便：能够：

通过命令行或像Runscope这样的API资源管理器轻松测试我的API请求。

Basic Auth因为“不安全”而声名狼藉，但这并不一定是真的。

有几件事可以确保您的API服务(由Basic Auth保护)尽可能安全：

始终通过https运行所有请求。如果您不使用SSL，那么无论您使用哪种身份验证协议，您都永远不会是安全的。除非您重新使用https，否则您的所有凭据都将以纯文本形式通过网络发送：这是一个可怕的想法。

为您的开发人员提供生成任意数量的API密钥对的能力。这使得开发人员可以很容易地将他们对apiKey对的使用隔离到单个应用程序或服务。

允许您的开发人员在需要时撤销API密钥访问。例如：如果开发人员意外泄露了他在Github上的API密钥，他应该能够撤销该API密钥对，从而保证它不会被其他任何人使用。

使用uuid生成随机API密钥对。这确保了API密钥对不可猜测。

此外，对于使用基本身份验证的开发人员，您应该始终记住以下几点：

安全存储您的API密钥。如果您使用的是支持Basic Auth的API服务，请确保不要将API密钥存储在您的public Github repo中。

不要使用不是在https上运行的API服务--将来肯定会有问题。

为您编写的每个应用程序使用唯一的API密钥对。这样，如果意外丢失API密钥或将其公开泄漏，您只需撤销特定的API密钥，并且只需更新依赖于该API密钥的单个代码库。从长远来看，这将使你的生活变得容易得多。

如果您正在寻找API公司正确处理API密钥的好例子，请查看AWS。

Basic Auth的另一个伟大之处在于，每个人都只使用一种实现-这意味着对于如何制作请求或服务器端组件永远不会有任何模棱两可的地方：它总是相同的。

获取API密钥ID和API密钥Secret，并将它们放入以冒号分隔的字符串中，如下所示：'；xxx：yyy'；。

然后在字符串前面加上单词'；Basic'；，这样就有：'；Basicxxx：YYY&39；。

然后对字符串的API密钥部分进行Base64编码，因此以：'；basic eH4Onl5eQ=='；结束。

最后，在发出HTTP请求时将此值设置为HTTP Authorization标头。

左边是API密钥ID，右边是API KeySecret。

然后，服务器验证这些凭据，并允许您访问或返回HTTP 401未经授权的响应。

基本身份验证没有任何含糊之处。这意味着每种编程语言都有对该标准的顶级支持，而且很容易找到将Basic Auth用作生产者和消费者的广受好评的库。

我希望在OAuth继续流行的同时，开发人员会继续最大限度地支持Basic Auth。

这不仅让我作为一名开发人员的生活变得更轻松，而且也让我的生活更愉快。

对于任何信任其开发人员的API服务来说，您真的不能通过支持基本身份验证来实现。

和…。即使对于那些不信任开发者的服务--比如Google、Facebook、Fitbit等消费者服务--支持Basic Auth仍然是个好主意。这至少使他们的用户能够务实地访问他们自己的数据，而不需要跳过OAuthhoops。

注：我意识到这是一个颇具争议性的话题。我最终改写了这篇文章的许多草稿，结果都是因为它们的范围扩大了太多而把它们扔掉了。在未来，我计划写更多的文章来讨论OAuth和Basic Auth的各种缺陷，深入探讨我的观点的更深层次的技术原因。

附注：如果你读到这里，你可能想在Twitter或GitHub上关注我，并通过RSS或下面的电子邮件订阅(我会在我发布新文章时给你发电子邮件)。