🔐4. 认证，第一部分
作者：Bryan Cooksey 发布日期：2014年4月22日
我们对API的理解正在逐渐加深。我们知道客户端和服务器是谁，我们知道它们使用HTTP来互相通信，我们也知道它们使用特定的数据格式来相互理解。然而，知道如何交流还有一个重要的问题：服务器如何知道客户端是其所声称的那个身份？在本章中，我们将探讨客户端向服务器证明其身份的两种方式。
虚拟世界中的身份认证
你可能之前在一个网站上注册过账号。这个过程涉及到网站要求你提供一些个人信息，尤其是用户名和密码。这两个信息成为你的身份标识。我们称之为你的凭证（credentials）。当你再次访问该网站时，你可以通过提供这些凭证来登录。
使用用户名和密码登录是身份认证（authentication）的一个例子。当你向服务器进行身份认证时，你通过告诉服务器只有你知道的信息来证明你的身份（至少我们希望只有你知道）。一旦服务器知道了你是谁，它就可以信任你并透露你账户中的私人数据。
API使用几种技术来对客户端进行身份认证。这些被称为身份认证方案（authentication schemes）。现在让我们来看看其中两种方案。
基本身份认证
上面的登录示例是最基本的身份认证形式。事实上，它的官方名称就是基本身份认证（Basic Authentication，它的朋友们称之为“Basic Auth”）。虽然这个名字没有获得任何创意奖，但这种方案是服务器对API客户端进行身份认证的一种完全可接受的方式。
基本身份认证只需要用户名和密码。客户端将这两个凭证结合在一起形成一个单一的值1，并将其作为HTTP头部Authorization中的一部分传递给服务器。
当服务器接收到请求时，它查看Authorization头部并将其与存储的凭证进行比较。如果用户名和密码与服务器列表中的某个用户匹配，服务器将以该用户身份满足客户端的请求。如果没有匹配，服务器将返回一个特殊的状态码（401）来告知客户端认证失败并拒绝请求。
虽然基本身份认证是一种有效的身份认证方案，但使用相同的用户名和密码来访问API和管理账户的事实并不理想。这就像一个酒店将整个建筑的钥匙交给客人，而不是一个房间的钥匙。
类似地，在API中，有时客户端应该具有不同于账户所有者的权限。例如，一个企业主雇佣一个承包商代表其编写使用API的程序。将账户凭证交给承包商会使所有者面临风险，因为不诚实的承包商可能会更改密码，将企业主锁在自己的账户之外。显然，有一个替代方案会很好。
API密钥认证
API密钥认证(key authentication)是一种克服使用共享凭证弱点的技术，它要求使用唯一的密钥访问API。在这种方案中，密钥通常是一长串字母和数字，与账户所有者的登录密码不同。所有者将密钥交给客户端，就像酒店将一把钥匙交给客人一样。
当客户端使用API密钥进行身份认证时，服务器知道允许客户端访问数据，但现在可以选择限制管理功能，如更改密码或删除账户。有时，仅仅为了用户不必提供密码，就使用密钥。API密钥认证具有灵活性，可以限制控制，同时保护用户密码。
那么，API密钥放在哪里呢？有一个头部可以放吗？不幸的是，没有。与基本身份认证不同，基本身份认证是一个具有严格规则的已建立标准，API密钥是在Web早期由多个公司提出的。因此，API密钥认证有点像野西部；每个人都有自己的做法。
然而，随着时间的推移，一些常见的方法已经出现。其中一种方法是让客户端将密钥放在Authorization头部中，代替用户名和密码。另一种方法是将密钥添加到URL中（http://example.com?api_key=my_secret_key）。较少见的是将密钥隐藏在请求体中的数据旁边。无论密钥放在哪里，效果是相同的-它允许服务器对客户端进行身份认证。
第4章总结
在本章中，我们学习了客户端如何向服务器证明自己的身份，这个过程被称为身份认证。我们看了API用于进行身份认证的两种技术或方案。
我们学到的关键词是：
身份认证（Authentication）：客户端向服务器证明自己的身份的过程
凭证（Credentials）：用于证明客户端身份的秘密信息（用户名、密码等）
基本身份认证（Basic Auth）：使用编码的用户名和密码作为凭证的方案
API密钥认证（API Key Auth）：使用唯一密钥作为凭证的方案
Authorization头部（Authorization Header）：用于保存凭证的HTTP头部
接下来
在下一章中，我们将继续讨论身份认证，探讨第三种技术；这种技术正在迅速成为Web的标准。
最后更新于